From fastegal at openjdk.java.net Tue Jun 1 10:34:34 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 1 Jun 2021 10:34:34 GMT Subject: RFR: 8267094: TreeCell: cancelEvent must return correct editing location [v2] In-Reply-To: References: Message-ID: > the bug is an incorrect edit location (for tree: treeItem) in edit cancel events - expected is the location at the time the cell edit was started, actual was the location of at the time the edit was cancelled. See the report for details. > > Fixed by storing the edit location in startEdit and use that in cancelEdit. > > Added tests that failed before and passed after and tests that (accidentally :) passed before and still pass after. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: fixed memory leak introduced in previous version ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/524/files - new: https://git.openjdk.java.net/jfx/pull/524/files/ab2da1e4..ea3b705f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=524&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=524&range=00-01 Stats: 74 lines in 2 files changed: 74 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/524.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/524/head:pull/524 PR: https://git.openjdk.java.net/jfx/pull/524 From arapte at openjdk.java.net Tue Jun 1 11:11:25 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Jun 2021 11:11:25 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v3] In-Reply-To: References: Message-ID: On Sat, 29 May 2021 21:09:33 GMT, Marius Hanl wrote: >> ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ >> EDIT: Thank you, Kevin. :) >> >> This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: >> - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. >> -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) >> - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) >> - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) >> >> **-> With this, I can run all normal tests with IntelliJ** >> >> ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): >> - IntelliJ is not detecting javafx.graphic inside the shims >> - All javafx.* dependencies are not found for the system tests >> >> **-> If someone has a solution, feel free to comment :)** > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Reverted JUnit4 orderEntry > > Looks like the gradle settings did the trick. Is a specific version of IntelliJ required to test this fix, I use 2019.2 version. I always build using terminal, on my IntelliJ the build fails both before and after. .idea/gradle.xml line 28: > 26: > 27: > 28: I can see the same modules in project structure with or without this change. Is this required for build to work ? .idea/modules.xml line 28: > 26: > 27: > 28: This change should be removed from PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From johan.vos at gluonhq.com Tue Jun 1 11:27:35 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 1 Jun 2021 13:27:35 +0200 Subject: platformWidth Message-ID: Hi, com.sun.glass.ui.Screen has 3 width (and height) parameters, each with a getter: * width * visibleWidth * platformWidth The latter seems to be used only in the windows build, via screen.containsPlatformRect and screen.portionIntersectsPlatformRect I don't really understand what the goal of this platformWidth/Height is. It seems a bit artificial if this is not used on the other platforms, but I might be missing the bigger purpose of this? - Johan From kcr at openjdk.java.net Tue Jun 1 12:38:20 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 1 Jun 2021 12:38:20 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v4] In-Reply-To: <4RqUfRekXEnOOyCAOiYGTwG4mz7do5SEPgvNYDL01_E=.6eaaab7d-63df-41b7-9831-3c56af6da53b@github.com> References: <4RqUfRekXEnOOyCAOiYGTwG4mz7do5SEPgvNYDL01_E=.6eaaab7d-63df-41b7-9831-3c56af6da53b@github.com> Message-ID: On Mon, 31 May 2021 06:37:40 GMT, Ambarish Rapte wrote: >> `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. >> >> I have tried three approaches and tested with modena.css which is ~134 KB in size. >> Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, >> >> 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : >> - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms >> 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) >> - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms >> 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. >> - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms >> >> >> The time taken by `StyleManager.calculateCheckSum()` with current implementation is, >> - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms >> >> >> Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. >> However we can choose approach#2 also. >> If we choose approach#3 then bug summary should be changed accordingly. > > 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 seven additional commits since the last revision: > > - Merge branch 'master' into SM_BufferedInputStream_8239138 > - review update > - minor: format correction > - add test > - only buffer[4096], similar to NativeLibLoader.calculateCheckSum() > - BufferedInputStream + buffer[4096] > - use BufferedInputStream Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From arapte at openjdk.java.net Tue Jun 1 13:36:27 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Jun 2021 13:36:27 GMT Subject: Integrated: 8239138: StyleManager should use a BufferedInputStream In-Reply-To: References: Message-ID: On Tue, 25 May 2021 09:04:07 GMT, Ambarish Rapte wrote: > `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. > > I have tried three approaches and tested with modena.css which is ~134 KB in size. > Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, > > 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : > - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms > 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) > - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms > 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. > - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms > > > The time taken by `StyleManager.calculateCheckSum()` with current implementation is, > - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms > > > Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. > However we can choose approach#2 also. > If we choose approach#3 then bug summary should be changed accordingly. This pull request has now been integrated. Changeset: 526f990e Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/526f990ecd279618da0ce792c34d7cfd803db963 Stats: 181 lines in 4 files changed: 180 ins; 0 del; 1 mod 8239138: StyleManager should use a BufferedInputStream Reviewed-by: kcr, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From mstrauss at openjdk.java.net Tue Jun 1 13:55:20 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 1 Jun 2021 13:55:20 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v8] In-Reply-To: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> References: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> Message-ID: On Sat, 29 May 2021 12:31:33 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix tests @kleopatra Do you think this PR is good to go? ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From github.com+16880178+palexdev at openjdk.java.net Tue Jun 1 17:25:36 2021 From: github.com+16880178+palexdev at openjdk.java.net (Alessadro Parisi) Date: Tue, 1 Jun 2021 17:25:36 GMT Subject: RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed Message-ID: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> This change allows custom control to change their style dynamically When the user-agent stylesheet changes the property automatically calls `NodeHelper.reapplyCSS(Region.this);` to recompute the CSS for the node and its children. To make this work the StyleManager class must be fixed too. The line `regionUserAgentStylesheet = weakRegionUserAgentStylesheetMap.computeIfAbsent((Region)region, Region::getUserAgentStylesheet); ` is problematic because if the region is already present in the map but the user-agent stylesheet changed, the value of `regionUserAgentStylesheet` is not updated and this leads to controls having the wrong style. To fix this issue I added this check: if (((Region) region).getUserAgentStylesheet() != null && !((Region) region).getUserAgentStylesheet().equals(regionUserAgentStylesheet)) { weakRegionUserAgentStylesheetMap.put((Region) region, ((Region) region).getUserAgentStylesheet()); regionUserAgentStylesheet = ((Region) region).getUserAgentStylesheet(); } ------------- Commit messages: - Allow dynamic implementation of user-agent stylesheet Changes: https://git.openjdk.java.net/jfx/pull/525/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=525&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263095 Stats: 44 lines in 2 files changed: 24 ins; 17 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/525.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/525/head:pull/525 PR: https://git.openjdk.java.net/jfx/pull/525 From github.com+16880178+palexdev at openjdk.java.net Wed Jun 2 02:00:40 2021 From: github.com+16880178+palexdev at openjdk.java.net (Alessadro Parisi) Date: Wed, 2 Jun 2021 02:00:40 GMT Subject: RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed In-Reply-To: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> References: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> Message-ID: On Mon, 31 May 2021 13:57:22 GMT, Alessadro Parisi wrote: > This change allows custom control to change their style dynamically > When the user-agent stylesheet changes the property automatically calls `NodeHelper.reapplyCSS(Region.this);` to recompute the CSS for the node and its children. > To make this work the StyleManager class must be fixed too. > The line `regionUserAgentStylesheet = weakRegionUserAgentStylesheetMap.computeIfAbsent((Region)region, Region::getUserAgentStylesheet); > ` is problematic because if the region is already present in the map but the user-agent stylesheet changed, the value of `regionUserAgentStylesheet` is not updated and this leads to controls having the wrong style. > To fix this issue I added this check: > > if (((Region) region).getUserAgentStylesheet() != null && !((Region) region).getUserAgentStylesheet().equals(regionUserAgentStylesheet)) { > weakRegionUserAgentStylesheetMap.put((Region) region, ((Region) region).getUserAgentStylesheet()); > regionUserAgentStylesheet = ((Region) region).getUserAgentStylesheet(); > } @nlisker Hello, sorry I'm new to contributions, my OCA has been approved recently I have read the CSR FAQ but I don't understand where I should go to create it ------------- PR: https://git.openjdk.java.net/jfx/pull/525 From nlisker at openjdk.java.net Wed Jun 2 03:05:33 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 2 Jun 2021 03:05:33 GMT Subject: RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed In-Reply-To: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> References: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> Message-ID: <2hBaV0Xk4R3YHPlLrhrJ0_VY0SuFpbtePyjO35R_YCU=.6e888dc4-f9f1-44f4-bb52-49abec06f8a9@github.com> On Mon, 31 May 2021 13:57:22 GMT, Alessadro Parisi wrote: > This change allows custom control to change their style dynamically > When the user-agent stylesheet changes the property automatically calls `NodeHelper.reapplyCSS(Region.this);` to recompute the CSS for the node and its children. > To make this work the StyleManager class must be fixed too. > The line `regionUserAgentStylesheet = weakRegionUserAgentStylesheetMap.computeIfAbsent((Region)region, Region::getUserAgentStylesheet); > ` is problematic because if the region is already present in the map but the user-agent stylesheet changed, the value of `regionUserAgentStylesheet` is not updated and this leads to controls having the wrong style. > To fix this issue I added this check: > > if (((Region) region).getUserAgentStylesheet() != null && !((Region) region).getUserAgentStylesheet().equals(regionUserAgentStylesheet)) { > weakRegionUserAgentStylesheetMap.put((Region) region, ((Region) region).getUserAgentStylesheet()); > regionUserAgentStylesheet = ((Region) region).getUserAgentStylesheet(); > } Don't worry about the CSR for now, someone will create it when the review is near completion. However, since this is an enhancement, you should discuss it first in the mailing list as explained in the README file of the repo. ------------- PR: https://git.openjdk.java.net/jfx/pull/525 From github.com+66004280+maran23 at openjdk.java.net Wed Jun 2 07:11:54 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 2 Jun 2021 07:11:54 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: > ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ > EDIT: Thank you, Kevin. :) > > This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: > - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. > -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) > - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) > - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) > > **-> With this, I can run all normal tests with IntelliJ** > > ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): > - IntelliJ is not detecting javafx.graphic inside the shims > - All javafx.* dependencies are not found for the system tests > > **-> If someone has a solution, feel free to comment :)** Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Reverted whitespace made by IntelliJ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/506/files - new: https://git.openjdk.java.net/jfx/pull/506/files/e6963285..591bdacf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=506&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=506&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/506.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/506/head:pull/506 PR: https://git.openjdk.java.net/jfx/pull/506 From github.com+66004280+maran23 at openjdk.java.net Wed Jun 2 07:11:55 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 2 Jun 2021 07:11:55 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 11:08:26 GMT, Ambarish Rapte wrote: > Is a specific version of IntelliJ required to test this fix, I use 2019.2 version. I always build using terminal, on my IntelliJ the build fails both before and after. ### I'm using the newest version (Community edition, 2021.1.2). Executing `gradle` via the IntelliJ build-in terminal works for me: ![image](https://user-images.githubusercontent.com/66004280/120437105-090cdc00-c380-11eb-9c8b-0b692a567dae.png) Executing `gradle sdk` via 'IntelliJ Gradle' works for me: ![image](https://user-images.githubusercontent.com/66004280/120437762-c5ff3880-c380-11eb-8b01-83f1bc034029.png) And running normal unit tests works for me as well: ![image](https://user-images.githubusercontent.com/66004280/120438189-59386e00-c381-11eb-9243-9ab25aa263bf.png) Any chance you can test it with the newest version? > .idea/gradle.xml line 28: > >> 26: >> 27: >> 28: > > I can see the same modules in project structure with or without this change. Is this required for build to work ? This enabled the IntelliJ gradle plugin for me, so e.g. the support for doing the tasks in the ide. And with it, I was able to run normal unit tests from the ide (see also screenshot(s) below) ![image](https://user-images.githubusercontent.com/66004280/120438497-c0562280-c381-11eb-8bda-f1d17d8b30ac.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From arapte at openjdk.java.net Wed Jun 2 09:34:32 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 2 Jun 2021 09:34:32 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v8] In-Reply-To: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> References: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> Message-ID: On Sat, 29 May 2021 12:31:33 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix tests I tested several scenarios with TreeTableView and ListView. It is behaving as expected. I still need to review the code changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From fastegal at openjdk.java.net Wed Jun 2 09:57:47 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 2 Jun 2021 09:57:47 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v8] In-Reply-To: References: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> Message-ID: <23J5FvqphfjBcuZf4lsa9eB35dc4A_nHUF5nqkrz12A=.3a2242cf-54b3-40a8-8fc1-9e713e4f8aa5@github.com> On Tue, 1 Jun 2021 13:52:31 GMT, Michael Strau? wrote: > > > @kleopatra Do you think this PR is good to go? Didn't look close enough to judge that - just interested in the unusual (to put it mildly ;) implementation of selectedItems. Don't intend to go for a review, sry that I didn't make that clear from the start. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From r.lichtenberger at gmail.com Wed Jun 2 10:43:10 2021 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Wed, 2 Jun 2021 12:43:10 +0200 Subject: Cannot load jpeg images on Fedora 34 Message-ID: Using this testapplication: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.image.Image; import javafx.scene.image.ImageView; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class ImageTest extends Application { ??? @Override ??? public void start(Stage stage) throws Exception { ??? ??? Image img = new Image("https://www.synedra.com/_thumbnails_/606_11_robert_lichtenberger.jpg"); ??? ??? if (img.isError()) { ??? ??? ??? System.out.println(img.getException()); ??? ??? } ??? ??? ImageView imgView = new ImageView(img); ??? ??? StackPane stack = new StackPane(); ??? ??? stack.getChildren().add(imgView); ??? ??? Scene scene = new Scene(stack, 640, 480); ??? ??? stage.setScene(scene); ??? ??? stage.show(); ??? } ??? public static void main(String[] args) { ??? ??? launch(); ??? } } And running it with regular JavaFX-16 (downloaded from gluonhq), I get: [rli at rlimbus javafx]$ java --module-path /home/rli/Downloads/javafx-sdk-16/lib --add-modules javafx.controls,javafx.fxml ImageTest java.io.IOException: Wrong JPEG library version: library is 62, caller expects 90 and the image will not be loaded. The same happens for all other regular JavaFX SDKs (even tried LTS 11.0.12). When I compile JavaFX myself, it works as expected: [rli at rlimbus javafx]$ java --module-path /home/rli/PWEs/jfx/build/sdk/lib --add-modules javafx.controls,javafx.fxml ImageTest The problem seems to be related to the OS version, because on Fedora 33 everything works fine. Other applications are also impacted, e.g. AsciidocFX cannot show previews of jpeg images on Fedora 34. Any hints / ideas appreciated. Robert From arapte at openjdk.java.net Wed Jun 2 12:15:36 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 2 Jun 2021 12:15:36 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v19] In-Reply-To: <_2nurMPXTT-4aUq2nhlowFkQHetpemAEbD-ESFdhY3A=.50f97ff2-b0d7-4123-9d64-9175e9617e71@github.com> References: <_2nurMPXTT-4aUq2nhlowFkQHetpemAEbD-ESFdhY3A=.50f97ff2-b0d7-4123-9d64-9175e9617e71@github.com> Message-ID: On Sun, 30 May 2021 05:05:12 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Updated image and docs Provided few more suggestions for class doc. Also I noticed that we are not providing a position property for both Point and Spot light. However as of now it seems not required. Should we consider to add it in future ? modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 44: > 42: * A {@code SpotLight} is a {@code PointLight} that radiates light in a cone in a specific direction. The direction is > 43: * defined by the {@link #directionProperty() direction} vector property relative to the rotation of the > 44: * {@code SpotLight} that is set with the rotation transforms of the node. For example, if the direction vector is may be rephrase as -> `The direction is defined by the {@link #directionProperty() direction} vector property of the light. The direction can be rotated by setting a rotation transform on the {@code SpotLight}.` modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 145: > 143: * The angle of the spotlight's inner cone (as shown in the class doc image). A point whose angle to the light's > 144: * origin is less than this angle is not attenuated by the spotlight factor ({@code spot = 1}). At larger angles, > 145: * the light intensity starts to drop. The intensity inside inner cone is not attenuated, so the drop in intensity happens only in outer cone. Then the statement `At larger angles, the light intensity starts to drop.` may not be needed here. The drop should be described only with outer angle. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 173: > 171: > 172: /** > 173: * The angle of the spotlight's outer cone (as shown in the class doc image). A point whose angle to the light's Let's include the unit **degrees** -> `The angle of the spotlight's outer cone, in degrees (as ...` similar change for innerAngle. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 175: > 173: * The angle of the spotlight's outer cone (as shown in the class doc image). A point whose angle to the light's > 174: * origin is greater than this angle receive no light ({@code spot = 0}). At smaller angles, the light intensity > 175: * starts to increase. 1. minor typo: receive -> receives. 2. At smaller angles, the light intensity starts to increase -> I think the statement should be rephrased similar to falloff statement. May be re-use a statement from falloff doc, with minor changes, `A point whose angle to the light's position is greater than the inner angle but less than the outer angle receives partial intensity governed by the falloff factor` modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 203: > 201: > 202: /** > 203: * The intensity falloff factor of the spotlight's outer cone. A point whose angle to the light's origin is greater During this doc the position of light is referred using two different words `origin` and `source` ( Line 58, in class doc ). I would recommend to use word `position` uniformly. modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main2Lights.frag line 76: > 74: varying vec4 lightTangentSpaceDirections[3]; > 75: > 76: // Because pow(0, 0) is undefined (https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-pow), This is hlsl reference link, may be we should find a similar link for glsl or remove this reference. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Wed Jun 2 14:32:29 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 2 Jun 2021 14:32:29 GMT Subject: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:18:24 GMT, Alexander Matveev wrote: > JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/directsound/gstdirectsoundnotify.cpp line 57: > 55: bool bResult = false; > 56: > 57: if (FAILED(CoInitialize(NULL))) { As per the [`CoUninitialize` doc](https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize#remarks), `CoUninitialize` should also be called if `CoInitialize` returns S_FALSE. Can you please check. ------------- PR: https://git.openjdk.java.net/jfx/pull/521 From kevin.rushforth at oracle.com Wed Jun 2 21:06:42 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 2 Jun 2021 14:06:42 -0700 Subject: Tons of gradle warnings In-Reply-To: <20210528124538.Horde.bdz_ZlUQh3hgPrpWJz6dog1@webmail.df.eu> References: <20210528124538.Horde.bdz_ZlUQh3hgPrpWJz6dog1@webmail.df.eu> Message-ID: <5e317815-f375-ed66-21b7-d08c77f9ad55@oracle.com> Yeah, both Ambarish and I noticed the odd formatting and the warnings as well. I'll file follow-on issues for the warnings. -- Kevin On 5/28/2021 3:45 AM, Jeanette Winzenburg wrote: > > Hi Experts, > > yesterday gradle auto-updated to version 7 (?), since then I get many > warnings like: > > Execution optimizations have been disabled for task > ':graphics:copyClassFilesWin' to ensure correctness due to the > following reasons: > ? - Gradle detected a problem with the following location: > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.graphics\build\module-classes'. > Reason: Task ':graphics:copyClassFilesWin' uses this output of task > ':graphics:buildModuleWin' without declaring an explicit or implicit > dependency. This can lead to incorrect results being produced, > depending on what order the tasks are executed. > > Looks like it is safe to ignore them, just want to be sure :) > > Another very minor issue: since the same time, there's an issue with > terminal output in that I see the "executing" messages written out like: > > <=======------> 58% EXECUTING [54s]> > :graphics:copyClassFilesWin<=======------> 58% EXECUTING > [55s]<=======------> 58% EXECUTING [56s]<=======------> 58% EXECUTING > [57s]<=======------> 58% EXECUTING [58s]<=======------> 58% EXECUTING > [59s]<=======------> 58% EXECUTING [1m 0s]<=======------> 58% > EXECUTING [1m 1s]<=======------> and-so-on-to-the-end > > Can live with it, but any idea how to get rid off them? > > -- Jeanette > From kcr at openjdk.java.net Wed Jun 2 21:58:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Jun 2021 21:58:34 GMT Subject: RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed In-Reply-To: <2hBaV0Xk4R3YHPlLrhrJ0_VY0SuFpbtePyjO35R_YCU=.6e888dc4-f9f1-44f4-bb52-49abec06f8a9@github.com> References: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> <2hBaV0Xk4R3YHPlLrhrJ0_VY0SuFpbtePyjO35R_YCU=.6e888dc4-f9f1-44f4-bb52-49abec06f8a9@github.com> Message-ID: On Wed, 2 Jun 2021 03:02:26 GMT, Nir Lisker wrote: > Don't worry about the CSR for now, someone will create it when the review is near completion. However, since this is an enhancement, you should discuss it first in the mailing list as explained in the README file of the repo. Exactly. The discussion should happen on openjfx-dev at openjdk.java.net. Specifically, the place to start is with the newly proposed API and behavioral changes. This is what is important to get general agreement / buy-in on. Any newly proposed public methods need to be clearly documented and justified. Also, there needs to be a discussion as to whether this change in behavior should be done unconditionally, which the current PR proposes to do, or whether this behavior should be "opt in". Since we haven't yet had the discussion, this PR is not yet ready to be reviewed. It can be used for illustrative purposes as long as the focus is on the public API and behavioral changes and not (yet anyway) on the code. ------------- PR: https://git.openjdk.java.net/jfx/pull/525 From almatvee at openjdk.java.net Wed Jun 2 22:00:43 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 2 Jun 2021 22:00:43 GMT Subject: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 14:29:41 GMT, Ambarish Rapte wrote: >> JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/directsound/gstdirectsoundnotify.cpp line 57: > >> 55: bool bResult = false; >> 56: >> 57: if (FAILED(CoInitialize(NULL))) { > > As per the [`CoUninitialize` doc](https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize#remarks), `CoUninitialize` should also be called if `CoInitialize` returns S_FALSE. > Can you please check. It will be called. S_FALSE is not a failure and defined as 1. FAILED macro returns true if error code < 0. ------------- PR: https://git.openjdk.java.net/jfx/pull/521 From arapte at openjdk.java.net Thu Jun 3 02:22:37 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 3 Jun 2021 02:22:37 GMT Subject: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:18:24 GMT, Alexander Matveev wrote: > JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/521 From jvos at openjdk.java.net Thu Jun 3 11:32:47 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 3 Jun 2021 11:32:47 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms Message-ID: Add EGL cursor implementation (Java + native) and the link to low-level drivers. Fix for JDK-8268120 ------------- Commit messages: - fix whitespace error - Add EGL cursor implementation (Java + native) and the link to low-level Changes: https://git.openjdk.java.net/jfx/pull/527/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=527&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268120 Stats: 150 lines in 4 files changed: 149 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/527.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/527/head:pull/527 PR: https://git.openjdk.java.net/jfx/pull/527 From jvos at openjdk.java.net Thu Jun 3 11:41:02 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 3 Jun 2021 11:41:02 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v2] In-Reply-To: References: Message-ID: > Add EGL cursor implementation (Java + native) and the link to low-level drivers. > Fix for JDK-8268120 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: fix typo after last-minute inversion (make hwcursor default instead of swcursor) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/527/files - new: https://git.openjdk.java.net/jfx/pull/527/files/a6dfe628..2a86c4a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=527&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=527&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/527.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/527/head:pull/527 PR: https://git.openjdk.java.net/jfx/pull/527 From nlisker at openjdk.java.net Thu Jun 3 14:50:41 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 3 Jun 2021 14:50:41 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v19] In-Reply-To: References: <_2nurMPXTT-4aUq2nhlowFkQHetpemAEbD-ESFdhY3A=.50f97ff2-b0d7-4123-9d64-9175e9617e71@github.com> Message-ID: On Wed, 2 Jun 2021 12:12:39 GMT, Ambarish Rapte wrote: > Also I noticed that we are not providing a position property for both Point and Spot light. However as of now it seems not required. Should we consider to add it in future ? The translate/layout transforms set the position. The direction is different because the rotation transforms are not easy to work with and users will want something like a "loot at" function. That was a big point of discussion in the review process. > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 145: > >> 143: * The angle of the spotlight's inner cone (as shown in the class doc image). A point whose angle to the light's >> 144: * origin is less than this angle is not attenuated by the spotlight factor ({@code spot = 1}). At larger angles, >> 145: * the light intensity starts to drop. > > The intensity inside inner cone is not attenuated, so the drop in intensity happens only in outer cone. Then the statement `At larger angles, the light intensity starts to drop.` may not be needed here. The drop should be described only with outer angle. I would say that the outer cone is defined by both angles (from inner to outer). When I write about an angle, I would like to say what happens both before and after it. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Thu Jun 3 15:54:08 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 3 Jun 2021 15:54:08 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v20] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Updated docs per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/49171039..0bdb7cdd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=18-19 Stats: 17 lines in 2 files changed: 1 ins; 0 del; 16 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 michaelstrau2 at gmail.com Thu Jun 3 19:41:41 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 3 Jun 2021 21:41:41 +0200 Subject: Inverse bidirectional binding for Boolean properties Message-ID: Here's a simple thing I've come across frequently: Let's say you want to bidirectionally bind a CheckBox to a boolean property in a backend class (or any class that contains some kind of business logic). That's very easy, except if the backend property is worded in the "negative" (i.e. the frontend and backend values should be bound such that if one is true, the other is false). Since this is a very common scenario, I think it should be supported out-of-the-box in JavaFX by an addition to the `javafx.beans.binding.Bindings` class: public static void bindInverseBidirectional( Property property1, Property property2); The semantics for any two bound properties should be as follows: 1. If one property is `true`, the other property is `false`. 2. If one property is `null`, the other property is also `null`. Any thoughts? From tobias.oelgarte at gmail.com Thu Jun 3 20:32:50 2021 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Thu, 3 Jun 2021 22:32:50 +0200 Subject: Inverse bidirectional binding for Boolean properties In-Reply-To: References: Message-ID: <5235336d-2b0f-8926-6e8c-9e8a81cc5541@gmail.com> On 03.06.21 21:41, Michael Strau? wrote: > Here's a simple thing I've come across frequently: > > Let's say you want to bidirectionally bind a CheckBox to a boolean > property in a backend class (or any class that contains some kind of > business logic). > > That's very easy, except if the backend property is worded in the > "negative" (i.e. the frontend and backend values should be bound such > that if one is true, the other is false). > > Since this is a very common scenario, I think it should be supported > out-of-the-box in JavaFX by an addition to the > `javafx.beans.binding.Bindings` class: > > public static void bindInverseBidirectional( > Property property1, > Property property2); > > The semantics for any two bound properties should be as follows: > 1. If one property is `true`, the other property is `false`. > 2. If one property is `null`, the other property is also `null`. > > Any thoughts? I had a similar need to create a bidirectional binding that could additionally convert between two types. I came up with an utility class that provides the following method: ??? public static void bindBidirectional( ??????????? Property a, ??????????? Property b, ??????????? Function convertTo, ??????????? Function convertFrom); See https://pastebin.com/uxjp30VH In your case one could simply write: ??? bindBidirectional(a, b, a -> a == null ? null : !b, b -> b == null ? null : !a); or even simpler without null handling: ??? bindBidirectional(a, b, a -> !b, b -> !a); From hjohn at xs4all.nl Thu Jun 3 21:38:12 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 3 Jun 2021 23:38:12 +0200 Subject: platformWidth In-Reply-To: References: Message-ID: Perhaps an example will help from my machine. I'm running on a 4k screen at 150% scaling. These are the values: outputScaleX = 1.5 outputScaleY = 1.5 platformScaleX = 1.5 platformScaleY = 1.5 width = 2560 height = 1440 visibleWidth = 2560 visibleHeight = 1400 platformWidth = 3840 platformHeight = 2160 So it seems that platform values report the actual resolution of the Screen / Monitor. Probably they're what is being reported by Windows and stored there by JavaFX to derive the actual width/height it should use while taking scaling into account. You didn't ask about the difference between visibleHeight and height. But just incase, the visibleHeight is 40 pixels smaller than height, as this space is taken up by the task bar. --John On 01/06/2021 13:27, Johan Vos wrote: > Hi, > > com.sun.glass.ui.Screen has 3 width (and height) parameters, each with a > getter: > * width > * visibleWidth > * platformWidth > > The latter seems to be used only in the windows build, > via screen.containsPlatformRect and screen.portionIntersectsPlatformRect > > I don't really understand what the goal of this platformWidth/Height is. It > seems a bit artificial if this is not used on the other platforms, but I > might be missing the bigger purpose of this? > > - Johan > From almatvee at openjdk.java.net Thu Jun 3 21:51:01 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 3 Jun 2021 21:51:01 GMT Subject: Integrated: 8267819: CoInitialize/CoUninitialize should be called on same thread In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:18:24 GMT, Alexander Matveev wrote: > JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. This pull request has now been integrated. Changeset: 47700d8e Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/47700d8ef0175d4b457bb658371d2da4ec0a8181 Stats: 22 lines in 2 files changed: 10 ins; 9 del; 3 mod 8267819: CoInitialize/CoUninitialize should be called on same thread Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/521 From kevin.rushforth at oracle.com Thu Jun 3 22:03:18 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 Jun 2021 15:03:18 -0700 Subject: platformWidth In-Reply-To: References: Message-ID: <11e660c9-9ab8-21b4-03c8-26885d5b3a9c@oracle.com> The platformWidth / platformHeight can also be different from the width / height on Linux with Hi-DPI scaling, at least in theory, since the Screen constructor is called using different parameters for the platform values. Mac is different because of how the retina scaling is handled on macOS -- even on a retina display, platformWidth/platformHeight == width/height and platformScale{X,Y} == 1. -- Kevin On 6/3/2021 2:38 PM, John Hendrikx wrote: > Perhaps an example will help from my machine. > > I'm running on a 4k screen at 150% scaling. These are the values: > > outputScaleX = 1.5 > outputScaleY = 1.5 > platformScaleX = 1.5 > platformScaleY = 1.5 > width = 2560 > height = 1440 > visibleWidth = 2560 > visibleHeight = 1400 > platformWidth = 3840 > platformHeight = 2160 > > So it seems that platform values report the actual resolution of the > Screen / Monitor. Probably they're what is being reported by Windows > and stored there by JavaFX to derive the actual width/height it should > use while taking scaling into account. > > You didn't ask about the difference between visibleHeight and height. > But just incase, the visibleHeight is 40 pixels smaller than height, > as this space is taken up by the task bar. > > --John > > > On 01/06/2021 13:27, Johan Vos wrote: >> Hi, >> >> com.sun.glass.ui.Screen has 3 width (and height) parameters, each with a >> getter: >> * width >> * visibleWidth >> * platformWidth >> >> The latter seems to be used only in the windows build, >> via screen.containsPlatformRect and screen.portionIntersectsPlatformRect >> >> I don't really understand what the goal of this platformWidth/Height >> is. It >> seems a bit artificial if this is not used on the other platforms, but I >> might be missing the bigger purpose of this? >> >> - Johan >> From kcr at openjdk.java.net Thu Jun 3 22:07:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Jun 2021 22:07:54 GMT Subject: RFR: 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 09:37:18 GMT, Alexander Matveev wrote: > With recent GStreamer update gstmpegaudioparse no longer provides audio buffers with valid timestamps. This issue is only reproducible with MP3 HTTP Live Stream and was noticed on Linux. I think Windows audio decoder handles such case better and thus MP3 HLS works fine. I did not figure out why it behaves this way and for now fix is reverting gstmpegaudioparse changeset which caused it. Follow up issue will be filed to investigate why javasource and/or hlsprogressbuffer no longer compatible with gstmpegaudioparse and gstmpegaudioparse cannot figure out correct PTS. Also, fixed potential null pointer reference for buffers with invalid PTS. Looks good. I did a build / test on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/526 From michaelstrau2 at gmail.com Thu Jun 3 23:26:29 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 4 Jun 2021 01:26:29 +0200 Subject: Inverse bidirectional binding for Boolean properties In-Reply-To: <5235336d-2b0f-8926-6e8c-9e8a81cc5541@gmail.com> References: <5235336d-2b0f-8926-6e8c-9e8a81cc5541@gmail.com> Message-ID: That also looks very useful, although having a converter interface would be more similar to the existing `javafx.util.StringConverter` class and its corresponding `BidirectionalBinding` implementations. Such an interface could look like this: public interface ValueConverter { T convert(S value); S convertBack(T value); } The public `Bindings` API would then be: public static void bindBidirectional( Property property1, Property property2, ValueConverter converter) For ease of use, some predefined converters could be added to a convenience class `ValueConverters`. Here's how this could be used in code: var p1 = new SimpleBooleanProperty(); var p2 = new SimpleBooleanProperty(); Bindings.bindBidirectional(p1, p2, ValueConverters.not()); var p3 = new SimpleDoubleProperty(); var p4 = new SimpleDoubleProperty(); Bindings.bindBidirectional(p3, p4, ValueConverters.add(5)); Am Do., 3. Juni 2021 um 22:33 Uhr schrieb Tobias Oelgarte : > > On 03.06.21 21:41, Michael Strau? wrote: > > Here's a simple thing I've come across frequently: > > > > Let's say you want to bidirectionally bind a CheckBox to a boolean > > property in a backend class (or any class that contains some kind of > > business logic). > > > > That's very easy, except if the backend property is worded in the > > "negative" (i.e. the frontend and backend values should be bound such > > that if one is true, the other is false). > > > > Since this is a very common scenario, I think it should be supported > > out-of-the-box in JavaFX by an addition to the > > `javafx.beans.binding.Bindings` class: > > > > public static void bindInverseBidirectional( > > Property property1, > > Property property2); > > > > The semantics for any two bound properties should be as follows: > > 1. If one property is `true`, the other property is `false`. > > 2. If one property is `null`, the other property is also `null`. > > > > Any thoughts? > > I had a similar need to create a bidirectional binding that could > additionally convert between two types. I came up with an utility class > that provides the following method: > > public static void bindBidirectional( > Property a, > Property b, > Function convertTo, > Function convertFrom); > > See https://pastebin.com/uxjp30VH > > In your case one could simply write: > > bindBidirectional(a, b, a -> a == null ? null : !b, b -> b == null > ? null : !a); > > or even simpler without null handling: > > bindBidirectional(a, b, a -> !b, b -> !a); > From kcr at openjdk.java.net Thu Jun 3 23:42:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Jun 2021 23:42:19 GMT Subject: RFR: 8264139: Suppress removal warnings for Security Manager methods Message-ID: This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. There are four commits: 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. 2. 9698e87 : Same as above for the tests. 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. modules/javafx.web/src/android/java/com/sun/webkit/Timer.java modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java ------------- Commit messages: - Narrow the scope of @SuppressWarnings("removal") annotation - Remove unused security manager imports - Suppress removal warnings for Security Manager methods in tests - 8264139: Suppress removal warnings for Security Manager methods Changes: https://git.openjdk.java.net/jfx/pull/528/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=528&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264139 Stats: 586 lines in 194 files changed: 464 ins; 3 del; 119 mod Patch: https://git.openjdk.java.net/jfx/pull/528.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/528/head:pull/528 PR: https://git.openjdk.java.net/jfx/pull/528 From mstrauss at openjdk.java.net Fri Jun 4 05:04:17 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 4 Jun 2021 05:04:17 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: > This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. > > The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into fixes/JDK-8267059 - Use cmd /s option when building on Windows ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/499/files - new: https://git.openjdk.java.net/jfx/pull/499/files/b11d0b1e..111b23d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=499&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=499&range=00-01 Stats: 1534 lines in 75 files changed: 976 ins; 254 del; 304 mod Patch: https://git.openjdk.java.net/jfx/pull/499.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/499/head:pull/499 PR: https://git.openjdk.java.net/jfx/pull/499 From mstrauss at openjdk.java.net Fri Jun 4 05:14:00 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 4 Jun 2021 05:14:00 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:04:17 GMT, Michael Strau? wrote: >> This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. >> >> The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into fixes/JDK-8267059 > - Use cmd /s option when building on Windows I've tested the `:clean` and `:apps` tasks on Windows, Linux, and macOS: On Windows 10 20H2, `:clean` and `:apps` fail before and succeed after the fix. On macOS 10.15.1, `:clean` and `:apps` succeed before and after the fix. On Ubuntu 20.04, `:clean` succeeds before and after the fix. The `:apps` task fails before and after the fix: [javac] Compiling 143 source files to /home/ubuntu/jfx/apps/samples/3DViewer/build/classes [javac] error: invalid flag: @/home/ubuntu/jfx/build/compile.args [javac] Usage: javac [javac] use --help for a list of possible options ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From johan.vos at gluonhq.com Fri Jun 4 07:43:41 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 4 Jun 2021 09:43:41 +0200 Subject: platformWidth In-Reply-To: <11e660c9-9ab8-21b4-03c8-26885d5b3a9c@oracle.com> References: <11e660c9-9ab8-21b4-03c8-26885d5b3a9c@oracle.com> Message-ID: Hi John, Kevin, Thanks for the replies. The relation between actual resolution of the Screen and the JavaFX rendering is kept in the renderScale and outputScale, and does not come from platformWidth. The value of platformWidth is never used apart from the 2 methods I pointed out above. The first reason I started this is because it is already complex with a viewScale, platformScale, renderScale and outputScale, and I don't see where the platformWidth fits in this picture -- especially since the latter is not used at all on linux/mac. The second reason is that I am looking into a more generic way to deal with output dimensions that don't match the dimensions of the JavaFX main texture. We currently support linear scaling with those scale factors, but for some local work, I added rotation as well (e.g. to allow rendering on a portrait screen when the source is in landscape coordinates). This works surprisingly well by only manipulating the transformation in ES2SwapChain.prepare (adding the rotation there). I am doing that now conditionally, based on (yet even more) system properties, but it might make sense to add an "orientation" parameter to the Screen. But before adding something, I first try to see if there is something unused that can be removed -- hence my question about platformWidth/Height. - Johan On Fri, Jun 4, 2021 at 12:04 AM Kevin Rushforth wrote: > The platformWidth / platformHeight can also be different from the width > / height on Linux with Hi-DPI scaling, at least in theory, since the > Screen constructor is called using different parameters for the platform > values. Mac is different because of how the retina scaling is handled on > macOS -- even on a retina display, platformWidth/platformHeight == > width/height and platformScale{X,Y} == 1. > > -- Kevin > > > On 6/3/2021 2:38 PM, John Hendrikx wrote: > > Perhaps an example will help from my machine. > > > > I'm running on a 4k screen at 150% scaling. These are the values: > > > > outputScaleX = 1.5 > > outputScaleY = 1.5 > > platformScaleX = 1.5 > > platformScaleY = 1.5 > > width = 2560 > > height = 1440 > > visibleWidth = 2560 > > visibleHeight = 1400 > > platformWidth = 3840 > > platformHeight = 2160 > > > > So it seems that platform values report the actual resolution of the > > Screen / Monitor. Probably they're what is being reported by Windows > > and stored there by JavaFX to derive the actual width/height it should > > use while taking scaling into account. > > > > You didn't ask about the difference between visibleHeight and height. > > But just incase, the visibleHeight is 40 pixels smaller than height, > > as this space is taken up by the task bar. > > > > --John > > > > > > On 01/06/2021 13:27, Johan Vos wrote: > >> Hi, > >> > >> com.sun.glass.ui.Screen has 3 width (and height) parameters, each with a > >> getter: > >> * width > >> * visibleWidth > >> * platformWidth > >> > >> The latter seems to be used only in the windows build, > >> via screen.containsPlatformRect and screen.portionIntersectsPlatformRect > >> > >> I don't really understand what the goal of this platformWidth/Height > >> is. It > >> seems a bit artificial if this is not used on the other platforms, but I > >> might be missing the bigger purpose of this? > >> > >> - Johan > >> > > From arapte at openjdk.java.net Fri Jun 4 08:32:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 4 Jun 2021 08:32:56 GMT Subject: RFR: 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 09:37:18 GMT, Alexander Matveev wrote: > With recent GStreamer update gstmpegaudioparse no longer provides audio buffers with valid timestamps. This issue is only reproducible with MP3 HTTP Live Stream and was noticed on Linux. I think Windows audio decoder handles such case better and thus MP3 HLS works fine. I did not figure out why it behaves this way and for now fix is reverting gstmpegaudioparse changeset which caused it. Follow up issue will be filed to investigate why javasource and/or hlsprogressbuffer no longer compatible with gstmpegaudioparse and gstmpegaudioparse cannot figure out correct PTS. Also, fixed potential null pointer reference for buffers with invalid PTS. looks good to me, tested on windows and Linux. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/526 From ajoseph at openjdk.java.net Fri Jun 4 10:52:09 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 4 Jun 2021 10:52:09 GMT Subject: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously Message-ID: The title property is not guaranteed to be updated right after the page is loaded, but gets updated asynchronously. ------------- Commit messages: - Fix javadoc comment - Merge branch 'master' into 8267858 - 8267858: Document that title property in WebEngine gets updated asynchronously Changes: https://git.openjdk.java.net/jfx/pull/522/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=522&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267858 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/522.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/522/head:pull/522 PR: https://git.openjdk.java.net/jfx/pull/522 From jvos at openjdk.java.net Fri Jun 4 10:52:09 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 4 Jun 2021 10:52:09 GMT Subject: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously In-Reply-To: References: Message-ID: On Thu, 27 May 2021 17:25:27 GMT, Arun Joseph wrote: > The title property is not guaranteed to be updated right after the page is loaded, but gets updated asynchronously. modules/javafx.web/src/main/java/javafx/scene/web/WebEngine.java line 441: > 439: > 440: /* > 441: * The page title. This gets updated asynchronously. Is there any more information or guarantee when the update is expected to be complete, or is it truly asynchronous? I we know that this will happen between the current pulse and the next one, that might be helpful to developers (although I agree waiting for the titleProperty to be changed is the better approach). If there is no link beween the webkit thread that gets the title and the quantum renderer, it is really asynchronous and in that case tricks like waiting for a few pulses won't help either -- but it would be good to mention that so that developers don't create workarounds that might work in some cases and fail in others. ------------- PR: https://git.openjdk.java.net/jfx/pull/522 From kcr at openjdk.java.net Fri Jun 4 10:52:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 10:52:10 GMT Subject: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously In-Reply-To: References: Message-ID: On Fri, 28 May 2021 06:52:30 GMT, Johan Vos wrote: >> The title property is not guaranteed to be updated right after the page is loaded, but gets updated asynchronously. > > modules/javafx.web/src/main/java/javafx/scene/web/WebEngine.java line 441: > >> 439: >> 440: /* >> 441: * The page title. This gets updated asynchronously. > > Is there any more information or guarantee when the update is expected to be complete, or is it truly asynchronous? I we know that this will happen between the current pulse and the next one, that might be helpful to developers (although I agree waiting for the titleProperty to be changed is the better approach). > If there is no link beween the webkit thread that gets the title and the quantum renderer, it is really asynchronous and in that case tricks like waiting for a few pulses won't help either -- but it would be good to mention that so that developers don't create workarounds that might work in some cases and fail in others. I had exactly the same thought about the need to document it more clearly. Maybe something like: "This property will be updated asynchronously some time after the page is loaded. Applications should not rely on any particular timing, but should listen for changes to this property, or bind to it, to know when it has been updated." Btw, you modified an ordinary comment, not a javadoc comment. The newly added sentence needs to go on the javadoc comment, which is on the `titleProperty` method a few lines down from here. Be sure to run `gradle javadoc` and look at the generated docs. ------------- PR: https://git.openjdk.java.net/jfx/pull/522 From ajoseph at openjdk.java.net Fri Jun 4 10:52:10 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 4 Jun 2021 10:52:10 GMT Subject: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 23:53:48 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/java/javafx/scene/web/WebEngine.java line 441: >> >>> 439: >>> 440: /* >>> 441: * The page title. This gets updated asynchronously. >> >> Is there any more information or guarantee when the update is expected to be complete, or is it truly asynchronous? I we know that this will happen between the current pulse and the next one, that might be helpful to developers (although I agree waiting for the titleProperty to be changed is the better approach). >> If there is no link beween the webkit thread that gets the title and the quantum renderer, it is really asynchronous and in that case tricks like waiting for a few pulses won't help either -- but it would be good to mention that so that developers don't create workarounds that might work in some cases and fail in others. > > I had exactly the same thought about the need to document it more clearly. Maybe something like: > > "This property will be updated asynchronously some time after the page is loaded. Applications should not rely on any particular timing, but should listen for changes to this property, or bind to it, to know when it has been updated." > > Btw, you modified an ordinary comment, not a javadoc comment. The newly added sentence needs to go on the javadoc comment, which is on the `titleProperty` method a few lines down from here. Be sure to run `gradle javadoc` and look at the generated docs. I've modified the right javadoc comment now. ------------- PR: https://git.openjdk.java.net/jfx/pull/522 From jpereda at openjdk.java.net Fri Jun 4 12:04:56 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 4 Jun 2021 12:04:56 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:41:02 GMT, Johan Vos wrote: >> Add EGL cursor implementation (Java + native) and the link to low-level drivers. >> Fix for JDK-8268120 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > fix typo after last-minute inversion (make hwcursor default instead of swcursor) I've tested this PR on embedded, and with it there is a visible mouse cursor, so the issue gets fixed. I have some comments. modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLPlatform.java line 55: > 53: boolean swcursor = Boolean.getBoolean("monocle.egl.swcursor"); > 54: final NativeCursor c = useCursor ? (swcursor ? new SoftwareCursor() : new EGLCursor()) : new NullCursor(); > 55: return c; Other platforms add a logging here, with `NativePlatform::logSelectedCursor`. modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c line 164: > 162: jbyte *attrArray = (*env)->GetByteArrayElements(env, jarr, JNI_FALSE); > 163: if (attrArray == 0) { > 164: fprintf(stderr, "Fatal error getting char* from jbyteArray\n"); do you mean `getting jbyte*`? ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From alexsch at openjdk.java.net Fri Jun 4 12:28:58 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 4 Jun 2021 12:28:58 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:41:02 GMT, Johan Vos wrote: >> Add EGL cursor implementation (Java + native) and the link to low-level drivers. >> Fix for JDK-8268120 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > fix typo after last-minute inversion (make hwcursor default instead of swcursor) modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 39: > 37: > 38: // initialize the EGL system with the specified handle > 39: extern jboolean doEglInitialize(void* handle); Is it possible to declare arguments as `jlong eglDisplay` here instead of `void* handle` as it is done in other methods? As I see nEglInitialize() passes eglDisplay on the java side: https://github.com/openjdk/jfx/blob/47700d8ef0175d4b457bb658371d2da4ec0a8181/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java#L48 but it needs to convert it to a ptr in the native code: https://github.com/openjdk/jfx/blob/47700d8ef0175d4b457bb658371d2da4ec0a8181/modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c#L46 ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From kcr at openjdk.java.net Fri Jun 4 12:44:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 12:44:56 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 12:26:01 GMT, Alexander Scherbatiy wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo after last-minute inversion (make hwcursor default instead of swcursor) > > modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 39: > >> 37: >> 38: // initialize the EGL system with the specified handle >> 39: extern jboolean doEglInitialize(void* handle); > > Is it possible to declare arguments as `jlong eglDisplay` here instead of `void* handle` as it is done in other methods? > As I see nEglInitialize() passes eglDisplay on the java side: > https://github.com/openjdk/jfx/blob/47700d8ef0175d4b457bb658371d2da4ec0a8181/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java#L48 > but it needs to convert it to a ptr in the native code: > https://github.com/openjdk/jfx/blob/47700d8ef0175d4b457bb658371d2da4ec0a8181/modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c#L46 What would be the advantage of changing it? In any case, it seems unrelated to this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From alexsch at openjdk.java.net Fri Jun 4 12:57:59 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 4 Jun 2021 12:57:59 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 12:42:23 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 39: >> >>> 37: >>> 38: // initialize the EGL system with the specified handle >>> 39: extern jboolean doEglInitialize(void* handle); >> >> Is it possible to declare arguments as `jlong eglDisplay` here instead of `void* handle` as it is done in other methods? >> As I see nEglInitialize() passes eglDisplay on the java side: >> https://github.com/openjdk/jfx/blob/47700d8ef0175d4b457bb658371d2da4ec0a8181/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java#L48 >> but it needs to convert it to a ptr in the native code: >> https://github.com/openjdk/jfx/blob/47700d8ef0175d4b457bb658371d2da4ec0a8181/modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c#L46 > > What would be the advantage of changing it? In any case, it seems unrelated to this fix. All other methods doEglChooseConfig, doEglCreateWindowSurface, doEglCreateContext, doEglMakeCurrent, doEglSwapBuffers use `jlong eglDisplay`. It would be good if all functions have the same style in function argument declaration. I am wondering, was it made by purpose and `void* handle` really make sense in doEglInitialize function? If no, I can change it in a separate fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From kcr at openjdk.java.net Fri Jun 4 14:00:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 14:00:00 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:41:02 GMT, Johan Vos wrote: >> Add EGL cursor implementation (Java + native) and the link to low-level drivers. >> Fix for JDK-8268120 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > fix typo after last-minute inversion (make hwcursor default instead of swcursor) I don't have any comments aside from those Jose pointed out. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/527 From jvos at openjdk.java.net Fri Jun 4 14:00:00 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 4 Jun 2021 14:00:00 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v2] In-Reply-To: References: Message-ID: <41Bpa0ThxFemgFIIViBKhZiZIstXVOj96mFmsOyqFeA=.21641988-1b0b-4bcf-bf80-80b39b4966e0@github.com> On Fri, 4 Jun 2021 12:55:36 GMT, Alexander Scherbatiy wrote: >> What would be the advantage of changing it? In any case, it seems unrelated to this fix. > > All other methods doEglChooseConfig, doEglCreateWindowSurface, doEglCreateContext, doEglMakeCurrent, doEglSwapBuffers use `jlong eglDisplay`. It would be good if all functions have the same style in function argument declaration. > > I am wondering, was it made by purpose and `void* handle` really make sense in doEglInitialize function? > If no, I can change it in a separate fix. I agree it would be nice to have the same style in all functions, but in that case I think a `void*` is more appropriate, as that is what `EGLDisplay` is (https://www.khronos.org/registry/EGL/api/1.1/EGL/egl.h) One of the goals of `egl_ext.h` file is to stay as close as possible to the EGL specifications, avoiding the need for cast operations in the low-level implementation. Hence, it would make sense to completely get rid of the `jlong` declarations at all. It is the task of the `eglBridge.c` file to convert from Java style into EGL-style and vice versa. I am willing to change this, but then a separate issue would be more appropriate I believe. ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From jvos at openjdk.java.net Fri Jun 4 14:17:19 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 4 Jun 2021 14:17:19 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v3] In-Reply-To: References: Message-ID: > Add EGL cursor implementation (Java + native) and the link to low-level drivers. > Fix for JDK-8268120 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: address reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/527/files - new: https://git.openjdk.java.net/jfx/pull/527/files/2a86c4a4..64b89037 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=527&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=527&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/527.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/527/head:pull/527 PR: https://git.openjdk.java.net/jfx/pull/527 From kcr at openjdk.java.net Fri Jun 4 14:19:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 14:19:56 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v3] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 14:17:19 GMT, Johan Vos wrote: >> Add EGL cursor implementation (Java + native) and the link to low-level drivers. >> Fix for JDK-8268120 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > address reviewer comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From jpereda at openjdk.java.net Fri Jun 4 14:23:00 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 4 Jun 2021 14:23:00 GMT Subject: RFR: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms [v3] In-Reply-To: References: Message-ID: <3IsQqPIenETvFG7akuAXHZZ0yElPMFgdw3L-Ao3czf0=.b39a51bb-8574-4066-a395-70ce09173c07@github.com> On Fri, 4 Jun 2021 14:17:19 GMT, Johan Vos wrote: >> Add EGL cursor implementation (Java + native) and the link to low-level drivers. >> Fix for JDK-8268120 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > address reviewer comments Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From weijun at openjdk.java.net Fri Jun 4 14:52:58 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 4 Jun 2021 14:52:58 GMT Subject: RFR: 8264139: Suppress removal warnings for Security Manager methods In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 23:34:38 GMT, Kevin Rushforth wrote: > This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. > > There are four commits: > > 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. > 2. 9698e87 : Same as above for the tests. > 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. > 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. > > The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. > > I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. > > NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. > > > modules/javafx.web/src/android/java/com/sun/webkit/Timer.java > modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java > modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java > modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java > modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java > modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java > modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java All change looks good. Some personal style preferences comments. modules/javafx.fxml/src/main/java/com/sun/javafx/fxml/ModuleHelper.java line 41: > 39: > 40: static { > 41: verbose = AccessController.doPrivileged((PrivilegedAction) () -> You can merge this assignment with the declaration on line 38. Or you can keep this so the check of verbose is in the same block with its assignment. modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 43: > 41: > 42: static { > 43: @SuppressWarnings("removal") Combine assignment and declaration? modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxArch.java line 36: > 34: > 35: static { > 36: bits = AccessController.doPrivileged((PrivilegedAction) () -> { Combine? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9969: > 9967: accessible = Application.GetApplication().createAccessible(); > 9968: accessible.setEventHandler(new Accessible.EventHandler() { > 9969: @SuppressWarnings("removal") Was this "deprecation" already useless before this change? modules/javafx.web/src/main/java/com/sun/webkit/network/HTTP2Loader.java line 415: > 413: // Run the HttpClient in the page's access control context > 414: @SuppressWarnings("removal") > 415: CompletableFuture tmpResponse = AccessController.doPrivileged((PrivilegedAction>) () -> { Is "var" enough? modules/javafx.web/src/main/java/com/sun/webkit/network/NetworkContext.java line 245: > 243: private static final Permission modifyThreadPerm = new RuntimePermission("modifyThread"); > 244: > 245: @SuppressWarnings("removal") Maybe move this onto the 1st line inside the method? ------------- Marked as reviewed by weijun (no project role). PR: https://git.openjdk.java.net/jfx/pull/528 From kcr at openjdk.java.net Fri Jun 4 14:59:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 14:59:55 GMT Subject: RFR: 8264139: Suppress removal warnings for Security Manager methods In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 14:31:49 GMT, Weijun Wang wrote: >> This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. >> >> There are four commits: >> >> 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. >> 2. 9698e87 : Same as above for the tests. >> 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. >> 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. >> >> The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. >> >> I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. >> >> NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. >> >> >> modules/javafx.web/src/android/java/com/sun/webkit/Timer.java >> modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java >> modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java >> modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java >> modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java >> modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java >> modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9969: > >> 9967: accessible = Application.GetApplication().createAccessible(); >> 9968: accessible.setEventHandler(new Accessible.EventHandler() { >> 9969: @SuppressWarnings("removal") > > Was this "deprecation" already useless before this change? Yes. The code to which it applied was removed back in JDK 9, but we forgot to remove the annotation. ------------- PR: https://git.openjdk.java.net/jfx/pull/528 From kcr at openjdk.java.net Fri Jun 4 15:18:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 15:18:00 GMT Subject: RFR: 8264139: Suppress removal warnings for Security Manager methods In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 14:37:05 GMT, Weijun Wang wrote: >> This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. >> >> There are four commits: >> >> 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. >> 2. 9698e87 : Same as above for the tests. >> 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. >> 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. >> >> The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. >> >> I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. >> >> NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. >> >> >> modules/javafx.web/src/android/java/com/sun/webkit/Timer.java >> modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java >> modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java >> modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java >> modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java >> modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java >> modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java > > modules/javafx.fxml/src/main/java/com/sun/javafx/fxml/ModuleHelper.java line 41: > >> 39: >> 40: static { >> 41: verbose = AccessController.doPrivileged((PrivilegedAction) () -> > > You can merge this assignment with the declaration on line 38. Or you can keep this so the check of verbose is in the same block with its assignment. I think I'll keep this one as is to minimize changes. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Screen.java line 43: > >> 41: >> 42: static { >> 43: @SuppressWarnings("removal") > > Combine assignment and declaration? Good idea. This allows the static block to be removed. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxArch.java line 36: > >> 34: >> 35: static { >> 36: bits = AccessController.doPrivileged((PrivilegedAction) () -> { > > Combine? Good idea. This allows the static block to be removed. > modules/javafx.web/src/main/java/com/sun/webkit/network/HTTP2Loader.java line 415: > >> 413: // Run the HttpClient in the page's access control context >> 414: @SuppressWarnings("removal") >> 415: CompletableFuture tmpResponse = AccessController.doPrivileged((PrivilegedAction>) () -> { > > Is "var" enough? Yes, I'll change it. ------------- PR: https://git.openjdk.java.net/jfx/pull/528 From michaelstrau2 at gmail.com Fri Jun 4 16:39:48 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 4 Jun 2021 18:39:48 +0200 Subject: Surface the ImageLoader API Message-ID: I've been trying to add SVG support to a JavaFX application (which is the image format I'm encountering most often in app projects), but that's quite hard because the ImageLoader API is pretty much closed for extension. I'm proposing to open up the ImageLoader API to enable third-party developers to create image loaders for emerging image formats like SVG or WebP. There will need to be some minor API and behavioral changes: 1. `ImageLoader.load` requires a new parameter "pixelScale": current: ImageFrame load(int, int width, int height, boolean, boolean) new: ImageFrame load(int, int width, int height, double pixelScale, boolean, boolean) This parameter is important for vector image loaders like SVG. If an image loader is invoked with `width==0` and `height==0`, the implementation should return an image with its natural resolution. Vector image loaders need to know the requested pixel scale in order to render the image with the correct pixel density. 2. `ImageFormatDescription.Signature` must be able to accept `null` values in the byte array: current: public Signature(byte...) {...} new: public Signature(Byte...) {...} A `null` value will match any byte at the corresponding position in the image file header. This is necessary to match file headers that contain variable data, like the WebP image header: byte 0-3: 'R', 'I', 'F', 'F' byte 4-7: byte 8-11: 'W', 'E', 'B', 'P' Note that in this example, the corresponding signature description would be: { 'R', 'I', 'F', 'F', null, null, null, null, 'W', 'E', 'B', 'P' } 3. Enable file extension matching (in addition to signature matching) with the following semantics: Any valid `ImageFormatDescription` MUST contain at least one file extension, and MAY contain any number of signatures and MIME types (or none at all). When `ImageStorage` chooses an image loader for a file, it first tries to match the file by signature, and if it doesn't match, it tries to match by file extension (or, if the source is a "data" URI, it tries to match by MIME type). The reason for this is that some image formats like SVG cannot be meaningfully matched by signature; in this case, the SVG image format description would not contain a signature description and would always fall back to matching by file extension or MIME type. I'd welcome any opinions on this proposal. From kcr at openjdk.java.net Fri Jun 4 16:39:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 16:39:26 GMT Subject: RFR: 8264139: Suppress removal warnings for Security Manager methods [v2] In-Reply-To: References: Message-ID: > This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. > > There are four commits: > > 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. > 2. 9698e87 : Same as above for the tests. > 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. > 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. > > The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. > > I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. > > NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. > > > modules/javafx.web/src/android/java/com/sun/webkit/Timer.java > modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java > modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java > modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java > modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java > modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java > modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review feedback ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/528/files - new: https://git.openjdk.java.net/jfx/pull/528/files/4f87d187..84775ff5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=528&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=528&range=00-01 Stats: 42 lines in 6 files changed: 6 ins; 25 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/528.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/528/head:pull/528 PR: https://git.openjdk.java.net/jfx/pull/528 From kcr at openjdk.java.net Fri Jun 4 16:39:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 16:39:56 GMT Subject: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously In-Reply-To: References: Message-ID: <29qX8mQyAWQhnJBriXGSqct6hwE0tuoxqOZ9T1Vs14I=.720b3dea-010c-4fe4-9bdb-94895ca8d3e8@github.com> On Thu, 27 May 2021 17:25:27 GMT, Arun Joseph wrote: > The title property is not guaranteed to be updated right after the page is loaded, but gets updated asynchronously. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/522 From michaelstrau2 at gmail.com Fri Jun 4 16:45:36 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 4 Jun 2021 18:45:36 +0200 Subject: Surface the ImageLoader API In-Reply-To: References: Message-ID: I should note that these proposed changes were sufficient for me to implement an SVG image loader and a WebP image loader using third-party libraries. From jvos at openjdk.java.net Fri Jun 4 16:50:59 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 4 Jun 2021 16:50:59 GMT Subject: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously In-Reply-To: References: Message-ID: On Thu, 27 May 2021 17:25:27 GMT, Arun Joseph wrote: > The title property is not guaranteed to be updated right after the page is loaded, but gets updated asynchronously. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/522 From kcr at openjdk.java.net Fri Jun 4 18:18:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 18:18:06 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:04:17 GMT, Michael Strau? wrote: >> This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. >> >> The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into fixes/JDK-8267059 > - Use cmd /s option when building on Windows Looks fine. I tested it on Windows with / without spaces in `ANT_HOME` and it does what I would expect. I sanity tested it on Linux. > On Ubuntu 20.04 ... The :apps task fails before and after the fix Maybe something with the version of Java you are using? It runs fine my system, and the GitHub actions build is fine. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/499 From kevin.rushforth at oracle.com Fri Jun 4 20:02:39 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 Jun 2021 13:02:39 -0700 Subject: Surface the ImageLoader API In-Reply-To: References: Message-ID: Characterizing a new feature in terms of exposing internal interfaces isn't really the right way to think about it. The fact that there might be internal classes that do something similar to what you propose isn't really relevant (other than later down the road when it comes time to discuss the implementation). Rather you should start with a description of the enhancement you would like to see: additional image loading capability, in this case. Then a discussion of the API would be in order. What's really being asked for here is a feature like Java2D's Image I/O with pluggable image formats. We spent some time looking at that a few years ago. Doing this right would be a very large effort. I wouldn't be in favor of a piecemeal approach without understanding the larger picture. So I don't support this proposal as stated. -- Kevin On 6/4/2021 9:39 AM, Michael Strau? wrote: > I've been trying to add SVG support to a JavaFX application (which is > the image format I'm encountering most often in app projects), but > that's quite hard because the ImageLoader API is pretty much closed > for extension. > > I'm proposing to open up the ImageLoader API to enable third-party > developers to create image loaders for emerging image formats like SVG > or WebP. > > There will need to be some minor API and behavioral changes: > > > 1. `ImageLoader.load` requires a new parameter "pixelScale": > current: ImageFrame load(int, int width, int height, boolean, boolean) > new: ImageFrame load(int, int width, int height, double pixelScale, > boolean, boolean) > > This parameter is important for vector image loaders like SVG. If an > image loader is invoked with `width==0` and `height==0`, the > implementation should return an image with its natural resolution. > Vector image loaders need to know the requested pixel scale in order > to render the image with the correct pixel density. > > > 2. `ImageFormatDescription.Signature` must be able to accept `null` > values in the byte array: > current: public Signature(byte...) {...} > new: public Signature(Byte...) {...} > > A `null` value will match any byte at the corresponding position in > the image file header. This is necessary to match file headers that > contain variable data, like the WebP image header: > byte 0-3: 'R', 'I', 'F', 'F' > byte 4-7: > byte 8-11: 'W', 'E', 'B', 'P' > > Note that in this example, the corresponding signature description would be: > { 'R', 'I', 'F', 'F', null, null, null, null, 'W', 'E', 'B', 'P' } > > > 3. Enable file extension matching (in addition to signature matching) > with the following semantics: > Any valid `ImageFormatDescription` MUST contain at least one file > extension, and MAY contain any number of signatures and MIME types (or > none at all). When `ImageStorage` chooses an image loader for a file, > it first tries to match the file by signature, and if it doesn't > match, it tries to match by file extension (or, if the source is a > "data" URI, it tries to match by MIME type). > > The reason for this is that some image formats like SVG cannot be > meaningfully matched by signature; in this case, the SVG image format > description would not contain a signature description and would always > fall back to matching by file extension or MIME type. > > > I'd welcome any opinions on this proposal. From kcr at openjdk.java.net Fri Jun 4 20:06:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 20:06:55 GMT Subject: RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed In-Reply-To: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> References: <_FO9Rfzh0C5DItqp1cCCCHtayURl4r48IN54Yp9an4c=.ee7648e4-e70a-426e-a1d3-77462d51b544@github.com> Message-ID: On Mon, 31 May 2021 13:57:22 GMT, Alessadro Parisi wrote: > This change allows custom control to change their style dynamically > When the user-agent stylesheet changes the property automatically calls `NodeHelper.reapplyCSS(Region.this);` to recompute the CSS for the node and its children. > To make this work the StyleManager class must be fixed too. > The line `regionUserAgentStylesheet = weakRegionUserAgentStylesheetMap.computeIfAbsent((Region)region, Region::getUserAgentStylesheet); > ` is problematic because if the region is already present in the map but the user-agent stylesheet changed, the value of `regionUserAgentStylesheet` is not updated and this leads to controls having the wrong style. > To fix this issue I added this check: > > if (((Region) region).getUserAgentStylesheet() != null && !((Region) region).getUserAgentStylesheet().equals(regionUserAgentStylesheet)) { > weakRegionUserAgentStylesheetMap.put((Region) region, ((Region) region).getUserAgentStylesheet()); > regionUserAgentStylesheet = ((Region) region).getUserAgentStylesheet(); > } Moving this to `Draft` to make it clear that it isn't yet ready for review. ------------- PR: https://git.openjdk.java.net/jfx/pull/525 From kcr at openjdk.java.net Fri Jun 4 21:13:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 21:13:57 GMT Subject: RFR: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:07:12 GMT, Ambarish Rapte wrote: > Issue: > There are several issues related to Accelerator of MenuItem of a ConextMenu set on Control. > 1. Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene > 2. Accelerator is not updated correctly when the Control is removed from a Scene and Added to a different Scene > 3. Accelerator is not removed from Scene when the anchor node is removed from Scene and then it's ContextMenu is set to null > > Fix: > The accelerator should be added or removed correctly according to the Scene property of the anchor node. > The issue#3 in above list is only fixed for Button and fails for other Controls. A test is added for this scenario and I shall report a new issue to address it. > Added tests that fails before and pass after the fix. Looks good. I left one comment on the test. When you update it to include the bug ID of the follow-on bug, I'll re-review it. modules/javafx.controls/src/test/java/test/javafx/scene/control/AcceleratorParameterizedTest.java line 352: > 350: } > 351: > 352: @Ignore("Passes only for Button") Can you file the follow-on bug and then update this comment to use that bug ID? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/515 From michaelstrau2 at gmail.com Fri Jun 4 22:10:23 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 5 Jun 2021 00:10:23 +0200 Subject: Surface the ImageLoader API In-Reply-To: References: Message-ID: Let me restate my intentions to be more clear: What I'm asking for is a feature to support third-party image format plugins, with the intention of decoding images for use in the JavaFX scene graph. I think the following things should remain explicit non-goals: - writing images - transcoding images - reading or writing metadata There's Java2D for that, no need to duplicate existing functionality. For its intended purpose, I do think that the existing internal implementation is actually a good API, because it is geared towards the problem that it is trying to solve. Expanding the scope of the existing feature to include any of these additional things doesn't seem like a sensible idea to me. I would like to understand whether you disagree with my assessment of the intended purpose of this feature. Do you think that there is a "larger picture" that would change the goals and non-goals? You seem to imply that extending the existing feature is the wrong approach, and that there is a better approach which requires more effort. Can you share any of insights that lead to this conclusion? I haven't been able to find this information in JBS. Am Fr., 4. Juni 2021 um 22:03 Uhr schrieb Kevin Rushforth : > > Characterizing a new feature in terms of exposing internal interfaces > isn't really the right way to think about it. The fact that there might > be internal classes that do something similar to what you propose isn't > really relevant (other than later down the road when it comes time to > discuss the implementation). > > Rather you should start with a description of the enhancement you would > like to see: additional image loading capability, in this case. Then a > discussion of the API would be in order. > > What's really being asked for here is a feature like Java2D's Image I/O > with pluggable image formats. We spent some time looking at that a few > years ago. Doing this right would be a very large effort. I wouldn't be > in favor of a piecemeal approach without understanding the larger picture. > > So I don't support this proposal as stated. > > -- Kevin From kcr at openjdk.java.net Fri Jun 4 23:26:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 23:26:57 GMT Subject: RFR: 8267505: {List, Set, Map}PropertyBase::bind should check against identity In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:56:35 GMT, Jose Pereda wrote: > ListPropertyBase::bind, SetPropertyBase::bind, MapPropertyBase::bind have a check on whether a different instance of the observable is the same, and this PR changes that to check against identity. > > Tests are included. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/516 From kcr at openjdk.java.net Fri Jun 4 23:30:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 23:30:02 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 16:36:24 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into feature/image-datauri > > # Conflicts: > # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java > - Accept regular file paths, change javadoc > - Merge branch 'openjdk:master' into feature/image-datauri > - Rename DataURI.isValidURI > - Reverted a change > - Allow leading and trailing whitespace in data URI > - Removed test > - Changed data URI detection > - Merge branch 'master' into feature/image-datauri > - Moved test > - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 I haven't tested this yet, but have done a first pass on the spec changes and most of the implementation (I'll finish next week). Overall, the docs look good. Can you also update the list of supported image formats in the `Image` class docs just before line 76? modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 290: > 288: /** > 289: * Load all images present in the specified input. For more details refer to > 290: * {@link #loadAll(InputStream, ImageLoadListener, double, double, boolean, float, boolean)}. `ImageLoadListener` isn't imported, so still needs to be qualified (although we don't actually generate any docs since this is an implementation class). modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 333: > 331: loader = getLoaderBySignature(theStream, listener); > 332: } > 333: } catch (Exception e) { Is this change needed? modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 47: > 45: } > 46: > 47: int firstNonWhitespace = 0, length = uri.length(); Why do you need to trim leading spaces? The input URL strings should already be trimmed by the caller. modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 76: > 74: > 75: if (Character.isWhitespace(uri.charAt(0))) { > 76: uri = uri.trim(); Same question as above. modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 175: > 173: > 174: public byte[] getData() { > 175: return data; This returns a reference to the byte array rather than a copy. Is this what is wanted? If so, it would be good to add a comment. modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 185: > 183: > 184: return originalUri.substring(0, originalUri.length() - originalData.length()) > 185: + originalData.substring(0, 14) + "..." + originalData.substring(originalData.length() - 14); Why truncate it? modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 191: > 189: public boolean equals(Object o) { > 190: if (this == o) return true; > 191: if (o == null || getClass() != o.getClass()) return false; Can this be replaced by `o instanceof DataURI`? modules/javafx.graphics/src/main/java/javafx/css/converter/URLConverter.java line 98: > 96: } > 97: > 98: private URL resolve(String stylesheetUrl, String resource) { Why was this change done? It seems unnecessary and possibly unwanted. modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 612: > 610: /** > 611: * Constructs an {@code Image} with content loaded from the specified > 612: * image file. The {@code url} parameter can be one of the following: I would not use the words "image file" in the first sentence. I recommend to restore this to "url". modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 624: > 622: *

> 623: * If a URL uses the "data" scheme, the data must be base64-encoded > 624: * and the MIME type must either be empty or a subtype of the These two paragraphs might be better as part of the class docs (which is where we list the supported image formats). modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 638: > 636: /** > 637: * Constructs an {@code Image} with content loaded from the specified > 638: * image file. The {@code url} parameter can be one of the following: Similar comment. Maybe something like this for the first sentence? Constructs an {@code Image} with content loaded from the specified url using the specified parameters. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kevin.rushforth at oracle.com Fri Jun 4 23:38:52 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 Jun 2021 16:38:52 -0700 Subject: [External] : Re: Surface the ImageLoader API In-Reply-To: References: Message-ID: <9e520a9d-8ef9-1411-a261-0534372d411a@oracle.com> Two thoughts come to mind. 1. While I agree that it isn't necessary to do everything all at once, I don't agree that a full featured Image I/O API is off the table as a future enhancement. Whatever you end up proposing to do here should ideally fit into what we would want to do in the future in this space. At the very least we need to have a discussion about how the subset you propose would or would not fit in. I'm not suggesting that we need to plan for every possible unknown (and in some cases unknowable) future need, but there are some obvious things we might want to do in this space. Writing images and dealing with image meta-data (both of which you listed) are two of the main ones. We need to make sure that we don't preclude any likely future direction. Otherwise we could be left with an API that would need to be deprecated and replaced in order to fit into a future Image I/O-like API. 2. Whether or not the ImageLoader implementation classes might be good API isn't really the point. I rather doubt that defining a lookalike API in the public javafx.scene.image package that merely wraps those classes is what we want. Maybe you'll end up with an API that is somewhat close to that, but starting with an implementation to create the proposed API is backwards. One of the big things to consider is how image readers are registered: SPI? explicit registration API? something else? As for next steps, the first sentence of your latest email is a good start at a brief summary of what you are looking for: > ...a feature to support third-party image format plugins, with the intention of decoding images for use in the JavaFX scene graph. I'd recommend fleshing this out a bit, possibly with some mocked up API (high-level). If you haven't already looked at it, the JEP template [1] is good for describing non-trivial features such as what you propose. While we don't generally do JEPs for JavaFX APIs any more, the template can be a useful way to organize the information needed to evaluate the proposal. It gets you think about thinks like motivation, goals / non-goals, API, alternatives, testing, etc. If there is general buy-in that a pluggable image loader is worth doing, the main things to hash out before this can proceed are the two I mentioned above: 1) whether and how it would fit into a larger Image reader/writer API; and 2) what form the API should take. -- Kevin [1] https://openjdk.java.net/jeps/2 On 6/4/2021 3:10 PM, Michael Strau? wrote: > Let me restate my intentions to be more clear: > > What I'm asking for is a feature to support third-party image format > plugins, with the intention of decoding images for use in the JavaFX > scene graph. > > I think the following things should remain explicit non-goals: > - writing images > - transcoding images > - reading or writing metadata > > There's Java2D for that, no need to duplicate existing functionality. > > For its intended purpose, I do think that the existing internal > implementation is actually a good API, because it is geared towards > the problem that it is trying to solve. > Expanding the scope of the existing feature to include any of these > additional things doesn't seem like a sensible idea to me. > > I would like to understand whether you disagree with my assessment of > the intended purpose of this feature. > Do you think that there is a "larger picture" that would change the > goals and non-goals? > > You seem to imply that extending the existing feature is the wrong > approach, and that there is a better approach which requires more > effort. > Can you share any of insights that lead to this conclusion? I haven't > been able to find this information in JBS. > > > Am Fr., 4. Juni 2021 um 22:03 Uhr schrieb Kevin Rushforth > : >> Characterizing a new feature in terms of exposing internal interfaces >> isn't really the right way to think about it. The fact that there might >> be internal classes that do something similar to what you propose isn't >> really relevant (other than later down the road when it comes time to >> discuss the implementation). >> >> Rather you should start with a description of the enhancement you would >> like to see: additional image loading capability, in this case. Then a >> discussion of the API would be in order. >> >> What's really being asked for here is a feature like Java2D's Image I/O >> with pluggable image formats. We spent some time looking at that a few >> years ago. Doing this right would be a very large effort. I wouldn't be >> in favor of a piecemeal approach without understanding the larger picture. >> >> So I don't support this proposal as stated. >> >> -- Kevin From almatvee at openjdk.java.net Sat Jun 5 00:39:57 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 5 Jun 2021 00:39:57 GMT Subject: Integrated: 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams In-Reply-To: References: Message-ID: <_ni0PHe432WJX4N_TUWvshBlNqx3i9AnQHCuP-B_kkQ=.22e5fb8a-3a52-4140-91a1-8ccdb6d867a1@github.com> On Thu, 3 Jun 2021 09:37:18 GMT, Alexander Matveev wrote: > With recent GStreamer update gstmpegaudioparse no longer provides audio buffers with valid timestamps. This issue is only reproducible with MP3 HTTP Live Stream and was noticed on Linux. I think Windows audio decoder handles such case better and thus MP3 HLS works fine. I did not figure out why it behaves this way and for now fix is reverting gstmpegaudioparse changeset which caused it. Follow up issue will be filed to investigate why javasource and/or hlsprogressbuffer no longer compatible with gstmpegaudioparse and gstmpegaudioparse cannot figure out correct PTS. Also, fixed potential null pointer reference for buffers with invalid PTS. This pull request has now been integrated. Changeset: ee032387 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/ee032387badadb41ed36de745aea3c0a074b79bd Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/526 From hjohn at xs4all.nl Sat Jun 5 08:16:45 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 5 Jun 2021 10:16:45 +0200 Subject: RFR: 8267551: Support loading images from inline data-URIs In-Reply-To: References: Message-ID: <470eeb0b-9e5f-ee98-4cd6-45c68d8e5add@xs4all.nl> I have a question about this. Why would you make this part of JavaFX directly instead of offering it as a dependency that people can include in their project? As far as I know, it is possible to register custom URL handlers in Java, which should be used automatically by JavaFX assuming it constructs its URL's in the standard way when extracting them from the CSS. This can be done since Java 9+ via URLStreamHandlerProvider. You need to store the name of your provider in `META-INF/services`. Any reason why this route isn't being taken? --John On 21/05/2021 19:58, Michael Strau? wrote: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > ------------- > > Commit messages: > - Added data-URI loading support for images > > Changes: https://git.openjdk.java.net/jfx/pull/508/files > Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8267551 > Stats: 437 lines in 8 files changed: 414 ins; 9 del; 14 mod > Patch: https://git.openjdk.java.net/jfx/pull/508.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 > > PR: https://git.openjdk.java.net/jfx/pull/508 > From jhendrikx at openjdk.java.net Sat Jun 5 08:23:56 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 5 Jun 2021 08:23:56 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 16:36:24 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into feature/image-datauri > > # Conflicts: > # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java > - Accept regular file paths, change javadoc > - Merge branch 'openjdk:master' into feature/image-datauri > - Rename DataURI.isValidURI > - Reverted a change > - Allow leading and trailing whitespace in data URI > - Removed test > - Changed data URI detection > - Merge branch 'master' into feature/image-datauri > - Moved test > - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 modules/javafx.graphics/src/main/java/com/sun/javafx/css/StyleManager.java line 776: > 774: } else { > 775: logger.warning("Error loading image: " + url); > 776: } So if I understand this correctly, an Image is first loaded via the standard mechanism, and if that fails for any reason (`image.isError()`) a second attempt is made through `DataURI` ? Would it not be better to register a new protocol so `new Image` would just succeed for data uri's ? ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From jvos at openjdk.java.net Sat Jun 5 09:50:57 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 5 Jun 2021 09:50:57 GMT Subject: Integrated: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:23:25 GMT, Johan Vos wrote: > Add EGL cursor implementation (Java + native) and the link to low-level drivers. > Fix for JDK-8268120 This pull request has now been integrated. Changeset: fe81b9cf Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/fe81b9cf6e69ee4b11e68cb35b4bee9e4deb41eb Stats: 150 lines in 4 files changed: 149 ins; 0 del; 1 mod 8268120: Allow hardware cursor to be used on Monocle-EGL platforms Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/527 From jpereda at openjdk.java.net Sat Jun 5 10:49:59 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sat, 5 Jun 2021 10:49:59 GMT Subject: Integrated: 8267505: {List, Set, Map}PropertyBase::bind should check against identity In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:56:35 GMT, Jose Pereda wrote: > ListPropertyBase::bind, SetPropertyBase::bind, MapPropertyBase::bind have a check on whether a different instance of the observable is the same, and this PR changes that to check against identity. > > Tests are included. This pull request has now been integrated. Changeset: 59cf4de3 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/59cf4de33f4e5dd60be64a6ff381f17703e3175e Stats: 110 lines in 6 files changed: 107 ins; 0 del; 3 mod 8267505: {List,Set,Map}PropertyBase::bind should check against identity Reviewed-by: mhanl, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/516 From kevin.rushforth at oracle.com Sat Jun 5 14:11:41 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 5 Jun 2021 07:11:41 -0700 Subject: [External] : Re: platformWidth In-Reply-To: References: <11e660c9-9ab8-21b4-03c8-26885d5b3a9c@oracle.com> Message-ID: <0a958fcb-9f57-2c8e-9989-5cc7896b8627@oracle.com> Oh, I see. Yes, it looks like you are right. Since Windows is the only platform using platformWidth (and platformHeight), it might be possible to refactor it, but only if we can guarantee that (width * platformScaleX) == platformWidth, which would allow the Windows glass code to compute it for each screen (since there is no per-platform subclass of Screen). Alternatively, we could add a comment to the effect that those variables are unused for platforms other than Windows. -- Kevin On 6/4/2021 12:43 AM, Johan Vos wrote: > Hi John, Kevin, > > Thanks?for the replies. > The relation between actual resolution of the Screen and the JavaFX > rendering is kept in the renderScale and outputScale, and does not > come from platformWidth. The value of platformWidth is never used > apart from the 2 methods I pointed out above. > > The first reason I started this is because it is already complex with > a viewScale, platformScale, renderScale and outputScale, and I don't > see where the platformWidth? fits in this picture -- especially since > the latter is not used at all on linux/mac. > > The second reason is that I am looking into a more generic way to deal > with output dimensions that don't match the dimensions of the JavaFX > main texture. We currently support linear scaling with those scale > factors, but for some local work, I added rotation as well (e.g. to > allow rendering on a portrait screen when the source is in landscape > coordinates). This works surprisingly well by only manipulating the > transformation in ES2SwapChain.prepare (adding the rotation there). I > am doing that now conditionally, based on (yet even more) system > properties, but it might make sense to add an "orientation" parameter > to the Screen. But before adding something, I first try to see if > there is something unused that can be removed -- hence my question > about platformWidth/Height. > > - Johan > > On Fri, Jun 4, 2021 at 12:04 AM Kevin Rushforth > > wrote: > > The platformWidth / platformHeight can also be different from the > width > / height on Linux with Hi-DPI scaling, at least in theory, since the > Screen constructor is called using different parameters for the > platform > values. Mac is different because of how the retina scaling is > handled on > macOS -- even on a retina display, platformWidth/platformHeight == > width/height and platformScale{X,Y} == 1. > > -- Kevin > > > On 6/3/2021 2:38 PM, John Hendrikx wrote: > > Perhaps an example will help from my machine. > > > > I'm running on a 4k screen at 150% scaling. These are the values: > > > > outputScaleX = 1.5 > > outputScaleY = 1.5 > > platformScaleX = 1.5 > > platformScaleY = 1.5 > > width = 2560 > > height = 1440 > > visibleWidth = 2560 > > visibleHeight = 1400 > > platformWidth = 3840 > > platformHeight = 2160 > > > > So it seems that platform values report the actual resolution of > the > > Screen / Monitor. Probably they're what is being reported by > Windows > > and stored there by JavaFX to derive the actual width/height it > should > > use while taking scaling into account. > > > > You didn't ask about the difference between visibleHeight and > height. > > But just incase, the visibleHeight is 40 pixels smaller than > height, > > as this space is taken up by the task bar. > > > > --John > > > > > > On 01/06/2021 13:27, Johan Vos wrote: > >> Hi, > >> > >> com.sun.glass.ui.Screen has 3 width (and height) parameters, > each with a > >> getter: > >> * width > >> * visibleWidth > >> * platformWidth > >> > >> The latter seems to be used only in the windows build, > >> via screen.containsPlatformRect and > screen.portionIntersectsPlatformRect > >> > >> I don't really understand what the goal of this > platformWidth/Height > >> is. It > >> seems a bit artificial if this is not used on the other > platforms, but I > >> might be missing the bigger purpose of this? > >> > >> - Johan > >> > From michaelstrau2 at gmail.com Sat Jun 5 14:36:46 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 5 Jun 2021 16:36:46 +0200 Subject: RFR: 8267551: Support loading images from inline data-URIs In-Reply-To: <470eeb0b-9e5f-ee98-4cd6-45c68d8e5add@xs4all.nl> References: <470eeb0b-9e5f-ee98-4cd6-45c68d8e5add@xs4all.nl> Message-ID: That's a good question, and probably a valid approach. However, while app developers are certainly used to depending on third-party libraries for things like additional controls, I think it's questionable whether it's a good developer experience to needing to rely on the third-party ecosystem for core behavior. We could ship a custom `URLStreamHandler` with the javafx-graphics library, but that presents its own set of problems if app developers use fat jars and have their own implementations for `URLStreamHandlerProvider`. In this case, our implementation might silently fail because it is replaced by an application-provided `META-INF/services/java.net.spi.URLStreamHandlerProvider` file. While this can of course be worked around by using a resource transformer that merges all files of this kind, it is one more non-obvious thing that app developers need to know about. Am Sa., 5. Juni 2021 um 10:17 Uhr schrieb John Hendrikx : > > I have a question about this. > > Why would you make this part of JavaFX directly instead of offering it > as a dependency that people can include in their project? > > As far as I know, it is possible to register custom URL handlers in > Java, which should be used automatically by JavaFX assuming it > constructs its URL's in the standard way when extracting them from the CSS. > > This can be done since Java 9+ via URLStreamHandlerProvider. You need to > store the name of your provider in `META-INF/services`. > > Any reason why this route isn't being taken? > > --John From mstrauss at openjdk.java.net Sat Jun 5 14:50:03 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 14:50:03 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 21:54:12 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 290: > >> 288: /** >> 289: * Load all images present in the specified input. For more details refer to >> 290: * {@link #loadAll(InputStream, ImageLoadListener, double, double, boolean, float, boolean)}. > > `ImageLoadListener` isn't imported, so still needs to be qualified (although we don't actually generate any docs since this is an implementation class). `ImageLoadListener` is in the same package as `ImageStorage`, so it should be implicitly imported. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 14:53:57 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 14:53:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 21:56:32 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 333: > >> 331: loader = getLoaderBySignature(theStream, listener); >> 332: } >> 333: } catch (Exception e) { > > Is this change needed? If a MIME type other than `image` was specified in the data URL, `IllegalArgumentException` is thrown. If we only catch `IOException` here, the IAE will not be wrapped into a `ImageStorageException`. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 14:58:55 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 14:58:55 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 21:59:28 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 47: > >> 45: } >> 46: >> 47: int firstNonWhitespace = 0, length = uri.length(); > > Why do you need to trim leading spaces? The input URL strings should already be trimmed by the caller. I implemented it in this way so that this requirement is not imposed onto the caller, similar to `java.net.URL` does not impose this requirement onto its callers. I can imagine that `DataURI` might be used in other places, so it might make sense to make it more robust with regards to leading whitespace? ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 15:02:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 15:02:10 GMT Subject: [jfx11u] RFR: 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams Message-ID: This is a clean backport of a GStreamer audio fix for a regression caused by the recent GStreamer 1.18.3 update in [JDK-8262365](https://bugs.openjdk.java.net/browse/JDK-8262365). I tested it on all three platforms. ------------- Commit messages: - 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams Changes: https://git.openjdk.java.net/jfx11u/pull/22/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=22&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268152 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/22/head:pull/22 PR: https://git.openjdk.java.net/jfx11u/pull/22 From mstrauss at openjdk.java.net Sat Jun 5 15:10:59 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 15:10:59 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: <3tCTfL2pgZTVMtzqWQc3njo0CIBLREzFGSIbyk4HZj4=.74f836d9-03c4-4feb-a4dd-64cd75bd016d@github.com> On Fri, 4 Jun 2021 22:03:26 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 175: > >> 173: >> 174: public byte[] getData() { >> 175: return data; > > This returns a reference to the byte array rather than a copy. Is this what is wanted? If so, it would be good to add a comment. I added a comment that clarifies this. > modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 185: > >> 183: >> 184: return originalUri.substring(0, originalUri.length() - originalData.length()) >> 185: + originalData.substring(0, 14) + "..." + originalData.substring(originalData.length() - 14); > > Why truncate it? The idea was to not clutter logs with large pieces of data. Do you think that the entire data string should be logged? ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 15:10:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 15:10:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 14:56:15 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 47: >> >>> 45: } >>> 46: >>> 47: int firstNonWhitespace = 0, length = uri.length(); >> >> Why do you need to trim leading spaces? The input URL strings should already be trimmed by the caller. > > I implemented it in this way so that this requirement is not imposed onto the caller, similar to `java.net.URL` does not impose this requirement onto its callers. I can imagine that `DataURI` might be used in other places, so it might make sense to make it more robust with regards to leading whitespace? In that case, it might be clearer and simpler to just call `trim()` on the input String before doing anything with it, unless there is a reason not to. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 15:20:57 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 15:20:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 15:07:36 GMT, Kevin Rushforth wrote: >> I implemented it in this way so that this requirement is not imposed onto the caller, similar to `java.net.URL` does not impose this requirement onto its callers. I can imagine that `DataURI` might be used in other places, so it might make sense to make it more robust with regards to leading whitespace? > > In that case, it might be clearer and simpler to just call `trim()` on the input String before doing anything with it, unless there is a reason not to. My idea was to avoid repeatedly allocating a new String with the data contained in the URI. Since `matchScheme` is called at least twice (maybe more), that would be a total of at least three copies of the URI data until we parse it. Granted, this would only apply for URIs that contain leading or trailing whitespace (since `trim()` is specified to return the same String instance if it contains no leading or trailing whitespace). ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 15:20:59 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 15:20:59 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 22:06:31 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 191: > >> 189: public boolean equals(Object o) { >> 190: if (this == o) return true; >> 191: if (o == null || getClass() != o.getClass()) return false; > > Can this be replaced by `o instanceof DataURI`? Sure. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 15:30:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 15:30:55 GMT Subject: [jfx11u] Integrated: 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 14:00:38 GMT, Kevin Rushforth wrote: > This is a clean backport of a GStreamer audio fix for a regression caused by the recent GStreamer 1.18.3 update in [JDK-8262365](https://bugs.openjdk.java.net/browse/JDK-8262365). I tested it on all three platforms. This pull request has now been integrated. Changeset: 032368a7 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/032368a7bd9fd53b4448b1c26e78c95eca3dae49 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams Backport-of: ee032387badadb41ed36de745aea3c0a074b79bd ------------- PR: https://git.openjdk.java.net/jfx11u/pull/22 From mstrauss at openjdk.java.net Sat Jun 5 15:42:22 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 15:42:22 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v14] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/315523c5..f6201b7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=12-13 Stats: 107 lines in 2 files changed: 29 ins; 57 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 15:42:24 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 15:42:24 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: <1GhUQxHAeH8ZI8p33O1qQWaTeGXEy7M5iLefa827Sck=.a56262e4-7d31-406f-95bc-c4a364d7bf35@github.com> On Fri, 4 Jun 2021 22:14:12 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 612: > >> 610: /** >> 611: * Constructs an {@code Image} with content loaded from the specified >> 612: * image file. The {@code url} parameter can be one of the following: > > I would not use the words "image file" in the first sentence. I recommend to restore this to "url". Done. > modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 624: > >> 622: *

>> 623: * If a URL uses the "data" scheme, the data must be base64-encoded >> 624: * and the MIME type must either be empty or a subtype of the > > These two paragraphs might be better as part of the class docs (which is where we list the supported image formats). Done. > modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 638: > >> 636: /** >> 637: * Constructs an {@code Image} with content loaded from the specified >> 638: * image file. The {@code url} parameter can be one of the following: > > Similar comment. Maybe something like this for the first sentence? > > > Constructs an {@code Image} with content loaded from the specified url using the specified parameters. Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 15:46:58 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 15:46:58 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 22:09:09 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/javafx/css/converter/URLConverter.java line 98: > >> 96: } >> 97: >> 98: private URL resolve(String stylesheetUrl, String resource) { > > Why was this change done? It seems unnecessary and possibly unwanted. `resource` is never `null` at this point, and it is already trimmed. Also, contrary to the comment, I cannot see this method being used anywhere in tests, so I made it private. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 15:51:59 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 15:51:59 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 08:21:14 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/StyleManager.java line 776: > >> 774: } else { >> 775: logger.warning("Error loading image: " + url); >> 776: } > > So if I understand this correctly, an Image is first loaded via the standard mechanism, and if that fails for any reason (`image.isError()`) a second attempt is made through `DataURI` ? > > Would it not be better to register a new protocol so `new Image` would just succeed for data uri's ? In this specific case, image loading has failed for some reason. The call to `DataURI.tryParse` is only there to potentially call `DataURI.toString()` for a truncated log output, instead of logging the entire `url` String. If data-URI truncation is not wanted, this code can be reverted. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 15:56:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 15:56:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 15:17:09 GMT, Michael Strau? wrote: >> In that case, it might be clearer and simpler to just call `trim()` on the input String before doing anything with it, unless there is a reason not to. > > My idea was to avoid repeatedly allocating a new String with the data contained in the URI. Since `matchScheme` is called at least twice (maybe more), that would be a total of at least three copies of the URI data until we parse it. Granted, this would only apply for URIs that contain leading or trailing whitespace (since `trim()` is specified to return the same String instance if it contains no leading or trailing whitespace). I see. How about something like this then? if (uri == null || uri.isEmpty()) { return false; } if (Character.isWhiteSpace(uri.charAt(0)) { uri = uri.trim(); } if (uri.length() < 6) { return false; } The rest of the method can then work on a trimmed string. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 15:56:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 15:56:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: <3tCTfL2pgZTVMtzqWQc3njo0CIBLREzFGSIbyk4HZj4=.74f836d9-03c4-4feb-a4dd-64cd75bd016d@github.com> References: <3tCTfL2pgZTVMtzqWQc3njo0CIBLREzFGSIbyk4HZj4=.74f836d9-03c4-4feb-a4dd-64cd75bd016d@github.com> Message-ID: On Sat, 5 Jun 2021 15:08:29 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 185: >> >>> 183: >>> 184: return originalUri.substring(0, originalUri.length() - originalData.length()) >>> 185: + originalData.substring(0, 14) + "..." + originalData.substring(originalData.length() - 14); >> >> Why truncate it? > > The idea was to not clutter logs with large pieces of data. Do you think that the entire data string should be logged? Your explanation is fine. And since this is an internal class, it doesn't matter all that much. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 16:03:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 16:03:59 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v14] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 15:42:22 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Yes, it is a good question as to whether we should add Data URI support in the core of JavaFX or provide it via some other means. I agree that we wouldn't want to implement it in JavaFX with a pluggable protocol handler, so if we go that route we will end up pushing it off to the app. The other alternative that was mentioned (as a comment in the JBS bug) was to push for direct support in the JDK. Since that was requested some years ago and rejected -- see [JDK-4188739](https://bugs.openjdk.java.net/browse/JDK-4188739) -- I doubt that is likely. My gut feel is that adding Data URI support to JavaFX is a worthwhile feature, but it might warrant further discussion. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 16:14:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 16:14:58 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 15:44:38 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/converter/URLConverter.java line 98: >> >>> 96: } >>> 97: >>> 98: private URL resolve(String stylesheetUrl, String resource) { >> >> Why was this change done? It seems unnecessary and possibly unwanted. > > `resource` is never `null` at this point, and it is already trimmed. Also, contrary to the comment, I cannot see this method being used anywhere in tests, so I made it private. If that is guaranteed by all callers of this method (which is easier to check now that you made it private), this is fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 16:14:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 16:14:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 15:49:16 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/StyleManager.java line 776: >> >>> 774: } else { >>> 775: logger.warning("Error loading image: " + url); >>> 776: } >> >> So if I understand this correctly, an Image is first loaded via the standard mechanism, and if that fails for any reason (`image.isError()`) a second attempt is made through `DataURI` ? >> >> Would it not be better to register a new protocol so `new Image` would just succeed for data uri's ? > > In this specific case, image loading has failed for some reason. The call to `DataURI.tryParse` is only there to potentially call `DataURI.toString()` for a truncated log output, instead of logging the entire `url` String. If data-URI truncation is not wanted, this code can be reverted. Maybe add a brief comment to that effect? ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 16:24:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 16:24:59 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v14] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 15:42:22 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments The docs updates look good, with a few minor comments. modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 68: > 66: * images from a specified URL. > 67: * > 68: *

Supported image formats are: Can you revert this formatting change to avoid unnecessary diffs? (I mean the one that moved the sentence up to be on the same line as the `

`. The removal of the unneeded `

` is fine) The reason for this is to avoid extra diffs in public API. It will make it easier to see what needs to go into the CSR. modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 76: > 74: * > 75: * > 76: *

Images can be resized as they are loaded (for example to reduce the amount of Revert modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 619: > 617: * Constructs an {@code Image} with content loaded from the specified URL. > 618: * > 619: * @param url a resource path, file path or URL Please add a comma after `file path` (we prefer the Oxford comma in our docs). modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 632: > 630: * using the specified parameters. > 631: * > 632: * @param url a resource path, file path or URL Comma after `file path` modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 647: > 645: * using the specified parameters. > 646: * > 647: * @param url a resource path, file path or URL Comma after `file path` ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 16:33:21 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 16:33:21 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v15] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/f6201b7e..29178487 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=13-14 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From jhendrikx at openjdk.java.net Sat Jun 5 17:12:57 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 5 Jun 2021 17:12:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 16:10:59 GMT, Kevin Rushforth wrote: >> In this specific case, image loading has failed for some reason. The call to `DataURI.tryParse` is only there to potentially call `DataURI.toString()` for a truncated log output, instead of logging the entire `url` String. If data-URI truncation is not wanted, this code can be reverted. > > Maybe add a brief comment to that effect? Ok clear thanks ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 17:29:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 17:29:58 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Sat, 22 May 2021 02:27:41 GMT, Nir Lisker wrote: > Did you test the different `computeSpotlightFactor` methods in the shader? I got some 4 fps difference between the best and worst cases. Here are the performance numbers on my Mac (using the discrete `AMD Radeon Pro 5300M` graphics chipset) using the using the LightingSample test program with a mesh of 1000 quads rendered with 3 point lights and no attenuation: | shader compute method | fps | | -------------------- | ---- | | computeSpotlightFactor | 10.75 | | computeSpotlightFactor2 | 9.40 | | computeSpotlightFactor3 | 7.70 | So it looks like computeSpotlightFactor is the winner. Does that match your observations? It might be worth some further tuning. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Sat Jun 5 17:31:17 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 17:31:17 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v16] In-Reply-To: References: Message-ID: <7GKKu6Lc5iF1vBfztwG8rLA-4wvk4jW3tEJCBJ2dkZA=.34d72e93-1514-45b0-b3bd-737ba5a8b51e@github.com> > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added comment, simplified DataURI.matchScheme() ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/29178487..e490cc04 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=14-15 Stats: 20 lines in 2 files changed: 3 ins; 14 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 17:31:17 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 17:31:17 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 17:10:29 GMT, John Hendrikx wrote: >> Maybe add a brief comment to that effect? > > Ok clear thanks I added a comment that explains that. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 17:31:19 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 17:31:19 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 22:00:03 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into feature/image-datauri >> >> # Conflicts: >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java >> - Accept regular file paths, change javadoc >> - Merge branch 'openjdk:master' into feature/image-datauri >> - Rename DataURI.isValidURI >> - Reverted a change >> - Allow leading and trailing whitespace in data URI >> - Removed test >> - Changed data URI detection >> - Merge branch 'master' into feature/image-datauri >> - Moved test >> - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 > > modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 76: > >> 74: >> 75: if (Character.isWhitespace(uri.charAt(0))) { >> 76: uri = uri.trim(); > > Same question as above. Removed the conditional branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 17:31:17 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 17:31:17 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: <6D_uMk62u4-2PRD65zlA-FzKbNrRrMoU6Ag3JFabrCA=.1a9a5a73-4fbc-4f45-b527-53d92e510121@github.com> On Sat, 5 Jun 2021 15:52:01 GMT, Kevin Rushforth wrote: >> My idea was to avoid repeatedly allocating a new String with the data contained in the URI. Since `matchScheme` is called at least twice (maybe more), that would be a total of at least three copies of the URI data until we parse it. Granted, this would only apply for URIs that contain leading or trailing whitespace (since `trim()` is specified to return the same String instance if it contains no leading or trailing whitespace). > > I see. How about something like this then? > > > if (uri == null || uri.isEmpty()) { > return false; > } > > if (Character.isWhiteSpace(uri.charAt(0)) { > uri = uri.trim(); > } > > if (uri.length() < 6) { > return false; > } > > > The rest of the method can then work on a trimmed string. I replaced it with another implementation that is effectively the same as this. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Sat Jun 5 17:42:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Jun 2021 17:42:00 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v20] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 15:54:08 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Updated docs per review The updated docs look good (although I haven't looked at the javadoc-generated docs yet) with a couple minor comments. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 52: > 50: *

    > 51: *
  • {@link #innerAngleProperty() inner angle}: the angle of the inner cone (see image below) > 52: *
  • {@link #outerAngleProperty() outer angle}: the angle of the outer cone (see image below) I recommend changing these to `innerAngle` and `outerAngle` (one word, camel case) to match the names of the properties. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 144: > 142: /** > 143: * The angle of the spotlight's inner cone, in degrees (as shown in the class doc image). A point whose angle to the > 144: * light's position is less than this angle is not attenuated by the spotlight factor ({@code spot = 1}). At larger The term `angle to the light position` isn't precise since you need a second vector to form an angle. In the class docs, you use the wording `point whose vector to the light position forms an angle {@code theta} with the direction of the light`, which I like. Maybe you could work that into this description somehow? ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Sat Jun 5 17:42:55 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 17:42:55 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v16] In-Reply-To: <7GKKu6Lc5iF1vBfztwG8rLA-4wvk4jW3tEJCBJ2dkZA=.34d72e93-1514-45b0-b3bd-737ba5a8b51e@github.com> References: <7GKKu6Lc5iF1vBfztwG8rLA-4wvk4jW3tEJCBJ2dkZA=.34d72e93-1514-45b0-b3bd-737ba5a8b51e@github.com> Message-ID: On Sat, 5 Jun 2021 17:31:17 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added comment, simplified DataURI.matchScheme() Since this implementation doesn't surface any new API, it will not prevent us from removing it at any future time when the "data" protocol might be supported by the JDK. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat Jun 5 18:00:57 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 5 Jun 2021 18:00:57 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: <2VUtih7UVudx0PRCK5RrsdVufKrX21h5LjH0I4OoYVI=.f8b9bc76-1fec-4133-986e-eab08dc35837@github.com> On Sat, 5 Jun 2021 16:12:36 GMT, Kevin Rushforth wrote: >> `resource` is never `null` at this point, and it is already trimmed. Also, contrary to the comment, I cannot see this method being used anywhere in tests, so I made it private. > > If that is guaranteed by all callers of this method (which is easier to check now that you made it private), this is fine. This method is only used once, and only after `resource` has already been dereferenced. So if it was indeed `null`, we would have errored out with `NullPointerException` before calling this method. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From michaelstrau2 at gmail.com Sun Jun 6 00:59:02 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 6 Jun 2021 02:59:02 +0200 Subject: Support :focus-visible CSS pseudoclass In-Reply-To: References: Message-ID: I'd like to try to move this proposal forward, so here's a JEP-like summary of the proposal: Summary ------- Add the `javafx.scene.Node.focusVisible` property, as well as the "focus-visible" CSS pseudoclass. Motivation ---------- The W3C CSS Selectors Level 4 specification defines three focus-related pseudo-classes: "focus", which applies to a node that currently accepts keyboard or mouse input; "focus-visible", which applies to a focused node that visibly indicates focus, and "focus-within", which applies to a focused node and any of its parents. JavaFX currently implements the "focused" property only, which corresponds to the "focus" CSS pseudoclass. However, many contemporary UI designs do not always indicate focus in the same way that the built-in JavaFX themes do. For example, the Windows 10 theme or modern "Fluent" design implementations generally only indicate the focused element as a consequence of keyboard input. There are also "Material" design implementations with the same behavior. Adding a "focusVisible" property and the corresponding "focus-visible" pseudoclass to JavaFX will enable application developers to create modern themes that differentiate between logical input focus and visual focus indication. Description ----------- A new property will be added to javafx.scene.Node: public final boolean isFocusVisible() public final ReadOnlyBooleanProperty focusVisibleProperty() This new property will also toggle the "focus-visible" pseudo-class on its scene graph node. The property value is set in conjunction with the value of "Node.focused" as an atomic operation, so it will not be possible for listeners to observe inconsistent values. The value of "Node.focusVisible" will be determined by tracking the input modality that caused a node to acquire focus. The W3C CSS specification includes some suggestions for the heuristics used to determine whether or not focus should be indicated: https://drafts.csswg.org/selectors-4/#focus-visible-pseudo For JavaFX, "Node.focusVisible" would be set in addition to "Node.focused" if a scene graph node gained focus as a consequence of keyboard input. In all other cases, "Node.focusVisible" would not be set on a node. Additionally, the value of "Node.focusVisible" is cleared if the node receives interaction with mouse or touch. One of the W3C suggestions should not be implemented for JavaFX: > If the previously-focused element indicated focus, and a script causes focus to move elsewhere, the newly focused element should indicate focus. > Conversely, if the previously-focused element did not indicate focus, and a script causes focus to move elsewhere, the newly focused element should also not indicate focus. This behavior is difficult to implement in JavaFX, because there is no way for a node to know whether or not it gained focus programmatically, or as a result of a control skin invoking Node.requestFocus(). Supporting this scenario would require adding new public API and potentially changing lots of skins to account for the distinction between programmatic and mouse-based focus traversal. The impact on existing code would most likely be too large for a very marginal benefit. Alternatives ------------ As an alternative to implementing this feature, modality-aware focus indication might be implemented in a JavaFX application by installing event handlers on individual controls or on the Scene (in order to intercept the TAB key) and monitoring the "focused" property (or "focusOwner", respectively). As another alternative to using built-in rules to determine the value of the "focusVisible" property, there could be an API that allows application developers to change these rules. However, it appears that the benefit of doing to is very marginal, while the effort could be very significant. From mhanl at openjdk.java.net Sun Jun 6 12:49:06 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sun, 6 Jun 2021 12:49:06 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability Message-ID: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. While this PR fixes the problem described in the ticket, it does not fix the example. This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) ------------- Commit messages: - Table, Tree,-Cells respect the row editability now Changes: https://git.openjdk.java.net/jfx/pull/529/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=529&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252238 Stats: 54 lines in 4 files changed: 44 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/529.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/529/head:pull/529 PR: https://git.openjdk.java.net/jfx/pull/529 From nlisker at openjdk.java.net Sun Jun 6 16:23:02 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 6 Jun 2021 16:23:02 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Sat, 5 Jun 2021 17:27:13 GMT, Kevin Rushforth wrote: > So it looks like computeSpotlightFactor is the winner. Does that match your observations? It might be worth some further tuning. Yes, on Ubuntu. On Win, `computeSpotlightFactor3` was the best for me. I detailed my findings in the topmost comment. What further tuning are you thinking of? ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Sun Jun 6 17:27:02 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 6 Jun 2021 17:27:02 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v20] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 17:38:27 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated docs per review > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 144: > >> 142: /** >> 143: * The angle of the spotlight's inner cone, in degrees (as shown in the class doc image). A point whose angle to the >> 144: * light's position is less than this angle is not attenuated by the spotlight factor ({@code spot = 1}). At larger > > The term `angle to the light position` isn't precise since you need a second vector to form an angle. In the class docs, you use the wording `point whose vector to the light position forms an angle {@code theta} with the direction of the light`, which I like. Maybe you could work that into this description somehow? It can become cumbersome. Something like `A point whose whose vector to the light's position and the direction of the light form an angle that is less than this angle is not attenuated by the spotlight factor` or `A point whose vector to the light's position forms an angle {@code theta} with the direction of the light, and {@code theta} is smaller than this angle, is not attenuated by the spotlight factor.` is a lot to digest. I think that the meaning is intuitive. Maybe I can defined what an "angle of a point to the light" is in the class doc and use that definition in the `innerAngle` and `outerAngle` docs. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Mon Jun 7 04:19:58 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Jun 2021 04:19:58 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 07:11:54 GMT, Marius Hanl wrote: >> ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ >> EDIT: Thank you, Kevin. :) >> >> This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: >> - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. >> -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) >> - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) >> - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) >> >> **-> With this, I can run all normal tests with IntelliJ** >> >> ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): >> - IntelliJ is not detecting javafx.graphic inside the shims >> - All javafx.* dependencies are not found for the system tests >> >> **-> If someone has a solution, feel free to comment :)** > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Reverted whitespace made by IntelliJ I tested with IntelliJ IDEA 2021.1.2 (Community Edition) Build #IC-211.7442.40, built on June 1, 2021. I see no side effects of this change. However, I also don't see what you see too. I tried it with a fresh clone of repository. The build from IntelliJ's inbuilt terminal worked without this change too, that terminal picks JDK/gradle/ant that was set in bashrc. I also don't see the modules in gradle window. Here is the screenshot that I see when the project(with this PR change) is loaded for first time in the IntelliJ. ![image](https://user-images.githubusercontent.com/11330676/120957254-f6751700-c772-11eb-9fb4-51668d6f4e24.png) Is it possible that some local changes on your machine/repo result in what you see? Some idea files are ignored using .gitignore file, so they get modified they won't be shown in 'git status' **from .gitignore file** # Ignore IntelliJ files .idea/tasks.xml .idea/workspace.xml .idea/inspectionProfiles/** .idea/copyright/profiles_settings.xml .idea/codeStyles/** .idea/checkstyle-idea.xml It would be helpful to compare those files before and after loading the project in IntelliJ. Also, can you test the PR once, by cloning a fresh copy of repo and then apply the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From kcr at openjdk.java.net Mon Jun 7 13:22:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Jun 2021 13:22:03 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v20] In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 17:23:45 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 144: >> >>> 142: /** >>> 143: * The angle of the spotlight's inner cone, in degrees (as shown in the class doc image). A point whose angle to the >>> 144: * light's position is less than this angle is not attenuated by the spotlight factor ({@code spot = 1}). At larger >> >> The term `angle to the light position` isn't precise since you need a second vector to form an angle. In the class docs, you use the wording `point whose vector to the light position forms an angle {@code theta} with the direction of the light`, which I like. Maybe you could work that into this description somehow? > > It can become cumbersome. Something like `A point whose whose vector to the light's position and the direction of the light form an angle that is less than this angle is not attenuated by the spotlight factor` or `A point whose vector to the light's position forms an angle {@code theta} with the direction of the light, and {@code theta} is smaller than this angle, is not attenuated by the spotlight factor.` is a lot to digest. > > I think that the meaning is intuitive. Maybe I can defined what an "angle of a point to the light" is in the class doc and use that definition in the `innerAngle` and `outerAngle` docs. Yeah, I see your point. And yes, I think it would help to define that term in the class docs. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Mon Jun 7 13:36:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Jun 2021 13:36:34 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Sun, 6 Jun 2021 16:19:46 GMT, Nir Lisker wrote: > > So it looks like `computeSpotlightFactor` is the winner. Does that match your observations? It might be worth some further tuning. > > Yes, on Ubuntu. On Win, `computeSpotlightFactor3` was the best for me. I detailed my findings in the topmost comment. Oh, right. I didn't read that carefully. In that case, using `computeSpotlightFactor` in the GLSL shaders and `computeSpotlightFactor3` in the HLSL shaders seems like the way to go. If we are settled on this, the two you aren't using should be commented out or `#ifdef`ed out. > What further tuning are you thinking of? I don't have anything specific in mind. I was just wondering if there might be additional optimizations that one could do the `computeSpotlightFactor` method. Even if so, it could probably be done in a follow-on bug. The more interesting question is whether the gap between what we have now and what is possible for simple lights justifies additional shaders. Maybe not for point lights, but we need to at least consider it when you add directional lights. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From r.lichtenberger at gmail.com Mon Jun 7 15:12:32 2021 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 7 Jun 2021 17:12:32 +0200 Subject: Cannot load jpeg images on Fedora 34 In-Reply-To: References: Message-ID: <6c8642e5-3caf-e25f-b709-bf196a0e2647@gmail.com> I've analysed the problem described below and found out that: * When building JavaFX from master-branch, the problem is gone * When building from tags/16+8, the problem is present And finally I found https://bugs.openjdk.java.net/browse/JDK-8211362 (Restrict export of libjpeg symbols from libjavafx_iio.so) together with https://git.openjdk.java.net/jfx/pull/442 from Johan Vos. When I apply the changes in buildSrc/linux.gradle to tags/16+8, the problem goes away. I also found out that Fedora 34 is not the only Linux distribution affected by the problem. So the good news is, the problem will probably vanish with JavaFX 17. But the question remains whether the fix should be backported, since a lot of JavaFX applications will not work correctly under various modern Linux distributions. Best regards, Robert Am 6/2/21 um 12:43 PM schrieb Robert Lichtenberger: > Using this testapplication: > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.StackPane; > import javafx.stage.Stage; > > public class ImageTest extends Application { > > ??? @Override > ??? public void start(Stage stage) throws Exception { > > ??? ??? Image img = new > Image("https://www.synedra.com/_thumbnails_/606_11_robert_lichtenberger.jpg"); > ??? ??? if (img.isError()) { > ??? ??? ??? System.out.println(img.getException()); > ??? ??? } > ??? ??? ImageView imgView = new ImageView(img); > > ??? ??? StackPane stack = new StackPane(); > ??? ??? stack.getChildren().add(imgView); > ??? ??? Scene scene = new Scene(stack, 640, 480); > ??? ??? stage.setScene(scene); > ??? ??? stage.show(); > ??? } > > ??? public static void main(String[] args) { > ??? ??? launch(); > ??? } > } > > And running it with regular JavaFX-16 (downloaded from gluonhq), I get: > > [rli at rlimbus javafx]$ java --module-path > /home/rli/Downloads/javafx-sdk-16/lib --add-modules > javafx.controls,javafx.fxml ImageTest > java.io.IOException: Wrong JPEG library version: library is 62, caller > expects 90 > > and the image will not be loaded. > > The same happens for all other regular JavaFX SDKs (even tried LTS > 11.0.12). > > When I compile JavaFX myself, it works as expected: > > [rli at rlimbus javafx]$ java --module-path > /home/rli/PWEs/jfx/build/sdk/lib --add-modules > javafx.controls,javafx.fxml ImageTest > > The problem seems to be related to the OS version, because on Fedora > 33 everything works fine. > > Other applications are also impacted, e.g. AsciidocFX cannot show > previews of jpeg images on Fedora 34. > > Any hints / ideas appreciated. > > Robert > > > > From mstrauss at openjdk.java.net Mon Jun 7 20:57:42 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 7 Jun 2021 20:57:42 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses Message-ID: This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. ------------- Commit messages: - remove code comment - revert changes to line endings - added test - Merge branch 'master' into feature/focusvisible - Only fire focus change notification if value is actually different - minor naming change - added focusWithin - changed javadoc - Test for pseudo-class state - Changed javadoc, changed test - ... and 2 more: https://git.openjdk.java.net/jfx/compare/59cf4de3...7b3efd29 Changes: https://git.openjdk.java.net/jfx/pull/475/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268225 Stats: 566 lines in 21 files changed: 415 ins; 35 del; 116 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From mhanl at openjdk.java.net Mon Jun 7 20:57:42 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 7 Jun 2021 20:57:42 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:17:27 GMT, Michael Strau? wrote: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Do you have a example application or something, where the possible use case/the advantage of this can be shown? I can't imagine right now, where I may want to use that. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Mon Jun 7 20:57:42 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 7 Jun 2021 20:57:42 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 20:53:57 GMT, Marius Hanl wrote: > Do you have a example application or something, where the possible use case/the advantage of this can be shown? I can't imagine right now, where I may want to use that. If you are running Windows 10, try opening PC Settings, then go to a section like System > Notifications and actions. There are lots of switches and check boxes that you can toggle, but you'll notice that they don't have any visible focus indicator if you click on them (even tough they _are_ focused after clicking). Only if you press the Tab key you'll see a black border as a visual focus indicator, which will disappear again after clicking. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From kcr at openjdk.java.net Mon Jun 7 22:36:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Jun 2021 22:36:26 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:17:27 GMT, Michael Strau? wrote: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. I note that the discussion hasn't finished on the openjfx-dev mailing list as to whether to accept this feature. The proposed API and docs in this PR can be used to inform the discussion, but it's premature to start the code review. If it ends up going forward, it will need a CSR and 2 reviewers. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From michaelstrau2 at gmail.com Mon Jun 7 22:46:33 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 8 Jun 2021 00:46:33 +0200 Subject: Support :focus-visible CSS pseudoclass In-Reply-To: References: Message-ID: I have expanded the scope of the proposal to include the :focus-within pseudo-class, which completes the set of focus-related pseudo-classes. The updated text of the proposal can be found in the JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8268225 I'm looking forward to comments. From kevin.rushforth at oracle.com Mon Jun 7 23:08:28 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 7 Jun 2021 16:08:28 -0700 Subject: Support :focus-visible CSS pseudoclass In-Reply-To: References: Message-ID: I'd be interested in hearing from application developers as to whether and how they would use such a feature. As with all non-trivial features, we don't want to do it if only one or two developers are asking for it. This seems a reasonably new CSS feature; Firefox just added support in FF 85 released earlier this year and Safari still doesn't. That suggests it might be a bit early to adopt this for JavaFX. Also, one thing that isn't clear is whether there would be any user visible change using the standard themes. I presume that the answer is "no", meaning that unless your stylesheets do anything with focus-visible, it will not affect the look and feel of the app. That should be stated explicitly I also presume that there would be no application visible changes when using the standard themes, other than the presence of the two new read-only boolean properties? -- Kevin On 6/7/2021 3:46 PM, Michael Strau? wrote: > I have expanded the scope of the proposal to include the :focus-within > pseudo-class, which completes the set of focus-related pseudo-classes. > > The updated text of the proposal can be found in the JBS ticket: > https://bugs.openjdk.java.net/browse/JDK-8268225 > > I'm looking forward to comments. From nlisker at openjdk.java.net Mon Jun 7 23:38:44 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 7 Jun 2021 23:38:44 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed doc review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/0bdb7cdd..1f17f8ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=19-20 Stats: 12 lines in 1 file changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Mon Jun 7 23:38:44 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 7 Jun 2021 23:38:44 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Mon, 7 Jun 2021 13:29:01 GMT, Kevin Rushforth wrote: > In that case, using computeSpotlightFactor in the GLSL shaders and computeSpotlightFactor3 in the HLSL shaders seems like the way to go. If we are settled on this, the two you aren't using should be commented out or #ifdefed out. I think so too. Did you test on Win? Does @arapte want to test these functions too? > The more interesting question is whether the gap between what we have now and what is possible for simple lights justifies additional shaders. Maybe not for point lights, but we need to at least consider it when you add directional lights. The question of adding shaders is a bigger one than just the light types. I plan on adding emissive (or self-illuminating) color, in addition to the existing map, which will probably require creating additional shaders as we do for diffuse and specular colors/maps. Another change will be removing the limit of 3 lights. I have a patch that does it by removing the shader creation per light number. We will need to think how to redistribute the shaders since we can't create one for every light number. Either remove those or, if possible, divide then into 1 light, 2 lights, 3 lights, and 4+ lights. Not sure how to include different numbers of lights in the same shader syntactically. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at gmail.com Mon Jun 7 23:41:04 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 8 Jun 2021 02:41:04 +0300 Subject: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: Does this constitute sufficient interest in the enhancement? On Thu, May 13, 2021 at 6:41 PM Michael Strau? wrote: > Another option could be to mirror the `Color` API in both `Border` and > `Background`, like in the following examples: > > Color.rgb(125, 100, 75) > Border.rgb(125, 100, 75) > Background.rgb(125, 100, 75) > > Color.gray(127) > Border.gray(127) > Background.gray(127) > > Color.web("orange", 0.5) > Border.web("orange", 0.5) > Background.web("orange", 0.5) > > We could also mirror the named color constants, which would enable a > very compact syntax: > > StackPane pane = new StackPane(); > pane.setBorder(Border.RED); > pane.setBackground(Background.BLUE); > > This is very similar to how "red" or "blue" are valid values for > "-fx-border" or "-fx-background" in CSS. > From michaelstrau2 at gmail.com Mon Jun 7 23:42:42 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 8 Jun 2021 01:42:42 +0200 Subject: Support :focus-visible CSS pseudoclass In-Reply-To: References: Message-ID: I have added the following sentences to the JBS issue to clarify that there will be no change for existing applications: > The new "focusVisible" and "focusWithin" properties do not change the semantics of the existing "focused" property. > Existing JavaFX themes will not be impacted by this change. I will also note that the motivation for this proposal was primarily to support modality-aware focus indication, which has historically been more important for desktop applications than for web applications (as evidenced by many desktop OS themes). So the cost-benefit tradeoff is probably different than for the web. From kevin.rushforth at oracle.com Mon Jun 7 23:50:28 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 7 Jun 2021 16:50:28 -0700 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: If I recall, there were a few developers that chimed in. It's a simple enough addition -- at least your original proposal (not the suggestion of mirroring the Color API, which I don't like) -- that it seems OK to me. Can you repost your currently proposed API and see if those who might like to use it are satisfied with it? -- Kevin On 6/7/2021 4:41 PM, Nir Lisker wrote: > Does this constitute sufficient interest in the enhancement? > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > > wrote: > > Another option could be to mirror the `Color` API in both `Border` and > `Background`, like in the following examples: > > Color.rgb(125, 100, 75) > Border.rgb(125, 100, 75) > Background.rgb(125, 100, 75) > > Color.gray(127) > Border.gray(127) > Background.gray(127) > > Color.web("orange", 0.5) > Border.web("orange", 0.5) > Background.web("orange", 0.5) > > We could also mirror the named color constants, which would enable a > very compact syntax: > > StackPane pane = new StackPane(); > pane.setBorder(Border.RED); > pane.setBackground(Background.BLUE); > > This is very similar to how "red" or "blue" are valid values for > "-fx-border" or "-fx-background" in CSS. > From nlisker at gmail.com Tue Jun 8 01:19:41 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 8 Jun 2021 04:19:41 +0300 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: The new API: 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` that does `new Border(new BorderStroke(Paint stroke , BorderStrokeStyle.SOLID, null, null));` 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` that does `new Background(new BackgroundFill(Paint fill, null, null));` I don't mind either name choice. On Tue, Jun 8, 2021 at 2:50 AM Kevin Rushforth wrote: > If I recall, there were a few developers that chimed in. It's a simple > enough addition -- at least your original proposal (not the suggestion of > mirroring the Color API, which I don't like) -- that it seems OK to me. > > Can you repost your currently proposed API and see if those who might like > to use it are satisfied with it? > > -- Kevin > > > On 6/7/2021 4:41 PM, Nir Lisker wrote: > > Does this constitute sufficient interest in the enhancement? > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > wrote: > >> Another option could be to mirror the `Color` API in both `Border` and >> `Background`, like in the following examples: >> >> Color.rgb(125, 100, 75) >> Border.rgb(125, 100, 75) >> Background.rgb(125, 100, 75) >> >> Color.gray(127) >> Border.gray(127) >> Background.gray(127) >> >> Color.web("orange", 0.5) >> Border.web("orange", 0.5) >> Background.web("orange", 0.5) >> >> We could also mirror the named color constants, which would enable a >> very compact syntax: >> >> StackPane pane = new StackPane(); >> pane.setBorder(Border.RED); >> pane.setBackground(Background.BLUE); >> >> This is very similar to how "red" or "blue" are valid values for >> "-fx-border" or "-fx-background" in CSS. >> > > From michaelstrau2 at gmail.com Tue Jun 8 02:21:01 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 8 Jun 2021 04:21:01 +0200 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: What do you think about this variation? Border.solid(Paint color, double width) -> new Border(new BorderStroke(color, BorderStrokeStyle.SOLID, null, new BorderWidths(width))) Border.dashed(Paint color, double width) -> new Border(new BorderStroke(color, BorderStrokeStyle.DASHED, null, new BorderWidths(width))) Border.dotted(Paint color, double width) -> new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED, null, new BorderWidths(width))) Background.fill(Paint color) -> new BackgroundFill(color, null, null) This gives developers a good deal of customizability before needing to fall back to using constructors. Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker : > > The new API: > > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` that does > `new Border(new BorderStroke(Paint stroke , BorderStrokeStyle.SOLID, null, > null));` > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` that does > `new Background(new BackgroundFill(Paint fill, null, null));` > > I don't mind either name choice. > From tom.schindl at bestsolution.at Tue Jun 8 06:55:04 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 8 Jun 2021 08:55:04 +0200 Subject: Support :focus-visible CSS pseudoclass In-Reply-To: References: Message-ID: <639d1ca9-beb0-4653-45b1-b5986dc7e6a9@bestsolution.at> Hi, As an application developer I highly appreciate this built-in CSS support. We had to roll our own version for focus-visible and focus-within when implementing our custom controls and L&F but we would leverage this built-in support to remove complexity from our codebase. Beside Microsofts new L&F many Web-UI-Toolkits use this focus-visible-feature (and emulate it while not all browsers support it). How we use focus-visible: ------------------------ I think focus-visible has a fairly narrow scope so we use it to show input focus differently depending on the way an element got focused (mainly mouse-activation vs rest) How we use focus-within: ------------------------ We use focus-within to visiually indicate the area the focus is currently in by changing by lifting or coloring that area. Tom Am 08.06.21 um 01:08 schrieb Kevin Rushforth: > I'd be interested in hearing from application developers as to whether > and how they would use such a feature. As with all non-trivial features, > we don't want to do it if only one or two developers are asking for it. > This seems a reasonably new CSS feature; Firefox just added support in > FF 85 released earlier this year and Safari still doesn't. That suggests > it might be a bit early to adopt this for JavaFX. > > Also, one thing that isn't clear is whether there would be any user > visible change using the standard themes. I presume that the answer is > "no", meaning that unless your stylesheets do anything with > focus-visible, it will not affect the look and feel of the app. That > should be stated explicitly > > I also presume that there would be no application visible changes when > using the standard themes, other than the presence of the two new > read-only boolean properties? > > -- Kevin > > > On 6/7/2021 3:46 PM, Michael Strau? wrote: >> I have expanded the scope of the proposal to include the :focus-within >> pseudo-class, which completes the set of focus-related pseudo-classes. >> >> The updated text of the proposal can be found in the JBS ticket: >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> >> I'm looking forward to comments. > From ajoseph at openjdk.java.net Tue Jun 8 06:55:21 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 8 Jun 2021 06:55:21 GMT Subject: Integrated: 8267858: Document that title property in WebEngine gets updated asynchronously In-Reply-To: References: Message-ID: <8N18ARA6TPLmJ_rZjubhZEWhCd8rxzS60K2GKHe4qr0=.ca10ab2a-db18-4c81-a74b-866fee741472@github.com> On Thu, 27 May 2021 17:25:27 GMT, Arun Joseph wrote: > The title property is not guaranteed to be updated right after the page is loaded, but gets updated asynchronously. This pull request has now been integrated. Changeset: ca250364 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/ca250364aae7a4e071d307ac1091c22776cf9a38 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8267858: Document that title property in WebEngine gets updated asynchronously Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/522 From jvos at openjdk.java.net Tue Jun 8 07:47:30 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 8 Jun 2021 07:47:30 GMT Subject: [jfx11u] RFR: 8216377: JavaFX: memoryleak for initial nodes of Window Message-ID: 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window Add or remove the windowShowingChangedListener when the scene changes Reviewed-by: arapte, kcr ------------- Commit messages: - 8216377: Fix memoryleak for initial nodes of Window Changes: https://git.openjdk.java.net/jfx11u/pull/23/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=23&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8216377 Stats: 120 lines in 2 files changed: 119 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/23.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/23/head:pull/23 PR: https://git.openjdk.java.net/jfx11u/pull/23 From jvos at openjdk.java.net Tue Jun 8 08:41:29 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 8 Jun 2021 08:41:29 GMT Subject: [jfx11u] RFR: 8210199: [linux / macOS] fileChooser can't handle emojis Message-ID: Reviewed-by: pbansal, kcr ------------- Commit messages: - 8210199: [linux / macOS] fileChooser can't handle emojis Changes: https://git.openjdk.java.net/jfx11u/pull/24/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=24&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8210199 Stats: 15 lines in 2 files changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx11u/pull/24.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/24/head:pull/24 PR: https://git.openjdk.java.net/jfx11u/pull/24 From jvos at openjdk.java.net Tue Jun 8 08:43:29 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 8 Jun 2021 08:43:29 GMT Subject: [jfx11u] RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 Message-ID: ?xception: Index 4096 out of bounds for length 4096 Reviewed-by: kcr, arapte ------------- Commit messages: - 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 Changes: https://git.openjdk.java.net/jfx11u/pull/25/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=25&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267314 Stats: 130 lines in 2 files changed: 118 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jfx11u/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/25/head:pull/25 PR: https://git.openjdk.java.net/jfx11u/pull/25 From nlisker at gmail.com Tue Jun 8 11:25:04 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 8 Jun 2021 14:25:04 +0300 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: Are dashed and dotted used frequently? I find that I only use solid unless I'm doing something fancy. On Tue, Jun 8, 2021 at 5:21 AM Michael Strau? wrote: > What do you think about this variation? > > Border.solid(Paint color, double width) -> > new Border(new BorderStroke(color, BorderStrokeStyle.SOLID, > null, new BorderWidths(width))) > > Border.dashed(Paint color, double width) -> > new Border(new BorderStroke(color, BorderStrokeStyle.DASHED, > null, new BorderWidths(width))) > > Border.dotted(Paint color, double width) -> > new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED, > null, new BorderWidths(width))) > > Background.fill(Paint color) -> > new BackgroundFill(color, null, null) > > This gives developers a good deal of customizability before needing to > fall back to using constructors. > > > Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker : > > > > The new API: > > > > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` that does > > `new Border(new BorderStroke(Paint stroke , BorderStrokeStyle.SOLID, > null, > > null));` > > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` that > does > > `new Background(new BackgroundFill(Paint fill, null, null));` > > > > I don't mind either name choice. > > > From arapte at openjdk.java.net Tue Jun 8 11:51:32 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 8 Jun 2021 11:51:32 GMT Subject: RFR: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene [v2] In-Reply-To: References: Message-ID: > Issue: > There are several issues related to Accelerator of MenuItem of a ConextMenu set on Control. > 1. Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene > 2. Accelerator is not updated correctly when the Control is removed from a Scene and Added to a different Scene > 3. Accelerator is not removed from Scene when the anchor node is removed from Scene and then it's ContextMenu is set to null > > Fix: > The accelerator should be added or removed correctly according to the Scene property of the anchor node. > The issue#3 in above list is only fixed for Button and fails for other Controls. A test is added for this scenario and I shall report a new issue to address it. > Added tests that fails before and pass after the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: update @ignore() with bugid ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/515/files - new: https://git.openjdk.java.net/jfx/pull/515/files/f50a0232..45a4db9b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=515&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=515&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/515.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/515/head:pull/515 PR: https://git.openjdk.java.net/jfx/pull/515 From kcr at openjdk.java.net Tue Jun 8 11:51:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Jun 2021 11:51:33 GMT Subject: RFR: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 11:48:20 GMT, Ambarish Rapte wrote: >> Issue: >> There are several issues related to Accelerator of MenuItem of a ConextMenu set on Control. >> 1. Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene >> 2. Accelerator is not updated correctly when the Control is removed from a Scene and Added to a different Scene >> 3. Accelerator is not removed from Scene when the anchor node is removed from Scene and then it's ContextMenu is set to null >> >> Fix: >> The accelerator should be added or removed correctly according to the Scene property of the anchor node. >> The issue#3 in above list is only fixed for Button and fails for other Controls. A test is added for this scenario and I shall report a new issue to address it. >> Added tests that fails before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > update @ignore() with bugid Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/515 From arapte at openjdk.java.net Tue Jun 8 11:51:34 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 8 Jun 2021 11:51:34 GMT Subject: RFR: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 21:04:51 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> update @ignore() with bugid > > modules/javafx.controls/src/test/java/test/javafx/scene/control/AcceleratorParameterizedTest.java line 352: > >> 350: } >> 351: >> 352: @Ignore("Passes only for Button") > > Can you file the follow-on bug and then update this comment to use that bug ID? Updated with bug ID [JDK-8268374](https://bugs.openjdk.java.net/browse/JDK-8268374) ------------- PR: https://git.openjdk.java.net/jfx/pull/515 From kevin.rushforth at oracle.com Tue Jun 8 13:59:55 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 Jun 2021 06:59:55 -0700 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: <2df57c64-d484-58d6-af61-37edd33254ee@oracle.com> I think that the convenience methods should just cover the most common cases, so I'd rather skip the dotted and dashed variants. It is a good question as to whether there ought to be a variant that takes width. I wouldn't do that as the only method, though. I'd lean towards not taking the width. Once you start getting into more parameters you can just use the constructors without much more trouble. As for the names, I have a slight preference for Border.stroke and Background.fill. -- Kevin On 6/8/2021 4:25 AM, Nir Lisker wrote: > Are dashed and dotted used frequently? I find that I only use solid > unless I'm doing something fancy. > > On Tue, Jun 8, 2021 at 5:21 AM Michael Strau? > wrote: > > What do you think about this variation? > > ? ? Border.solid(Paint color, double width) -> > ? ? ? ? new Border(new BorderStroke(color, BorderStrokeStyle.SOLID, > null, new BorderWidths(width))) > > ? ? Border.dashed(Paint color, double width)? -> > ? ? ? ? new Border(new BorderStroke(color, BorderStrokeStyle.DASHED, > null, new BorderWidths(width))) > > ? ? Border.dotted(Paint color, double width) -> > ? ? ? ? new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED, > null, new BorderWidths(width))) > > ? ? Background.fill(Paint color) -> > ? ? ? ? new BackgroundFill(color, null, null) > > This gives developers a good deal of customizability before needing to > fall back to using constructors. > > > Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker > >: > > > > The new API: > > > > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` > that does > > `new Border(new BorderStroke(Paint stroke , > BorderStrokeStyle.SOLID, null, > > null));` > > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` > that does > > `new Background(new BackgroundFill(Paint fill, null, null));` > > > > I don't mind either name choice. > > > From kcr at openjdk.java.net Tue Jun 8 14:23:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Jun 2021 14:23:26 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: References: Message-ID: <1bbpV4_zJodprFDOTLySmZKs4xA_KP4yV_iURPEulaI=.fd216eb8-dcd9-4ff9-88b0-97f441455d84@github.com> On Mon, 7 Jun 2021 23:38:44 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed doc review comments I reviewed the API docs, and they look good. Can you update the CSR with the latest docs and move it to "Proposed"? ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From pedro.duquevieira at gmail.com Tue Jun 8 15:19:37 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 8 Jun 2021 16:19:37 +0100 Subject: Support :focus-visible CSS pseudoclass Message-ID: Hi, I'm an application developer and a software designer. I've done UI re-design of applications and designs for my clients. I also usually take care of UX. I've also developed a JavaFX theme which has been used by a number of high profile javafx apps and has a significant number of users (developers using it), called JMetro. JMetro is based on Fluent Design and I think it would be great if I could take advantage of this proposed feature. I think this would be great to have and thanks Michael Strau for taking the time and effort to propose and develop it. I also like how new themes can take advantage of this and it's not strictly necessary for the default JavaFX theme to support it. I think we could make the default JavaFX theme support it later. Thanks, -- Pedro Duque Vieira - https://www.pixelduke.com Virus-free. www.avg.com <#m_-5982963222453468535_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From swpalmer at gmail.com Tue Jun 8 15:29:26 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 8 Jun 2021 11:29:26 -0400 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: <2df57c64-d484-58d6-af61-37edd33254ee@oracle.com> References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> <2df57c64-d484-58d6-af61-37edd33254ee@oracle.com> Message-ID: <1BDAB32D-0BF5-4076-935A-F9F35F9EA0EB@gmail.com> +1 for having a variant that takes a width. Colour, width, and radius are the main parameters I need, so a variant that takes all three would help: Border.stroke(Paint p, double width, double radii) (Though to be honest for my larger projects most of the time this stuff is set in a style sheet. It?s smaller tools and utilities that I find this particularly tedious as the verbosity of the code becomes annoying.) Scott > On Jun 8, 2021, at 9:59 AM, Kevin Rushforth wrote: > > I think that the convenience methods should just cover the most common cases, so I'd rather skip the dotted and dashed variants. It is a good question as to whether there ought to be a variant that takes width. I wouldn't do that as the only method, though. I'd lean towards not taking the width. Once you start getting into more parameters you can just use the constructors without much more trouble. > > As for the names, I have a slight preference for Border.stroke and Background.fill. > > -- Kevin > > > On 6/8/2021 4:25 AM, Nir Lisker wrote: >> Are dashed and dotted used frequently? I find that I only use solid unless I'm doing something fancy. >> >> On Tue, Jun 8, 2021 at 5:21 AM Michael Strau? > wrote: >> >> What do you think about this variation? >> >> Border.solid(Paint color, double width) -> >> new Border(new BorderStroke(color, BorderStrokeStyle.SOLID, >> null, new BorderWidths(width))) >> >> Border.dashed(Paint color, double width) -> >> new Border(new BorderStroke(color, BorderStrokeStyle.DASHED, >> null, new BorderWidths(width))) >> >> Border.dotted(Paint color, double width) -> >> new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED, >> null, new BorderWidths(width))) >> >> Background.fill(Paint color) -> >> new BackgroundFill(color, null, null) >> >> This gives developers a good deal of customizability before needing to >> fall back to using constructors. >> >> >> Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker >> >: >> > >> > The new API: >> > >> > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` >> that does >> > `new Border(new BorderStroke(Paint stroke , >> BorderStrokeStyle.SOLID, null, >> > null));` >> > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` >> that does >> > `new Background(new BackgroundFill(Paint fill, null, null));` >> > >> > I don't mind either name choice. >> > >> > From william.h.duquette at jpl.nasa.gov Tue Jun 8 20:32:14 2021 From: william.h.duquette at jpl.nasa.gov (Duquette, Will (US 397J)) Date: Tue, 8 Jun 2021 20:32:14 +0000 Subject: Looked-up color fails for -fx-background-color in JavaFX CSS file Message-ID: Howdy! I'm migrating a code-base from JavaFX 8 to JavaFX 11, and I'm seeing some weird behavior. I have some CSS that looks like this (in part) .root { -theme-button: #0679DE; } .button-primary { -fx-background-color: -theme-button; } It's been working great in JavaFX 8 for quite a long while. When I load the same app, I get messages like this written to the console. Jun 08, 2021 10:40:07 AM javafx.scene.CssStyleHelper calculateValue WARNING: Caught 'java.lang.ClassCastException: class java.lang.String cannot be cast to class javafx.scene.paint.Paint (java.lang.String is in module java.base of loader 'bootstrap'; javafx.scene.paint.Paint is in module javafx.graphics at 11.0.11 of loader 'platform')' while converting value for '-fx-background-color' from rule '*.button-primary' in stylesheet file:/Users/will/github/dgs-tool/out/production/dgs-lib/dsn-dark.css Surprisingly, the color seems to still get set?but warnings written to the console are worrying. If I replace -theme-button with #0679DE in the .button-primary style, the message goes away. I'm seeing this for -fx-background-color and -fx-border-color, but not for any other places where I use looked-up colors. Any ideas? From william.h.duquette at jpl.nasa.gov Tue Jun 8 21:12:34 2021 From: william.h.duquette at jpl.nasa.gov (Duquette, Will (US 397J)) Date: Tue, 8 Jun 2021 21:12:34 +0000 Subject: [EXTERNAL] Looked-up color fails for -fx-background-color in JavaFX CSS file Message-ID: The problem arises when I switch out the stylesheet for an active GUI, with code like this: root.getStylesheets().clear() root.getStylesheets().add(styleSheetURL) It's the clear() that's the problem. If add the new stylesheet and then remove the old one, no messages are produced. I have a simple test program, if you'd like to have this submitted to a bug tracker. Will Duquette ?On 6/8/21, 1:33 PM, "openjfx-dev on behalf of Duquette, Will (US 397J)" wrote: Howdy! I'm migrating a code-base from JavaFX 8 to JavaFX 11, and I'm seeing some weird behavior. I have some CSS that looks like this (in part) .root { -theme-button: #0679DE; } .button-primary { -fx-background-color: -theme-button; } It's been working great in JavaFX 8 for quite a long while. When I load the same app, I get messages like this written to the console. Jun 08, 2021 10:40:07 AM javafx.scene.CssStyleHelper calculateValue WARNING: Caught 'java.lang.ClassCastException: class java.lang.String cannot be cast to class javafx.scene.paint.Paint (java.lang.String is in module java.base of loader 'bootstrap'; javafx.scene.paint.Paint is in module javafx.graphics at 11.0.11 of loader 'platform')' while converting value for '-fx-background-color' from rule '*.button-primary' in stylesheet file:/Users/will/github/dgs-tool/out/production/dgs-lib/dsn-dark.css Surprisingly, the color seems to still get set?but warnings written to the console are worrying. If I replace -theme-button with #0679DE in the .button-primary style, the message goes away. I'm seeing this for -fx-background-color and -fx-border-color, but not for any other places where I use looked-up colors. Any ideas? From kcr at openjdk.java.net Tue Jun 8 21:21:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Jun 2021 21:21:18 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 23:38:44 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed doc review comments I've finished reviewing the code for everything except the shaders themselves. That will be later this week I hope. I left a few comments on the tests. I also have one suggestion for an additional system test. It would be useful to test that a `Spotlight` with values that simulate a `PointLight` -- `direction` of `(0, 0, 1)`, `falloff` of 0, `innerAngle` of 0, `outerAngle` of 180 -- produce the same results as a `PointLight`. tests/system/src/test/java/test/javafx/scene/lighting3D/LightingTest.java line 59: > 57: // |/ > 58: // > 59: public class LightingTest { This class can be `abstract`. tests/system/src/test/java/test/javafx/scene/lighting3D/LightingTest.java line 65: > 63: protected static final String FAIL_MESSAGE = "Wrong color value"; > 64: > 65: protected static final int LIGTH_DIST = 60; Typo: `LIGTH_DIST` --> `LIGHT_DIST ` tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 65: > 63: LightingTest.light = LIGHT; > 64: new Thread(() -> Application.launch(TestApp.class, (String[]) null)).start(); > 65: assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(5, TimeUnit.SECONDS)); We should be using at least a 10 second startup timeout. See [JDK-8198587](https://bugs.openjdk.java.net/browse/JDK-8198587). tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 106: > 104: assertEquals(FAIL_MESSAGE, lambertSample * attn, sampledBlue, DELTA); > 105: > 106: Unneeded extra blank line? tests/system/src/test/java/test/javafx/scene/lighting3D/SpotLightAttenuationTest.java line 55: > 53: private static final int OUTSIDE_ANGLE_SAMPLE = 42; > 54: > 55: private static final double[] FALLOFF_FACTORS = new double[] {0.5, 1, 1}; Should that last value be `> 1` to test that case? tests/system/src/test/java/test/javafx/scene/lighting3D/SpotLightAttenuationTest.java line 68: > 66: LightingTest.light = LIGHT; > 67: new Thread(() -> Application.launch(TestApp.class, (String[]) null)).start(); > 68: assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(5, TimeUnit.SECONDS)); 10 seconds ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kevin.rushforth at oracle.com Tue Jun 8 21:27:45 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 Jun 2021 14:27:45 -0700 Subject: [EXTERNAL] Looked-up color fails for -fx-background-color in JavaFX CSS file In-Reply-To: References: Message-ID: If you have a test program, can you file it here? https://bugreport.java.com/ Thanks. -- Kevin On 6/8/2021 2:12 PM, Duquette, Will (US 397J) wrote: > The problem arises when I switch out the stylesheet for an active GUI, with code like this: > > root.getStylesheets().clear() > root.getStylesheets().add(styleSheetURL) > > It's the clear() that's the problem. If add the new stylesheet and then remove the old one, no messages are produced. > > I have a simple test program, if you'd like to have this submitted to a bug tracker. > > Will Duquette > > ?On 6/8/21, 1:33 PM, "openjfx-dev on behalf of Duquette, Will (US 397J)" wrote: > > Howdy! > > I'm migrating a code-base from JavaFX 8 to JavaFX 11, and I'm seeing some weird behavior. I have some CSS that looks like this (in part) > > .root { > -theme-button: #0679DE; > } > > .button-primary { > -fx-background-color: -theme-button; > } > > It's been working great in JavaFX 8 for quite a long while. When I load the same app, I get messages like this written to the console. > > Jun 08, 2021 10:40:07 AM javafx.scene.CssStyleHelper calculateValue > WARNING: Caught 'java.lang.ClassCastException: class java.lang.String cannot be cast to class javafx.scene.paint.Paint (java.lang.String is in module java.base of loader 'bootstrap'; javafx.scene.paint.Paint is in module javafx.graphics at 11.0.11 of loader 'platform')' while converting value for '-fx-background-color' from rule '*.button-primary' in stylesheet file:/Users/will/github/dgs-tool/out/production/dgs-lib/dsn-dark.css > > Surprisingly, the color seems to still get set?but warnings written to the console are worrying. > > If I replace -theme-button with #0679DE in the .button-primary style, the message goes away. > > I'm seeing this for -fx-background-color and -fx-border-color, but not for any other places where I use looked-up colors. > > Any ideas? > > > From kcr at openjdk.java.net Tue Jun 8 21:28:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Jun 2021 21:28:17 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 23:38:44 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed doc review comments One more comment about this PR. As I mentioned earlier, I am no longer able to test lighting on my Ubuntu 20.04 Linux Guest running in VirtualBox on my Windows 10 Host. In this mode I have to set `-Dprism.forceGPU=true` to get any 3D support at all, so it isn't a supported config, but point lights used to run before spotlight support was added to the shaders, and no longer do. This is not a stopper, but makes it harder for me to test (I need to arrange to get temporary access to a physical Linux box). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kevin.rushforth at oracle.com Tue Jun 8 21:40:06 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 Jun 2021 14:40:06 -0700 Subject: Support :focus-visible CSS pseudoclass In-Reply-To: <639d1ca9-beb0-4653-45b1-b5986dc7e6a9@bestsolution.at> References: <639d1ca9-beb0-4653-45b1-b5986dc7e6a9@bestsolution.at> Message-ID: Thanks to Tom and Pedro for their replies. That's good to know. Michael: It does sound like this is a generally useful feature to do in the near future, so it makes sense to proceed with the review. I presume that the API as you have described it in the JBS description is what you are currently proposing? If so, I'll take a look at the API + docs in the next couple of days and we can take it from there. As with any non-trivial feature, we won't rush it in -- it will go in when it's ready -- so it may already be too late for JavaFX 17, especially given the care that needs to be taken for any new CSS feature, and the number of other things in flight for JavaFX 17. -- Kevin On 6/7/2021 11:55 PM, Tom Schindl wrote: > Hi, > > As an application developer I highly appreciate this built-in CSS > support. > > We had to roll our own version for focus-visible and focus-within when > implementing our custom controls and L&F but we would leverage this > built-in support to remove complexity from our codebase. > > Beside Microsofts new L&F many Web-UI-Toolkits use this > focus-visible-feature (and emulate it while not all browsers support it). > > How we use focus-visible: > ------------------------ > I think focus-visible has a fairly narrow scope so we use it to show > input focus differently depending on the way an element got focused > (mainly mouse-activation vs rest) > > How we use focus-within: > ------------------------ > We use focus-within to visiually indicate the area the focus is > currently in by changing by lifting or coloring that area. > > Tom > > Am 08.06.21 um 01:08 schrieb Kevin Rushforth: >> I'd be interested in hearing from application developers as to >> whether and how they would use such a feature. As with all >> non-trivial features, we don't want to do it if only one or two >> developers are asking for it. This seems a reasonably new CSS >> feature; Firefox just added support in FF 85 released earlier this >> year and Safari still doesn't. That suggests it might be a bit early >> to adopt this for JavaFX. >> >> Also, one thing that isn't clear is whether there would be any user >> visible change using the standard themes. I presume that the answer >> is "no", meaning that unless your stylesheets do anything with >> focus-visible, it will not affect the look and feel of the app. That >> should be stated explicitly >> >> I also presume that there would be no application visible changes >> when using the standard themes, other than the presence of the two >> new read-only boolean properties? >> >> -- Kevin >> >> >> On 6/7/2021 3:46 PM, Michael Strau? wrote: >>> I have expanded the scope of the proposal to include the :focus-within >>> pseudo-class, which completes the set of focus-related pseudo-classes. >>> >>> The updated text of the proposal can be found in the JBS ticket: >>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>> >>> I'm looking forward to comments. >> From michaelstrau2 at gmail.com Tue Jun 8 23:13:15 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 9 Jun 2021 01:13:15 +0200 Subject: Support :focus-visible CSS pseudoclass In-Reply-To: References: <639d1ca9-beb0-4653-45b1-b5986dc7e6a9@bestsolution.at> Message-ID: > Michael: It does sound like this is a generally useful feature to do in > the near future, so it makes sense to proceed with the review. I presume > that the API as you have described it in the JBS description is what you > are currently proposing? If so, I'll take a look at the API + docs in > the next couple of days and we can take it from there. Yes, the JBS issue has the latest version of my proposal for this feature: https://bugs.openjdk.java.net/browse/JDK-8268225 From nlisker at gmail.com Wed Jun 9 00:22:18 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 9 Jun 2021 03:22:18 +0300 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: <1BDAB32D-0BF5-4076-935A-F9F35F9EA0EB@gmail.com> References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> <2df57c64-d484-58d6-af61-37edd33254ee@oracle.com> <1BDAB32D-0BF5-4076-935A-F9F35F9EA0EB@gmail.com> Message-ID: > > (Though to be honest for my larger projects most of the time this stuff is > set in a style sheet. It?s smaller tools and utilities that I find this > particularly tedious as the verbosity of the code becomes annoying.) > This was exactly my original question. If people use css most for most cases, what do the small tools and utilities use? Width I can understand, but is radius common enough for simple cases? On Tue, Jun 8, 2021 at 6:47 PM Scott Palmer wrote: > +1 for having a variant that takes a width. Colour, width, and radius are > the main parameters I need, so a variant that takes all three would help: > > Border.stroke(Paint p, double width, double radii) > > (Though to be honest for my larger projects most of the time this stuff is > set in a style sheet. It?s smaller tools and utilities that I find this > particularly tedious as the verbosity of the code becomes annoying.) > > Scott > > > On Jun 8, 2021, at 9:59 AM, Kevin Rushforth > wrote: > > > > I think that the convenience methods should just cover the most common > cases, so I'd rather skip the dotted and dashed variants. It is a good > question as to whether there ought to be a variant that takes width. I > wouldn't do that as the only method, though. I'd lean towards not taking > the width. Once you start getting into more parameters you can just use the > constructors without much more trouble. > > > > As for the names, I have a slight preference for Border.stroke and > Background.fill. > > > > -- Kevin > > > > > > On 6/8/2021 4:25 AM, Nir Lisker wrote: > >> Are dashed and dotted used frequently? I find that I only use solid > unless I'm doing something fancy. > >> > >> On Tue, Jun 8, 2021 at 5:21 AM Michael Strau? > wrote: > >> > >> What do you think about this variation? > >> > >> Border.solid(Paint color, double width) -> > >> new Border(new BorderStroke(color, BorderStrokeStyle.SOLID, > >> null, new BorderWidths(width))) > >> > >> Border.dashed(Paint color, double width) -> > >> new Border(new BorderStroke(color, BorderStrokeStyle.DASHED, > >> null, new BorderWidths(width))) > >> > >> Border.dotted(Paint color, double width) -> > >> new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED, > >> null, new BorderWidths(width))) > >> > >> Background.fill(Paint color) -> > >> new BackgroundFill(color, null, null) > >> > >> This gives developers a good deal of customizability before needing > to > >> fall back to using constructors. > >> > >> > >> Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker > >> >: > >> > > >> > The new API: > >> > > >> > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` > >> that does > >> > `new Border(new BorderStroke(Paint stroke , > >> BorderStrokeStyle.SOLID, null, > >> > null));` > >> > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` > >> that does > >> > `new Background(new BackgroundFill(Paint fill, null, null));` > >> > > >> > I don't mind either name choice. > >> > > >> > > > > From jvos at openjdk.java.net Wed Jun 9 08:11:17 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Jun 2021 08:11:17 GMT Subject: [jfx11u] Integrated: 8216377: JavaFX: memoryleak for initial nodes of Window In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 07:42:19 GMT, Johan Vos wrote: > 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window > > Add or remove the windowShowingChangedListener when the scene changes > > Reviewed-by: arapte, kcr This pull request has now been integrated. Changeset: 8af39d66 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/8af39d66924ec1a958894c2b10ee50285f21e251 Stats: 120 lines in 2 files changed: 119 ins; 0 del; 1 mod 8216377: JavaFX: memoryleak for initial nodes of Window 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window Add or remove the windowShowingChangedListener when the scene changes Backport-of: e21606d3a1b73cd4b44383babc750a4b4721edfd ------------- PR: https://git.openjdk.java.net/jfx11u/pull/23 From jvos at openjdk.java.net Wed Jun 9 08:16:18 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Jun 2021 08:16:18 GMT Subject: [jfx11u] Integrated: 8210199: [linux / macOS] fileChooser can't handle emojis In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 08:34:30 GMT, Johan Vos wrote: > Reviewed-by: pbansal, kcr This pull request has now been integrated. Changeset: 259cd4f9 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/259cd4f91b050263a178079966b5f71e5a21b207 Stats: 15 lines in 2 files changed: 12 ins; 0 del; 3 mod 8210199: [linux / macOS] fileChooser can't handle emojis Backport-of: aebac072b1919e68f7732de929dc085d00c62e92 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/24 From jvos at openjdk.java.net Wed Jun 9 08:20:15 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Jun 2021 08:20:15 GMT Subject: [jfx11u] Integrated: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 08:37:45 GMT, Johan Vos wrote: > ?xception: Index 4096 out of bounds for length 4096 > > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: db9b1b74 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/db9b1b74408a78353af331a048c9b7165c143cec Stats: 130 lines in 2 files changed: 118 ins; 1 del; 11 mod 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 Backport-of: 7b7050c46299c0e6771ae02fbb5ceaf22104d3e4 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/25 From aghaisas at openjdk.java.net Wed Jun 9 10:36:16 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 9 Jun 2021 10:36:16 GMT Subject: RFR: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 11:51:32 GMT, Ambarish Rapte wrote: >> Issue: >> There are several issues related to Accelerator of MenuItem of a ConextMenu set on Control. >> 1. Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene >> 2. Accelerator is not updated correctly when the Control is removed from a Scene and Added to a different Scene >> 3. Accelerator is not removed from Scene when the anchor node is removed from Scene and then it's ContextMenu is set to null >> >> Fix: >> The accelerator should be added or removed correctly according to the Scene property of the anchor node. >> The issue#3 in above list is only fixed for Button and fails for other Controls. A test is added for this scenario and I shall report a new issue to address it. >> Added tests that fails before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > update @ignore() with bugid Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/515 From hjohn at xs4all.nl Wed Jun 9 11:59:55 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 9 Jun 2021 13:59:55 +0200 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: <1BDAB32D-0BF5-4076-935A-F9F35F9EA0EB@gmail.com> References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> <2df57c64-d484-58d6-af61-37edd33254ee@oracle.com> <1BDAB32D-0BF5-4076-935A-F9F35F9EA0EB@gmail.com> Message-ID: <1dd6be35-9032-f238-866d-9577a1b92d32@xs4all.nl> I'm not entirely convinced taking width is all that useful. The (final) pxiel width of a border is normally a calculated value based on the chosen unit and scaling needs of the platform. A lot of methods in JavaFX work with pixel values only, while for proper scaling I often find myself needing a different unit, in which case CSS is the only option. Perhaps however this is a different issue, as it would apply to much more than just borders. --John On 08/06/2021 17:29, Scott Palmer wrote: > +1 for having a variant that takes a width. Colour, width, and radius are the main parameters I need, so a variant that takes all three would help: > > Border.stroke(Paint p, double width, double radii) > > (Though to be honest for my larger projects most of the time this stuff is set in a style sheet. It?s smaller tools and utilities that I find this particularly tedious as the verbosity of the code becomes annoying.) > > Scott > >> On Jun 8, 2021, at 9:59 AM, Kevin Rushforth wrote: >> >> I think that the convenience methods should just cover the most common cases, so I'd rather skip the dotted and dashed variants. It is a good question as to whether there ought to be a variant that takes width. I wouldn't do that as the only method, though. I'd lean towards not taking the width. Once you start getting into more parameters you can just use the constructors without much more trouble. >> >> As for the names, I have a slight preference for Border.stroke and Background.fill. >> >> -- Kevin >> >> >> On 6/8/2021 4:25 AM, Nir Lisker wrote: >>> Are dashed and dotted used frequently? I find that I only use solid unless I'm doing something fancy. >>> >>> On Tue, Jun 8, 2021 at 5:21 AM Michael Strau? > wrote: >>> >>> What do you think about this variation? >>> >>> Border.solid(Paint color, double width) -> >>> new Border(new BorderStroke(color, BorderStrokeStyle.SOLID, >>> null, new BorderWidths(width))) >>> >>> Border.dashed(Paint color, double width) -> >>> new Border(new BorderStroke(color, BorderStrokeStyle.DASHED, >>> null, new BorderWidths(width))) >>> >>> Border.dotted(Paint color, double width) -> >>> new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED, >>> null, new BorderWidths(width))) >>> >>> Background.fill(Paint color) -> >>> new BackgroundFill(color, null, null) >>> >>> This gives developers a good deal of customizability before needing to >>> fall back to using constructors. >>> >>> >>> Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker >>> >: >>> > >>> > The new API: >>> > >>> > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` >>> that does >>> > `new Border(new BorderStroke(Paint stroke , >>> BorderStrokeStyle.SOLID, null, >>> > null));` >>> > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` >>> that does >>> > `new Background(new BackgroundFill(Paint fill, null, null));` >>> > >>> > I don't mind either name choice. >>> > >>> >> > From nmrview at mac.com Wed Jun 9 12:21:07 2021 From: nmrview at mac.com (Bruce Johnson) Date: Wed, 9 Jun 2021 08:21:07 -0400 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: <1dd6be35-9032-f238-866d-9577a1b92d32@xs4all.nl> References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> <2df57c64-d484-58d6-af61-37edd33254ee@oracle.com> <1BDAB32D-0BF5-4076-935A-F9F35F9EA0EB@gmail.com> <1dd6be35-9032-f238-866d-9577a1b92d32@xs4all.nl> Message-ID: <8E51BEDA-F581-4FF2-A5E9-862F0FF9E345@mac.com> I very much like the idea of a simpler way to create Borders and Backgrounds, but once you get beyond the original proposal of Border.stroke(Paint stroke), it seems like a case where a fluent interface would be useful. The alternatives of multiple argument constructors just start getting back into more complexity and debates about who needs what combination of options supported. So if one wanted a simple border: Border.stroke(Color.RED) but if you want to set width and styles you could do something like: Border.stroke(Color.RED).width(3).dotted(); ?Bruce > On Jun 9, 2021, at 7:59 AM, John Hendrikx wrote: > > I'm not entirely convinced taking width is all that useful. The (final) pxiel width of a border is normally a calculated value based on the chosen unit and scaling needs of the platform. > > A lot of methods in JavaFX work with pixel values only, while for proper scaling I often find myself needing a different unit, in which case CSS is the only option. > > Perhaps however this is a different issue, as it would apply to much more than just borders. > > --John > > On 08/06/2021 17:29, Scott Palmer wrote: >> +1 for having a variant that takes a width. Colour, width, and radius are the main parameters I need, so a variant that takes all three would help: >> >> Border.stroke(Paint p, double width, double radii) >> >> (Though to be honest for my larger projects most of the time this stuff is set in a style sheet. It?s smaller tools and utilities that I find this particularly tedious as the verbosity of the code becomes annoying.) >> >> Scott >> >>> On Jun 8, 2021, at 9:59 AM, Kevin Rushforth wrote: >>> >>> I think that the convenience methods should just cover the most common cases, so I'd rather skip the dotted and dashed variants. It is a good question as to whether there ought to be a variant that takes width. I wouldn't do that as the only method, though. I'd lean towards not taking the width. Once you start getting into more parameters you can just use the constructors without much more trouble. >>> >>> As for the names, I have a slight preference for Border.stroke and Background.fill. >>> >>> -- Kevin >>> >>> >>> On 6/8/2021 4:25 AM, Nir Lisker wrote: >>>> Are dashed and dotted used frequently? I find that I only use solid unless I'm doing something fancy. >>>> >>>> On Tue, Jun 8, 2021 at 5:21 AM Michael Strau? > wrote: >>>> >>>> What do you think about this variation? >>>> >>>> Border.solid(Paint color, double width) -> >>>> new Border(new BorderStroke(color, BorderStrokeStyle.SOLID, >>>> null, new BorderWidths(width))) >>>> >>>> Border.dashed(Paint color, double width) -> >>>> new Border(new BorderStroke(color, BorderStrokeStyle.DASHED, >>>> null, new BorderWidths(width))) >>>> >>>> Border.dotted(Paint color, double width) -> >>>> new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED, >>>> null, new BorderWidths(width))) >>>> >>>> Background.fill(Paint color) -> >>>> new BackgroundFill(color, null, null) >>>> >>>> This gives developers a good deal of customizability before needing to >>>> fall back to using constructors. >>>> >>>> >>>> Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker >>>> >: >>>> > >>>> > The new API: >>>> > >>>> > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` >>>> that does >>>> > `new Border(new BorderStroke(Paint stroke , >>>> BorderStrokeStyle.SOLID, null, >>>> > null));` >>>> > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` >>>> that does >>>> > `new Background(new BackgroundFill(Paint fill, null, null));` >>>> > >>>> > I don't mind either name choice. >>>> > >>>> >>> >> From kcr at openjdk.java.net Wed Jun 9 13:09:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Jun 2021 13:09:19 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:17:27 GMT, Michael Strau? wrote: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. I took an initial pass at the API docs. I have a couple global comments. First, can you reorder the properties and their associated methods such that they are grouped together? If the docs are on the (private) field, which is what we usually do, it should be followed immediately by the associated setter (if any), getter, and property methods. The order should be: /** * EXISTING API DOCS FOR FOCUSED PROPERTY */ private FocusPropertyBase focused; protected final void setFocused(boolean value) { public final boolean isFocused() { public final ReadOnlyBooleanProperty focusedProperty() { /** * API DOCS FOR NEW FOCUSVISIBLE PROPERTY */ private FocusPropertyBase focusVisible; public final boolean isFocusVisible() { public final ReadOnlyBooleanProperty focusVisibleProperty() { ... Second, the two new properties need both a `@defaultValue` and an `@since NN` tag. You can optimistically use `@since 17` or you can use `@since 18` (the latter is more likely). modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8167: > 8165: /** > 8166: * Indicates whether this {@code Node} should visibly indicate focus. > 8167: * This flag is set when a node acquired input focus via keyboard navigation, `acquired` --> `acquires` ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From kcr at openjdk.java.net Wed Jun 9 13:38:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Jun 2021 13:38:16 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v16] In-Reply-To: <7GKKu6Lc5iF1vBfztwG8rLA-4wvk4jW3tEJCBJ2dkZA=.34d72e93-1514-45b0-b3bd-737ba5a8b51e@github.com> References: <7GKKu6Lc5iF1vBfztwG8rLA-4wvk4jW3tEJCBJ2dkZA=.34d72e93-1514-45b0-b3bd-737ba5a8b51e@github.com> Message-ID: On Sat, 5 Jun 2021 17:31:17 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added comment, simplified DataURI.matchScheme() The docs look good. I left one minor comment inline. You can update the CSR when ready. As I mentioned in a comment in the CSR, the `Specification` section should consist of the diffs to the API documentation. Make sure you note what API element (e.g., class doc, `Image(String url)` constructor, and so forth) each change is for, if it isn't clear from the diffs. You can omit the removal of the `

    ` html tags and the change from `example.` to `example:` from the diffs in the CSR. modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 95: > 93: * the protocol handlers that are registered for the application. > 94: * > 95: *

    If a URL uses the "data" scheme, the data must be base64-encoded I think these two sentences should be in the same paragraph. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Wed Jun 9 14:18:41 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Jun 2021 14:18:41 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2] In-Reply-To: References: Message-ID: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - wording - Re-ordered methods ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/7b3efd29..cf1daa2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=00-01 Stats: 65 lines in 2 files changed: 35 ins; 30 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Wed Jun 9 14:18:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Jun 2021 14:18:43 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 13:01:17 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - wording >> - Re-ordered methods > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8167: > >> 8165: /** >> 8166: * Indicates whether this {@code Node} should visibly indicate focus. >> 8167: * This flag is set when a node acquired input focus via keyboard navigation, > > `acquired` --> `acquires` Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Wed Jun 9 14:20:42 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Jun 2021 14:20:42 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v16] In-Reply-To: References: <7GKKu6Lc5iF1vBfztwG8rLA-4wvk4jW3tEJCBJ2dkZA=.34d72e93-1514-45b0-b3bd-737ba5a8b51e@github.com> Message-ID: On Wed, 9 Jun 2021 13:18:29 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> added comment, simplified DataURI.matchScheme() > > modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 95: > >> 93: * the protocol handlers that are registered for the application. >> 94: * >> 95: *

    If a URL uses the "data" scheme, the data must be base64-encoded > > I think these two sentences should be in the same paragraph. Ok. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Wed Jun 9 14:20:41 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Jun 2021 14:20:41 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v17] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: doc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/e490cc04..ed498ef6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=15-16 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Wed Jun 9 14:39:18 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Jun 2021 14:39:18 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v17] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 14:20:41 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > doc I've updated the CSR with the documentation diffs. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From github.com+85555697+andreas-heger at openjdk.java.net Wed Jun 9 18:06:24 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Wed, 9 Jun 2021 18:06:24 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight Message-ID: The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) ------------- Commit messages: - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays Changes: https://git.openjdk.java.net/jfx/pull/530/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255015 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/530.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/530/head:pull/530 PR: https://git.openjdk.java.net/jfx/pull/530 From github.com+85555697+andreas-heger at openjdk.java.net Wed Jun 9 18:27:32 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Wed, 9 Jun 2021 18:27:32 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight Message-ID: The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) ------------- Commit messages: - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays Changes: https://git.openjdk.java.net/jfx/pull/531/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255015 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531 From github.com+85555697+andreas-heger at openjdk.java.net Wed Jun 9 18:27:37 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Wed, 9 Jun 2021 18:27:37 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v2] In-Reply-To: References: Message-ID: <55IxKpCK8ssJBzfWGHWSkilRgGegVGGivW9nAB4nq80=.8c4e4838-b163-4190-8270-705d873897d5@github.com> > The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug > [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger 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. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/530/files - new: https://git.openjdk.java.net/jfx/pull/530/files/66b361a0..ca250364 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=530&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=530&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/530.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/530/head:pull/530 PR: https://git.openjdk.java.net/jfx/pull/530 From github.com+85555697+andreas-heger at openjdk.java.net Wed Jun 9 18:27:37 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Wed, 9 Jun 2021 18:27:37 GMT Subject: Withdrawn: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 18:02:30 GMT, Andreas Heger wrote: > The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug > [https://bugs.openjdk.java.net/browse/JDK-8255015](url) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/530 From kcr at openjdk.java.net Wed Jun 9 18:49:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Jun 2021 18:49:13 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 18:22:31 GMT, Andreas Heger wrote: > The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) @andreas-heger Welcome to the `jfx` project. At a quick glance, the fix looks promising. Have you tested this on Windows with Hi-DPI to make sure there is no impact? Would you be able add an automated test case that fails (only on Mac retina) without the fix and passes (on all platforms) with your fix? Hi-DPI fixes are often tricky to test in an automated test, so if not, we can use the existing manual test. @nlisker this is the same problem I noted while testing PR #334. Clearly I had forgotten that it was not only a preexisting bug, but a known bug that was already filed. I intend to test this alone and in connection with your PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From github.com+85555697+andreas-heger at openjdk.java.net Wed Jun 9 19:41:14 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Wed, 9 Jun 2021 19:41:14 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 18:46:16 GMT, Kevin Rushforth wrote: > @andreas-heger Welcome to the `jfx` project. At a quick glance, the fix looks promising. Have you tested this on Windows with Hi-DPI to make sure there is no impact? No, I only have got MacOS on retina / non retina and a non Hi-DPI Ubuntu system available for tests, but no Windows. > Would you be able add an automated test case that fails (only on Mac retina) without the fix and passes (on all platforms) with your fix? Hi-DPI fixes are often tricky to test in an automated test, so if not, we can use the existing manual test. I'm not very experienced in automated tests in general and a test which verifies graphic output might be really challenging. I can take a look at it, but please don't expect any results for the next couple of weeks, or any at all. ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From nlisker at openjdk.java.net Wed Jun 9 23:14:13 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 9 Jun 2021 23:14:13 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: <7GgUVS0Ffe-XnxzBC9n5SFdvOjpjrkDD0NIvb8Ux4yE=.5665c358-6bc4-4e82-a399-9fda802b6ed4@github.com> On Wed, 9 Jun 2021 18:46:16 GMT, Kevin Rushforth wrote: > I intend to test this alone and in connection with your PR. Alright. I'll keep an eye on this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From aghaisas at openjdk.java.net Thu Jun 10 10:52:12 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 10 Jun 2021 10:52:12 GMT Subject: RFR: 8267094: TreeCell: cancelEvent must return correct editing location [v2] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 10:34:34 GMT, Jeanette Winzenburg wrote: >> the bug is an incorrect edit location (for tree: treeItem) in edit cancel events - expected is the location at the time the cell edit was started, actual was the location of at the time the edit was cancelled. See the report for details. >> >> Fixed by storing the edit location in startEdit and use that in cancelEdit. >> >> Added tests that failed before and passed after and tests that (accidentally :) passed before and still pass after. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > fixed memory leak introduced in previous version Fix looks good to me. Nicely written tests! Some of them passed without this fix (you have mentioned this in the PR description) - but, good to have them for covering all scenarios. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/524 From fastegal at openjdk.java.net Thu Jun 10 11:40:13 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 10 Jun 2021 11:40:13 GMT Subject: Integrated: 8267094: TreeCell: cancelEvent must return correct editing location In-Reply-To: References: Message-ID: On Fri, 28 May 2021 14:18:42 GMT, Jeanette Winzenburg wrote: > the bug is an incorrect edit location (for tree: treeItem) in edit cancel events - expected is the location at the time the cell edit was started, actual was the location of at the time the edit was cancelled. See the report for details. > > Fixed by storing the edit location in startEdit and use that in cancelEdit. > > Added tests that failed before and passed after and tests that (accidentally :) passed before and still pass after. This pull request has now been integrated. Changeset: e6cf1df4 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/e6cf1df477a78d65e959e4d8f7b5a5de43f845f8 Stats: 196 lines in 3 files changed: 171 ins; 21 del; 4 mod 8267094: TreeCell: cancelEvent must return correct editing location Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/524 From mhanl at openjdk.java.net Thu Jun 10 14:47:51 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 10 Jun 2021 14:47:51 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 04:17:06 GMT, Ambarish Rapte wrote: > I tested with IntelliJ IDEA 2021.1.2 (Community Edition) Build #IC-211.7442.40, built on June 1, 2021. > > I see no side effects of this change. However, I also don't see what you see too. > I tried it with a fresh clone of repository. > The build from IntelliJ's inbuilt terminal worked without this change too, that terminal picks JDK/gradle/ant that was set in bashrc. > > I also don't see the modules in gradle window. Here is the screenshot that I see when the project(with this PR change) is loaded for first time in the IntelliJ. > ![image](https://user-images.githubusercontent.com/11330676/120957254-f6751700-c772-11eb-9fb4-51668d6f4e24.png) This might not work because of the dependency verification error you have in your console. I had this as well and I temporary deleted the **verification-metadata.xml** inside the **gradle** folder. As stated in the mailing list you can also delete the **.gradle** **cache** and **native** folder, but that's the easier way to test it though. Then you can click on the refresh icon in the gradle window and everything should build and then the projects should be visible in the gradle window. ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From nlisker at openjdk.java.net Fri Jun 11 01:07:59 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 11 Jun 2021 01:07:59 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: <1bbpV4_zJodprFDOTLySmZKs4xA_KP4yV_iURPEulaI=.fd216eb8-dcd9-4ff9-88b0-97f441455d84@github.com> References: <1bbpV4_zJodprFDOTLySmZKs4xA_KP4yV_iURPEulaI=.fd216eb8-dcd9-4ff9-88b0-97f441455d84@github.com> Message-ID: On Tue, 8 Jun 2021 14:20:24 GMT, Kevin Rushforth wrote: > I reviewed the API docs, and they look good. Can you update the CSR with the latest docs and move it to "Proposed"? I added a single sentence to the direction property saying `It can be rotated by setting a rotation transform on the {@code SpotLight}.` as mentioned in the class doc. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Fri Jun 11 01:14:53 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 11 Jun 2021 01:14:53 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 14:47:39 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed doc review comments > > tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 65: > >> 63: LightingTest.light = LIGHT; >> 64: new Thread(() -> Application.launch(TestApp.class, (String[]) null)).start(); >> 65: assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(5, TimeUnit.SECONDS)); > > We should be using at least a 10 second startup timeout. See [JDK-8198587](https://bugs.openjdk.java.net/browse/JDK-8198587). I copied this from some other class, so I did a search and found the following tests calling `startupLatch.await` with less than 10 seconds: `HeadlessGeometry1Test` `HeadlessGeometry2Test` `TextNodeTest` ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Fri Jun 11 01:24:57 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 11 Jun 2021 01:24:57 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 14:51:05 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed doc review comments > > tests/system/src/test/java/test/javafx/scene/lighting3D/PointLightAttenuationTest.java line 106: > >> 104: assertEquals(FAIL_MESSAGE, lambertSample * attn, sampledBlue, DELTA); >> 105: >> 106: > > Unneeded extra blank line? I wanted to separated the 2 tests, but a better way was to extract a method. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Fri Jun 11 01:30:27 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 11 Jun 2021 01:30:27 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v22] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/1f17f8ba..f3e2e5bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=20-21 Stats: 37 lines in 4 files changed: 6 ins; 10 del; 21 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 Fri Jun 11 01:37:54 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 11 Jun 2021 01:37:54 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v21] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 21:25:39 GMT, Kevin Rushforth wrote: > (I need to arrange to get temporary access to a physical Linux box). I would hope that Oracle can provide the hardware required to test its only 3D-capable library... :) ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Fri Jun 11 09:11:03 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Jun 2021 09:11:03 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v8] In-Reply-To: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> References: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> Message-ID: On Sat, 29 May 2021 12:31:33 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix tests Fix looks good to me. Provided few minor comments. modules/javafx.base/src/test/java/test/javafx/collections/MockListObserver.java line 174: > 172: assertFalse(tooManyCalls); > 173: assertEquals(1, calls.size()); > 174: } Minor: The `check1` method can be changed to internally call `checkN`. modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 101: > 99: @Override public int getTo() { > 100: checkState(); > 101: return from; How about reverting this change ? modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableListTest.java line 66: > 64: selectedIndices.addAll(0, 1, 2, 3, 4); > 65: assertEquals(1, changes.size()); > 66: assertEquals(change(added(0, "foo", "bar", "baz", "qux", "quz")), changes.get(0)); I would recommend to use the exact string in the expected parameter instead of the helper function. `assertEquals("{ [foo, bar, baz, qux, quz] added at 0 }", changes.get(0));` This way improves readability. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableListTest.java line 107: > 105: */ > 106: @Test > 107: @Ignore("see JDK-8267951") Generally we use only the bug ID here -> @Ignore("JDK-8267951") ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/478 From arapte at openjdk.java.net Fri Jun 11 11:42:00 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Jun 2021 11:42:00 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: <7L8s7FBgIXgIZS5Tw2eeRDpxMgPRYYizMaFdKGQkSD0=.b76290fa-1aa8-4945-bfae-1490ec3cff28@github.com> References: <7L8s7FBgIXgIZS5Tw2eeRDpxMgPRYYizMaFdKGQkSD0=.b76290fa-1aa8-4945-bfae-1490ec3cff28@github.com> Message-ID: On Tue, 25 May 2021 09:36:55 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update documentation > > Hello Nir, could you please merge this branch with latest master. > I think so too. Did you test on Win? Does @arapte want to test these functions too? Yes, I shall test too, and get back to the review... ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Fri Jun 11 16:38:52 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Jun 2021 16:38:52 GMT Subject: Integrated: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:07:12 GMT, Ambarish Rapte wrote: > Issue: > There are several issues related to Accelerator of MenuItem of a ConextMenu set on Control. > 1. Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene > 2. Accelerator is not updated correctly when the Control is removed from a Scene and Added to a different Scene > 3. Accelerator is not removed from Scene when the anchor node is removed from Scene and then it's ContextMenu is set to null > > Fix: > The accelerator should be added or removed correctly according to the Scene property of the anchor node. > The issue#3 in above list is only fixed for Button and fails for other Controls. A test is added for this scenario and I shall report a new issue to address it. > Added tests that fails before and pass after the fix. This pull request has now been integrated. Changeset: 0ffa8e28 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/0ffa8e2824d64b585363ae7a1a51890e1f5b9000 Stats: 125 lines in 2 files changed: 112 ins; 12 del; 1 mod 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/515 From mstrauss at openjdk.java.net Fri Jun 11 20:26:24 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 11 Jun 2021 20:26:24 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9] In-Reply-To: References: Message-ID: > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes as per review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/478/files - new: https://git.openjdk.java.net/jfx/pull/478/files/20fdb393..1672f4da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=07-08 Stats: 53 lines in 3 files changed: 0 ins; 34 del; 19 mod Patch: https://git.openjdk.java.net/jfx/pull/478.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/478/head:pull/478 PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Fri Jun 11 20:40:57 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 11 Jun 2021 20:40:57 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 20:26:24 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes as per review comments Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From kcr at openjdk.java.net Fri Jun 11 23:06:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Jun 2021 23:06:52 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 18:22:31 GMT, Andreas Heger wrote: > The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) The fix looks good. I tested it both in isolation and with PR #334 and it works on both a retina and non-retina display. If you have time to write an automated test, that would be useful, but if not then a manual test would be OK. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGSubScene.java line 211: > 209: // The pixel scale factors must be set to the rttGraphics, otherwise the position > 210: // of the lights will not be scaled correctly on retina displays > 211: // See https://bugs.openjdk.java.net/browse/JDK-8255015 We typically don't put pointers to bug IDs in the code (we used to, and still sometimes do in some special cases, but here it isn't needed). ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From kcr at openjdk.java.net Fri Jun 11 23:30:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Jun 2021 23:30:55 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v22] In-Reply-To: References: Message-ID: <3uFaGzFjRJX2Txl4T7a1UjiYWuxiVa3_w6XDQLFhxMo=.5d88b276-b96a-493b-8407-e6e573ee08ed@github.com> On Fri, 11 Jun 2021 01:30:27 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments I tested this on a somewhat older physical Linux box yesterday. It runs better than it does on my VirtuaBox VM, but there are still regressions. When running the old attenuation.LightingSample sample with the SpotLight patch, on Linux only the last light is applied. For example, if all three lights are selected, only the magenta light is applied. If both red and blue lights are selected, only the blue light is applied. If the red light is selected by itself then it is applied. Without the patch, all selected lights are applied (up to max of 3). The same behavior happens with the new sample when using spot lights. I wonder if this is indicative of using more resources than are available on older graphics cards? I can't spot anything obvious, though. I do note that if I build and force the ES2 pipeline on my Windows 10 system (which is not supported, but is another interesting data point), that runs fine. Here is the output of `java -Dprism.verbose=true`: Prism pipeline init order: es2 sw Using Double Precision Marlin Rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline Maximum supported texture size: 16384 Maximum texture size clamped to 4096 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 4096 Maximum number of uniform fragment components = 4096 Maximum number of varying components = 124 Maximum number of texture units usable in a vertex shader = 32 Maximum number of texture units usable in a fragment shader = 32 Graphics Vendor: NVIDIA Corporation Renderer: Quadro 600/PCIe/SSE2 Version: 4.5.0 NVIDIA 384.130 vsync: true vpipe: true ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From almatvee at openjdk.java.net Sat Jun 12 00:16:02 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 12 Jun 2021 00:16:02 GMT Subject: RFR: 8268219: Investigate gstmpegaudioparse PTS issue Message-ID: - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. After GStreamer update mpregparser no longer tries to figure out timestamps if stream in time format and it will assume that upstream provides timestamps. Fixed by providing starting timestamp at the beginning or after seek. In this case mpegparser able to figure out timestamps and will provide them for each buffer downstream. - Segment start was also incorrect it should be seek position, otherwise after seek playback waits for seek time. For example if we seek to 2 min, mediaplayer hangs for 2 min and only after that resumes playback. I think it worked before, since mpegparser handled PTS before. ------------- Commit messages: - 8268219: Investigate gstmpegaudioparse PTS issue Changes: https://git.openjdk.java.net/jfx/pull/532/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=532&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268219 Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/532.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/532/head:pull/532 PR: https://git.openjdk.java.net/jfx/pull/532 From kcr at openjdk.java.net Sat Jun 12 12:33:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Jun 2021 12:33:52 GMT Subject: RFR: 8268219: Investigate gstmpegaudioparse PTS issue In-Reply-To: References: Message-ID: On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. After GStreamer update mpregparser no longer tries to figure out timestamps if stream in time format and it will assume that upstream provides timestamps. Fixed by providing starting timestamp at the beginning or after seek. In this case mpegparser able to figure out timestamps and will provide them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise after seek playback waits for seek time. For example if we seek to 2 min, mediaplayer hangs for 2 min and only after that resumes playback. I think it worked before, since mpegparser handled PTS before. @sashamatveev Since I presume you are done investigating the problem, can you change the title of the JBS bug and this PR to be more description of the problem being fixed? ------------- PR: https://git.openjdk.java.net/jfx/pull/532 From kcr at openjdk.java.net Sat Jun 12 14:22:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Jun 2021 14:22:55 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v17] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 14:20:41 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > doc I reviewed and tested the implementation. I left a couple questions inline. modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 314: > 312: } > 313: > 314: theStream = new ByteArrayInputStream(dataUri.getData()); By parsing the Data URI before calling `ImageTools.createInputStream` our internal handling will take precedence over a custom handler that an application might have installed. I'm not sure this is what we want. modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 185: > 183: @Override > 184: public String toString() { > 185: if (originalData.length() < 30) { I think this should be `< 32`. As it stands, if length is `30` or `31` the data portion of the string will be 31 characters with either 2 or 3 middle chars replaced by `"..."`. In those cases it would be better to just use the original data. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From arapte at openjdk.java.net Sun Jun 13 07:32:19 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sun, 13 Jun 2021 07:32:19 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v22] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 01:30:27 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments The light color is not applied correctly. I tested on a mac machine, Mac Mojave 10.14.6, Integrated GPU: Intel Iris Graphics 6100 1536 MB. Following is the screenshot with only Magenta SpotLight enabled. ![image](https://user-images.githubusercontent.com/11330676/121798812-224a3e00-cc46-11eb-8b96-75b4addcd763.png) Provided couple minor comments.(Can be addressed anytime later) modules/javafx.graphics/src/main/java/com/sun/javafx/scene/SpotLightHelper.java line 67: > 65: public static void setSpotLightAccessor(final SpotLightAccessor newAccessor) { > 66: if (spotLightAccessor != null) { > 67: throw new IllegalStateException("Accesor already exists"); minor typo: Accesor -> Accessor modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 50: > 48: > 49: bool D3DLight::isPointLight() { > 50: return falloff == 0 && outerAngle == 180; The range for the SpotLight properties is, `{@code 0 <= innerAngle <= outerAngle <= 180} and {@code falloff >= 0};` A SpotLight can be defined as , innerAngle= 30, outerAngle= 180 and falloff= 0. This light will be treated as a PointLight. Do we need also need to check if innerAngle == 0 ? modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 152: > 150: } > 151: > 152: float lighsNormDirection[MAX_NUM_LIGHTS * 4]; // 3 lights x (3 coords + 1 padding) minor typo : lighsNormDirection -> lightsNormDirection ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Sun Jun 13 23:08:22 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 13 Jun 2021 23:08:22 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v23] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/f3e2e5bd..09a0ec42 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=21-22 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Sun Jun 13 23:08:23 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 13 Jun 2021 23:08:23 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v22] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 12:54:43 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 50: > >> 48: >> 49: bool D3DLight::isPointLight() { >> 50: return falloff == 0 && outerAngle == 180; > > The range for the SpotLight properties is, > `{@code 0 <= innerAngle <= outerAngle <= 180} and {@code falloff >= 0};` > A SpotLight can be defined as , innerAngle= 30, outerAngle= 180 and falloff= 0. This light will be treated as a PointLight. Do we need also need to check if innerAngle == 0 ? I don't think so. If the falloff is 0 then the spotlight factor is 1, so points in the inner cone and outer cone are treated the same, ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Mon Jun 14 00:04:00 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 14 Jun 2021 00:04:00 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v23] In-Reply-To: References: Message-ID: On Sun, 13 Jun 2021 23:08:22 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments I retested on Linux Ubuntu 20 with an AMD RX 470, all 3 lights show correctly: ![Screenshot from 2021-06-14 02-52-54](https://user-images.githubusercontent.com/37422899/121825552-c6220100-ccbb-11eb-8854-18c1bc86c87f.png) @arapte If you run the test app without the spotlight patch, but with the attenuation patch, does it work better? ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Mon Jun 14 01:06:25 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 14 Jun 2021 01:06:25 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Updated links in glsl shaders ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/09a0ec42..96e4e5ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=22-23 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 arapte at openjdk.java.net Mon Jun 14 07:05:55 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 14 Jun 2021 07:05:55 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 20:26:24 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes as per review comments Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/478 From arapte at openjdk.java.net Mon Jun 14 07:59:51 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 14 Jun 2021 07:59:51 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 14:45:18 GMT, Marius Hanl wrote: > This might not work because of the dependency verification error you have in your console. I had this as well and I temporary deleted the **verification-metadata.xml** inside the **gradle** folder. Deleting **verification-metadata.xml** temporarily solves the error on my system. The modules and tasks get listed in gradle window. Could execute graphics:test task from the gradle window. The step to delete **verification-metadata.xml** seems acceptable. (May be we should include the whole IntelliJ setup steps with build documentation.) It does not seem like a stopper to me, but would like to get @kevinrushforth 's opinion. ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From mstrauss at openjdk.java.net Mon Jun 14 08:44:29 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 14 Jun 2021 08:44:29 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v18] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes as per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/ed498ef6..5cbfa701 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=16-17 Stats: 23 lines in 2 files changed: 13 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Mon Jun 14 08:50:25 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 14 Jun 2021 08:50:25 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v19] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/5cbfa701..8023fb81 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=17-18 Stats: 17 lines in 1 file changed: 7 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Mon Jun 14 09:11:52 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 14 Jun 2021 09:11:52 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v19] In-Reply-To: References: Message-ID: <4TNlzAFd8mSoLcH-p-JLF6pBx02Zqm1ZX19No7XJ2Dc=.6ebaa414-9b32-4626-abe3-3784d401633d@github.com> On Mon, 14 Jun 2021 08:50:25 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes Made changes as per review. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From github.com+85555697+andreas-heger at openjdk.java.net Mon Jun 14 11:07:57 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Mon, 14 Jun 2021 11:07:57 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 18:46:16 GMT, Kevin Rushforth wrote: >> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. >> >> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) > > @andreas-heger Welcome to the `jfx` project. At a quick glance, the fix looks promising. Have you tested this on Windows with Hi-DPI to make sure there is no impact? Would you be able add an automated test case that fails (only on Mac retina) without the fix and passes (on all platforms) with your fix? Hi-DPI fixes are often tricky to test in an automated test, so if not, we can use the existing manual test. > > @nlisker this is the same problem I noted while testing PR #334. Clearly I had forgotten that it was not only a preexisting bug, but a known bug that was already filed. I intend to test this alone and in connection with your PR. @kevinrushforth > The fix looks good. I tested it both in isolation and with PR #334 and it works on both a retina and non-retina display. > > If you have time to write an automated test, that would be useful, but if not then a manual test would be OK. Ok, I will try to write an automated test case which draws a sphere in a SubScene and then calculates the average color of the generated image. The test will be passed if the calculated average does not differ from the excepted average color by a certain tolerance value. I'm not sure if I will manage to do this... but I will give it a try. ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From nlisker at openjdk.java.net Mon Jun 14 11:20:55 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 14 Jun 2021 11:20:55 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 11:05:25 GMT, Andreas Heger wrote: > Ok, I will try to write an automated test case which draws a sphere in a SubScene and then calculates the average color of the generated image. The test will be passed if the calculated average does not differ from the excepted average color by a certain tolerance value. I'm not sure if I will manage to do this... but I will give it a try. You can look at such lighting tests in [this PR](https://github.com/nlisker/jfx/tree/8234920_Add_SpotLight_to_the_selection_of_3D_light_types/tests/system/src/test/java/test/javafx/scene/lighting3D). I suspect you will have to do something very similar. Since the scaling is off, I think that you can just sample a few points that have different colors with and without your patch. As noted in the files, you will have to be careful with taking a snapshot in a subscene because of [JDK-8260013](https://bugs.openjdk.java.net/browse/JDK-8260013) (which I have just unassigned from myself because it doesn't seem like I will have time for it). ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From aghaisas at openjdk.java.net Mon Jun 14 15:34:55 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 14 Jun 2021 15:34:55 GMT Subject: RFR: 8264139: Suppress removal warnings for Security Manager methods [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 16:39:26 GMT, Kevin Rushforth wrote: >> This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. >> >> There are four commits: >> >> 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. >> 2. 9698e87 : Same as above for the tests. >> 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. >> 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. >> >> The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. >> >> I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. >> >> NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. >> >> >> modules/javafx.web/src/android/java/com/sun/webkit/Timer.java >> modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java >> modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java >> modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java >> modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java >> modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java >> modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback Marked as reviewed by aghaisas (Reviewer). When built with JDK 17ea26 + `gradle -PLINT=removal` - I cross verified on my macBook (macOS 10.15) that - - without this fix - the warnings are generated - with this fix - the warnings are not generated ------------- PR: https://git.openjdk.java.net/jfx/pull/528 From jgneff at openjdk.java.net Mon Jun 14 16:52:54 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 14 Jun 2021 16:52:54 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 19:05:34 GMT, Kevin Rushforth wrote: >> John Neffenger has updated the pull request incrementally with one additional commit since the last revision: >> >> Include WebKit shared library for Windows >> >> Enable reproducible builds of the native WebKit shared library for >> Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > > Note that this PR is dependent on PR #422 . > > @jgneff As an alternative, you could close that PR (since all of the changes from that one are currently included here), and list both issues in this PR with Skara's `/issue add ...` command. It's up to you. @kevinrushforth I'll take the opportunity provided by this *merge-conflict* to simplify as you suggested. I'll close pull request #422, list both issues in this pull request, add Bernhard as a contributor, and add a commit that makes the `all` task reproducible. That will consolidate what would have been three pull requests into one and will leave only the build path problem for a follow-up request (fix number 4 in my first comment). ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Mon Jun 14 17:04:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Jun 2021 17:04:59 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v19] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 08:50:25 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes Looks good. I reviewed the CSR, so you can move that to Finalized now. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Mon Jun 14 17:12:05 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 14 Jun 2021 17:12:05 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation Message-ID: * Expand the `Property.bind` and `Property.bindBidirectional` documentation * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable") ------------- Commit messages: - Expanded Property documentation Changes: https://git.openjdk.java.net/jfx/pull/533/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=533&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268642 Stats: 190 lines in 18 files changed: 36 ins; 17 del; 137 mod Patch: https://git.openjdk.java.net/jfx/pull/533.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/533/head:pull/533 PR: https://git.openjdk.java.net/jfx/pull/533 From kcr at openjdk.java.net Mon Jun 14 17:17:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Jun 2021 17:17:49 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:06:34 GMT, Michael Strau? wrote: > * Expand the `Property.bind` and `Property.bindBidirectional` documentation > * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable") If this is go forward, it will need a CSR. Before you spend time creating one, I want to do a preliminary read through this, since it is a somewhat large doc change. ------------- PR: https://git.openjdk.java.net/jfx/pull/533 From kevin.rushforth at oracle.com Mon Jun 14 20:15:59 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Jun 2021 13:15:59 -0700 Subject: Moving src.zip out of the lib directory of the JavaFX SDK Message-ID: We deliver a set of modular jars in the lib directory of the standalone JavaFX SDK. We also deliver src.zip for use by IDEs into that same directory. If you add the lib directory to your application's module path in your IDE, it will try to load src.zip as if it were a jar file, and will fail. This is a pain point for developers using the SDK. This problem has been raised on the mailing list a couple of times, and I think it's time to fix it. This issue is tracked in JBS by JDK-8258499 [1]. I propose to move the src.zip file from the lib directory to the top directory of the SDK. Alternatively, we could create a new directory for src.zip (either a sibling of lib or sub-directory under lib). However, I think it would be easier to find in the top dir of the SDK, and I don't see the need for a new directory just to hold src.zip. Before I create the PR and the associated CSR, I'd like to hear developer's opinions on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8258499 From jgneff at openjdk.java.net Mon Jun 14 20:42:51 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 14 Jun 2021 20:42:51 GMT Subject: Withdrawn: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 22:20:10 GMT, John Neffenger wrote: > This is a continuation of the [pull request][1] started by @bmwiedemann in January 2020. After this change is integrated, I can follow up immediately with additional pull requests that get us much closer to providing fully reproducible builds. > > #### Motivation > > The only conclusive way to verify a software package is to reproduce it. That's the main point of the Linux Foundation article [Preventing Supply Chain Attacks like SolarWinds][2] by David Wheeler, Director of Open Source Supply Chain Security. "In the longer term," he writes, "I know of only one strong countermeasure for this kind of attack: verified reproducible builds." > > It's not enough anymore to trust the person, organization, or company that publishes a software package. David Wheeler explains, "Assuming a system can 'never be broken into' is a failing strategy." As I see it, any project that doesn't yet allow for reproducible builds is on a list of possible attack vectors. I'd like to get OpenJFX off that list. > > This is a huge undertaking involving the entire open-source community. Just [Debian, for example][3], has over 30,000 source packages to build in a reproducible manner. Remarkably, it's almost 96 percent complete. The OpenJFX package is one of three percent still failing. Our first step towards helping in this goal is to support the [`SOURCE_DATE_EPOCH` specification][4]. > > #### Implementation > > When you want to build 30,000 packages in a reproducible manner, [command-line flags][5] unique to each package aren't so helpful. The environment variable needs to be set, anyway, for the tools invoked by Gradle to pick it up. We could allow for a Gradle property in addition to the environment variable. The Gradle property would override the default current date and export the environment variable, and the environment variable would override the command-line property. I think it makes more sense in the OpenJFX build to support the environment variable directly. > > With these considerations, I added the support just as recommended by the example for "Java / gradle" on the Reproducible Builds [`SOURCE_DATE_EPOCH`][6] page. For comparison, the [OpenJDK build][7] does the reverse, using the *configure* script option `--with-source-date` to export the `SOURCE_DATE_EPOCH` environment variable. > > [1]: https://github.com/openjdk/jfx/pull/99 > [2]: https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds > [3]: https://tests.reproducible-builds.org/debian/reproducible.html > [4]: https://reproducible-builds.org/specs/source-date-epoch/ > [5]: https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion > [6]: https://reproducible-builds.org/docs/source-date-epoch/ > [7]: https://github.com/openjdk/jdk/commit/1a16a4b6 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/422 From jgneff at openjdk.java.net Mon Jun 14 20:42:45 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 14 Jun 2021 20:42:45 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 00:10:30 GMT, John Neffenger wrote: >> This is a continuation of the [pull request][1] started by @bmwiedemann in January 2020. After this change is integrated, I can follow up immediately with additional pull requests that get us much closer to providing fully reproducible builds. >> >> #### Motivation >> >> The only conclusive way to verify a software package is to reproduce it. That's the main point of the Linux Foundation article [Preventing Supply Chain Attacks like SolarWinds][2] by David Wheeler, Director of Open Source Supply Chain Security. "In the longer term," he writes, "I know of only one strong countermeasure for this kind of attack: verified reproducible builds." >> >> It's not enough anymore to trust the person, organization, or company that publishes a software package. David Wheeler explains, "Assuming a system can 'never be broken into' is a failing strategy." As I see it, any project that doesn't yet allow for reproducible builds is on a list of possible attack vectors. I'd like to get OpenJFX off that list. >> >> This is a huge undertaking involving the entire open-source community. Just [Debian, for example][3], has over 30,000 source packages to build in a reproducible manner. Remarkably, it's almost 96 percent complete. The OpenJFX package is one of three percent still failing. Our first step towards helping in this goal is to support the [`SOURCE_DATE_EPOCH` specification][4]. >> >> #### Implementation >> >> When you want to build 30,000 packages in a reproducible manner, [command-line flags][5] unique to each package aren't so helpful. The environment variable needs to be set, anyway, for the tools invoked by Gradle to pick it up. We could allow for a Gradle property in addition to the environment variable. The Gradle property would override the default current date and export the environment variable, and the environment variable would override the command-line property. I think it makes more sense in the OpenJFX build to support the environment variable directly. >> >> With these considerations, I added the support just as recommended by the example for "Java / gradle" on the Reproducible Builds [`SOURCE_DATE_EPOCH`][6] page. For comparison, the [OpenJDK build][7] does the reverse, using the *configure* script option `--with-source-date` to export the `SOURCE_DATE_EPOCH` environment variable. >> >> [1]: https://github.com/openjdk/jfx/pull/99 >> [2]: https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds >> [3]: https://tests.reproducible-builds.org/debian/reproducible.html >> [4]: https://reproducible-builds.org/specs/source-date-epoch/ >> [5]: https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion >> [6]: https://reproducible-builds.org/docs/source-date-epoch/ >> [7]: https://github.com/openjdk/jdk/commit/1a16a4b6 > > 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 source-date-epoch > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Closing this pull request in favor of #446. The [changes in this pull request][1] are included as the [first commit][2] of pull request #446. [1]: https://github.com/openjdk/jfx/pull/422/commits/3ada5a30c490abec884d878b4fd86219f2f8c60c [2]: https://github.com/openjdk/jfx/pull/446/commits/7ef5031c25fe52c3967c482d6960544aa0e1c9f5 ------------- PR: https://git.openjdk.java.net/jfx/pull/422 From jgneff at openjdk.java.net Mon Jun 14 20:53:50 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 14 Jun 2021 20:53:50 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: > > > $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > $ bash gradlew sdk jmods javadoc > $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod > > > The three commands: > > 1. set the build timestamp to the date of the latest source code change, > 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and > 3. recreate the JMOD files with stable file modification times and ordering. > > The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. > > #### Fixes > > There are at least four sources of non-determinism in the JavaFX builds: > > 1. Build timestamp > > The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. > > 2. Modification times > > The JAR, JMOD, and ZIP archives store the modification time of each file. > > 3. File ordering > > The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. > > 4. Build path > > The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. > > This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Make build of SDK ZIP bundle reproducible - Merge branch 'master' into allow-reproducible-builds - Merge branch 'master' into allow-reproducible-builds - Include WebKit shared library for Windows Enable reproducible builds of the native WebKit shared library for Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. - Include media shared libraries for Windows Enable reproducible builds of the native media shared libraries for Windows when SOURCE_DATE_EPOCH is defined. The libraries are: fxplugins.dll glib-lite.dll gstreamer-lite.dll jfxmedia.dll - Enable reproducible builds with SOURCE_DATE_EPOCH - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH ------------- Changes: https://git.openjdk.java.net/jfx/pull/446/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=04 Stats: 83 lines in 7 files changed: 55 ins; 13 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/446.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/446/head:pull/446 PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Mon Jun 14 21:21:33 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 14 Jun 2021 21:21:33 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > - Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll > - Enable reproducible builds with SOURCE_DATE_EPOCH > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH I re-tested the following build commands on Linux, macOS, and Windows. 1. Developer - the tasks I use for my JavaFX developer builds: `gradle sdk jmods javadoc` 2. GitHub Actions - the task used by the repository to test pull requests: `gradle all` 3. Production - the properties and tasks for the JavaFX production builds: `gradle -PCONF=Release -PPROMOTED_BUILD_NUMBER=12 -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true sdk jmods javadoc` I also ran the unit test tasks on each platform: `test -x :web:test` for the first two and `test` for the third. In each case, the files under the `build` directory created by two consecutive builds from the same location are identical except for the JMOD files, as explained in the description at the top of this pull request. For now, the JMOD files and their bundled artifact `javafx-jmods-17.zip` can be normalized using the `strip-nondeterminism` command. The table below shows the number of files created under the `build` directory for each type of build on the three platforms: | Build Type | Linux | macOS | Win10 | | -------------- | ------:| ------:| ------:| | Developer | 17,109 | 17,121 | 17,338 | | GitHub Actions | 12,600 | 12,608 | 12,563 | | Production | 10,676 | 10,680 | 10,633 | ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From arapte at openjdk.java.net Tue Jun 15 08:09:45 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Jun 2021 08:09:45 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: <7L8s7FBgIXgIZS5Tw2eeRDpxMgPRYYizMaFdKGQkSD0=.b76290fa-1aa8-4945-bfae-1490ec3cff28@github.com> Message-ID: On Fri, 11 Jun 2021 11:38:33 GMT, Ambarish Rapte wrote: >> Hello Nir, could you please merge this branch with latest master. > >> I think so too. Did you test on Win? Does @arapte want to test these functions too? > > Yes, I shall test too, and get back to the review... > @arapte If you run the test app without the spotlight patch, but with the attenuation patch, does it work better? Here is what I tried, 1. Run existing AttenLightingSample without this PR changes. The sample works as expected. 2. Run existing AttenLightingSample with this PR. The sample does NOT work as expected. 2.1 If any one light is turned on then the output is same as the screenshot I shared in previous comment. 2.2 If two or three lights(including red light) are turned on then the red light does not illuminate correctly. (Observe the following screenshot, there are some yellow colored pixels in red light color) ![image](https://user-images.githubusercontent.com/11330676/122015572-d6320180-cddd-11eb-8421-158618d64cd4.png) So looks like, the issue occurs only with the changes in this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Tue Jun 15 08:10:44 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Jun 2021 08:10:44 GMT Subject: RFR: 8264139: Suppress removal warnings for Security Manager methods [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 16:39:26 GMT, Kevin Rushforth wrote: >> This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. >> >> There are four commits: >> >> 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. >> 2. 9698e87 : Same as above for the tests. >> 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. >> 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. >> >> The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. >> >> I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. >> >> NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. >> >> >> modules/javafx.web/src/android/java/com/sun/webkit/Timer.java >> modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java >> modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java >> modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java >> modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java >> modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java >> modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/528 From nlisker at openjdk.java.net Tue Jun 15 08:59:51 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 15 Jun 2021 08:59:51 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 01:06:25 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Updated links in glsl shaders Looks like artifacts. I don't know if a mistake in the code can produce such results. Did the tests that fail with this patch all run on the integrated graphics? Kevin's Mac behaved correctly with this patch. Can you get a dedicated GPU so test this with? I tested with a dedicated GPU on both Win10 and Ubuntu 20 so make sure that both pipelines work. I don't have any more environments I can test on. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Jun 15 09:28:39 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 15 Jun 2021 09:28:39 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:06:34 GMT, Michael Strau? wrote: > * Expand the `Property.bind` and `Property.bindBidirectional` documentation > * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable") I will review this. ------------- PR: https://git.openjdk.java.net/jfx/pull/533 From arapte at openjdk.java.net Tue Jun 15 10:04:44 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Jun 2021 10:04:44 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 08:57:18 GMT, Nir Lisker wrote: > > > Looks like artifacts. I don't know if a mistake in the code can produce such results. I will try with a full clean build and update. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Jun 15 12:53:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Jun 2021 12:53:40 GMT Subject: Integrated: 8264139: Suppress removal warnings for Security Manager methods In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 23:34:38 GMT, Kevin Rushforth wrote: > This PR adds the necessary `@SuppressWarnings("removal")` annotations for the recently-integrated security manager deprecation, [JEP 411](https://openjdk.java.net/jeps/411). See openjdk/jdk#4073. > > There are four commits: > > 1. 678b026 : A patch generated by @wangweij to add annotations to the runtime (`modules/*/src/main/java`) using the same automated tooling that he used as part of the implementation of JEP 411. > 2. 9698e87 : Same as above for the tests. > 3. 1c42cf8 : Manually removes a pair of unused imports, one of which (a static import) was causing a removal warning. > 4. 4f87d18 : Manually reduced the scope of the annotation where it was added to an entire class, or to a large method where only a small part of the method uses a deprecated method. This was done using similar techniques to the following fixes that Weijun did in openjdk/jdk#4172. > > The first two commits represent the bulk of the changes. Other than scanning to ensure that there are no obvious errors, and testing, they probably don't need the same level of scrutiny as the manual changes do. > > I tested this on all three platforms by doing a build / test with `JDK_HOME` set to a local JDK 17 ea build that includes the fix for JEP 411. I ran the build with `gradle -PLINT=removal` and verified that there were removal warnings for the security manager APIs without this fix and none with this fix. > > NOTE: The following files under `modules/javafx.web/src/android` and `modules/javafx.web/src/ios` were not processed by the automated tool. As I have no way to compile them, I chose not to manually fix them either, but doing so would be trivial as a follow-up fix if desired. > > > modules/javafx.web/src/android/java/com/sun/webkit/Timer.java > modules/javafx.web/src/android/java/com/sun/webkit/WebPage.java > modules/javafx.web/src/android/java/javafx/scene/web/WebEngine.java > modules/javafx.web/src/ios/java/javafx/scene/web/ExportedJavaObject.java > modules/javafx.web/src/ios/java/javafx/scene/web/HTMLEditorSkin.java > modules/javafx.web/src/ios/java/javafx/scene/web/JS2JavaBridge.java > modules/javafx.web/src/ios/java/javafx/scene/web/WebEngine.java This pull request has now been integrated. Changeset: c81a7226 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/c81a722614e46844c285d4a4a623352ef227da87 Stats: 605 lines in 194 files changed: 461 ins; 19 del; 125 mod 8264139: Suppress removal warnings for Security Manager methods Co-authored-by: Weijun Wang Co-authored-by: Kevin Rushforth Reviewed-by: aghaisas, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/528 From arapte at openjdk.java.net Tue Jun 15 15:16:53 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Jun 2021 15:16:53 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: <6OFAA3QNs1qTLiLXTzttONKkSK7xP7wVYMzQlug2qOI=.ac48bcc3-9e51-4acb-bf06-1d388add6911@github.com> On Tue, 15 Jun 2021 10:02:02 GMT, Ambarish Rapte wrote: > I will try with a full clean build and update. I executed the sample with a clean build and also with a fresh clone of repo. The issue still reproduces. > Did the tests that fail with this patch all run on the integrated graphics? Kevin's Mac behaved correctly with this patch. Can you get a dedicated GPU so test this with? Yes, I have a machine with integrated GPU: Mac Mojave 10.14.6, Integrated GPU: Intel Iris Graphics 6100 1536 MB. The issue seems to be specific to this machine. I don't have another mac with discrete GPU. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Tue Jun 15 17:47:41 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Jun 2021 17:47:41 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 07:11:54 GMT, Marius Hanl wrote: >> ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ >> EDIT: Thank you, Kevin. :) >> >> This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: >> - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. >> -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) >> - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) >> - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) >> >> **-> With this, I can run all normal tests with IntelliJ** >> >> ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): >> - IntelliJ is not detecting javafx.graphic inside the shims >> - All javafx.* dependencies are not found for the system tests >> >> **-> If someone has a solution, feel free to comment :)** > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Reverted whitespace made by IntelliJ >From the gradle documentation: [Skipping Javadocs and sources](https://docs.gradle.org/current/userguide/dependency_verification.html#sec:skipping-javadocs) The verification of auto downloaded *-sources.jar files can be skipped using following change. This way we can avoid deleting the `verification-metadata.xml` file. diff --git a/gradle/verification-metadata.xml b/gradle/verification-metadata.xml index abacd0b05b..0a3d33726d 100644 --- a/gradle/verification-metadata.xml +++ b/gradle/verification-metadata.xml @@ -3,6 +3,9 @@ true false + + + I tested this change in addition to the PR changes, dependency verification does not fail with this change but fails without. Can you please verify and test this change preferably on a clean repo by creating a new IntelliJ project. ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From kcr at openjdk.java.net Tue Jun 15 18:06:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Jun 2021 18:06:46 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 07:11:54 GMT, Marius Hanl wrote: >> ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ >> EDIT: Thank you, Kevin. :) >> >> This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: >> - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. >> -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) >> - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) >> - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) >> >> **-> With this, I can run all normal tests with IntelliJ** >> >> ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): >> - IntelliJ is not detecting javafx.graphic inside the shims >> - All javafx.* dependencies are not found for the system tests >> >> **-> If someone has a solution, feel free to comment :)** > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Reverted whitespace made by IntelliJ Good find. If this works, it seems like a good compromise to me. We don't download any `*-sources` or `*-javadoc` artifacts in our build, but it seems that IDEs do. If we add this exclusion, I think we should do it using separate bug ID and a separate PR (requiring two reviewers, since this is an area we need to be careful about). As part of that, we would need to update the [`gradle/README.txt`](https://github.com/openjdk/jfx/blob/master/gradle/README.txt) file to let people know why the `*-sources` / `*-javadoc` exclusion is there. ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From kcr at openjdk.java.net Tue Jun 15 18:59:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Jun 2021 18:59:51 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 01:06:25 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Updated links in glsl shaders I also see the same problem as Ambarish does when I run it on my older MacBook Pro with integrated graphics. I tracked it down to a bug in the newly added `computeLight` method in the GLSL shaders. See my inline comments. When I apply that fix it works fine for me on my older MacBook. Additionally, my VirtualBox Linux system now works as expected. Basically, you were getting lucky that it worked at all on the graphics cards it did work on. While you are making changes to the shaders, I think it's time to change the GLSL shaders to use `computeSpotlightFactor` and comment (or ifdef) out the other two, and similarly change the HLSL shaders to use `computeSpotlightFactor3`. modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main1Light.frag line 113: > 111: } > 112: > 113: void computeLight(int i, vec3 n, vec3 refl, float specPower, out vec3 d, out vec3 s) { The storage modifier for `d` and `s` must be changed to `inout` instead of `out`. modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main2Lights.frag line 113: > 111: } > 112: > 113: void computeLight(int i, vec3 n, vec3 refl, float specPower, out vec3 d, out vec3 s) { The storage modifier for `d` and `s` must be changed to `inout` instead of `out`. modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main3Lights.frag line 113: > 111: } > 112: > 113: void computeLight(int i, vec3 n, vec3 refl, float specPower, out vec3 d, out vec3 s) { The storage modifier for `d` and `s` must be changed to `inout` instead of `out`. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Jun 15 22:29:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Jun 2021 22:29:33 GMT Subject: RFR: 8268219: hlsprogressbuffer should provide PTS after GStreamer update In-Reply-To: References: Message-ID: <9nEcdnp2EtnnJb82kqxc8SO4ZhGJqf9fT6iz3AWYpME=.7bd821bf-d7e5-4e97-8b89-69b3e979829b@github.com> On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. After GStreamer update mpregparser no longer tries to figure out timestamps if stream in time format and it will assume that upstream provides timestamps. Fixed by providing starting timestamp at the beginning or after seek. In this case mpegparser able to figure out timestamps and will provide them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise after seek playback waits for seek time. For example if we seek to 2 min, mediaplayer hangs for 2 min and only after that resumes playback. I think it worked before, since mpegparser handled PTS before. Looks good. Tested on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/532 From arapte at openjdk.java.net Wed Jun 16 11:17:45 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Jun 2021 11:17:45 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v19] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 08:50:25 GMT, Michael Strau? wrote: >> This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes Looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/508 From arapte at openjdk.java.net Wed Jun 16 12:56:38 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Jun 2021 12:56:38 GMT Subject: RFR: 8268219: hlsprogressbuffer should provide PTS after GStreamer update In-Reply-To: References: Message-ID: On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. After GStreamer update mpregparser no longer tries to figure out timestamps if stream in time format and it will assume that upstream provides timestamps. Fixed by providing starting timestamp at the beginning or after seek. In this case mpegparser able to figure out timestamps and will provide them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise after seek playback waits for seek time. For example if we seek to 2 min, mediaplayer hangs for 2 min and only after that resumes playback. I think it worked before, since mpegparser handled PTS before. Looks good to me, verified on macOS Mojave 10.14.6. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/532 From arapte at openjdk.java.net Wed Jun 16 13:31:42 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Jun 2021 13:31:42 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 18:57:09 GMT, Kevin Rushforth wrote: > When I apply that fix it works fine for me on my older MacBook. With the change, It works fine on my mac machine too. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Wed Jun 16 14:08:24 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 16 Jun 2021 14:08:24 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v25] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fix for glsl shaders ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/96e4e5ff..c9fb2452 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=23-24 Stats: 28 lines in 4 files changed: 25 ins; 0 del; 3 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 Wed Jun 16 14:08:27 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 16 Jun 2021 14:08:27 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 01:06:25 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Updated links in glsl shaders Thanks for the debugging, Kevin! In the HLSL shader these are already `in out` variables, so no changes there. I commented out the less performant methods. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From john at status6.com Wed Jun 16 16:27:42 2021 From: john at status6.com (John Neffenger) Date: Wed, 16 Jun 2021 09:27:42 -0700 Subject: =?UTF-8?Q?Command_Line_Tools_for_Xcode_12=2e4_=e2=86=92_12=2e5?= Message-ID: Just a heads-up about using the latest Xcode 12.5 ... I use the Command Line Tools for Xcode 12.4 (at 431 MB) to build JavaFX on macOS as an alternative to the full Xcode package (at 11.86 GB). Thank you, Arunprasad Rajkumar! [1] Then Apple Software Update installed the latest Command Line Tools for Xcode 12.5, and my builds of JavaFX with WebKit started failing. You can find out what version you're using with the command: $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 12.5.0.0.1.1617976050 volume: / location: / install-time: 1623800794 groups: com.apple.FindSystemFiles.pkg-group You can download and revert to the 12.4 release below: More Downloads https://developer.apple.com/download/all/?q=12.4 Note that the OpenJFX project uses version 12.4 (build.properties): jfx.build.macosx.xcode.version=Xcode12.4+1.0 The errors using version 12.5 start with: .../modules/javafx.web/src/main/native/Source/ThirdParty/ sqlite/./version:1:1: error: expected unqualified-id /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ usr/include/c++/v1/cstddef:49:9: error: no member named 'ptrdiff_t' in the global namespace and end with: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/... clang: note: diagnostic msg: /var/folders/... clang: note: diagnostic msg: Crash backtrace is located in clang: note: diagnostic msg: /Users/john/Library/Logs/ DiagnosticReports/clang__.crash clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash) clang: note: diagnostic msg: John [1]: https://github.com/openjdk/jfx/pull/13 From kevin.rushforth at oracle.com Wed Jun 16 16:43:42 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Jun 2021 09:43:42 -0700 Subject: =?UTF-8?Q?Re=3a_Command_Line_Tools_for_Xcode_12=2e4_=e2=86=92_12=2e?= =?UTF-8?Q?5?= In-Reply-To: References: Message-ID: <10b96fa2-18c3-a354-a406-38664da2c625@oracle.com> Can you file a bug? We will take a look at it. Thanks. -- Kevin On 6/16/2021 9:27 AM, John Neffenger wrote: > Just a heads-up about using the latest Xcode 12.5 ... > > I use the Command Line Tools for Xcode 12.4 (at 431 MB) to build > JavaFX on macOS as an alternative to the full Xcode package (at 11.86 > GB). Thank you, Arunprasad Rajkumar! [1] > > Then Apple Software Update installed the latest Command Line Tools for > Xcode 12.5, and my builds of JavaFX with WebKit started failing. You > can find out what version you're using with the command: > > ? $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables > ? package-id: com.apple.pkg.CLTools_Executables > ? version: 12.5.0.0.1.1617976050 > ? volume: / > ? location: / > ? install-time: 1623800794 > ? groups: com.apple.FindSystemFiles.pkg-group > > You can download and revert to the 12.4 release below: > > ? More Downloads > ? https://developer.apple.com/download/all/?q=12.4 > > Note that the OpenJFX project uses version 12.4 (build.properties): > > ? jfx.build.macosx.xcode.version=Xcode12.4+1.0 > > The errors using version 12.5 start with: > > ? .../modules/javafx.web/src/main/native/Source/ThirdParty/ > ??? sqlite/./version:1:1: error: expected unqualified-id > > ? /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ > ??? usr/include/c++/v1/cstddef:49:9: error: no member named > ??? 'ptrdiff_t' in the global namespace > > and end with: > > ? PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > ? Preprocessed source(s) and associated run script(s) are located at: > ? clang: note: diagnostic msg: /var/folders/... > ? clang: note: diagnostic msg: /var/folders/... > ? clang: note: diagnostic msg: Crash backtrace is located in > ? clang: note: diagnostic msg: /Users/john/Library/Logs/ > DiagnosticReports/clang__.crash > ? clang: note: diagnostic msg: (choose the .crash file that > ???????? corresponds to your crash) > ? clang: note: diagnostic msg: > > John > > [1]: https://github.com/openjdk/jfx/pull/13 > From philip.race at oracle.com Wed Jun 16 16:56:41 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 Jun 2021 09:56:41 -0700 Subject: =?UTF-8?Q?Re=3a_Command_Line_Tools_for_Xcode_12=2e4_=e2=86=92_12=2e?= =?UTF-8?Q?5?= In-Reply-To: References: Message-ID: <198b4b93-4f42-1df1-f861-3577b95eed0b@oracle.com> FWIW this is why I 1) Don't let macOS upgrade my xcode tools automatically 2) Let someone else trail blaze? :-), unless I am ready to do the work to make the upgraded tools work. -phil. On 6/16/21 9:27 AM, John Neffenger wrote: > Just a heads-up about using the latest Xcode 12.5 ... From john at status6.com Wed Jun 16 17:21:46 2021 From: john at status6.com (John Neffenger) Date: Wed, 16 Jun 2021 10:21:46 -0700 Subject: =?UTF-8?Q?Re=3a_Command_Line_Tools_for_Xcode_12=2e4_=e2=86=92_12=2e?= =?UTF-8?Q?5?= In-Reply-To: <198b4b93-4f42-1df1-f861-3577b95eed0b@oracle.com> References: <198b4b93-4f42-1df1-f861-3577b95eed0b@oracle.com> Message-ID: On 6/16/21 9:56 AM, Philip Race wrote: > 1) Don't let macOS upgrade my xcode tools automatically Lesson learned! But then there's that annoying red badge on your System Preferences forever. :-) Actually, it was worse, and went more like this (just in case any else gets led off-course by the error message below): 1. Naively download the latest CLTools 12.5. 2. See the following error message and think I need the full Xcode: xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance That is a red herring. It's just the build testing whether the full Xcode is installed by running the command 'xcodebuild -version -showsdks'. When that command fails, the build runs 'xcrun --show-sdk-path' and continues without problems. 3. Download and install the full Xcode 12.5, and it still fails! 4. Finally look up what the GitHub Actions are using (12.4). 5. Download and install CLTools 12.4 -- works! 6. Uninstall the 11-GB constantly-updating Xcode app. John From john at status6.com Wed Jun 16 17:54:35 2021 From: john at status6.com (John Neffenger) Date: Wed, 16 Jun 2021 10:54:35 -0700 Subject: =?UTF-8?Q?Re=3a_Command_Line_Tools_for_Xcode_12=2e4_=e2=86=92_12=2e?= =?UTF-8?Q?5?= In-Reply-To: References: <198b4b93-4f42-1df1-f861-3577b95eed0b@oracle.com> Message-ID: <7839b16b-84a5-63d5-f26b-cd0c7b69d27d@status6.com> On 6/16/21 10:21 AM, John Neffenger wrote: > 4. Finally look up what the GitHub Actions are using (12.4). Oops, make that "Finally look up what the project uses (12.4)." For the record, our GitHub Actions use Xcode_11.3.1. [1] John [1]: https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml#L202 From kevin.rushforth at oracle.com Wed Jun 16 18:37:20 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Jun 2021 11:37:20 -0700 Subject: =?UTF-8?Q?Re=3a_Command_Line_Tools_for_Xcode_12=2e4_=e2=86=92_12=2e?= =?UTF-8?Q?5?= In-Reply-To: <7839b16b-84a5-63d5-f26b-cd0c7b69d27d@status6.com> References: <198b4b93-4f42-1df1-f861-3577b95eed0b@oracle.com> <7839b16b-84a5-63d5-f26b-cd0c7b69d27d@status6.com> Message-ID: Our production builds use Xcode 12.4 [1].? The GitHub Actions build haven't caught up yet. See JDK-8266218 [2]. -- Kevin [1] https://github.com/openjdk/jfx/blob/master/build.properties#L93 [2] https://bugs.openjdk.java.net/browse/JDK-8266218 On 6/16/2021 10:54 AM, John Neffenger wrote: > On 6/16/21 10:21 AM, John Neffenger wrote: >> 4. Finally look up what the GitHub Actions are using (12.4). > > Oops, make that "Finally look up what the project uses (12.4)." > > For the record, our GitHub Actions use Xcode_11.3.1. [1] > > John > > [1]: > https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml#L202 From kcr at openjdk.java.net Wed Jun 16 20:43:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Jun 2021 20:43:25 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v25] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 14:08:24 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fix for glsl shaders The glsl `computeLight` methods are still calling the now-commented-out alternative shaders, so it fails at load time. See, for example, [main1Light.frag#L129](https://github.com/openjdk/jfx/blob/c9fb2452cffad5e9256e4ef7dbb733a69a655dac/modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main1Light.frag#L129). The rest of the changes look fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From almatvee at openjdk.java.net Wed Jun 16 21:52:19 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 16 Jun 2021 21:52:19 GMT Subject: Integrated: 8268219: hlsprogressbuffer should provide PTS after GStreamer update In-Reply-To: References: Message-ID: On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. After GStreamer update mpregparser no longer tries to figure out timestamps if stream in time format and it will assume that upstream provides timestamps. Fixed by providing starting timestamp at the beginning or after seek. In this case mpegparser able to figure out timestamps and will provide them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise after seek playback waits for seek time. For example if we seek to 2 min, mediaplayer hangs for 2 min and only after that resumes playback. I think it worked before, since mpegparser handled PTS before. This pull request has now been integrated. Changeset: 98138c84 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/98138c84a7f286731ad12dd5c533cd3fa265bf56 Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod 8268219: hlsprogressbuffer should provide PTS after GStreamer update Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/532 From nlisker at openjdk.java.net Thu Jun 17 00:38:56 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 17 Jun 2021 00:38:56 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v26] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed method call in glsl shaders ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/c9fb2452..5c775341 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=25 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=24-25 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 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 fastegal at openjdk.java.net Thu Jun 17 12:47:36 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 17 Jun 2021 12:47:36 GMT Subject: RFR: 8240506: TextFieldSkin/Behavior: misbehavior on switching skin Message-ID: The issue is about memory leaks and side-effects (like NPEs) when switching skins. Details (copied from issue for convenience): memory leak in TextInputControlBehavior: - listener accidentally added twice (removed once) - keyPad mappings not properly installed/disposed memory leak TextFieldBehavior: - listeners to scene/focusOwner property not removed, memory leak in TextInputControlSkin: - event handlers related to inputMethods not removed issues in TextFieldSkin: - memory leak due to behavior leaking - memory leaks due to manually added change/invalidation listeners that are not removed - memory leaks due to not removing children with strong references to skin - side-effects (f.i. NPEs) due to listeners/bindings that are still active after dispose Fix was to properly install/remove those listeners/handlers. Added tests that failed/passed before/after the fix, respectively, also added tests passing before that must pass after the fix. ------------- Commit messages: - 8240506: TextFieldSkin/Behavior: misbehavior on switching skin Changes: https://git.openjdk.java.net/jfx/pull/534/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=534&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240506 Stats: 753 lines in 10 files changed: 687 ins; 38 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/534.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/534/head:pull/534 PR: https://git.openjdk.java.net/jfx/pull/534 From kcr at openjdk.java.net Thu Jun 17 14:57:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Jun 2021 14:57:45 GMT Subject: RFR: 8268915: WebKit build fails with Xcode 12.5 Message-ID: The JavaFX WebKit build fails with Xcode 12.5 + MacOS 11.3 SDK. This is related to the added C++20 support where some of the system include files now do `#include `. Because the macOS file system is case insensitive, it matches a file named `VERSION` in the sqlite source directory. That file is just a plain text file (not used by our build at all) so the fix is to rename it to `VERSION.txt`. I've done a CI build on all three platforms. @jgneff has verified that renaming this file fixes the build for XCode 12.5. ------------- Commit messages: - 8268915: WebKit build fails with Xcode 12.5 Changes: https://git.openjdk.java.net/jfx/pull/535/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=535&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268915 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/535.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/535/head:pull/535 PR: https://git.openjdk.java.net/jfx/pull/535 From kcr at openjdk.java.net Thu Jun 17 19:50:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Jun 2021 19:50:36 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v26] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 00:38:56 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed method call in glsl shaders I did a full test run on 5 different system, including manual tests on 4 of them: Windows 10 w/ Intel graphics Linux w/ NVIDIA graphics (no manual testing) Linux VM guest running on Windows 10 host Mac w/ discrete graphics Mac w/ integrated graphics No problems detected. All looks good. I think there could be some additional tuning done for point lights, but that could be looked at in a follow-on fix. I reviewed the CSR and it is ready to be Finalized. I finished reviewing the shader code, and left a couple comments on the HLSL shaders. modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psConstants.h line 28: > 26: // see D3DPhongShader.h > 27: > 28: static const int numMaxLights = 3; I know we only support 3 lights, but I note that the vertex shader structures in `vsConstants.h` also have room for 5, and that number was unchanged by this PR. Have you ensured that the mismatch won't cause any problems? Also, with this change to `numMaxLights` from 5 to 3, the register assignments for the light arrays are now off (in a way that won't cause functional problems, just wasted space). I wonder if it's better to revert this change for now and deal with it in a follow-up issue? If not, I recommend to make the change from 5 to 3 more broadly. modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h line 58: > 56: float4x3 mBones[MAX_BONES] : register(c35); > 57: > 58: float4 gReserved240[16] : register(c240); `gReserved240` is now at the wrong location (it should be 245), so if it were ever used it would be a problem. It should be updated to avoid confusion at least. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Thu Jun 17 22:00:35 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 17 Jun 2021 22:00:35 GMT Subject: Integrated: 8267551: Support loading images from inline data-URIs In-Reply-To: References: Message-ID: On Wed, 19 May 2021 20:24:31 GMT, Michael Strau? wrote: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. This pull request has now been integrated. Changeset: 171e484c Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/171e484ca63bdfd50599417482eb704f71f10107 Stats: 552 lines in 8 files changed: 477 ins; 30 del; 45 mod 8267551: Support loading images from inline data-URIs Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Fri Jun 18 01:28:38 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 18 Jun 2021 01:28:38 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs Message-ID: This PR extends data URI support to allow stylesheets to be loaded from data URIs. ------------- Commit messages: - Stylesheets can be loaded from data URIs Changes: https://git.openjdk.java.net/jfx/pull/536/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267554 Stats: 237 lines in 4 files changed: 218 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/536.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536 PR: https://git.openjdk.java.net/jfx/pull/536 From fastegal at openjdk.java.net Fri Jun 18 10:17:30 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 18 Jun 2021 10:17:30 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability In-Reply-To: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Sun, 6 Jun 2021 12:44:00 GMT, Marius Hanl wrote: > This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. > > While this PR fixes the problem described in the ticket, it does not fix the example. > This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. > > While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). > > I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: > [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) fix looks good, verified new tests failing before and all tests passing after left minor comments to the test methods modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 329: > 327: public void testCellInUneditableRowIsNotEditable() { > 328: table.setEditable(true); > 329: TableRow row = new TableRow(); fix generic warning modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 641: > 639: row.setEditable(false); > 640: > 641: TreeTableColumn treeTableColumn = new TreeTableColumn(); fix generic warning ------------- Changes requested by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/529 From aghaisas at openjdk.java.net Fri Jun 18 10:17:31 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 18 Jun 2021 10:17:31 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability In-Reply-To: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Sun, 6 Jun 2021 12:44:00 GMT, Marius Hanl wrote: > This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. > > While this PR fixes the problem described in the ticket, it does not fix the example. > This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. > > While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). > > I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: > [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java line 310: > 308: (table != null && !table.isEditable()) || > 309: (column != null && !column.isEditable()) || > 310: (row != null) && !row.isEditable()) { Incorrect Line ---- "(row != null) && !row.isEditable())" Correction required ---- "(row != null && !row.isEditable()))" Refer similar line which is rightly implemented in TreeTableCell.java. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 327: > 325: > 326: @Test > 327: public void testCellInUneditableRowIsNotEditable() { I recommend adding tests for cell.startEdit() using all combinations of TableView, TableColumn and TableRow editable states. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 638: > 636: @Test > 637: public void testCellInUneditableRowIsNotEditable() { > 638: tree.setEditable(true); I recommend adding tests for cell.startEdit() using all combinations of TreeTableView, TreeTableColumn and TreeTableRow editable states. ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From fastegal at openjdk.java.net Fri Jun 18 10:17:32 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 18 Jun 2021 10:17:32 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Fri, 18 Jun 2021 10:10:42 GMT, Ajit Ghaisas wrote: >> This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. >> >> While this PR fixes the problem described in the ticket, it does not fix the example. >> This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. >> >> While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). >> >> I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: >> [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) > > modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java line 310: > >> 308: (table != null && !table.isEditable()) || >> 309: (column != null && !column.isEditable()) || >> 310: (row != null) && !row.isEditable()) { > > Incorrect Line ---- "(row != null) && !row.isEditable())" > Correction required ---- "(row != null && !row.isEditable()))" > > Refer similar line which is rightly implemented in TreeTableCell.java. darn .. you certainly have the better eyes :))) ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From fastegal at openjdk.java.net Fri Jun 18 10:26:28 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 18 Jun 2021 10:26:28 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability In-Reply-To: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Sun, 6 Jun 2021 12:44:00 GMT, Marius Hanl wrote: > I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: > [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) as already commented in the follow-up - I think that it will not be needed after fixing the precondition violation (there are none for any of the cell.xxEdit methods, so the concrete classes must not introduce any) [JDK-8188026](https://bugs.openjdk.java.net/browse/JDK-8188026). The impl pattern will be something like public void startEdit() { if (isEditing()) return; super.startEdit(); if (!isEditing()) return; // config edit state } Thus row editable will already be taking into account by super. ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From fastegal at openjdk.java.net Fri Jun 18 10:34:29 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 18 Jun 2021 10:34:29 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: <5ZgsybaYDU6LoffWgY-da1DGUrdfpBjuSfh0mvAX10c=.20eca4a0-535a-4233-a602-081c8b6ee84c@github.com> On Fri, 18 Jun 2021 10:14:40 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java line 310: >> >>> 308: (table != null && !table.isEditable()) || >>> 309: (column != null && !column.isEditable()) || >>> 310: (row != null) && !row.isEditable()) { >> >> Incorrect Line ---- "(row != null) && !row.isEditable())" >> Correction required ---- "(row != null && !row.isEditable()))" >> >> Refer similar line which is rightly implemented in TreeTableCell.java. > > darn .. you certainly have the better eyes :))) Hmm .. this should have been be found by a test .. having a combination table == null, column == null, row == null would throw. But then, test coverage is .. ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From kcr at openjdk.java.net Fri Jun 18 13:26:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Jun 2021 13:26:36 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v26] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 19:31:29 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed method call in glsl shaders > > modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h line 58: > >> 56: float4x3 mBones[MAX_BONES] : register(c35); >> 57: >> 58: float4 gReserved240[16] : register(c240); > > `gReserved240` is now at the wrong location (it should be 245), so if it were ever used it would be a problem. It should be updated to avoid confusion at least. I think the size should be updated to 11 as well (since we probably don't want to go past 256). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From jpereda at openjdk.java.net Fri Jun 18 14:12:41 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 18 Jun 2021 14:12:41 GMT Subject: RFR: 8269026: PasswordField doesn't render bullet character on Android Message-ID: This PR modifies the PasswordField's bullet character used on Android, as the current unicode code is not supported for most fonts, including Roboto. ------------- Commit messages: - Modify bullet character for PasswordField on Android Changes: https://git.openjdk.java.net/jfx/pull/537/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=537&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269026 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/537.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/537/head:pull/537 PR: https://git.openjdk.java.net/jfx/pull/537 From kcr at openjdk.java.net Fri Jun 18 14:27:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Jun 2021 14:27:35 GMT Subject: RFR: 8269026: PasswordField doesn't render bullet character on Android In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 14:08:25 GMT, Jose Pereda wrote: > This PR modifies the PasswordField's bullet character used on Android, as the current unicode code is not supported for most fonts, including Roboto. Marked as reviewed by kcr (Lead). modules/javafx.controls/src/android/java/javafx/scene/control/skin/TextFieldSkinAndroid.java line 82: > 80: return String.valueOf(BULLET).repeat(txt.length()); > 81: } else { > 82: return txt; Should this call `return super.maskText(txt);` in case the implementation of the superclass method ever changes? Either is OK with me. ------------- PR: https://git.openjdk.java.net/jfx/pull/537 From jpereda at openjdk.java.net Fri Jun 18 14:35:30 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 18 Jun 2021 14:35:30 GMT Subject: RFR: 8269026: PasswordField doesn't render bullet character on Android In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 14:21:16 GMT, Kevin Rushforth wrote: >> This PR modifies the PasswordField's bullet character used on Android, as the current unicode code is not supported for most fonts, including Roboto. > > modules/javafx.controls/src/android/java/javafx/scene/control/skin/TextFieldSkinAndroid.java line 82: > >> 80: return String.valueOf(BULLET).repeat(txt.length()); >> 81: } else { >> 82: return txt; > > Should this call `return super.maskText(txt);` in case the implementation of the superclass method ever changes? Either is OK with me. I think that makes sense, even if it causes a double check of getSkinnable(), but that seems negligible. I'll update it ------------- PR: https://git.openjdk.java.net/jfx/pull/537 From jpereda at openjdk.java.net Fri Jun 18 14:47:53 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 18 Jun 2021 14:47:53 GMT Subject: RFR: 8269026: PasswordField doesn't render bullet character on Android [v2] In-Reply-To: References: Message-ID: > This PR modifies the PasswordField's bullet character used on Android, as the current unicode code is not supported for most fonts, including Roboto. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback from reviewer ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/537/files - new: https://git.openjdk.java.net/jfx/pull/537/files/5cbe3372..be073acb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=537&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=537&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/537.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/537/head:pull/537 PR: https://git.openjdk.java.net/jfx/pull/537 From kcr at openjdk.java.net Fri Jun 18 14:47:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Jun 2021 14:47:55 GMT Subject: RFR: 8269026: PasswordField doesn't render bullet character on Android [v2] In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 14:45:21 GMT, Jose Pereda wrote: >> This PR modifies the PasswordField's bullet character used on Android, as the current unicode code is not supported for most fonts, including Roboto. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback from reviewer Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/537 From jpereda at openjdk.java.net Fri Jun 18 16:37:32 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 18 Jun 2021 16:37:32 GMT Subject: Integrated: 8269026: PasswordField doesn't render bullet character on Android In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 14:08:25 GMT, Jose Pereda wrote: > This PR modifies the PasswordField's bullet character used on Android, as the current unicode code is not supported for most fonts, including Roboto. This pull request has now been integrated. Changeset: 13cffbaa Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/13cffbaad4068177d2d3239fa297302c3f94c217 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod 8269026: PasswordField doesn't render bullet character on Android Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/537 From kcr at openjdk.java.net Fri Jun 18 18:46:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Jun 2021 18:46:40 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 01:23:50 GMT, Michael Strau? wrote: > This PR extends data URI support to allow stylesheets to be loaded from data URIs. I looked at just the public API and spec, and have two comments: * I don't see any justification for adding `Stylesheet::loadBinary(InputStream)` to the public API. See my comments inline. * Do you intend to support setting a user agent stylesheet via a data URL? The docs should be explicit about whether or not a data URI can be used for the following methods: * [Application::setUserAgentStylesheet](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/application/Application.java#L521) * [Scene::setUserAgentStylesheet](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L1697) * [SubScene::setUserAgentStylesheet](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java#L687) modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 301: > 299: * css version or if an I/O error occurs while reading from the stream > 300: */ > 301: public static Stylesheet loadBinary(InputStream stream) throws IOException { Why do you need to add this public method to the API? I don't see any discussion as to why JavaFX applications need it. It looks like it is just being used internally by `StyleManager`. Unless there is a compelling reason to add this to the API, you will need to make this method package-scope and use an accessor to access it from `StyleManager`. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From nlisker at openjdk.java.net Sat Jun 19 13:35:32 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 19 Jun 2021 13:35:32 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v26] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 19:17:49 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed method call in glsl shaders > > modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psConstants.h line 28: > >> 26: // see D3DPhongShader.h >> 27: >> 28: static const int numMaxLights = 3; > > I know we only support 3 lights, but I note that the vertex shader structures in `vsConstants.h` also have room for 5, and that number was unchanged by this PR. Have you ensured that the mismatch won't cause any problems? Also, with this change to `numMaxLights` from 5 to 3, the register assignments for the light arrays are now off (in a way that won't cause functional problems, just wasted space). > > I wonder if it's better to revert this change for now and deal with it in a follow-up issue? If not, I recommend to make the change from 5 to 3 more broadly. You are right, I will revert. I want to remove the restriction for 3 lights in the future anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Sat Jun 19 13:46:54 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 19 Jun 2021 13:46:54 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v27] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Updated float constant registers ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/5c775341..0b5d73cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=26 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=25-26 Stats: 51 lines in 4 files changed: 23 ins; 11 del; 17 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 Sat Jun 19 13:46:54 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 19 Jun 2021 13:46:54 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v26] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 00:38:56 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed method call in glsl shaders In addition to addressing the review comments, I added some comments on register assignments to help with the math and explanations. No functional changes were made there. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Sat Jun 19 13:46:55 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 19 Jun 2021 13:46:55 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v26] In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 13:23:14 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h line 58: >> >>> 56: float4x3 mBones[MAX_BONES] : register(c35); >>> 57: >>> 58: float4 gReserved240[16] : register(c240); >> >> `gReserved240` is now at the wrong location (it should be 245), so if it were ever used it would be a problem. It should be updated to avoid confusion at least. > > I think the size should be updated to 11 as well (since we probably don't want to go past 256). I wonder why we need `gReserved240` and `gSomethingElse` (in the pixel shader) at all. If they are at the end, they don't need to be reserved I think. Also, the vertex shader has `gReserved5[5]` that reserves c5 to c9, but the pixel shader does not have anything on c2 and c3, which are also reserved for something. Another thing I don't understand is why the vertex shader overlaps register definitions for `gAmbinet` and `gAmbinetData[10]`, and `mWorld` and `mBones[MAX_BONES]` (and why 70 of these?). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Sun Jun 20 00:07:56 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 20 Jun 2021 00:07:56 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v2] In-Reply-To: References: Message-ID: > This PR extends data URI support to allow stylesheets to be loaded from data URIs. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added docs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/536/files - new: https://git.openjdk.java.net/jfx/pull/536/files/16119e8c..70c29866 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=00-01 Stats: 48 lines in 3 files changed: 40 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/536.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536 PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Sun Jun 20 00:28:26 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 20 Jun 2021 00:28:26 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v2] In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 18:43:24 GMT, Kevin Rushforth wrote: > * Do you intend to support setting a user agent stylesheet via a data URL? The docs should be explicit about whether or not a data URI can be used for the following methods: > > * [Application::setUserAgentStylesheet](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/application/Application.java#L521) > * [Scene::setUserAgentStylesheet](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L1697) > * [SubScene::setUserAgentStylesheet](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java#L687) Data URIs also work for user-agent stylesheets. I added documentation to each of the methods. > modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 301: > >> 299: * css version or if an I/O error occurs while reading from the stream >> 300: */ >> 301: public static Stylesheet loadBinary(InputStream stream) throws IOException { > > Why do you need to add this public method to the API? I don't see any discussion as to why JavaFX applications need it. It looks like it is just being used internally by `StyleManager`. Unless there is a compelling reason to add this to the API, you will need to make this method package-scope and use an accessor to access it from `StyleManager`. I don't know why JavaFX applications would need this API. But the argument should be the same argument as for `loadBinary(URL)`, which is also only used internally by `StyleManager`. I think that this isn't opening up any new effective API surface, because it's arguably just another overload of the existing API. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From aghaisas at openjdk.java.net Mon Jun 21 11:29:39 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 21 Jun 2021 11:29:39 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods Message-ID: This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. ------------- Commit messages: - Fix LINT-deprecation warnings - Suppress LINT-removal warnings Changes: https://git.openjdk.java.net/jfx/pull/538/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=538&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264137 Stats: 111 lines in 9 files changed: 2 ins; 0 del; 109 mod Patch: https://git.openjdk.java.net/jfx/pull/538.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/538/head:pull/538 PR: https://git.openjdk.java.net/jfx/pull/538 From fastegal at openjdk.java.net Mon Jun 21 12:32:49 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 21 Jun 2021 12:32:49 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index Message-ID: Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). Added tests that are failing (and one that was accidentally passing) before, all passing after. ------------- Commit messages: - 8165214: ListView.EditEvent.getIndex() does not return the correct index Changes: https://git.openjdk.java.net/jfx/pull/539/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=539&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8165214 Stats: 105 lines in 2 files changed: 98 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/539.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/539/head:pull/539 PR: https://git.openjdk.java.net/jfx/pull/539 From mstrauss at openjdk.java.net Mon Jun 21 13:01:46 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 21 Jun 2021 13:01:46 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 12:27:37 GMT, Jeanette Winzenburg wrote: > Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). > > Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). > > Added tests that are failing (and one that was accidentally passing) before, all passing after. modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 356: > 354: **************************************************************************/ > 355: // index at time of startEdit - fix for JDK-8165214 > 356: int indexAtStartEdit; It seems like this field should be private. ------------- PR: https://git.openjdk.java.net/jfx/pull/539 From fastegal at openjdk.java.net Mon Jun 21 13:16:29 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 21 Jun 2021 13:16:29 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 12:57:34 GMT, Michael Strau? wrote: >> Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). >> >> Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). >> >> Added tests that are failing (and one that was accidentally passing) before, all passing after. > > modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 356: > >> 354: **************************************************************************/ >> 355: // index at time of startEdit - fix for JDK-8165214 >> 356: int indexAtStartEdit; > > It seems like this field should be private. indeed, thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/539 From fastegal at openjdk.java.net Mon Jun 21 13:22:07 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 21 Jun 2021 13:22:07 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index [v2] In-Reply-To: References: Message-ID: > Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). > > Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). > > Added tests that are failing (and one that was accidentally passing) before, all passing after. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: changed scope of field indexAtStartEdit to private ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/539/files - new: https://git.openjdk.java.net/jfx/pull/539/files/1d08587c..41be1163 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=539&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=539&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/539.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/539/head:pull/539 PR: https://git.openjdk.java.net/jfx/pull/539 From kcr at openjdk.java.net Mon Jun 21 14:16:32 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 21 Jun 2021 14:16:32 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v2] In-Reply-To: References: Message-ID: On Sun, 20 Jun 2021 00:22:57 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 301: >> >>> 299: * css version or if an I/O error occurs while reading from the stream >>> 300: */ >>> 301: public static Stylesheet loadBinary(InputStream stream) throws IOException { >> >> Why do you need to add this public method to the API? I don't see any discussion as to why JavaFX applications need it. It looks like it is just being used internally by `StyleManager`. Unless there is a compelling reason to add this to the API, you will need to make this method package-scope and use an accessor to access it from `StyleManager`. > > I don't know why JavaFX applications would need this API. But the argument should be the same argument as for `loadBinary(URL)`, which is also only used internally by `StyleManager`. I think that this isn't opening up any new effective API surface, because it's arguably just another overload of the existing API. An overloaded method with a new signature is still a new method that adds to the public API, although in an easy to understand way. I agree that the same argument could be made for it as for `loadBinary(URL)`, but if neither are needed, then maybe we would be better off to deprecate the existing method (not as part of this enhancement, of course), rather than adding a similar one that also isn't needed as part of the public API. On the other hand, if there is a good reason, I don't see a problem adding this new method. If you do propose to add this API, you will need to add an appropriate `@since` tag, and you should write an API-level test for this method as part of `StylesheetTest`. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Mon Jun 21 14:57:55 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 21 Jun 2021 14:57:55 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v3] In-Reply-To: References: Message-ID: > This PR extends data URI support to allow stylesheets to be loaded from data URIs. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added test for Stylesheet.loadBinary(InputStream) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/536/files - new: https://git.openjdk.java.net/jfx/pull/536/files/70c29866..39ff7583 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=01-02 Stats: 58 lines in 2 files changed: 40 ins; 17 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/536.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536 PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Mon Jun 21 15:07:39 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 21 Jun 2021 15:07:39 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v3] In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 14:13:47 GMT, Kevin Rushforth wrote: >> I don't know why JavaFX applications would need this API. But the argument should be the same argument as for `loadBinary(URL)`, which is also only used internally by `StyleManager`. I think that this isn't opening up any new effective API surface, because it's arguably just another overload of the existing API. > > An overloaded method with a new signature is still a new method that adds to the public API, although in an easy to understand way. I agree that the same argument could be made for it as for `loadBinary(URL)`, but if neither are needed, then maybe we would be better off to deprecate the existing method (not as part of this enhancement, of course), rather than adding a similar one that also isn't needed as part of the public API. On the other hand, if there is a good reason, I don't see a problem adding this new method. > > If you do propose to add this API, you will need to add an appropriate `@since` tag, and you should write an API-level test for this method as part of `StylesheetTest`. It seems to me that the only useful thing an application developer could do with a `Stylesheet` instance is to inspect its contents (the relevant APIs in javafx.css are public, after all). That seems like a niche use case, but to the extent that there are applications out there that inspect binary stylesheets, having the option to load them from a stream seems at least marginally useful. I slightly lean towards adding this public API also to not having to introducing a new helper class _just_ for this one benign method. If you have a stronger opinion on this, please go ahead and make the call. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From kcr at openjdk.java.net Mon Jun 21 16:32:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 21 Jun 2021 16:32:27 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 11:24:39 GMT, Ajit Ghaisas wrote: > This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. > > `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. I tested this patch, and verified that it does eliminate the deprecation and removal warnings when building the sdk. There are still a few warnings when compiling the tests. I ran the following command: $ gradle --continue --info -PLINT="deprecation,removal" test I get the following deprecation warnings: modules\javafx.graphics\src\shims\java\javafx\scene\input\GestureEventShim.java:48: warning: [deprecation] GestureEvent(Object,EventTarget,EventType) in GestureEvent has been deprecated modules\javafx.graphics\src\test\java\test\javafx\css\StylesheetTest.java:628: warning: [deprecation] toURL() in File has been deprecated modules\javafx.graphics\src\test\java\test\javafx\scene\Scenegraph_eventHandlers_Test.java:342: warning: [deprecation] EventType() in EventType has been deprecated modules\javafx.controls\src\test\java\test\javafx\scene\chart\XYChartTest.java:92: warning: [deprecation] set(S,V,StyleOrigin) in CssMetaData has been deprecated modules\javafx.controls\src\test\java\test\javafx\scene\control\LabeledTest.java:768: warning: [deprecation] set(S,V,StyleOrigin) in CssMetaData has been deprecated modules\javafx.controls\src\test\java\test\javafx\scene\control\TreeItemTest.java:201: warning: [deprecation] getNodeLevel(TreeItem) in TreeView has been deprecated modules\javafx.controls\src\test\java\test\javafx\scene\control\TreeItemTest.java:208: warning: [deprecation] getNodeLevel(TreeItem) in TreeView has been deprecated modules\javafx.controls\src\test\java\test\javafx\scene\control\TreeItemTest.java:217: warning: [deprecation] getNodeLevel(TreeItem) in TreeView has been deprecated modules\javafx.controls\src\test\java\test\javafx\scene\control\TreeItemTest.java:231: warning: [deprecation] getNodeLevel(TreeItem) in TreeView has been deprecated modules\javafx.controls\src\test\java\test\javafx\scene\control\TreeItemTest.java:232: warning: [deprecation] getNodeLevel(TreeItem) in TreeView has been deprecated modules\javafx.fxml\src\test\java\test\com\oracle\javafx\fxml\test\TestLoadPerformance.java:107: warning: [deprecation] XMLReaderFactory in org.xml.sax.helpers has been deprecated tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\input\devices\TestTouchDevices.java:46: warning: [deprecation] newInstance() in Class has been deprecated tests\system\src\test\java\test\robot\javafx\embed\swing\JFXPanelTest.java:95: warning: [deprecation] BUTTON1_MASK in InputEvent has been deprecated tests\system\src\test\java\test\robot\javafx\embed\swing\JFXPanelTest.java:96: warning: [deprecation] BUTTON1_MASK in InputEvent has been deprecated tests\system\src\test\java\test\robot\javafx\embed\swing\NonFocusableJFXPanelTest.java:74: warning: [deprecation] BUTTON1_MASK in InputEvent has been deprecated tests\system\src\test\java\test\robot\javafx\embed\swing\NonFocusableJFXPanelTest.java:75: warning: [deprecation] BUTTON1_MASK in InputEvent has been deprecated and the following removal warnings: modules\javafx.base\src\shims\java\javafx\util\converter\DateTimeStringConverterShim.java:34: warning: [removal] timeStyle in DateTimeStringConverter has been deprecated and marked for removal modules\javafx.base\src\shims\java\javafx\util\converter\DateTimeStringConverterShim.java:38: warning: [removal] pattern in DateTimeStringConverter has been deprecated and marked for removal modules\javafx.base\src\shims\java\javafx\util\converter\DateTimeStringConverterShim.java:42: warning: [removal] dateStyle in DateTimeStringConverter has been deprecated and marked for removal modules\javafx.base\src\shims\java\javafx\util\converter\DateTimeStringConverterShim.java:46: warning: [removal] getDateFormat() in DateTimeStringConverter has been deprecated and marked for removal modules\javafx.base\src\shims\java\javafx\util\converter\DateTimeStringConverterShim.java:50: warning: [removal] dateFormat in DateTimeStringConverter has been deprecated and marked for removal modules\javafx.base\src\shims\java\javafx\util\converter\DateTimeStringConverterShim.java:54: warning: [removal] locale in DateTimeStringConverter has been deprecated and marked for removal You can either fix it as part of this bug fix or else file a follow-on bug for the tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/538 From kcr at openjdk.java.net Mon Jun 21 17:45:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 21 Jun 2021 17:45:31 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 11:24:39 GMT, Ajit Ghaisas wrote: > This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. > > `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. I'd like a second pair of eyes on this. The changes are very straight-forward, but there are a lot of them and it would be easy to have a copy-paste error and use `snapSizeX` instead of `snapSizeY` or vice versa. ------------- PR: https://git.openjdk.java.net/jfx/pull/538 From kcr at openjdk.java.net Mon Jun 21 18:26:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 21 Jun 2021 18:26:27 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 11:24:39 GMT, Ajit Ghaisas wrote: > This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. > > `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/538 From mhanl at openjdk.java.net Tue Jun 22 06:07:28 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 22 Jun 2021 06:07:28 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 17:44:43 GMT, Ambarish Rapte wrote: > ``` > diff --git a/gradle/verification-metadata.xml b/gradle/verification-metadata.xml > index abacd0b05b..0a3d33726d 100644 > --- a/gradle/verification-metadata.xml > +++ b/gradle/verification-metadata.xml > @@ -3,6 +3,9 @@ > > true > false > + > + > + > > > > ``` > > I tested this change in addition to the PR changes, dependency verification does not fail with this change but fails without. > Can you please verify and test this change preferably on a clean repo by creating a new IntelliJ project. Good catch indeed! This works like a charm. I think this is a good follow-up. ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From mhanl at openjdk.java.net Tue Jun 22 06:28:49 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 22 Jun 2021 06:28:49 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability [v2] In-Reply-To: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: > This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. > > While this PR fixes the problem described in the ticket, it does not fix the example. > This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. > > While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). > > I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: > [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/529/files - new: https://git.openjdk.java.net/jfx/pull/529/files/e40be321..e35bf49a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=529&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=529&range=00-01 Stats: 122 lines in 3 files changed: 116 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/529.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/529/head:pull/529 PR: https://git.openjdk.java.net/jfx/pull/529 From mhanl at openjdk.java.net Tue Jun 22 06:28:50 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 22 Jun 2021 06:28:50 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability [v2] In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Fri, 18 Jun 2021 10:14:40 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java line 310: >> >>> 308: (table != null && !table.isEditable()) || >>> 309: (column != null && !column.isEditable()) || >>> 310: (row != null) && !row.isEditable()) { >> >> Incorrect Line ---- "(row != null) && !row.isEditable())" >> Correction required ---- "(row != null && !row.isEditable()))" >> >> Refer similar line which is rightly implemented in TreeTableCell.java. > > darn .. you certainly have the better eyes :))) Good catch, I really don't know how I couldnt see that. ?? fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From mhanl at openjdk.java.net Tue Jun 22 06:28:51 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 22 Jun 2021 06:28:51 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability [v2] In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Fri, 18 Jun 2021 10:01:42 GMT, Ajit Ghaisas wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 327: > >> 325: >> 326: @Test >> 327: public void testCellInUneditableRowIsNotEditable() { > > I recommend adding tests for cell.startEdit() using all combinations of TableView, TableColumn and TableRow editable states. done > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 638: > >> 636: @Test >> 637: public void testCellInUneditableRowIsNotEditable() { >> 638: tree.setEditable(true); > > I recommend adding tests for cell.startEdit() using all combinations of TreeTableView, TreeTableColumn and TreeTableRow editable states. done ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From mhanl at openjdk.java.net Tue Jun 22 06:28:53 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 22 Jun 2021 06:28:53 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability [v2] In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Fri, 18 Jun 2021 10:10:43 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 329: > >> 327: public void testCellInUneditableRowIsNotEditable() { >> 328: table.setEditable(true); >> 329: TableRow row = new TableRow(); > > fix generic warning done > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 641: > >> 639: row.setEditable(false); >> 640: >> 641: TreeTableColumn treeTableColumn = new TreeTableColumn(); > > fix generic warning done ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From arapte at openjdk.java.net Tue Jun 22 11:28:38 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Jun 2021 11:28:38 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v27] In-Reply-To: References: Message-ID: On Sat, 19 Jun 2021 13:46:54 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Updated float constant registers Provided two suggestions. You can address if you think they are worth to address now. Over all the PR looks good to me, I observed an existing issue while testing the attenuation.AttenLightingSample. Both Point and Spot light are not correctly applied to Mesh when number of faces is increased to more than 60. Following are steps to reproduce with Point light with existing source without this PR. As this is an existing issue we can address it in a follow on. 1. Apply this patch current repo, without this PR --- a/tests/performance/3DLighting/attenuation/LightingSample.java +++ b/tests/performance/3DLighting/attenuation/LightingSample.java @@ -69,8 +69,8 @@ public class LightingSample extends Application { var sphere = new Button("Sphere"); sphere.setOnAction(e -> switchTo(environment.createSphere((int) subdivisionSlider.getValue()))); - var quadSlider = new Slider(500, 10_000, 1000); - quadSlider.setMajorTickUnit(500); + var quadSlider = new Slider(10, 200, 60); + quadSlider.setMajorTickUnit(10); setupSlier(quadSlider); var quadLabel = new Label(); 2. Compile and run attenuation.AttenLightingSample 3. Turn on Magenta light and click Mesh button. Observe that light is proper ![image](https://user-images.githubusercontent.com/11330676/122915765-bcfaf900-d379-11eb-9d45-a57736c50789.png) 4. Increase the number of quads to 70 and observe that light is not proper ![image](https://user-images.githubusercontent.com/11330676/122915852-d9973100-d379-11eb-88b9-a2981961c616.png) modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main.vert line 50: > 48: > 49: varying vec4 lightTangentSpacePositions[3]; > 50: varying vec4 lightTangentSpaceDirections[3]; `lightTangentSpacePositions` is pre existing variable. I think the name `lightTangentSpacePositions` is misguiding here. We use this variable to hold a point to light vector in tangent space. I think the name should have been something like, `tangentSpacePointToLightVec` or `pointToLightVecInTangentSpace`. Again this is not mandatory for this PR, But it did confuse me a bit while reading. The other variable name `lightTangentSpaceDirections` sounds correct, as it holds the lights direction in tangent space, but if we change the existing variable then similarly this variable name should be also be changed. modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main2Lights.frag line 66: > 64: float cosOuter; > 65: float denom; // cosInner - cosOuter > 66: float falloff; I am not sure about the memory alignment of this struct in shader. But I would recommend to group `vec3`s together. The members are not accessed using stride so it should not matter much. I leave it to you. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Jun 22 11:50:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Jun 2021 11:50:40 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v27] In-Reply-To: References: Message-ID: <8k3vobCTEsb0ltOtjjJEwjthQtR0T64EK0QivKHubO4=.98344973-d1b7-44b2-a168-3f436bbd7f89@github.com> On Tue, 22 Jun 2021 11:25:42 GMT, Ambarish Rapte wrote: > Both Point and Spot light are not correctly applied to Mesh when number of faces is increased to more than 60. > Following are steps to reproduce with Point light with existing source without this PR. > As this is an existing issue we can address it in a follow on. @arapte can you file a JBS bug for this? ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mhanl at openjdk.java.net Tue Jun 22 12:39:31 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 22 Jun 2021 12:39:31 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Fri, 18 Jun 2021 10:23:33 GMT, Jeanette Winzenburg wrote: > > I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: > > [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) > > as already commented in the follow-up - I think that it will not be needed after fixing the precondition violation (there are none for any of the cell.xxEdit methods, so the concrete classes must not introduce any) [JDK-8188026](https://bugs.openjdk.java.net/browse/JDK-8188026). The impl pattern will be something like > > ``` > public void startEdit() { > if (isEditing()) return; > super.startEdit(); > if (!isEditing()) return; > // config edit state > } > ``` > > Thus row editable will already be taking into account by super. I like this idea. Then only the CheckBox... implementations needs to be adjusted. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From arapte at openjdk.java.net Tue Jun 22 12:56:33 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Jun 2021 12:56:33 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 13:29:03 GMT, Ambarish Rapte wrote: >> I also see the same problem as Ambarish does when I run it on my older MacBook Pro with integrated graphics. I tracked it down to a bug in the newly added `computeLight` method in the GLSL shaders. See my inline comments. When I apply that fix it works fine for me on my older MacBook. Additionally, my VirtualBox Linux system now works as expected. Basically, you were getting lucky that it worked at all on the graphics cards it did work on. >> >> While you are making changes to the shaders, I think it's time to change the GLSL shaders to use `computeSpotlightFactor` and comment (or ifdef) out the other two, and similarly change the HLSL shaders to use `computeSpotlightFactor3`. > >> When I apply that fix it works fine for me on my older MacBook. > > With the change, It works fine on my mac machine too. > @arapte can you file a JBS bug for this? Reported the issue here: [JDK-8269133](https://bugs.openjdk.java.net/browse/JDK-8269133) ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mhanl at openjdk.java.net Tue Jun 22 13:06:27 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 22 Jun 2021 13:06:27 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 11:24:39 GMT, Ajit Ghaisas wrote: > This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. > > `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. Looks good. I double checked the snapSizeX/Y and snapPositionX/Y methods, I didn't found any location where the wrong method is used. Good to see that all deprecated snapSize/snapPosition usages are finally replaced. :) Btw, it looks like this PR also resolves: https://bugs.openjdk.java.net/browse/JDK-8252820 So this ticket can be either added to the issues this PR resolves or be closed. ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/538 From johan.vos at gluonhq.com Tue Jun 22 15:29:03 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 22 Jun 2021 17:29:03 +0200 Subject: split code and tests in a PR Message-ID: Hi, I really like the automation that Skara is providing. It saves time for committers as well as for reviewers. In order to increase productivity even more (without decreasing quality), there might be an additional step we might somehow automate. Many PR's contain changes in java code and in test code. What I typically do as a first step of a review, is to first run the tests on the latest code, then apply the PR, and run the tests again. Clearly, no test should fail in the second run, while it would be ok (and desired) that at least 1 tests fails in the first run. My typical approach for this is to download the diff, and manually split it in 2 parts: code + tests. I then apply the part with the tests, and run them. Next, I apply the part with the code, and re-run the tests. Clearly, this is not enough for a review, but if we automate this, it gives an additional indication that a PR is going in the right direction. I'm not sure how easy/hard this would be to implement. The bot should be able to detect the `src/test/java`, and provide 2 downloads in the comments of the PR ("download test diff" and "download code diff"). It can also execute those steps in a github action, and fail if the resulting tests are failing after applying the code diff. Thoughts? - Johan From nlisker at gmail.com Tue Jun 22 16:06:46 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 22 Jun 2021 19:06:46 +0300 Subject: split code and tests in a PR In-Reply-To: References: Message-ID: I also thought it would be useful for the bot to run the tests after the patch and notify on a failure. I didn't think about applying the new tests to the old code with "hopes" for a failure, I like this idea. Providing 2 downloads is also useful. One thing we need to be careful with is that an older test can fail with a new patch even though the tests that come with the patch pass because the patch could have broken some dependent code (which could also mean that the problem is in the dependent code). How expensive is it for the bot to run the tests? On Tue, Jun 22, 2021 at 6:31 PM Johan Vos wrote: > Hi, > > I really like the automation that Skara is providing. It saves time for > committers as well as for reviewers. In order to increase productivity even > more (without decreasing quality), there might be an additional step we > might somehow automate. Many PR's contain changes in java code and in test > code. What I typically do as a first step of a review, is to first run the > tests on the latest code, then apply the PR, and run the tests again. > Clearly, no test should fail in the second run, while it would be ok (and > desired) that at least 1 tests fails in the first run. > > My typical approach for this is to download the diff, and manually split it > in 2 parts: code + tests. I then apply the part with the tests, and run > them. Next, I apply the part with the code, and re-run the tests. > Clearly, this is not enough for a review, but if we automate this, it gives > an additional indication that a PR is going in the right direction. > > I'm not sure how easy/hard this would be to implement. The bot should be > able to detect the `src/test/java`, and provide 2 downloads in the comments > of the PR ("download test diff" and "download code diff"). It can also > execute those steps in a github action, and fail if the resulting tests are > failing after applying the code diff. > > Thoughts? > > - Johan > From jvos at openjdk.java.net Tue Jun 22 16:28:56 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 22 Jun 2021 16:28:56 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index [v2] In-Reply-To: References: Message-ID: <3WX-a6Rv2AJ4_SDa4Jlwd4MiHWF112WAWxjX2AlrVXU=.05fb7e48-f2c4-4b34-ad5b-e3b3a9f95b9f@github.com> On Mon, 21 Jun 2021 13:22:07 GMT, Jeanette Winzenburg wrote: >> Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). >> >> Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). >> >> Added tests that are failing (and one that was accidentally passing) before, all passing after. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changed scope of field indexAtStartEdit to private This looks the correct approach indeed. Tests fail before and succeed after. That is, the first test succeeds before as well, but it makes sense as there is no action that would change the index. So I don't think it is accidentally passing? ------------- PR: https://git.openjdk.java.net/jfx/pull/539 From fastegal at openjdk.java.net Tue Jun 22 16:28:56 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 22 Jun 2021 16:28:56 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index [v2] In-Reply-To: <3WX-a6Rv2AJ4_SDa4Jlwd4MiHWF112WAWxjX2AlrVXU=.05fb7e48-f2c4-4b34-ad5b-e3b3a9f95b9f@github.com> References: <3WX-a6Rv2AJ4_SDa4Jlwd4MiHWF112WAWxjX2AlrVXU=.05fb7e48-f2c4-4b34-ad5b-e3b3a9f95b9f@github.com> Message-ID: On Tue, 22 Jun 2021 15:36:04 GMT, Johan Vos wrote: > > > This looks the correct approach indeed. Tests fail before and succeed after. > That is, the first test succeeds before as well, but it makes sense as there is no action that would change the index. So I don't think it is accidentally passing? maybe "accidentally" is wrong word :) I meant it in the sense I summarized in [JDK-8266969](https://bugs.openjdk.java.net/browse/JDK-8266969): all cell types have issues with configuring edit events with incorrect locations, some take the control's location at the time of the cancel (like ListCell), some take the cell's. For all there are execution paths that carry the correct (which I call "accidental") and some that carry the wrong location. For ListCell the "accidentally" correct locations are set on cell-reuse and after cancel on the cell, the incorrect are all others. ------------- PR: https://git.openjdk.java.net/jfx/pull/539 From kevin.rushforth at oracle.com Tue Jun 22 16:30:46 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 22 Jun 2021 09:30:46 -0700 Subject: split code and tests in a PR In-Reply-To: References: Message-ID: <06b5aa92-fad3-1423-8376-21b80a5ed310@oracle.com> When I am doing a review and want to test a PR, I do something similar to what Johan mentioned. I download the PR to my local fork, verify it (often with manual testing in addition to the provided tests), and then backout the code changes to see whether the provided automated test would catch the failure. The Skara bots don't run any tests at all. What Skara does do is run a PR check that looks for the results of a GitHub actions test run, which is run in the context of the personal fork of the PR author, and present those results to the reviewers of the PR. So we already get this level of testing. I can't think of a good way to automate running the new / modified tests without the fix. I don't think we want Skara to get into the business of understanding enough about the different projects (jfx, jdk, skara itself, etc) to be able to split a PR into multiple parts. Also, we don't run any tests either in the bots themselves or in the openjdk group on GitHub, only on individual user's personal forks. Anything we do would be down to whatever we could run in the GitHub actions on the developer's personal fork. -- Kevin On 6/22/2021 9:06 AM, Nir Lisker wrote: > I also thought it would be useful for the bot to run the tests after the > patch and notify on a failure. I didn't think about applying the new tests > to the old code with "hopes" for a failure, I like this idea. Providing 2 > downloads is also useful. > > One thing we need to be careful with is that an older test can fail with a > new patch even though the tests that come with the patch pass because the > patch could have broken some dependent code (which could also mean that the > problem is in the dependent code). > How expensive is it for the bot to run the tests? > > On Tue, Jun 22, 2021 at 6:31 PM Johan Vos wrote: > >> Hi, >> >> I really like the automation that Skara is providing. It saves time for >> committers as well as for reviewers. In order to increase productivity even >> more (without decreasing quality), there might be an additional step we >> might somehow automate. Many PR's contain changes in java code and in test >> code. What I typically do as a first step of a review, is to first run the >> tests on the latest code, then apply the PR, and run the tests again. >> Clearly, no test should fail in the second run, while it would be ok (and >> desired) that at least 1 tests fails in the first run. >> >> My typical approach for this is to download the diff, and manually split it >> in 2 parts: code + tests. I then apply the part with the tests, and run >> them. Next, I apply the part with the code, and re-run the tests. >> Clearly, this is not enough for a review, but if we automate this, it gives >> an additional indication that a PR is going in the right direction. >> >> I'm not sure how easy/hard this would be to implement. The bot should be >> able to detect the `src/test/java`, and provide 2 downloads in the comments >> of the PR ("download test diff" and "download code diff"). It can also >> execute those steps in a github action, and fail if the resulting tests are >> failing after applying the code diff. >> >> Thoughts? >> >> - Johan >> From jvos at openjdk.java.net Tue Jun 22 17:16:34 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 22 Jun 2021 17:16:34 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index [v2] In-Reply-To: References: Message-ID: <7eHBrPEXhuwLO4Fz0oXDRlQCwtnuQIXByggw-Lw7DGI=.4d110007-2047-4f62-bd71-073e509adaaa@github.com> On Mon, 21 Jun 2021 13:22:07 GMT, Jeanette Winzenburg wrote: >> Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). >> >> Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). >> >> Added tests that are failing (and one that was accidentally passing) before, all passing after. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changed scope of field indexAtStartEdit to private Looks good, and it's great to see old bugs being tackled. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/539 From kcr at openjdk.java.net Tue Jun 22 20:48:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Jun 2021 20:48:49 GMT Subject: RFR: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later Message-ID: This is a fix for the assertion error message that is printed to the console on macOS 10.15 or later when an application calls `Platform.exit` while a `Stage` is showing. The root cause is a latent bug in the JavaFX glass code that was revealed by an apparent change of behavior in macOS. A few of the object deallocation methods, which are called by the Objective C auto-release mechanism, use the standard `GET_MAIN_JENV` macro to get the JNI environment. The macro will print an assertion warning if Java has been detached. I instrumented the code and can see that `GlassViewDelegate::dealloc` is now called after the `GlassApplication` main loop has detached Java. Since we don't control when the dealloc method is called, it is not correct to do the assertion check in those cases. Some of the dealloc methods already skip this assertion check by grabbing the jEnv pointer directly, so we need to fix the others. I added a new variant of the macro called `GET_MAIN_JENV_NOWARN` with a comment indicating that is suitable for use by the dealloc methods. In addition to verifying that the test program attached to JBS now exits cleanly with no assertion failure message, I added an automated system test that fails on macOS before the fix and passes after the fix. On other platforms it passes already. ------------- Commit messages: - 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later Changes: https://git.openjdk.java.net/jfx/pull/540/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=540&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231558 Stats: 208 lines in 7 files changed: 204 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/540.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/540/head:pull/540 PR: https://git.openjdk.java.net/jfx/pull/540 From kcr at openjdk.java.net Tue Jun 22 21:17:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Jun 2021 21:17:34 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v27] In-Reply-To: References: Message-ID: On Tue, 22 Jun 2021 10:28:16 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated float constant registers > > modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main.vert line 50: > >> 48: >> 49: varying vec4 lightTangentSpacePositions[3]; >> 50: varying vec4 lightTangentSpaceDirections[3]; > > `lightTangentSpacePositions` is pre existing variable. I think the name `lightTangentSpacePositions` is misguiding here. We use this variable to hold a point to light vector in tangent space. I think the name should have been something like, `tangentSpacePointToLightVec` or `pointToLightVecInTangentSpace`. Again this is not mandatory for this PR, But it did confuse me a bit while reading. > > The other variable name `lightTangentSpaceDirections` sounds correct, as it holds the lights direction in tangent space, but if we change the existing variable then similarly this variable name should be also be changed. Since this is preexisting, I probably wouldn't change it as part of this PR, but instead it could be done as part of the future work to support more than 3 lights. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Jun 22 21:24:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Jun 2021 21:24:38 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v27] In-Reply-To: References: Message-ID: On Sat, 19 Jun 2021 13:46:54 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Updated float constant registers I don't have any more comments or concerns. If you choose to reorder the variables or make other simple changes, I'll re-approve. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Jun 22 22:47:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Jun 2021 22:47:29 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v3] In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 15:04:26 GMT, Michael Strau? wrote: >> An overloaded method with a new signature is still a new method that adds to the public API, although in an easy to understand way. I agree that the same argument could be made for it as for `loadBinary(URL)`, but if neither are needed, then maybe we would be better off to deprecate the existing method (not as part of this enhancement, of course), rather than adding a similar one that also isn't needed as part of the public API. On the other hand, if there is a good reason, I don't see a problem adding this new method. >> >> If you do propose to add this API, you will need to add an appropriate `@since` tag, and you should write an API-level test for this method as part of `StylesheetTest`. > > It seems to me that the only useful thing an application developer could do with a `Stylesheet` instance is to inspect its contents (the relevant APIs in javafx.css are public, after all). That seems like a niche use case, but to the extent that there are applications out there that inspect binary stylesheets, having the option to load them from a stream seems at least marginally useful. > > I slightly lean towards adding this public API also to not having to introducing a new helper class _just_ for this one benign method. If you have a stronger opinion on this, please go ahead and make the call. Avoiding the need for an accessor isn't sufficient reason, but I do like the symmetry with the existing `loadBinary(URL)` method. Also, one can create a `Stylesheet` by parsing a text file using the various `parse` methods of `CssParser`, so there is ample precedent for doing this. I have no objection to the public method. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Tue Jun 22 23:15:55 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 22 Jun 2021 23:15:55 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v4] In-Reply-To: References: Message-ID: > This PR extends data URI support to allow stylesheets to be loaded from data URIs. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: simplified branch in StyleManager.loadStylesheetUnPrivileged ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/536/files - new: https://git.openjdk.java.net/jfx/pull/536/files/39ff7583..7dfbc0cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=02-03 Stats: 46 lines in 1 file changed: 15 ins; 24 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/536.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536 PR: https://git.openjdk.java.net/jfx/pull/536 From ajoseph at openjdk.java.net Wed Jun 23 04:17:32 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 23 Jun 2021 04:17:32 GMT Subject: RFR: 8268915: WebKit build fails with Xcode 12.5 In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 14:52:53 GMT, Kevin Rushforth wrote: > The JavaFX WebKit build fails with Xcode 12.5 + MacOS 11.3 SDK. This is related to the added C++20 support where some of the system include files now do `#include `. Because the macOS file system is case insensitive, it matches a file named `VERSION` in the sqlite source directory. That file is just a plain text file (not used by our build at all) so the fix is to rename it to `VERSION.txt`. I've done a CI build on all three platforms. @jgneff has verified that renaming this file fixes the build for XCode 12.5. Fix looks good. ------------- Marked as reviewed by ajoseph (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/535 From aghaisas at openjdk.java.net Wed Jun 23 05:41:28 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 23 Jun 2021 05:41:28 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability [v2] In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Tue, 22 Jun 2021 06:28:49 GMT, Marius Hanl wrote: >> This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. >> >> While this PR fixes the problem described in the ticket, it does not fix the example. >> This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. >> >> While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). >> >> I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: >> [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From jgneff at openjdk.java.net Wed Jun 23 06:19:26 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 23 Jun 2021 06:19:26 GMT Subject: RFR: 8268915: WebKit build fails with Xcode 12.5 In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 14:52:53 GMT, Kevin Rushforth wrote: > The JavaFX WebKit build fails with Xcode 12.5 + MacOS 11.3 SDK. This is related to the added C++20 support where some of the system include files now do `#include `. Because the macOS file system is case insensitive, it matches a file named `VERSION` in the sqlite source directory. That file is just a plain text file (not used by our build at all) so the fix is to rename it to `VERSION.txt`. I've done a CI build on all three platforms. @jgneff has verified that renaming this file fixes the build for XCode 12.5. I just tested this pull request on macOS using the Command Line Tools for Xcode 12.5.1 update released on June 20, 2021: $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 12.5.1.0.1.1623191612 volume: / location: / install-time: 1624422801 groups: com.apple.FindSystemFiles.pkg-group The build and unit tests were successful: BUILD SUCCESSFUL in 1h 5m 9s 214 actionable tasks: 214 executed ------------- PR: https://git.openjdk.java.net/jfx/pull/535 From aghaisas at openjdk.java.net Wed Jun 23 06:55:27 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 23 Jun 2021 06:55:27 GMT Subject: RFR: 8165214: ListView.EditEvent.getIndex() does not return the correct index [v2] In-Reply-To: References: Message-ID: <11lmCpjNYY790ow7c0nlVZU96YgSr-erDpo7Gzn_mWM=.76d67fc8-7e8f-4b7c-9102-b6eabc5350d8@github.com> On Mon, 21 Jun 2021 13:22:07 GMT, Jeanette Winzenburg wrote: >> Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). >> >> Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). >> >> Added tests that are failing (and one that was accidentally passing) before, all passing after. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changed scope of field indexAtStartEdit to private Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/539 From fastegal at openjdk.java.net Wed Jun 23 07:46:27 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 23 Jun 2021 07:46:27 GMT Subject: Integrated: 8165214: ListView.EditEvent.getIndex() does not return the correct index In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 12:27:37 GMT, Jeanette Winzenburg wrote: > Issue was that the cancel event carried the listView's editingIndex at the time of firing the event - that's wrong nearly always (because the list's editing state/index might have changed between start and cancel, f.i. due to calling list.edit(someDifferentIndex)). > > Fixed by keeping the index at startEdit and using that in cancelEdit (similar approach as in TreeCell fix [TreeCell fix JDK-8265210](https://bugs.openjdk.java.net/browse/JDK-8265210). > > Added tests that are failing (and one that was accidentally passing) before, all passing after. This pull request has now been integrated. Changeset: 04493e55 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/04493e55e8ccb98d308a0ed73a20ca31fe868bc1 Stats: 105 lines in 2 files changed: 98 ins; 4 del; 3 mod 8165214: ListView.EditEvent.getIndex() does not return the correct index Reviewed-by: jvos, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/539 From fastegal at openjdk.java.net Wed Jun 23 07:47:32 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 23 Jun 2021 07:47:32 GMT Subject: RFR: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability [v2] In-Reply-To: References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Tue, 22 Jun 2021 06:28:49 GMT, Marius Hanl wrote: >> This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. >> >> While this PR fixes the problem described in the ticket, it does not fix the example. >> This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. >> >> While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). >> >> I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: >> [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by fastegal (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From mhanl at openjdk.java.net Wed Jun 23 09:23:27 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 23 Jun 2021 09:23:27 GMT Subject: Integrated: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability In-Reply-To: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> References: <7MmxYZB469m2ws9jXfl1OhHsexvGNOqzkKBm77YUqM0=.609d5e7e-07c4-4615-a1ae-0582529c07dc@github.com> Message-ID: On Sun, 6 Jun 2021 12:44:00 GMT, Marius Hanl wrote: > This PR enables Tree- and TableCells to also check the row editability when an edit should happen. With this a Tree- or TableCell is not editable, when the row where the cell is in is not. > > While this PR fixes the problem described in the ticket, it does not fix the example. > This is due the example uses the **CheckBoxTableCell**, which is a ready-to-use subclass of **TableCell**. > > While looking into this, I found out that multiple sub implementations still have this issue, but the fix is not always the same, e.g. CheckBoxTableCell should disable the CheckBox (in **updateItem**), while the ChoiceBoxTableCell should check the row editability in the **startEdit** method (like this PR does). > > I created a follow-up issues for fixing all the sub Tree- and TableCell implementation which do not count the row editability in: > [JDK-8268295](https://bugs.openjdk.java.net/browse/JDK-8268295) This pull request has now been integrated. Changeset: 45786ac4 Author: Marius Hanl Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/45786ac4f6c3abda45b162b27d158e2dee9e9c14 Stats: 169 lines in 4 files changed: 159 ins; 0 del; 10 mod 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability Reviewed-by: fastegal, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/529 From aghaisas at openjdk.java.net Wed Jun 23 11:16:09 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 23 Jun 2021 11:16:09 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods [v2] In-Reply-To: References: Message-ID: > This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. > > `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision: - Suppress/Fix LINT-deprecation warnings from tests - Suppress LINT-removal warnings from tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/538/files - new: https://git.openjdk.java.net/jfx/pull/538/files/f8dd3ae3..dcbd6169 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=538&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=538&range=00-01 Stats: 23 lines in 11 files changed: 13 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/538.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/538/head:pull/538 PR: https://git.openjdk.java.net/jfx/pull/538 From aghaisas at openjdk.java.net Wed Jun 23 11:16:10 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 23 Jun 2021 11:16:10 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 16:29:56 GMT, Kevin Rushforth wrote: > You can either fix it as part of this bug fix or else file a follow-on bug for the tests. Thanks for reporting these warnings. I will fix them as part of the same PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/538 From kcr at openjdk.java.net Wed Jun 23 11:50:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Jun 2021 11:50:31 GMT Subject: Integrated: 8268915: WebKit build fails with Xcode 12.5 In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 14:52:53 GMT, Kevin Rushforth wrote: > The JavaFX WebKit build fails with Xcode 12.5 + MacOS 11.3 SDK. This is related to the added C++20 support where some of the system include files now do `#include `. Because the macOS file system is case insensitive, it matches a file named `VERSION` in the sqlite source directory. That file is just a plain text file (not used by our build at all) so the fix is to rename it to `VERSION.txt`. I've done a CI build on all three platforms. @jgneff has verified that renaming this file fixes the build for XCode 12.5. This pull request has now been integrated. Changeset: 8e11b94f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/8e11b94ff90d6640c8e7a1dc0da83599b9d16b84 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 8268915: WebKit build fails with Xcode 12.5 Reviewed-by: ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/535 From kcr at openjdk.java.net Wed Jun 23 12:05:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Jun 2021 12:05:34 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods [v2] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 11:16:09 GMT, Ajit Ghaisas wrote: >> This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. >> >> `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. > > Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision: > > - Suppress/Fix LINT-deprecation warnings from tests > - Suppress LINT-removal warnings from tests Test changes look good, too. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/538 From mhanl at openjdk.java.net Wed Jun 23 12:41:30 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 23 Jun 2021 12:41:30 GMT Subject: RFR: 8264137: Suppress deprecation and removal warnings of internal methods [v2] In-Reply-To: References: Message-ID: <0wWhiYsnbwfJsaPhjEiy82KsXPRkteyYLywrKi4oYb0=.1d78ec03-64d3-4502-af9b-4021a629572e@github.com> On Wed, 23 Jun 2021 11:16:09 GMT, Ajit Ghaisas wrote: >> This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. >> >> `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. > > Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision: > > - Suppress/Fix LINT-deprecation warnings from tests > - Suppress LINT-removal warnings from tests Looks good. ?? ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/538 From kcr at openjdk.java.net Wed Jun 23 13:00:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Jun 2021 13:00:31 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v4] In-Reply-To: References: Message-ID: On Tue, 22 Jun 2021 23:15:55 GMT, Michael Strau? wrote: >> This PR extends data URI support to allow stylesheets to be loaded from data URIs. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > simplified branch in StyleManager.loadStylesheetUnPrivileged The API and spec changes look good. As I mentioned in a comment added to the CSR, it is ready to move to "Proposed". Once we are farther along in the code review, I'll formally review the CSR. One thing I noticed is that the diffs don't exactly match what you pasted in the CSR (looks like a copy/paste issue). The `Scene::setUserAgentStylesheet` and `SubScene::setUserAgentStylesheet` methods each have three unchanged lines that are marked with the `+` diff indicator. Can you double-check? I'll review the implementation next. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Wed Jun 23 13:09:51 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 23 Jun 2021 13:09:51 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v5] In-Reply-To: References: Message-ID: > This PR extends data URI support to allow stylesheets to be loaded from data URIs. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: cleaned up paragraph tags ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/536/files - new: https://git.openjdk.java.net/jfx/pull/536/files/7dfbc0cb..c734640f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=03-04 Stats: 8 lines in 3 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/536.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536 PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Wed Jun 23 13:16:36 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 23 Jun 2021 13:16:36 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v4] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 12:57:10 GMT, Kevin Rushforth wrote: > One thing I noticed is that the diffs don't exactly match what you pasted in the CSR (looks like a copy/paste issue). The `Scene::setUserAgentStylesheet` and `SubScene::setUserAgentStylesheet` methods each have three unchanged lines that are marked with the `+` diff indicator. Can you double-check? I've fixed that, and also cleaned up the `

    ` tags for the new paragraphs. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From aghaisas at openjdk.java.net Wed Jun 23 13:35:30 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 23 Jun 2021 13:35:30 GMT Subject: Integrated: 8264137: Suppress deprecation and removal warnings of internal methods In-Reply-To: References: Message-ID: On Mon, 21 Jun 2021 11:24:39 GMT, Ajit Ghaisas wrote: > This PR suppresses -PLINT="removal" warnings and fixes -PLINT="deprecation" warnings. I have created separate commits for each type of warnings for the ease of review. > > `gradle --info -PLINT="deprecation,removal"` -- results in warnings during build without this PR and results in no warnings with this PR. This pull request has now been integrated. Changeset: 063bfe87 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/063bfe877555dea9e2060e651192f95e529db56d Stats: 134 lines in 20 files changed: 15 ins; 0 del; 119 mod 8264137: Suppress deprecation and removal warnings of internal methods 8252820: Skins: cleanup use of deprecated snapSize/snapPosition Reviewed-by: kcr, mhanl ------------- PR: https://git.openjdk.java.net/jfx/pull/538 From kevin.rushforth at oracle.com Wed Jun 23 13:50:40 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Jun 2021 06:50:40 -0700 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: References: Message-ID: Are there any IDE users who are currently having problems as a result of this? If not, I'll retarget this for a future release. -- Kevin On 6/14/2021 1:15 PM, Kevin Rushforth wrote: > We deliver a set of modular jars in the lib directory of the > standalone JavaFX SDK. We also deliver src.zip for use by IDEs into > that same directory. If you add the lib directory to your > application's module path in your IDE, it will try to load src.zip as > if it were a jar file, and will fail. This is a pain point for > developers using the SDK. This problem has been raised on the mailing > list a couple of times, and I think it's time to fix it. This issue is > tracked in JBS by JDK-8258499 [1]. > > I propose to move the src.zip file from the lib directory to the top > directory of the SDK. > > Alternatively, we could create a new directory for src.zip (either a > sibling of lib or sub-directory under lib). However, I think it would > be easier to find in the top dir of the SDK, and I don't see the need > for a new directory just to hold src.zip. > > Before I create the PR and the associated CSR, I'd like to hear > developer's opinions on this. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8258499 > From cjgunzel at gmail.com Wed Jun 23 13:54:53 2021 From: cjgunzel at gmail.com (Chuck Davis) Date: Wed, 23 Jun 2021 06:54:53 -0700 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: References: Message-ID: I'm only an application developer but I look at scr.zip occasionally and your proposal makes a lot of sense to me. On Wed, Jun 23, 2021 at 6:51 AM Kevin Rushforth wrote: > Are there any IDE users who are currently having problems as a result of > this? If not, I'll retarget this for a future release. > > -- Kevin > > > On 6/14/2021 1:15 PM, Kevin Rushforth wrote: > > We deliver a set of modular jars in the lib directory of the > > standalone JavaFX SDK. We also deliver src.zip for use by IDEs into > > that same directory. If you add the lib directory to your > > application's module path in your IDE, it will try to load src.zip as > > if it were a jar file, and will fail. This is a pain point for > > developers using the SDK. This problem has been raised on the mailing > > list a couple of times, and I think it's time to fix it. This issue is > > tracked in JBS by JDK-8258499 [1]. > > > > I propose to move the src.zip file from the lib directory to the top > > directory of the SDK. > > > > Alternatively, we could create a new directory for src.zip (either a > > sibling of lib or sub-directory under lib). However, I think it would > > be easier to find in the top dir of the SDK, and I don't see the need > > for a new directory just to hold src.zip. > > > > Before I create the PR and the associated CSR, I'd like to hear > > developer's opinions on this. > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8258499 > > > > From arapte at openjdk.java.net Wed Jun 23 15:01:32 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 23 Jun 2021 15:01:32 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 07:11:54 GMT, Marius Hanl wrote: >> ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ >> EDIT: Thank you, Kevin. :) >> >> This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: >> - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. >> -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) >> - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) >> - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) >> >> **-> With this, I can run all normal tests with IntelliJ** >> >> ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): >> - IntelliJ is not detecting javafx.graphic inside the shims >> - All javafx.* dependencies are not found for the system tests >> >> **-> If someone has a solution, feel free to comment :)** > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Reverted whitespace made by IntelliJ The follow on is reported here: [JDK-8269244](https://bugs.openjdk.java.net/browse/JDK-8269244) ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From john at status6.com Wed Jun 23 16:21:29 2021 From: john at status6.com (John Neffenger) Date: Wed, 23 Jun 2021 09:21:29 -0700 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: References: Message-ID: <2c0bea99-e753-7428-f7c1-2e24f6260440@status6.com> On 6/23/21 6:50 AM, Kevin Rushforth wrote: > Are there any IDE users who are currently having problems as a result of > this? If not, I'll retarget this for a future release. I haven't seen problems with the current location of the 'src.zip' file in NetBeans. For Apache Ant projects, though, I do need to extract the archive into a different location and attach the individual source directories to their corresponding modules one at a time. For anyone interested, the following issue tracks the sub-tasks for each of the problems I encountered using the JavaFX Javadocs and Sources with NetBeans: NETBEANS-3296: Attaching JavaFX Javadoc and Sources https://issues.apache.org/jira/browse/NETBEANS-3296 For the Apache Ant work-around, see the section with the title "Add to JAR files." John From nlisker at openjdk.java.net Wed Jun 23 18:21:20 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 23 Jun 2021 18:21:20 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v28] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Grouped vec3's together ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/0b5d73cd..aacac4c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=27 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=26-27 Stats: 6 lines in 3 files changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Wed Jun 23 20:10:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Jun 2021 20:10:36 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v28] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 18:21:20 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Grouped vec3's together You need a corresponding change in the vertex shader. modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main.vert line 40: > 38: vec3 attn; > 39: float range; > 40: vec3 dir; These need to be reordered to match the changes in the fragment shaders. As it is, it causes a shader link error. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kevin.rushforth at oracle.com Wed Jun 23 22:27:34 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Jun 2021 15:27:34 -0700 Subject: Cleanup JavaFX apps, tests, and scripts Message-ID: We discussed earlier the idea of cleaning up some of the unused programs and eventually reorganizing the apps and test directories. As a first step, I filed JDK-8269259 [1] in which I propose to delete the following applications, tests, and scripts that are either obsolete or unmaintained: apps/performance/* apps/tests/HelloTest apps/toys/FXSlideShow apps/toys/Industrial apps/toys/Shape3DToy apps/toys/StretchyGrid apps/toys/TouchSuite tests/performance/VMPerformance tools/* While some of them might be useful, they aren't in their current form, and it is likely not worth the effort to fix them. They will be in the repo history if anyone really needs them. If anyone objects to a specific program or subdirectory in the above list, let me know how you are using it or why you think it is still useful. To put this in context, this is step 1 of a multipart effort to reduce unmaintained or obsolete applications, tests, and scripts in our repo. When we are all done, the test directory will contain automated and manual tests that are built on a regular basis (and it should be straightforward to run the manual tests). The apps directory will just contain the samples [2]. The following directories will be examined during this extended effort. apps/ ? performance/ ? tests/ ? toys/ tests/ ? functional/ ? manual/ ? performance/ tools/ ? gltrace/ ? scripts/ As mentioned at the beginning, step 1 is to identify those programs that will be deleted. That way we don't expend any more effort on them when we do subsequent steps. I expect the rest will be done incrementally, and include (not necessarily in order): 1. Wire up the programs under tests/manual to the build, possibly with a new gradle task. If it isn't built as part of "gradle test" then that new task needs to be added to "gradle all" 2. Wire up the programs under tests/performance to the build, probably the same build task as used in step 1. 3. Move the remaining test programs from apps/toys/* and apps/tests/* to tests/manual/ -- since we currently use many of these in manual testing, they need to continue to be built by either "gradle all" or "gradle test", and be easily able to run even if step 1 isn't done. 4. If there are any remaining test programs in apps/performance, move them to tests/performance (currently I propose to delete them all, so this step will go away). Comments? -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8269259 [2] As a separate effort -- not directly associated with this cleanup -- the samples could possibly be forked and maintained elsewhere as long as they are easy to download, build and run. Anything related to apps/samples should be discussed in a separate email thread. From kevin.rushforth at oracle.com Wed Jun 23 22:30:40 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Jun 2021 15:30:40 -0700 Subject: Cleanup JavaFX apps, tests, and scripts In-Reply-To: References: Message-ID: <6a4d73b3-6aec-db53-30c0-e4c931f3595e@oracle.com> I missed one. I also propose to delete: tests/functional/* This was one of the directories that prompted this discussion in the first place. It was on my working list to delete and I missed copying it into this email. -- Kevin On 6/23/2021 3:27 PM, Kevin Rushforth wrote: > We discussed earlier the idea of cleaning up some of the unused > programs and eventually reorganizing the apps and test directories. > > As a first step, I filed JDK-8269259 [1] in which I propose to delete > the following applications, tests, and scripts that are either > obsolete or unmaintained: > > apps/performance/* > > apps/tests/HelloTest > > apps/toys/FXSlideShow > apps/toys/Industrial > apps/toys/Shape3DToy > apps/toys/StretchyGrid > apps/toys/TouchSuite > > tests/performance/VMPerformance > > tools/* > > While some of them might be useful, they aren't in their current form, > and it is likely not worth the effort to fix them. They will be in the > repo history if anyone really needs them. > > If anyone objects to a specific program or subdirectory in the above > list, let me know how you are using it or why you think it is still > useful. > > To put this in context, this is step 1 of a multipart effort to reduce > unmaintained or obsolete applications, tests, and scripts in our repo. > > When we are all done, the test directory will contain automated and > manual tests that are built on a regular basis (and it should be > straightforward to run the manual tests). The apps directory will just > contain the samples [2]. > > The following directories will be examined during this extended effort. > > apps/ > ? performance/ > ? tests/ > ? toys/ > > tests/ > ? functional/ > ? manual/ > ? performance/ > > tools/ > ? gltrace/ > ? scripts/ > > As mentioned at the beginning, step 1 is to identify those programs > that will be deleted. That way we don't expend any more effort on them > when we do subsequent steps. > > I expect the rest will be done incrementally, and include (not > necessarily in order): > > 1. Wire up the programs under tests/manual to the build, possibly with > a new gradle task. If it isn't built as part of "gradle test" then > that new task needs to be added to "gradle all" > > 2. Wire up the programs under tests/performance to the build, probably > the same build task as used in step 1. > > 3. Move the remaining test programs from apps/toys/* and apps/tests/* > to tests/manual/ -- since we currently use many of these in manual > testing, they need to continue to be built by either "gradle all" or > "gradle test", and be easily able to run even if step 1 isn't done. > > 4. If there are any remaining test programs in apps/performance, move > them to tests/performance (currently I propose to delete them all, so > this step will go away). > > Comments? > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8269259 > > [2] As a separate effort -- not directly associated with this cleanup > -- the samples could possibly be forked and maintained elsewhere as > long as they are easy to download, build and run. Anything related to > apps/samples should be discussed in a separate email thread. > From nlisker at openjdk.java.net Wed Jun 23 22:37:11 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 23 Jun 2021 22:37:11 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v29] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Corrected vertex shader ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/aacac4c1..f9ce9624 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=28 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=27-28 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Wed Jun 23 22:37:16 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 23 Jun 2021 22:37:16 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v28] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 20:07:02 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Grouped vec3's together > > modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main.vert line 40: > >> 38: vec3 attn; >> 39: float range; >> 40: vec3 dir; > > These need to be reordered to match the changes in the fragment shaders. As it is, it causes a shader link error. Sorry, I can't test the fix on Linux for now. I hope made the change, but didn't verify that it works. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Wed Jun 23 23:37:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Jun 2021 23:37:45 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v29] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 22:37:11 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected vertex shader Tested on Mac and Linux. Works fine again. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at gmail.com Wed Jun 23 23:43:58 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 24 Jun 2021 02:43:58 +0300 Subject: Cleanup JavaFX apps, tests, and scripts In-Reply-To: <6a4d73b3-6aec-db53-30c0-e4c931f3595e@oracle.com> References: <6a4d73b3-6aec-db53-30c0-e4c931f3595e@oracle.com> Message-ID: Sounds good. I never understood the current organization scheme. IDEs will need to adjust their files accordingly. On Thu, Jun 24, 2021 at 1:31 AM Kevin Rushforth wrote: > I missed one. I also propose to delete: > > tests/functional/* > > This was one of the directories that prompted this discussion in the > first place. It was on my working list to delete and I missed copying it > into this email. > > -- Kevin > > > On 6/23/2021 3:27 PM, Kevin Rushforth wrote: > > We discussed earlier the idea of cleaning up some of the unused > > programs and eventually reorganizing the apps and test directories. > > > > As a first step, I filed JDK-8269259 [1] in which I propose to delete > > the following applications, tests, and scripts that are either > > obsolete or unmaintained: > > > > apps/performance/* > > > > apps/tests/HelloTest > > > > apps/toys/FXSlideShow > > apps/toys/Industrial > > apps/toys/Shape3DToy > > apps/toys/StretchyGrid > > apps/toys/TouchSuite > > > > tests/performance/VMPerformance > > > > tools/* > > > > While some of them might be useful, they aren't in their current form, > > and it is likely not worth the effort to fix them. They will be in the > > repo history if anyone really needs them. > > > > If anyone objects to a specific program or subdirectory in the above > > list, let me know how you are using it or why you think it is still > > useful. > > > > To put this in context, this is step 1 of a multipart effort to reduce > > unmaintained or obsolete applications, tests, and scripts in our repo. > > > > When we are all done, the test directory will contain automated and > > manual tests that are built on a regular basis (and it should be > > straightforward to run the manual tests). The apps directory will just > > contain the samples [2]. > > > > The following directories will be examined during this extended effort. > > > > apps/ > > performance/ > > tests/ > > toys/ > > > > tests/ > > functional/ > > manual/ > > performance/ > > > > tools/ > > gltrace/ > > scripts/ > > > > As mentioned at the beginning, step 1 is to identify those programs > > that will be deleted. That way we don't expend any more effort on them > > when we do subsequent steps. > > > > I expect the rest will be done incrementally, and include (not > > necessarily in order): > > > > 1. Wire up the programs under tests/manual to the build, possibly with > > a new gradle task. If it isn't built as part of "gradle test" then > > that new task needs to be added to "gradle all" > > > > 2. Wire up the programs under tests/performance to the build, probably > > the same build task as used in step 1. > > > > 3. Move the remaining test programs from apps/toys/* and apps/tests/* > > to tests/manual/ -- since we currently use many of these in manual > > testing, they need to continue to be built by either "gradle all" or > > "gradle test", and be easily able to run even if step 1 isn't done. > > > > 4. If there are any remaining test programs in apps/performance, move > > them to tests/performance (currently I propose to delete them all, so > > this step will go away). > > > > Comments? > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8269259 > > > > [2] As a separate effort -- not directly associated with this cleanup > > -- the samples could possibly be forked and maintained elsewhere as > > long as they are easy to download, build and run. Anything related to > > apps/samples should be discussed in a separate email thread. > > > > From kevin.rushforth at oracle.com Wed Jun 23 23:56:24 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Jun 2021 16:56:24 -0700 Subject: [External] : Re: Cleanup JavaFX apps, tests, and scripts In-Reply-To: References: <6a4d73b3-6aec-db53-30c0-e4c931f3595e@oracle.com> Message-ID: > IDEs will need to adjust their files accordingly. For the first step (the removal covered by JDK-8269259), I think I got them all for IntelliJ and Eclipse, but that will need to be verified. I want to hear if there are any other comments, so I'll send a PR later this week or on Monday. -- Kevin On 6/23/2021 4:43 PM, Nir Lisker wrote: > Sounds good. I never understood the current organization scheme. > > IDEs will need to adjust their files accordingly. > > On Thu, Jun 24, 2021 at 1:31 AM Kevin Rushforth > > wrote: > > I missed one. I also propose to delete: > > tests/functional/* > > This was one of the directories that prompted this discussion in the > first place. It was on my working list to delete and I missed > copying it > into this email. > > -- Kevin > > > On 6/23/2021 3:27 PM, Kevin Rushforth wrote: > > We discussed earlier the idea of cleaning up some of the unused > > programs and eventually reorganizing the apps and test directories. > > > > As a first step, I filed JDK-8269259 [1] in which I propose to > delete > > the following applications, tests, and scripts that are either > > obsolete or unmaintained: > > > > apps/performance/* > > > > apps/tests/HelloTest > > > > apps/toys/FXSlideShow > > apps/toys/Industrial > > apps/toys/Shape3DToy > > apps/toys/StretchyGrid > > apps/toys/TouchSuite > > > > tests/performance/VMPerformance > > > > tools/* > > > > While some of them might be useful, they aren't in their current > form, > > and it is likely not worth the effort to fix them. They will be > in the > > repo history if anyone really needs them. > > > > If anyone objects to a specific program or subdirectory in the > above > > list, let me know how you are using it or why you think it is still > > useful. > > > > To put this in context, this is step 1 of a multipart effort to > reduce > > unmaintained or obsolete applications, tests, and scripts in our > repo. > > > > When we are all done, the test directory will contain automated and > > manual tests that are built on a regular basis (and it should be > > straightforward to run the manual tests). The apps directory > will just > > contain the samples [2]. > > > > The following directories will be examined during this extended > effort. > > > > apps/ > > ? performance/ > > ? tests/ > > ? toys/ > > > > tests/ > > ? functional/ > > ? manual/ > > ? performance/ > > > > tools/ > > ? gltrace/ > > ? scripts/ > > > > As mentioned at the beginning, step 1 is to identify those programs > > that will be deleted. That way we don't expend any more effort > on them > > when we do subsequent steps. > > > > I expect the rest will be done incrementally, and include (not > > necessarily in order): > > > > 1. Wire up the programs under tests/manual to the build, > possibly with > > a new gradle task. If it isn't built as part of "gradle test" then > > that new task needs to be added to "gradle all" > > > > 2. Wire up the programs under tests/performance to the build, > probably > > the same build task as used in step 1. > > > > 3. Move the remaining test programs from apps/toys/* and > apps/tests/* > > to tests/manual/ -- since we currently use many of these in manual > > testing, they need to continue to be built by either "gradle > all" or > > "gradle test", and be easily able to run even if step 1 isn't done. > > > > 4. If there are any remaining test programs in apps/performance, > move > > them to tests/performance (currently I propose to delete them > all, so > > this step will go away). > > > > Comments? > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8269259 > > > > > [2] As a separate effort -- not directly associated with this > cleanup > > -- the samples could possibly be forked and maintained elsewhere as > > long as they are easy to download, build and run. Anything > related to > > apps/samples should be discussed in a separate email thread. > > > From nlisker at openjdk.java.net Thu Jun 24 01:21:28 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 24 Jun 2021 01:21:28 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:06:34 GMT, Michael Strau? wrote: > * Expand the `Property.bind` and `Property.bindBidirectional` documentation > * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable") Looks good in general. I left some inline comments which are mostly optional. modules/javafx.base/src/main/java/javafx/beans/property/BooleanPropertyBase.java line 165: > 163: if (source == null) { > 164: throw new NullPointerException("Cannot bind to null"); > 165: } I recommend using `Objects.requireNonNull(source, "Cannot bind to null");` while these are being changed. Same for other files in this PR. modules/javafx.base/src/main/java/javafx/beans/property/BooleanPropertyBase.java line 167: > 165: } > 166: > 167: final ObservableBooleanValue newObservable = (source instanceof ObservableBooleanValue) ? (ObservableBooleanValue) source This line is longer than 120 characters. You can break it into final ObservableBooleanValue newObservable = (source instanceof ObservableBooleanValue) ? (ObservableBooleanValue) source : new ValueWrapper(source); modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 47: > 45: *

    > 46: * After establishing the binding, the value of the bound property is synchronized with the value > 47: * of the binding source. If the value of the binding source changes, the change is immediately I would align the phrasing here with the one from bidirectional binding: After establishing the binding, the value of the bound property is synchronized with the value of the binding source: any change to the value of the binding source will immediately result in the value of the bound property being changed accordingly. modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 68: > 66: > 67: /** > 68: * Removes a unidirectional binding that was established with {@link #bind(ObservableValue)}. Why "**a** unidirectional binding" and not "**the**"? "a" implies that there can be more than one binding at the same time. At least that's how I read it. modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 115: > 113: * @param other the other property > 114: * @throws NullPointerException if {@code other} is {@code null} > 115: * @throws IllegalArgumentException if {@code other} is {@code this} Since there are many references to unidirectional bindings, it might be wise to add an `@see` for the `bind` method. It could also be done with an `@link` on the first occurrence of "unidirectional binding". modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 120: > 118: > 119: /** > 120: * Removes a bidirectional binding that was established with {@link #bindBidirectional(Property)}. "the" (it's possible to have multiple bidi bindings, but only 1 to the same `other` property). ------------- PR: https://git.openjdk.java.net/jfx/pull/533 From mstrauss at openjdk.java.net Thu Jun 24 01:53:53 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 24 Jun 2021 01:53:53 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation [v2] In-Reply-To: References: Message-ID: > * Expand the `Property.bind` and `Property.bindBidirectional` documentation > * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable") Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes as per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/533/files - new: https://git.openjdk.java.net/jfx/pull/533/files/db112677..ea1bf776 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=533&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=533&range=00-01 Stats: 70 lines in 11 files changed: 20 ins; 26 del; 24 mod Patch: https://git.openjdk.java.net/jfx/pull/533.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/533/head:pull/533 PR: https://git.openjdk.java.net/jfx/pull/533 From mstrauss at openjdk.java.net Thu Jun 24 02:23:27 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 24 Jun 2021 02:23:27 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 01:00:54 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes as per review > > modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 68: > >> 66: >> 67: /** >> 68: * Removes a unidirectional binding that was established with {@link #bind(ObservableValue)}. > > Why "**a** unidirectional binding" and not "**the**"? "a" implies that there can be more than one binding at the same time. At least that's how I read it. That's an interesting observation. The way I read it, "the" sounds very specific, like we're talking about a particular binding to a particular source. However, `unbind()` doesn't only remove _one_ particular binding, it removes _any_ particular binding of the infinite number of particular bindings that can exist (although not at the same time), or no binding at all if the property is not bound. That being said, if you have a stronger opinion on this, please go ahead and make the call. ------------- PR: https://git.openjdk.java.net/jfx/pull/533 From nlisker at openjdk.java.net Thu Jun 24 02:38:30 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 24 Jun 2021 02:38:30 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation [v2] In-Reply-To: References: Message-ID: <4exmGlg2Co45tgbmJA2xGLfw7nZYQpW_DYO4S-QSdy0=.184e3c66-4d3f-476b-8568-5604ef376ed8@github.com> On Thu, 24 Jun 2021 02:20:09 GMT, Michael Strau? wrote: >> modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 68: >> >>> 66: >>> 67: /** >>> 68: * Removes a unidirectional binding that was established with {@link #bind(ObservableValue)}. >> >> Why "**a** unidirectional binding" and not "**the**"? "a" implies that there can be more than one binding at the same time. At least that's how I read it. > > That's an interesting observation. The way I read it, "the" sounds very specific, like we're talking about a particular binding to a particular source. However, `unbind()` doesn't only remove _one_ particular binding, it removes _any_ particular binding of the infinite number of particular bindings that can exist (although not at the same time), or no binding at all if the property is not bound. > > That being said, if you have a stronger opinion on this, please go ahead and make the call. Let's see what Kevin says when he reviews this. ------------- PR: https://git.openjdk.java.net/jfx/pull/533 From almatvee at openjdk.java.net Thu Jun 24 02:54:43 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 24 Jun 2021 02:54:43 GMT Subject: RFR: 8269147: Update GStreamer to version 1.18.4 Message-ID: - GStreamer updated to 1.18.4. - Tested on all platforms with all formats. ------------- Commit messages: - 8269147: Update GStreamer to version 1.18.4 Changes: https://git.openjdk.java.net/jfx/pull/541/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=541&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269147 Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod Patch: https://git.openjdk.java.net/jfx/pull/541.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/541/head:pull/541 PR: https://git.openjdk.java.net/jfx/pull/541 From tom.schindl at bestsolution.at Thu Jun 24 08:19:09 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 24 Jun 2021 10:19:09 +0200 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: References: Message-ID: well I guess eclipse users won't see the sources anymore if they are moved, as we expect the src.zip next to the jar file [1] if I read my code appropriately. I filed [2] to adapt our code Tom [1] https://github.com/eclipse-efx/efxclipse-eclipse/blob/master/bundles/tooling/org.eclipse.fx.ide.jdt.core/src/org/eclipse/fx/ide/jdt/core/internal/BuildPathSupport.java#L80 [2] https://github.com/eclipse-efx/efxclipse-eclipse/issues/85 Am 23.06.21 um 15:50 schrieb Kevin Rushforth: > Are there any IDE users who are currently having problems as a result of > this? If not, I'll retarget this for a future release. > > -- Kevin > > > On 6/14/2021 1:15 PM, Kevin Rushforth wrote: >> We deliver a set of modular jars in the lib directory of the >> standalone JavaFX SDK. We also deliver src.zip for use by IDEs into >> that same directory. If you add the lib directory to your >> application's module path in your IDE, it will try to load src.zip as >> if it were a jar file, and will fail. This is a pain point for >> developers using the SDK. This problem has been raised on the mailing >> list a couple of times, and I think it's time to fix it. This issue is >> tracked in JBS by JDK-8258499 [1]. >> >> I propose to move the src.zip file from the lib directory to the top >> directory of the SDK. >> >> Alternatively, we could create a new directory for src.zip (either a >> sibling of lib or sub-directory under lib). However, I think it would >> be easier to find in the top dir of the SDK, and I don't see the need >> for a new directory just to hold src.zip. >> >> Before I create the PR and the associated CSR, I'd like to hear >> developer's opinions on this. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8258499 >> > From jvos at openjdk.java.net Thu Jun 24 08:23:31 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 24 Jun 2021 08:23:31 GMT Subject: RFR: 8269147: Update GStreamer to version 1.18.4 In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. Those changes look reasonable. It seems that mainly windows is impacted. @tiainen can you double-check the static windows builds are ok with those changes? ------------- PR: https://git.openjdk.java.net/jfx/pull/541 From youngty1997 at gmail.com Thu Jun 24 09:37:29 2021 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 24 Jun 2021 02:37:29 -0700 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: References: Message-ID: <139f91a1-1b64-456d-11be-8796b037c673@gmail.com> Netbeans no longer defaults to creating Ant based projects unlike years ago & there has been, IIRC, some talk on further retiring support for it and Maven works just fine provided that you use the JavaFX Maven plugin*. Still maybe worth fixing since support isn't completely removed and there may be cases where one might want to download and use a JavaFX SDK dist. * the situation with IDE JavaFX support is complicated due to a project created outside Netbeans not set up with hacks Netbeans needs for green run button but there is an in-IDE option to do javafx:run and intellij needs a custom run action created to do javafx:run AFAIK, but I digress. On 6/14/2021 1:15 PM, Kevin Rushforth wrote: > We deliver a set of modular jars in the lib directory of the > standalone JavaFX SDK. We also deliver src.zip for use by IDEs into > that same directory. If you add the lib directory to your > application's module path in your IDE, it will try to load src.zip as > if it were a jar file, and will fail. This is a pain point for > developers using the SDK. This problem has been raised on the mailing > list a couple of times, and I think it's time to fix it. This issue is > tracked in JBS by JDK-8258499 [1]. > > I propose to move the src.zip file from the lib directory to the top > directory of the SDK. > > Alternatively, we could create a new directory for src.zip (either a > sibling of lib or sub-directory under lib). However, I think it would > be easier to find in the top dir of the SDK, and I don't see the need > for a new directory just to hold src.zip. > > Before I create the PR and the associated CSR, I'd like to hear > developer's opinions on this. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8258499 > From kcr at openjdk.java.net Thu Jun 24 13:17:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Jun 2021 13:17:28 GMT Subject: RFR: 8269147: Update GStreamer to version 1.18.4 In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. The code changes look good. I tested it on all three platforms. No problems. @tiainen can be the second reviewer on this. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/541 From arapte at openjdk.java.net Thu Jun 24 17:54:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 24 Jun 2021 17:54:40 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v29] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 22:37:11 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected vertex shader Excellent work. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/334 From kevin.rushforth at oracle.com Thu Jun 24 18:16:24 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 24 Jun 2021 11:16:24 -0700 Subject: Proposed schedule for JavaFX 17 In-Reply-To: <88e02367-1438-57e5-b243-578feb74ad8e@oracle.com> References: <88e02367-1438-57e5-b243-578feb74ad8e@oracle.com> Message-ID: As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 17 starts on July 8, 2021 at 16:00 UTC (09:00 Pacific time), which is two weeks from today. During rampdown of JavaFX 17, the "master" branch of the jfx repo will be open for JavaFX 18 fixes. Please allow sufficient time for any feature that needs a CSR. New features should be far enough along in the review process that you can finalize the CSR before Thursday, July 1, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 18. We will follow the same process as in previous releases for getting fixes into JavaFX 17 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 3/30/2021 7:30 AM, Kevin Rushforth wrote: > I just noticed a copy/paste error: > > > We plan to fork a jfx16 stabilization branch at RDP1. > > That should be a "jfx17" branch. > > -- Kevin > > > On 3/30/2021 7:28 AM, Kevin Rushforth wrote: >> ?Here is the proposed schedule for JavaFX 17. >> >> RDP1: Jul 8, 2021 (aka ?feature freeze?) >> RDP2: Jul 29, 2021 >> Freeze: Aug 19, 2021 >> GA: Sep 7, 2021 >> >> We plan to fork a jfx16 stabilization branch at RDP1. The GA date is >> expected to be one week ahead of JDK 17, matching what we did for 16. >> >> As was done for the previous release, the start of RDP1, the start of >> RDP2, and the code freeze will be 16:00 UTC on the respective dates. >> >> Please let Johan or me know if you have any questions. >> >> -- Kevin >> > From kevin.rushforth at oracle.com Thu Jun 24 18:22:34 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 24 Jun 2021 11:22:34 -0700 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: <139f91a1-1b64-456d-11be-8796b037c673@gmail.com> References: <139f91a1-1b64-456d-11be-8796b037c673@gmail.com> Message-ID: <36ecc54c-be93-9276-7f92-cfa82390f0a6@oracle.com> Since it seems that this change will cause Eclipse to not find the sources without changes on their part (see Tom's message), and might not be as important any more for Netbeans users, it's less clear to me that we should make this change. Netbeans users who download and use the JavaFX SDK can already use the documented workaround of adding the individual jar files rather than the entire lib directory to the module path. Anyone feel strongly that we should still do this? -- Kevin On 6/24/2021 2:37 AM, Ty Young wrote: > Netbeans no longer defaults to creating Ant based projects unlike > years ago & there has been, IIRC, some talk on further retiring > support for it and Maven works just fine provided that you use the > JavaFX Maven plugin*. > > > Still maybe worth fixing since support isn't completely removed and > there may be cases where one might want to download and use a JavaFX > SDK dist. > > > * the situation with IDE JavaFX support is complicated due to a > project created outside Netbeans not set up with hacks Netbeans needs > for green run button but there is an in-IDE option to do javafx:run > and intellij needs a custom run action created to do javafx:run AFAIK, > but I digress. > > > On 6/14/2021 1:15 PM, Kevin Rushforth wrote: >> We deliver a set of modular jars in the lib directory of the >> standalone JavaFX SDK. We also deliver src.zip for use by IDEs into >> that same directory. If you add the lib directory to your >> application's module path in your IDE, it will try to load src.zip as >> if it were a jar file, and will fail. This is a pain point for >> developers using the SDK. This problem has been raised on the mailing >> list a couple of times, and I think it's time to fix it. This issue >> is tracked in JBS by JDK-8258499 [1]. >> >> I propose to move the src.zip file from the lib directory to the top >> directory of the SDK. >> >> Alternatively, we could create a new directory for src.zip (either a >> sibling of lib or sub-directory under lib). However, I think it would >> be easier to find in the top dir of the SDK, and I don't see the need >> for a new directory just to hold src.zip. >> >> Before I create the PR and the associated CSR, I'd like to hear >> developer's opinions on this. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8258499 >> From tom.schindl at bestsolution.at Thu Jun 24 18:33:21 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 24 Jun 2021 20:33:21 +0200 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: <36ecc54c-be93-9276-7f92-cfa82390f0a6@oracle.com> References: <139f91a1-1b64-456d-11be-8796b037c673@gmail.com> <36ecc54c-be93-9276-7f92-cfa82390f0a6@oracle.com> Message-ID: well I can push a new release in a few days if I know your final decision? You proposed option 1 and to me that sounds fine to me. Tom Am 24.06.21 um 20:22 schrieb Kevin Rushforth: > Since it seems that this change will cause Eclipse to not find the > sources without changes on their part (see Tom's message), and might not > be as important any more for Netbeans users, it's less clear to me that > we should make this change. Netbeans users who download and use the > JavaFX SDK can already use the documented workaround of adding the > individual jar files rather than the entire lib directory to the module > path. > > Anyone feel strongly that we should still do this? > > -- Kevin > > > On 6/24/2021 2:37 AM, Ty Young wrote: >> Netbeans no longer defaults to creating Ant based projects unlike >> years ago & there has been, IIRC, some talk on further retiring >> support for it and Maven works just fine provided that you use the >> JavaFX Maven plugin*. >> >> >> Still maybe worth fixing since support isn't completely removed and >> there may be cases where one might want to download and use a JavaFX >> SDK dist. >> >> >> * the situation with IDE JavaFX support is complicated due to a >> project created outside Netbeans not set up with hacks Netbeans needs >> for green run button but there is an in-IDE option to do javafx:run >> and intellij needs a custom run action created to do javafx:run AFAIK, >> but I digress. >> >> >> On 6/14/2021 1:15 PM, Kevin Rushforth wrote: >>> We deliver a set of modular jars in the lib directory of the >>> standalone JavaFX SDK. We also deliver src.zip for use by IDEs into >>> that same directory. If you add the lib directory to your >>> application's module path in your IDE, it will try to load src.zip as >>> if it were a jar file, and will fail. This is a pain point for >>> developers using the SDK. This problem has been raised on the mailing >>> list a couple of times, and I think it's time to fix it. This issue >>> is tracked in JBS by JDK-8258499 [1]. >>> >>> I propose to move the src.zip file from the lib directory to the top >>> directory of the SDK. >>> >>> Alternatively, we could create a new directory for src.zip (either a >>> sibling of lib or sub-directory under lib). However, I think it would >>> be easier to find in the top dir of the SDK, and I don't see the need >>> for a new directory just to hold src.zip. >>> >>> Before I create the PR and the associated CSR, I'd like to hear >>> developer's opinions on this. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8258499 >>> > From nlisker at openjdk.java.net Thu Jun 24 18:35:43 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 24 Jun 2021 18:35:43 GMT Subject: Integrated: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: <9giDcwFf486yqVga2d6opw1G1b02OYPVxihDKF_VXIw=.c1d3ef89-9b77-4a98-b2e6-ff30085dee4a@github.com> On Thu, 22 Oct 2020 18:29:19 GMT, Nir Lisker wrote: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. This pull request has now been integrated. Changeset: 3fd4c97f Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/3fd4c97ff22b9970f13b612209dbcdfe16eaed8c Stats: 1803 lines in 40 files changed: 1364 ins; 125 del; 314 mod 8234920: Add SpotLight to the selection of 3D light types Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Thu Jun 24 18:52:40 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 24 Jun 2021 18:52:40 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v29] In-Reply-To: References: Message-ID: <91WhQJs-wLAjTo684slGTe15wzgyp3x1aTyXou_d7UA=.6b9abc1b-b772-4cfa-a9e2-25b52450e040@github.com> On Wed, 23 Jun 2021 22:37:11 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected vertex shader Thanks for the all the work Kevin and Ambarish. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kevin.rushforth at oracle.com Thu Jun 24 19:56:33 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 24 Jun 2021 12:56:33 -0700 Subject: Moving src.zip out of the lib directory of the JavaFX SDK In-Reply-To: References: <139f91a1-1b64-456d-11be-8796b037c673@gmail.com> <36ecc54c-be93-9276-7f92-cfa82390f0a6@oracle.com> Message-ID: Ah, OK. If it won't cause you any problems, then it still seems worth considering. I would like to hear from at least one IntelliJ user as to whether this change affects users of that IDE -- either positively or negatively. Does anyone else have any concerns? -- Kevin On 6/24/2021 11:33 AM, Tom Schindl wrote: > well I can push a new release in a few days if I know your final > decision? You proposed option 1 and to me that sounds fine to me. > > Tom > > Am 24.06.21 um 20:22 schrieb Kevin Rushforth: >> Since it seems that this change will cause Eclipse to not find the >> sources without changes on their part (see Tom's message), and might >> not be as important any more for Netbeans users, it's less clear to >> me that we should make this change. Netbeans users who download and >> use the JavaFX SDK can already use the documented workaround of >> adding the individual jar files rather than the entire lib directory >> to the module path. >> >> Anyone feel strongly that we should still do this? >> >> -- Kevin >> >> >> On 6/24/2021 2:37 AM, Ty Young wrote: >>> Netbeans no longer defaults to creating Ant based projects unlike >>> years ago & there has been, IIRC, some talk on further retiring >>> support for it and Maven works just fine provided that you use the >>> JavaFX Maven plugin*. >>> >>> >>> Still maybe worth fixing since support isn't completely removed and >>> there may be cases where one might want to download and use a JavaFX >>> SDK dist. >>> >>> >>> * the situation with IDE JavaFX support is complicated due to a >>> project created outside Netbeans not set up with hacks Netbeans >>> needs for green run button but there is an in-IDE option to do >>> javafx:run and intellij needs a custom run action created to do >>> javafx:run AFAIK, but I digress. >>> >>> >>> On 6/14/2021 1:15 PM, Kevin Rushforth wrote: >>>> We deliver a set of modular jars in the lib directory of the >>>> standalone JavaFX SDK. We also deliver src.zip for use by IDEs into >>>> that same directory. If you add the lib directory to your >>>> application's module path in your IDE, it will try to load src.zip >>>> as if it were a jar file, and will fail. This is a pain point for >>>> developers using the SDK. This problem has been raised on the >>>> mailing list a couple of times, and I think it's time to fix it. >>>> This issue is tracked in JBS by JDK-8258499 [1]. >>>> >>>> I propose to move the src.zip file from the lib directory to the >>>> top directory of the SDK. >>>> >>>> Alternatively, we could create a new directory for src.zip (either >>>> a sibling of lib or sub-directory under lib). However, I think it >>>> would be easier to find in the top dir of the SDK, and I don't see >>>> the need for a new directory just to hold src.zip. >>>> >>>> Before I create the PR and the associated CSR, I'd like to hear >>>> developer's opinions on this. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8258499 >>>> >> From kcr at openjdk.java.net Thu Jun 24 21:42:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Jun 2021 21:42:11 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v5] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 13:09:51 GMT, Michael Strau? wrote: >> This PR extends data URI support to allow stylesheets to be loaded from data URIs. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > cleaned up paragraph tags I spent some time analyzing the changes to `StyleManager::loadStylesheetUnPrivileged`, especially around the use of the local `parse` variable, since you no longer modify it during the processing in a couple places. I think everything is fine, but I'd like @aghaisas to also look at this when he reviews it. If @dsgrieve has any comments, they would be welcome. The following is the current behavior for the case where `fname` ends with `.css` or `.bss`: | `fname` | `.css` exists | `.bss` exists | Result | | ------- | ------------- | ------------- | ------ | | _SOMENAME_.bss | YES | NO | fail | | _SOMENAME_.bss | NO | YES | Use _SOMENAME_.bss instead | | _SOMENAME_.bss | YES | YES | Use _SOMENAME_.bss | | _SOMENAME_.css | YES | NO | Use _SOMENAME_.css | | _SOMENAME_.css | NO | YES | Use _SOMENAME_.bss (NOTE: if `-Dbinary.css=false` then fail) | | _SOMENAME_.css | YES | YES | Use _SOMENAME_.bss (NOTE: if `-Dbinary.css=false` then _SOMENAME_.css) | In case where `fname` ends with neither `.css` nor `.css`, it is assumed to be a CSS file and parsed as such. As near as I can tell, both from reading the code and from running tests, this is still working as expected. So there should be no regression in behavior. The code to process a data URI looks good. As for the tests, can you add at least one test of calling the public `setUserAgentStylesheet` method using a data URI? Maybe as part of `StyleManagerTest`? Also, I left a couple suggestions inline. modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 316: > 314: final int bssVersion = dataInputStream.readShort(); > 315: if (bssVersion > Stylesheet.BINARY_CSS_VERSION) { > 316: throw new IOException("Wrong binary CSS version: " If the `url` string is non-null shouldn't it still be part of the exception message? modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 658: > 656: try { > 657: inputFile = File.createTempFile("convertCssTextToBinary", ".css"); > 658: outputFile = File.createTempFile("convertCssTextToBinary", ".bss"); Instead of writing a pair of temp files, maybe you can call `CssParser.parse` to create a `Stylesheet` and then `Stylesheet.writeBinary` to write to an in memory `DataOutputStream`? Or alternatively, create the `.bss file` and add it as a resource under `src/test/resources/...`? ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From prr at openjdk.java.net Thu Jun 24 22:21:18 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Jun 2021 22:21:18 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API Message-ID: This enhancement adds the String property outputFileProperty() to the JobSettings class. The value should be a string that references a local file encoded as a URL. If this is non-null and set to a location that the user has permission to write to, then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. ------------- Commit messages: - 8223717: javafx printing: Support Specifying Print to File in the API - -8223717: javafx printing: Support Specifying Print to File in the API Changes: https://git.openjdk.java.net/jfx/pull/543/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223717 Stats: 303 lines in 3 files changed: 301 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/543/head:pull/543 PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Thu Jun 24 22:34:36 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Jun 2021 22:34:36 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v2] In-Reply-To: References: Message-ID: > This enhancement adds the String property outputFileProperty() to the JobSettings class. > The value should be a string that references a local file encoded as a URL. > If this is non-null and set to a location that the user has permission to write to, > then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. > The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. > > A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. Phil Race has updated the pull request incrementally with two additional commits since the last revision: - 8223717: javafx printing: Support Specifying Print to File in the API - 8223717: javafx printing: Support Specifying Print to File in the API ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/543/files - new: https://git.openjdk.java.net/jfx/pull/543/files/4edc1315..1c21e10f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/543/head:pull/543 PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Thu Jun 24 22:42:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Jun 2021 22:42:06 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 22:34:36 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with two additional commits since the last revision: > > - 8223717: javafx printing: Support Specifying Print to File in the API > - 8223717: javafx printing: Support Specifying Print to File in the API I left some preliminary comments on the API spec. modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 474: > 472: * encoded name of a filesystem file, to which the platform printer > 473: * driver should spool the rendered print data. > 474: *

    Can you add a sentence indicating that the URL needs to be a `file:` URL? And indicate what happens if it isn't (I presume it is ignored)? modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 475: > 473: * driver should spool the rendered print data. > 474: *

    > 475: * Applications can use this to request print-to-file behaviour where behaviour -> behavior modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 488: > 486: * If the print system does not support print-to-file, then this > 487: *

    > 488: * setting will be ignored. These two lines should be switched. modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 490: > 488: * setting will be ignored. > 489: * If the URL specifies a non-existent path, or does not specify > 490: * a writable file it may be ignored, or a SecurityException may be thrown. I want to look at what we do for other properties like this. I'm not sure how feasible it is to throw an exception back to the application. And I wouldn't want to single out a security exception (what about a read-only file system?). I think that whatever the reason, if the file can't be written to, we should treat it consistently. Probably by ignoring the request. I presume that's what will happen if the print driver doesn't support print-to-file? modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 495: > 493: * > 494: * @return the name of a printer spool file > 495: * @since 13 17 ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Thu Jun 24 22:47:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Jun 2021 22:47:09 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 22:34:36 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with two additional commits since the last revision: > > - 8223717: javafx printing: Support Specifying Print to File in the API > - 8223717: javafx printing: Support Specifying Print to File in the API One more comment on the API for the getters and setter methods. modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 541: > 539: * @since 17 > 540: */ > 541: public String getOutputFile() { This should be final (as should the setter). I see that other getter and setter methods in this class are also non-final, but we shouldn't propagate this mistake. Also, you don't need javadoc comments on the getters and setters, since it will copy them from the property (and add appropriate links). ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Thu Jun 24 23:00:42 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Jun 2021 23:00:42 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: > This enhancement adds the String property outputFileProperty() to the JobSettings class. > The value should be a string that references a local file encoded as a URL. > If this is non-null and set to a location that the user has permission to write to, > then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. > The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. > > A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8223717: javafx printing: Support Specifying Print to File in the API ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/543/files - new: https://git.openjdk.java.net/jfx/pull/543/files/1c21e10f..8050d5f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/543/head:pull/543 PR: https://git.openjdk.java.net/jfx/pull/543 From swpalmer at openjdk.java.net Thu Jun 24 23:00:44 2021 From: swpalmer at openjdk.java.net (Scott Palmer) Date: Thu, 24 Jun 2021 23:00:44 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 22:25:53 GMT, Kevin Rushforth wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8223717: javafx printing: Support Specifying Print to File in the API > > modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 474: > >> 472: * encoded name of a filesystem file, to which the platform printer >> 473: * driver should spool the rendered print data. >> 474: *

    > > Can you add a sentence indicating that the URL needs to be a `file:` URL? And indicate what happens if it isn't (I presume it is ignored)? As a potential user of this API I have to ask, why would this be a URL instead of a File or Path ? Particularly if only "file:" URLs will be valid. I can't think of a scenario where it won't always be an extra inconvenience to convert the path I have to a URL. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Thu Jun 24 23:00:48 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Jun 2021 23:00:48 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 22:38:40 GMT, Kevin Rushforth wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8223717: javafx printing: Support Specifying Print to File in the API > > modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 490: > >> 488: * setting will be ignored. >> 489: * If the URL specifies a non-existent path, or does not specify >> 490: * a writable file it may be ignored, or a SecurityException may be thrown. > > I want to look at what we do for other properties like this. I'm not sure how feasible it is to throw an exception back to the application. And I wouldn't want to single out a security exception (what about a read-only file system?). I think that whatever the reason, if the file can't be written to, we should treat it consistently. Probably by ignoring the request. I presume that's what will happen if the print driver doesn't support print-to-file? Not easy to specify exactly. We are handing it off to 2D We aren't doing any up-front verification here, but I don't want to copy 2D behaviour into the docs, even if I could be sure about that .. I may just want to be more waffly about what happens. Could be printed to the printer, could be a failed job, could be an exception of some kind if some nice piece of Java code recognises a problem up-front ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Thu Jun 24 23:05:59 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Jun 2021 23:05:59 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: <0OhFEFnNt5rSW2l_NfW2pmM0ZHuCIic_zGtWquq3eqw=.038b55ea-b49a-45ff-ad5f-4c96cb24c85a@github.com> On Thu, 24 Jun 2021 22:53:57 GMT, Scott Palmer wrote: >> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 474: >> >>> 472: * encoded name of a filesystem file, to which the platform printer >>> 473: * driver should spool the rendered print data. >>> 474: *

    >> >> Can you add a sentence indicating that the URL needs to be a `file:` URL? And indicate what happens if it isn't (I presume it is ignored)? > > As a potential user of this API I have to ask, why would this be a URL instead of a File or Path ? Particularly if only "file:" URLs will be valid. I can't think of a scenario where it won't always be an extra inconvenience to convert the path I have to a URL. We aren't ignoring it .. its just handed on, so its going to be the same as the other non-writable case .. file could not be created .. printing error .. we could do some up-front validation if that seems like the way we want to go. This could I guess also check if the file is writeable .. but since the user can select a non-writable file location in the dialog I don't think we should do that part. In which case I wonder about the URL validation too .. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Thu Jun 24 23:10:04 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Jun 2021 23:10:04 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v2] In-Reply-To: References: Message-ID: <9XHiBWyQ4u6hoTf88a6jvNoAZBMymNgfw3kOT2a0XNE=.a3bfa36b-740d-46c8-a1a8-6b877a1310d4@github.com> On Thu, 24 Jun 2021 22:42:00 GMT, Kevin Rushforth wrote: >> Phil Race has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8223717: javafx printing: Support Specifying Print to File in the API >> - 8223717: javafx printing: Support Specifying Print to File in the API > > modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 541: > >> 539: * @since 17 >> 540: */ >> 541: public String getOutputFile() { > > This should be final (as should the setter). I see that other getter and setter methods in this class are also non-final, but we shouldn't propagate this mistake. > > Also, you don't need javadoc comments on the getters and setters, since it will copy them from the property (and add appropriate links). But the JobSettings class is final .. is it still necessary ? ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Thu Jun 24 23:22:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Jun 2021 23:22:04 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: <0OhFEFnNt5rSW2l_NfW2pmM0ZHuCIic_zGtWquq3eqw=.038b55ea-b49a-45ff-ad5f-4c96cb24c85a@github.com> References: <0OhFEFnNt5rSW2l_NfW2pmM0ZHuCIic_zGtWquq3eqw=.038b55ea-b49a-45ff-ad5f-4c96cb24c85a@github.com> Message-ID: On Thu, 24 Jun 2021 23:03:29 GMT, Phil Race wrote: >> As a potential user of this API I have to ask, why would this be a URL instead of a File or Path ? Particularly if only "file:" URLs will be valid. I can't think of a scenario where it won't always be an extra inconvenience to convert the path I have to a URL. > > We aren't ignoring it .. its just handed on, so its going to be the same as the other non-writable case .. file could not be created .. printing error .. > we could do some up-front validation if that seems like the way we want to go. This could I guess also check if the file is writeable .. but since the user can select a non-writable file location in the dialog I don't think we should do that part. In which case I wonder about the URL validation too .. Consistency with other APIs would be the main reason. We could do something similar to what we do for `Image`, and treat a string without a protocol as a file (although not relative to the classpath as in the case of images), turning it into a `file:` URL internally where needed. @prrace what do you think? ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Thu Jun 24 23:22:05 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Jun 2021 23:22:05 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: <0OhFEFnNt5rSW2l_NfW2pmM0ZHuCIic_zGtWquq3eqw=.038b55ea-b49a-45ff-ad5f-4c96cb24c85a@github.com> Message-ID: On Thu, 24 Jun 2021 23:19:22 GMT, Kevin Rushforth wrote: >> We aren't ignoring it .. its just handed on, so its going to be the same as the other non-writable case .. file could not be created .. printing error .. >> we could do some up-front validation if that seems like the way we want to go. This could I guess also check if the file is writeable .. but since the user can select a non-writable file location in the dialog I don't think we should do that part. In which case I wonder about the URL validation too .. > > Consistency with other APIs would be the main reason. We could do something similar to what we do for `Image`, and treat a string without a protocol as a file (although not relative to the classpath as in the case of images), turning it into a `file:` URL internally where needed. > > @prrace what do you think? > As a potential user of this API I have to ask, why would this be a URL instead of a File or Path ? Particularly if only "file:" URLs will be valid. I can't think of a scenario where it won't always be an extra inconvenience to convert the path I have to a URL. I will think about it but not promising yet. We only forsee (for now) a file .. We use URL a lot and also the javax.print API in 2D uses URL .. and so 2D hands us a file URL as well as expecting one .. and FX printing depends heavily on that right now so there's no escaping URLs somewhere. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From mstrauss at openjdk.java.net Thu Jun 24 23:24:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 24 Jun 2021 23:24:43 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v6] In-Reply-To: References: Message-ID: > This PR extends data URI support to allow stylesheets to be loaded from data URIs. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/536/files - new: https://git.openjdk.java.net/jfx/pull/536/files/c734640f..64d72fe3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=04-05 Stats: 84 lines in 4 files changed: 52 ins; 9 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/536.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536 PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Thu Jun 24 23:24:47 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 24 Jun 2021 23:24:47 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v5] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 21:12:36 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> cleaned up paragraph tags > > modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 316: > >> 314: final int bssVersion = dataInputStream.readShort(); >> 315: if (bssVersion > Stylesheet.BINARY_CSS_VERSION) { >> 316: throw new IOException("Wrong binary CSS version: " > > If the `url` string is non-null shouldn't it still be part of the exception message? True. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Thu Jun 24 23:35:04 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 24 Jun 2021 23:35:04 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v6] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 23:24:43 GMT, Michael Strau? wrote: >> This PR extends data URI support to allow stylesheets to be loaded from data URIs. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review I added a test for each of `Application.setUserAgentStylesheet`, `Scene.setUserAgentStylesheet`, and `SubScene.setUserAgentStylesheet`. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From kcr at openjdk.java.net Thu Jun 24 23:51:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Jun 2021 23:51:03 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v6] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 23:24:43 GMT, Michael Strau? wrote: >> This PR extends data URI support to allow stylesheets to be loaded from data URIs. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review Changes look good. I'll do a final pass tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From kcr at openjdk.java.net Fri Jun 25 00:22:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 00:22:00 GMT Subject: RFR: 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. In-Reply-To: <1olf0WwPCG_Oa4E6nVkGyNJuElqLdSC65mAt661TX_w=.a8a59aca-c092-47aa-9c4b-c448321e9aaf@github.com> References: <1olf0WwPCG_Oa4E6nVkGyNJuElqLdSC65mAt661TX_w=.a8a59aca-c092-47aa-9c4b-c448321e9aaf@github.com> Message-ID: On Wed, 26 May 2021 20:39:32 GMT, Jose Pereda wrote: > This PR adds several resource bundles with High Contrast Scheme possible values for several locales. > > These values have been found by installing the required language packages on Windows 10 Pro 20H2 (build 19042.985), enabling Settings->High Contrast and finding the high contrast scheme values in the Windows registry (and translating to unicode when needed). Other locales could be generated as well, but so far the list is the same as the locales supported by Controls. > > With these bundles, and assuming the application uses a locale that matches the system settings language, the theme name provided natively (only on Windows so far) can be matched with the high contrast scheme, and the proper stylesheet can be applied. > > This PR has been tested on the same Windows machine, selecting each possible language and setting the locale for the app accordingly. Sorry for the delay. The fix looks good to me. I'll test it tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/520 From psadhukhan at openjdk.java.net Fri Jun 25 07:23:03 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 25 Jun 2021 07:23:03 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 23:00:42 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8223717: javafx printing: Support Specifying Print to File in the API modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java line 352: > 350: try { > 351: settings.setOutputFile(dest.getURI().toURL().toString()); > 352: } catch (MalformedURLException e) { I guess in 2D RasterPrinterJob, if there is any exception, we try to form a default file "out.prn" [https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L1137] and try to print there. Can't we do it here too? modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java line 356: > 354: } else { > 355: settings.setOutputFile(""); > 356: } Actually in 2D , it seems if dest is null, we redirect printing to actual printer instead of file. Not sure if that is what we need to do here too!! [https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L1148] modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java line 839: > 837: security.checkPrintJobAccess(); > 838: String file = settings.getOutputFile(); > 839: if (!file.isEmpty()) { Don't we need to check for file!= null? modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 485: > 483: *

    > 484: * If the application does not have permission to write to the specified > 485: * file, a {@code SecurityException} may be thrown when printing. As I see in 2D atleast in Win32PrintService, if there is a SecurityException for creating a Destination object from a URI, it retries again by creating a new URL with default file "file:out.prn" Is it not needed here? [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/sun/print/Win32PrintService.java#L1181] ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From jvos at openjdk.java.net Fri Jun 25 07:23:03 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 25 Jun 2021 07:23:03 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: <0OhFEFnNt5rSW2l_NfW2pmM0ZHuCIic_zGtWquq3eqw=.038b55ea-b49a-45ff-ad5f-4c96cb24c85a@github.com> Message-ID: On Thu, 24 Jun 2021 23:19:22 GMT, Kevin Rushforth wrote: >> We aren't ignoring it .. its just handed on, so its going to be the same as the other non-writable case .. file could not be created .. printing error .. >> we could do some up-front validation if that seems like the way we want to go. This could I guess also check if the file is writeable .. but since the user can select a non-writable file location in the dialog I don't think we should do that part. In which case I wonder about the URL validation too .. > > Consistency with other APIs would be the main reason. We could do something similar to what we do for `Image`, and treat a string without a protocol as a file (although not relative to the classpath as in the case of images), turning it into a `file:` URL internally where needed. > > @prrace what do you think? I agree with @kevinrushforth that if a String without protocol is passed, it should be treated as a file (absolute or relative to ?) I'm also not sure that the URL should be exposed here. I understand it's needed in the lower-level print API but you already do the conversion in the `syncOutputFile` method. Hence, since only the file protocol is supported, it might be easier for API users to pass the location of the file instead of a URL. In case later other URL protocols are supported, a property `outputURL` might be introduced? ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From aghaisas at openjdk.java.net Fri Jun 25 12:17:04 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 25 Jun 2021 12:17:04 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v6] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 23:24:43 GMT, Michael Strau? wrote: >> This PR extends data URI support to allow stylesheets to be loaded from data URIs. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review Code changes are OK. I found an Exception being logged from newly added test. Please check. modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/StyleManagerTest.java line 1171: > 1169: assertEquals(Color.BLUE, rect.getFill()); > 1170: } finally { > 1171: Application.setUserAgentStylesheet(uaStylesheet); This line in `finally` block results in `ClassNotFoundException` Run the tests as below to get the log- `gradle --info :graphics:test &> test.log` ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From kcr at openjdk.java.net Fri Jun 25 13:04:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 13:04:09 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 20:26:24 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes as per review comments Looks good. I have one minor comment on the test. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableListTest.java line 105: > 103: */ > 104: @Test > 105: @Ignore("see JDK-8267951") The comment by @arapte was not addressed. Please remove `see ` from the string passed to `@Ignore`. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Fri Jun 25 13:08:36 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 25 Jun 2021 13:08:36 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v10] In-Reply-To: References: Message-ID: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/478/files - new: https://git.openjdk.java.net/jfx/pull/478/files/1672f4da..8746dee1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/478.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/478/head:pull/478 PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Fri Jun 25 13:08:41 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 25 Jun 2021 13:08:41 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v9] In-Reply-To: References: Message-ID: <0g2UHC8qMIYkRFSoInc9-FgdLZglEg3SagATfeFXjwk=.456962c6-7412-49b2-91fb-b4e60b99417f@github.com> On Fri, 25 Jun 2021 12:53:13 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes as per review comments > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableListTest.java line 105: > >> 103: */ >> 104: @Test >> 105: @Ignore("see JDK-8267951") > > The comment by @arapte was not addressed. Please remove `see ` from the string passed to `@Ignore`. Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From kcr at openjdk.java.net Fri Jun 25 13:12:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 13:12:01 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v10] In-Reply-To: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> References: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> Message-ID: On Fri, 25 Jun 2021 13:08:36 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From kcr at openjdk.java.net Fri Jun 25 13:35:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 13:35:08 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v6] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 12:07:23 GMT, Ajit Ghaisas wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes per review > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/StyleManagerTest.java line 1171: > >> 1169: assertEquals(Color.BLUE, rect.getFill()); >> 1170: } finally { >> 1171: Application.setUserAgentStylesheet(uaStylesheet); > > This line in `finally` block results in `ClassNotFoundException` > > Run the tests as below to get the log- > > `gradle --info :graphics:test &> test.log` Good catch. The reason for this is that the default Stylesheet is in the `javafx.controls` module, which is not available when running unit tests in the `javafx.graphics` module. I recommend to either `@Ignore` this test or else reset it to an empty style sheet (which is effectively what it will be for `javafx.graphics` tests, since the platform initialization code that sets up the default stylesheet is never called for these tests). ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Fri Jun 25 13:54:24 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 25 Jun 2021 13:54:24 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v7] In-Reply-To: References: Message-ID: <3P94MNvCPqXDO-L9QV3m-kGIOD1Pcp4etwbYeFfVDN8=.86c55aa2-d958-4121-bc09-06fc07fcd958@github.com> > This PR extends data URI support to allow stylesheets to be loaded from data URIs. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: reset app UA stylesheet to empty stylesheet ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/536/files - new: https://git.openjdk.java.net/jfx/pull/536/files/64d72fe3..230cc49e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=536&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/536.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536 PR: https://git.openjdk.java.net/jfx/pull/536 From mstrauss at openjdk.java.net Fri Jun 25 13:54:24 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 25 Jun 2021 13:54:24 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v6] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 13:31:45 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/StyleManagerTest.java line 1171: >> >>> 1169: assertEquals(Color.BLUE, rect.getFill()); >>> 1170: } finally { >>> 1171: Application.setUserAgentStylesheet(uaStylesheet); >> >> This line in `finally` block results in `ClassNotFoundException` >> >> Run the tests as below to get the log- >> >> `gradle --info :graphics:test &> test.log` > > Good catch. The reason for this is that the default Stylesheet is in the `javafx.controls` module, which is not available when running unit tests in the `javafx.graphics` module. I recommend to either `@Ignore` this test or else reset it to an empty style sheet (which is effectively what it will be for `javafx.graphics` tests, since the platform initialization code that sets up the default stylesheet is never called for these tests). I've decided to reset the UA stylesheet to an empty stylesheet. ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From kcr at openjdk.java.net Fri Jun 25 14:04:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 14:04:07 GMT Subject: RFR: 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. In-Reply-To: <1olf0WwPCG_Oa4E6nVkGyNJuElqLdSC65mAt661TX_w=.a8a59aca-c092-47aa-9c4b-c448321e9aaf@github.com> References: <1olf0WwPCG_Oa4E6nVkGyNJuElqLdSC65mAt661TX_w=.a8a59aca-c092-47aa-9c4b-c448321e9aaf@github.com> Message-ID: On Wed, 26 May 2021 20:39:32 GMT, Jose Pereda wrote: > This PR adds several resource bundles with High Contrast Scheme possible values for several locales. > > These values have been found by installing the required language packages on Windows 10 Pro 20H2 (build 19042.985), enabling Settings->High Contrast and finding the high contrast scheme values in the Windows registry (and translating to unicode when needed). Other locales could be generated as well, but so far the list is the same as the locales supported by Controls. > > With these bundles, and assuming the application uses a locale that matches the system settings language, the theme name provided natively (only on Windows so far) can be matched with the high contrast scheme, and the proper stylesheet can be applied. > > This PR has been tested on the same Windows machine, selecting each possible language and setting the locale for the app accordingly. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/520 From kcr at openjdk.java.net Fri Jun 25 14:48:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 14:48:07 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v7] In-Reply-To: <3P94MNvCPqXDO-L9QV3m-kGIOD1Pcp4etwbYeFfVDN8=.86c55aa2-d958-4121-bc09-06fc07fcd958@github.com> References: <3P94MNvCPqXDO-L9QV3m-kGIOD1Pcp4etwbYeFfVDN8=.86c55aa2-d958-4121-bc09-06fc07fcd958@github.com> Message-ID: On Fri, 25 Jun 2021 13:54:24 GMT, Michael Strau? wrote: >> This PR extends data URI support to allow stylesheets to be loaded from data URIs. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > reset app UA stylesheet to empty stylesheet Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/536 From kcr at openjdk.java.net Fri Jun 25 15:06:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 15:06:48 GMT Subject: RFR: 8269259: Remove obsolete apps, tests, and scripts Message-ID: This PR deletes the following applications, tests, and scripts that are either obsolete or unmaintained: apps/performance/* apps/tests/HelloTest apps/toys/FXSlideShow apps/toys/Industrial apps/toys/Shape3DToy apps/toys/StretchyGrid apps/toys/TouchSuite tests/functional/* tests/performance/VMPerformance tools/* See the JBS issue and [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030894.html) on the openjfx-dev mailing list for more info. There are two commits for ease of review. The first one is generated by doing a "git rm -r" on each of the above listed directories. The second is to remove any remaining references to the removed directories. ------------- Commit messages: - Remove references to removed dirs and apps - 8269259: Remove obsolete apps, tests, and scripts Changes: https://git.openjdk.java.net/jfx/pull/545/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=545&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269259 Stats: 33646 lines in 196 files changed: 0 ins; 33645 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/545.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/545/head:pull/545 PR: https://git.openjdk.java.net/jfx/pull/545 From aghaisas at openjdk.java.net Fri Jun 25 16:32:05 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 25 Jun 2021 16:32:05 GMT Subject: RFR: 8267554: Support loading stylesheets from data-URIs [v7] In-Reply-To: <3P94MNvCPqXDO-L9QV3m-kGIOD1Pcp4etwbYeFfVDN8=.86c55aa2-d958-4121-bc09-06fc07fcd958@github.com> References: <3P94MNvCPqXDO-L9QV3m-kGIOD1Pcp4etwbYeFfVDN8=.86c55aa2-d958-4121-bc09-06fc07fcd958@github.com> Message-ID: On Fri, 25 Jun 2021 13:54:24 GMT, Michael Strau? wrote: >> This PR extends data URI support to allow stylesheets to be loaded from data URIs. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > reset app UA stylesheet to empty stylesheet Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From nlisker at openjdk.java.net Fri Jun 25 16:48:06 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 25 Jun 2021 16:48:06 GMT Subject: RFR: 8269259: Remove obsolete apps, tests, and scripts In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 14:59:00 GMT, Kevin Rushforth wrote: > This PR deletes the following applications, tests, and scripts that are either obsolete > or unmaintained: > > apps/performance/* > > apps/tests/HelloTest > > apps/toys/FXSlideShow > apps/toys/Industrial > apps/toys/Shape3DToy > apps/toys/StretchyGrid > apps/toys/TouchSuite > > tests/functional/* > tests/performance/VMPerformance > > tools/* > > See the JBS issue and [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030894.html) on the openjfx-dev mailing list for more info. > > There are two commits for ease of review. The first one is generated by doing a "git rm -r" on each of the above listed directories. The second is to remove any remaining references to the removed directories. I will review the eclipse file changes. I'm not sure what constitutes a review for removed files in the case where nothing depends on them. ------------- PR: https://git.openjdk.java.net/jfx/pull/545 From mstrauss at openjdk.java.net Fri Jun 25 20:11:03 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 25 Jun 2021 20:11:03 GMT Subject: Integrated: 8267554: Support loading stylesheets from data-URIs In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 01:23:50 GMT, Michael Strau? wrote: > This PR extends data URI support to allow stylesheets to be loaded from data URIs. This pull request has now been integrated. Changeset: 78179be1 Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/78179be10199291461411f09e4f6c4a1e653b195 Stats: 355 lines in 7 files changed: 314 ins; 15 del; 26 mod 8267554: Support loading stylesheets from data-URIs Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/536 From kcr at openjdk.java.net Fri Jun 25 21:20:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 21:20:04 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v2] In-Reply-To: <9XHiBWyQ4u6hoTf88a6jvNoAZBMymNgfw3kOT2a0XNE=.a3bfa36b-740d-46c8-a1a8-6b877a1310d4@github.com> References: <9XHiBWyQ4u6hoTf88a6jvNoAZBMymNgfw3kOT2a0XNE=.a3bfa36b-740d-46c8-a1a8-6b877a1310d4@github.com> Message-ID: On Thu, 24 Jun 2021 23:06:54 GMT, Phil Race wrote: >> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 541: >> >>> 539: * @since 17 >>> 540: */ >>> 541: public String getOutputFile() { >> >> This should be final (as should the setter). I see that other getter and setter methods in this class are also non-final, but we shouldn't propagate this mistake. >> >> Also, you don't need javadoc comments on the getters and setters, since it will copy them from the property (and add appropriate links). > > But the JobSettings class is final .. is it still necessary ? It's still a good idea to follow the pattern, so yes let's make the new methods final. We can file a cleanup bug for the existing ones (and since the class is final, we can do it without compatibility concerns). Also, I built the docs, and it is better to not add any javadoc comments on the setter and getter. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Fri Jun 25 21:20:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 21:20:03 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: <0OhFEFnNt5rSW2l_NfW2pmM0ZHuCIic_zGtWquq3eqw=.038b55ea-b49a-45ff-ad5f-4c96cb24c85a@github.com> Message-ID: On Fri, 25 Jun 2021 07:18:50 GMT, Johan Vos wrote: >> Consistency with other APIs would be the main reason. We could do something similar to what we do for `Image`, and treat a string without a protocol as a file (although not relative to the classpath as in the case of images), turning it into a `file:` URL internally where needed. >> >> @prrace what do you think? > > I agree with @kevinrushforth that if a String without protocol is passed, it should be treated as a file (absolute or relative to ?) > I'm also not sure that the URL should be exposed here. I understand it's needed in the lower-level print API but you already do the conversion in the `syncOutputFile` method. Hence, since only the file protocol is supported, it might be easier for API users to pass the location of the file instead of a URL. > In case later other URL protocols are supported, a property `outputURL` might be introduced? I like the flexibility and consistency of defining it as a URL, as long as we also interpret a url without a scheme as a file name. Borrowing language from the Image docs, perhaps something like this? The URL string can either be a URL with a "file:" protocol that can be resolved by @link java.net.URL} or a file path that can be resolved by {@link java.io.File}. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Fri Jun 25 21:20:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 21:20:03 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 23:00:42 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8223717: javafx printing: Support Specifying Print to File in the API Overall the new API and functionality looks good, and fills a void that was discussed [in this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-May/023292.html) a couple years ago. General comments: * If the user selects "print to file" from the native dialog, it will write to the `outputFile` property. This should be documented. * On the question of error handling. There are two types of errors we could consider. The first, which is the one we had been discussing, is where the URL is a valid file URL, but the program can't write to it, either because we are running with a security manager and the application doesn't have permission, or because we can't write to the output file (e.g., the path doesn't exist or is read-only). The second is a bad URL. If the URL is malformed or uses an unsupported protocol (anything other than `file:`), we could throw IllegalArgumentException, either when the invalid URL is set or when the print job is run. We might want to do this regardless of what we do about the first type of error. This could be done as simple as adding `@throws IllegalArgumentException if the url uses a protocol other than "file:"`. What do you think? For files that can't be written (the first type of error), we have three choices: 1. Define it loosely such that using a file that cannot be written to will either throw an exception when the print job is run or it will be ignored. 2. Define it to always throw an exception. We would need to add validation logic in PrintJob before calling the implementation methods, but we wouldn't necessarily be able to catch all errors (e.g., an IOEXception that only happens after you start writing to the file). This seems like overkill. 3. Define it to never throw an exception. The implementation would need to wrap the call to print in a try / catch, probably logging the result. I would probably lean towards 1 (which is what you are suggesting), but 3 could work as well. I left a couple inline comments on the API. modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 492: > 490: * a writable file it may be ignored, or a SecurityException may be thrown. > 491: * The default value is an empty string, which is interpreted as unset, > 492: * which means output is sent to the printer. Can you add a `* @defaultValue empty string` javadoc tag? ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Fri Jun 25 21:28:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 21:28:04 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 03:44:56 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8223717: javafx printing: Support Specifying Print to File in the API > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java line 839: > >> 837: security.checkPrintJobAccess(); >> 838: String file = settings.getOutputFile(); >> 839: if (!file.isEmpty()) { > > Don't we need to check for file!= null? The default value for the property is the empty string. But it does bring up a good point that we should either check and throw NPE if `setOutputFile` is called with `null` or we should map null to the empty string. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Fri Jun 25 21:28:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 21:28:03 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 23:00:42 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8223717: javafx printing: Support Specifying Print to File in the API I left a comment on the implementation and a couple on the test inline. tests/manual/printing/PrintToFileTest.java line 134: > 132: job.printPage(printNode); > 133: job.endJob(); > 134: if (f.exists()) { I have only tried this on Windows. This check is failing for me when I run the test, and yet the file is created correctly. If I add a short sleep, it works (so the printing is likely being done on a different thread). tests/manual/printing/PrintToFileTest.java line 137: > 135: System.out.println("created file"); > 136: passed = true; > 137: f.delete(); Maybe leave the file? I found it useful to verify its contents. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Fri Jun 25 23:20:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 23:20:05 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 14:18:41 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - wording > - Re-ordered methods The API looks reasonable. I left one question inline. The implementation will take some time to go through. I doubt that this will make JavaFX 17 (which I alluded to earlier). I'm especially curious about some of the patterns that I see, mostly surrounding the `FocusPropertyBase` implementation class. 1. `FocusPropertyBase` overrides `set` (which is unusual). The current implementation (of `FocusedProperty `) has some custom logic as well, but it didn't try to use the set method of a writable property. Also, you use a writable property and don't override `invalidated`. Can you say why you made the changes you made? 2. I'm curious about the approach for notifying listeners. It seems similar to what is currently done for `focusedProperty`, but there are differences. Also, I'm not sure that the two newly added properties need to handle notifications in the same way as focused. I can think of at least one potential issue. If focus shifts from one node to another in the same parent, you might end up notifying a parent's listeners even though its `focusWithin` is unchanged. 3. I think the way you are propagating `focusWithin` might not work if nodes are added or removed from the scene graph. 4. Normally a read-only property that needs to be settable by the implementation would use `ReadOnlyBooleanWrapper`. And then the public property method would call `getReadOnlyProperty` to return the read-only property to the user. The implementation would access the wrapper and you don't need to cast. You could consider having `FocusPropertyBase` extend `ReadOnlyBooleanWrapper`. One thing to consider would be to keep the existing (internal) class for `focused` and use a more standard `ReadOnlyBooleanWrapper` class for the two new ones. But maybe there are some implications I haven't thought of yet. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8242: > 8240: * Indicates whether this {@code Node} should visibly indicate focus. > 8241: * This flag is set when a node acquires input focus via keyboard navigation, > 8242: * and it is cleared when {@link #requestFocus()} is called. It's also cleared if the node loses focus, right? ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Sat Jun 26 00:04:04 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 26 Jun 2021 00:04:04 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 23:17:10 GMT, Kevin Rushforth wrote: > 1. `FocusPropertyBase` overrides `set` (which is unusual). The current implementation (of `FocusedProperty `) has some custom logic as well, but it didn't try to use the set method of a writable property. Also, you use a writable property and don't override `invalidated`. Can you say why you made the changes you made? Technically, it doesn't _override_ `set`. `FocusPropertyBase` extends `ReadOnlyBooleanPropertyBase`, and also defines a _new_ `set` method. As implemented, setting the value is completely decoupled from notifying listeners, which leads me directly to your next question... > 2. I'm curious about the approach for notifying listeners. It seems similar to what is currently done for `focusedProperty`, but there are differences. Also, I'm not sure that the two newly added properties need to handle notifications in the same way as focused. I can think of at least one potential issue. If focus shifts from one node to another in the same parent, you might end up notifying a parent's listeners even though its `focusWithin` is unchanged. `FocusPropertyBase.set` just records the new value, and the decision of whether to notify listeners is deferred until after all focus-related properties have been set on the current node and any of its parents. In the scenario you describe, the recorded value of `focusWithin` is changed twice, but ends up being the same value as before. In this case, `FocusPropertyBase.notifyListeners` will _not_ fire a change notification. There's a test for this scenario: `FocusTest.testFocusWithinListenerIsNotInvokedIfPropertyDidNotEffectivelyChange`. > 3. I think the way you are propagating `focusWithin` might not work if nodes are added or removed from the scene graph. Good point, I'll try to come up with some test cases to see if there are any issues. > 4. Normally a read-only property that needs to be settable by the implementation would use `ReadOnlyBooleanWrapper`. And then the public property method would call `getReadOnlyProperty` to return the read-only property to the user. The implementation would access the wrapper and you don't need to cast. You could consider having `FocusPropertyBase` extend `ReadOnlyBooleanWrapper`. That could certainly be an option, although it would increase the memory footprint of `Node`. I'm thinking instead to eagerly instantiate all three focus-related properties. In this case, the property field could be referenced directly, which would also remove the need for most casts. I think that having the same deferred-notification property implementation for all three focus-related properties is the best approach, since the implementation guarantees that listeners are only notified after all changes are committed. At least, I see no upside to _not_ guarantee this. Maybe the atomicity guarantee for `focused`, `focusVisible` and `focusWithin` should be included in the documentation. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From ebresie at gmail.com Sat Jun 26 01:42:26 2021 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 25 Jun 2021 20:42:26 -0500 Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: nBsJ4D47ABUST7qaUiKc-jyBdafd09pPjxhLJRtlb_Y=.5de94fc4-8ff0-4d76-bc13-bb6bc8c33a9d@github.com References: BHSZbabOLqmhMbrtpNrmn5a6WTQEskyrnvryTvQcAqc=.220f90ad-081d-4f53-a7f2-a8fef21a3697@github.com UUlBUIjOIGsfLUZeI_ll5m_BHftJecblHutZGrFieuk=.3f0ca77d-f0ca-44f9-a7e5-a6ba531ab3b6@github.com UUlBUIjOIGsfLUZeI_ll5m_BHftJecblHutZGrFieuk=.3f0ca77d-f0ca-44f9-a7e5-a6ba531ab3b6@github.com Message-ID: > security manager That?s not the same security manager being discussed as being deprecated for Java 17 and beyond is it? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On June 25, 2021 at 4:20:03 PM CDT, Kevin Rushforth wrote: > On Thu, 24 Jun 2021 23:00:42 GMT, Phil Race wrote: > > Overall the new API and functionality looks good, and fills a void that was discussed [in this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-May/023292.html) a couple years ago. > > General comments: > > The first, which is the one we had been discussing, is where the URL is a valid file URL, but the program can't write to it, either because we are running with a security manager and the application doesn't have permission, or because we can't write to the output file (e.g., the path doesn't exist or is read-only). > > PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Sat Jun 26 13:07:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 26 Jun 2021 13:07:21 GMT Subject: RFR: 8269424: Some SuppressWarnings annotations can be more localized Message-ID: This is a follow-on fix to [JDK-8264139](https://bugs.openjdk.java.net/browse/JDK-8264139), which added `@SuppressWarning` annotations to usages of deprecated security manager methods. @wangweij noticed that there was one pattern where the automated tool added the warning at a higher level than was needed. This fix moves the annotation down to me more localized in the two places that were affected. ------------- Commit messages: - 8269424: Some SuppressWarnings annotations can be more localized Changes: https://git.openjdk.java.net/jfx/pull/546/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=546&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269424 Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/546.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/546/head:pull/546 PR: https://git.openjdk.java.net/jfx/pull/546 From jvos at openjdk.java.net Sat Jun 26 15:46:12 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 26 Jun 2021 15:46:12 GMT Subject: RFR: 8246104: Some complex text doesn't render correctly on macOS Message-ID: <9AkX_puthOSBlHiBmpmmfkp1Q4QuyBx4kM-B_2hvyzo=.1430c2f1-8bcf-4129-b591-9213dfa16517@github.com> [Mac only] register system fonts. Fix for JDK-8246104 The list of available fonts returned by CTFontCollectionCreateFromAvailableFonts does not contain internal fonts (at least not by default, although this is not documented). By registering font(s) (files), those fonts become available in the returned list. The CT Glyph processing might assign internal fonts to a glyph, and since we lookup the requested font in this list, we fail if the list doesn't contain the font. This PR registers all fonts in the system library so that they become available. This is not creating additional Java objects or overhead, as it almost directly invokes `CTFontManagerRegisterFontsForURL` via `CTFontFile.registerFont(String fontfile)` ------------- Commit messages: - Register system fonts so that they are retrieved via CTFontCollectionCreateFromAvailableFonts. Changes: https://git.openjdk.java.net/jfx/pull/547/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=547&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246104 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/547.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/547/head:pull/547 PR: https://git.openjdk.java.net/jfx/pull/547 From aghaisas at openjdk.java.net Sun Jun 27 05:09:08 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Sun, 27 Jun 2021 05:09:08 GMT Subject: RFR: 8269424: Some SuppressWarnings annotations can be more localized In-Reply-To: References: Message-ID: On Sat, 26 Jun 2021 13:01:15 GMT, Kevin Rushforth wrote: > This is a follow-on fix to [JDK-8264139](https://bugs.openjdk.java.net/browse/JDK-8264139), which added `@SuppressWarning` annotations to usages of deprecated security manager methods. @wangweij noticed that there was one pattern where the automated tool added the warning at a higher level than was needed. This fix moves the annotation down to be more localized in the two places that were affected. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/546 From arapte at openjdk.java.net Sun Jun 27 09:50:39 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sun, 27 Jun 2021 09:50:39 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v10] In-Reply-To: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> References: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> Message-ID: <3ITCv1sY3qlMfNFqnqEKgw4gFwZ62JTrkEWFVySN6w4=.8973c7b0-1f2d-4606-be7a-739e28ddf7ff@github.com> On Fri, 25 Jun 2021 13:08:36 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From mhanl at openjdk.java.net Sun Jun 27 10:44:28 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sun, 27 Jun 2021 10:44:28 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v10] In-Reply-To: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> References: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> Message-ID: On Fri, 25 Jun 2021 13:08:36 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 109: > 107: > 108: @Override public int getRemovedSize() { > 109: checkState(); Is this needed here? Just wondering because it was not there before. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From pbansal at openjdk.java.net Sun Jun 27 11:38:22 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 27 Jun 2021 11:38:22 GMT Subject: RFR: 8269424: Some SuppressWarnings annotations can be more localized In-Reply-To: References: Message-ID: On Sat, 26 Jun 2021 13:01:15 GMT, Kevin Rushforth wrote: > This is a follow-on fix to [JDK-8264139](https://bugs.openjdk.java.net/browse/JDK-8264139), which added `@SuppressWarning` annotations to usages of deprecated security manager methods. @wangweij noticed that there was one pattern where the automated tool added the warning at a higher level than was needed. This fix moves the annotation down to be more localized in the two places that were affected. Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/546 From mstrauss at openjdk.java.net Sun Jun 27 12:12:19 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 27 Jun 2021 12:12:19 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v10] In-Reply-To: References: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> Message-ID: On Sun, 27 Jun 2021 10:40:39 GMT, Marius Hanl wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes per review > > modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 109: > >> 107: >> 108: @Override public int getRemovedSize() { >> 109: checkState(); > > Is this needed here? Just wondering because it was not there before. Without the check, it would be possible to inspect the size without calling `next()` first. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From fastegal at openjdk.java.net Sun Jun 27 12:36:10 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 27 Jun 2021 12:36:10 GMT Subject: RFR: 8194924: Checking for selection size before update In-Reply-To: <1LUKuxbU1WR9kHFTKIyDkqi-nV4aGvh30wCcoj2ReLI=.a62fb7f0-ea6e-4660-b3b2-5ce99948496d@github.com> References: <1LUKuxbU1WR9kHFTKIyDkqi-nV4aGvh30wCcoj2ReLI=.a62fb7f0-ea6e-4660-b3b2-5ce99948496d@github.com> Message-ID: <1TeSzmyEao8FxGVHuC9CtIVXXv6FK0Rrzn2As_Z3Fts=.382d0739-3909-4719-acf0-e063bfd522b7@github.com> On Thu, 24 Jun 2021 11:29:23 GMT, Alexander Shaklein wrote: > It is possible situation when `clearSelection()` is invoked during `onChange()` notify. In such case `selectedCellsSeq` is clearing and possible `IndexOutOfBoundsException` on `GenericAddRemoveChange` creation. > So we should check it to create correct `GenericAddRemoveChange`. looks like a usage error to me, for multiple reasons: in a listener to property changes of one property, we must not - access the state of another property (except we can guarantee the other to be completely orthogonal to the sender) - change the state of the sender - change the state of related properties The example DavisSelectionTest in the report seems to do all of these ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/542 From github.com+26318329+cheesterx3 at openjdk.java.net Sun Jun 27 12:36:10 2021 From: github.com+26318329+cheesterx3 at openjdk.java.net (Alexander Shaklein) Date: Sun, 27 Jun 2021 12:36:10 GMT Subject: RFR: 8194924: Checking for selection size before update Message-ID: <1LUKuxbU1WR9kHFTKIyDkqi-nV4aGvh30wCcoj2ReLI=.a62fb7f0-ea6e-4660-b3b2-5ce99948496d@github.com> It is possible situation when `clearSelection()` is invoked during `onChange()` notify. In such case `selectedCellsSeq` is clearing and possible `IndexOutOfBoundsException` on `GenericAddRemoveChange` creation. So we should check it to create correct `GenericAddRemoveChange`. ------------- Commit messages: - 8194924: Checking for selection size before update Changes: https://git.openjdk.java.net/jfx/pull/542/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=542&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8194924 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/542.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/542/head:pull/542 PR: https://git.openjdk.java.net/jfx/pull/542 From mhanl at openjdk.java.net Sun Jun 27 12:48:04 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sun, 27 Jun 2021 12:48:04 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v10] In-Reply-To: References: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> Message-ID: <6aAUQICDhDCUHlYeY1KDwlrjkxmA9raQLi8ym6ZgNtI=.4f610738-35f8-436a-acfd-0d0a2718bcf6@github.com> On Sun, 27 Jun 2021 12:09:24 GMT, Michael Strau? wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 109: >> >>> 107: >>> 108: @Override public int getRemovedSize() { >>> 109: checkState(); >> >> Is this needed here? Just wondering because it was not there before. > > Without the check, it would be possible to inspect the size without calling `next()` first. Right. But I want to understand why this was not there before. Is this needed, because if you didn't called `next()`, there is no change yet to retrieve the removed size? ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Sun Jun 27 13:19:09 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 27 Jun 2021 13:19:09 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v10] In-Reply-To: <6aAUQICDhDCUHlYeY1KDwlrjkxmA9raQLi8ym6ZgNtI=.4f610738-35f8-436a-acfd-0d0a2718bcf6@github.com> References: <-qCrT0HmrD-DHup5Tww3vh10dUssMPuMuZ0Z4LhL57I=.645dec48-2d89-40aa-922b-330ec3fd36c1@github.com> <6aAUQICDhDCUHlYeY1KDwlrjkxmA9raQLi8ym6ZgNtI=.4f610738-35f8-436a-acfd-0d0a2718bcf6@github.com> Message-ID: On Sun, 27 Jun 2021 12:45:35 GMT, Marius Hanl wrote: >> Without the check, it would be possible to inspect the size without calling `next()` first. > > Right. But I want to understand why this was not there before. > > Is this needed, because if you didn't called `next()`, there is no change yet to retrieve the removed size? It is needed according to the documentation of `ListChangeListener.Change`: _Important: It's necessary to call next() method before calling any other method of Change. The same applies after calling reset(). The only methods that works at any time is getList()._ Also, it intuitively makes sense: a `Change` can consist of any number of sub-changes, so you need to select a sub-change first by calling `next()` before any of the other methods can be meaningfully called. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From pbansal at openjdk.java.net Sun Jun 27 13:22:04 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 27 Jun 2021 13:22:04 GMT Subject: RFR: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later In-Reply-To: References: Message-ID: On Tue, 22 Jun 2021 20:42:48 GMT, Kevin Rushforth wrote: > This is a fix for the assertion error message that is printed to the console on macOS 10.15 or later when an application calls `Platform.exit` while a `Stage` is showing. > > The root cause is a latent bug in the JavaFX glass code that was revealed by an apparent change of behavior in macOS. A few of the object deallocation methods, which are called by the Objective C auto-release mechanism, use the standard `GET_MAIN_JENV` macro to get the JNI environment. The macro will print an assertion warning if Java has been detached. I instrumented the code and can see that `GlassViewDelegate::dealloc` is now called after the `GlassApplication` main loop has detached Java. Since we don't control when the dealloc method is called, it is not correct to do the assertion check in those cases. Some of the dealloc methods already skip this assertion check by grabbing the jEnv pointer directly, so we need to fix the others. I added a new variant of the macro called `GET_MAIN_JENV_NOWARN` with a comment indicating that is suitable for use by the dealloc methods. > > In addition to verifying that the test program attached to JBS now exits cleanly with no assertion failure message, I added an automated system test that fails on macOS before the fix and passes after the fix. On other platforms it passes already. The fix looks fine. The attached test case fails without the fix and passes after the fix. I also ran the full test on Mac 10.15 and I don't see issue. tests/system/src/test/java/test/launchertest/Constants.java line 70: > 68: static final int ERROR_ASSERTION_FAILURE = 28; > 69: > 70: static final int ERROR_TIMEOUT = 28; Should not this be assigned error code 29 instead of 28? ------------- PR: https://git.openjdk.java.net/jfx/pull/540 From arapte at openjdk.java.net Mon Jun 28 09:55:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 28 Jun 2021 09:55:08 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 07:11:54 GMT, Marius Hanl wrote: >> ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ >> EDIT: Thank you, Kevin. :) >> >> This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: >> - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. >> -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) >> - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) >> - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) >> >> **-> With this, I can run all normal tests with IntelliJ** >> >> ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): >> - IntelliJ is not detecting javafx.graphic inside the shims >> - All javafx.* dependencies are not found for the system tests >> >> **-> If someone has a solution, feel free to comment :)** > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Reverted whitespace made by IntelliJ Approving, I re-verified the change: Loading project in IntelliJ does not cause any other changes in idea files. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/506 From mstrauss at openjdk.java.net Mon Jun 28 09:59:07 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 28 Jun 2021 09:59:07 GMT Subject: Integrated: 8196065: ListChangeListener getRemoved() returns items that were not removed. In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 03:19:03 GMT, Michael Strau? wrote: > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. This pull request has now been integrated. Changeset: c4cc9988 Author: Michael Strau? Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/c4cc99882928e423003d54cae0a6b0de2ec05007 Stats: 321 lines in 8 files changed: 291 ins; 6 del; 24 mod 8196065: ListChangeListener getRemoved() returns items that were not removed. Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From kcr at openjdk.java.net Mon Jun 28 12:27:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Jun 2021 12:27:34 GMT Subject: RFR: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later [v2] In-Reply-To: References: Message-ID: > This is a fix for the assertion error message that is printed to the console on macOS 10.15 or later when an application calls `Platform.exit` while a `Stage` is showing. > > The root cause is a latent bug in the JavaFX glass code that was revealed by an apparent change of behavior in macOS. A few of the object deallocation methods, which are called by the Objective C auto-release mechanism, use the standard `GET_MAIN_JENV` macro to get the JNI environment. The macro will print an assertion warning if Java has been detached. I instrumented the code and can see that `GlassViewDelegate::dealloc` is now called after the `GlassApplication` main loop has detached Java. Since we don't control when the dealloc method is called, it is not correct to do the assertion check in those cases. Some of the dealloc methods already skip this assertion check by grabbing the jEnv pointer directly, so we need to fix the others. I added a new variant of the macro called `GET_MAIN_JENV_NOWARN` with a comment indicating that is suitable for use by the dealloc methods. > > In addition to verifying that the test program attached to JBS now exits cleanly with no assertion failure message, I added an automated system test that fails on macOS before the fix and passes after the fix. On other platforms it passes already. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fix value of ERROR_TIMEOUT constant per code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/540/files - new: https://git.openjdk.java.net/jfx/pull/540/files/5abf1b66..68abfaf5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=540&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=540&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/540.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/540/head:pull/540 PR: https://git.openjdk.java.net/jfx/pull/540 From kcr at openjdk.java.net Mon Jun 28 12:41:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Jun 2021 12:41:05 GMT Subject: RFR: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later [v2] In-Reply-To: References: Message-ID: On Sun, 27 Jun 2021 13:16:40 GMT, Pankaj Bansal wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix value of ERROR_TIMEOUT constant per code review > > tests/system/src/test/java/test/launchertest/Constants.java line 70: > >> 68: static final int ERROR_ASSERTION_FAILURE = 28; >> 69: >> 70: static final int ERROR_TIMEOUT = 28; > > Should not this be assigned error code 29 instead of 28? Yes, thanks for catching this. I fixed it. ------------- PR: https://git.openjdk.java.net/jfx/pull/540 From pbansal at openjdk.java.net Mon Jun 28 12:45:06 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 28 Jun 2021 12:45:06 GMT Subject: RFR: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later [v2] In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 12:27:34 GMT, Kevin Rushforth wrote: >> This is a fix for the assertion error message that is printed to the console on macOS 10.15 or later when an application calls `Platform.exit` while a `Stage` is showing. >> >> The root cause is a latent bug in the JavaFX glass code that was revealed by an apparent change of behavior in macOS. A few of the object deallocation methods, which are called by the Objective C auto-release mechanism, use the standard `GET_MAIN_JENV` macro to get the JNI environment. The macro will print an assertion warning if Java has been detached. I instrumented the code and can see that `GlassViewDelegate::dealloc` is now called after the `GlassApplication` main loop has detached Java. Since we don't control when the dealloc method is called, it is not correct to do the assertion check in those cases. Some of the dealloc methods already skip this assertion check by grabbing the jEnv pointer directly, so we need to fix the others. I added a new variant of the macro called `GET_MAIN_JENV_NOWARN` with a comment indicating that is suitable for use by the dealloc methods. >> >> In addition to verifying that the test program attached to JBS now exits cleanly with no assertion failure message, I added an automated system test that fails on macOS before the fix and passes after the fix. On other platforms it passes already. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix value of ERROR_TIMEOUT constant per code review Looks good ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/540 From nlisker at openjdk.java.net Mon Jun 28 13:14:27 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 28 Jun 2021 13:14:27 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types Message-ID: Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. I noticed a drop of ~1 fps in the stress test of 5000 meshes. I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. ------------- Commit messages: - Small corrections to class members docs - Removed whitespace - Reordered setLight arguments in NGShape3D - Updated class doc - Initial commit of the opengl pipeline - Updated tests - Initial java and d3d implementation Changes: https://git.openjdk.java.net/jfx/pull/548/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234921 Stats: 533 lines in 29 files changed: 472 ins; 11 del; 50 mod Patch: https://git.openjdk.java.net/jfx/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/548/head:pull/548 PR: https://git.openjdk.java.net/jfx/pull/548 From mhanl at openjdk.java.net Mon Jun 28 13:47:06 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 28 Jun 2021 13:47:06 GMT Subject: RFR: 8240506: TextFieldSkin/Behavior: misbehavior on switching skin In-Reply-To: References: Message-ID: <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com> On Thu, 17 Jun 2021 12:41:56 GMT, Jeanette Winzenburg wrote: > The issue is about memory leaks and side-effects (like NPEs) when switching skins. > > Details (copied from issue for convenience): > > memory leak in TextInputControlBehavior: > - listener accidentally added twice (removed once) > - keyPad mappings not properly installed/disposed > > memory leak TextFieldBehavior: > - listeners to scene/focusOwner property not removed, > > memory leak in TextInputControlSkin: > - event handlers related to inputMethods not removed > > issues in TextFieldSkin: > - memory leak due to behavior leaking > - memory leaks due to manually added change/invalidation listeners that are not removed > - memory leaks due to not removing children with strong references to skin > - side-effects (f.i. NPEs) due to listeners/bindings that are still active after dispose > > Fix was to properly install/remove those listeners/handlers. Added tests that failed/passed before/after the fix, respectively, also added tests passing before that must pass after the fix. Just a formal review, I left some comments inline modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java line 75: > 73: } > 74: > 75: focusListener = (observable, oldValue, newValue) -> { Shouldn't this focusListener also be wrapped in a weakListener? Also this lambda expression can be a one-liner (no braces needed) modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 389: > 387: /** {@inheritDoc} */ > 388: @Override public void dispose() { > 389: if (getSkinnable() == null) return; Just curious: Can the skinnable be null here? And is it fine then to never call **super.dispose()** ? modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 390: > 388: @Override public void dispose() { > 389: if (getSkinnable() == null) return; > 390: getChildren().removeAll(textGroup, handleGroup); Also curious: Most of the skins don't remove their children in **dispose()**. Are they all wrong, or is this a special case here? modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/behavior/BehaviorCleanupTest.java line 162: > 160: secondStage.hide(); > 161: } > 162: minor: this empty line can be removed ------------- Changes requested by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/534 From mhanl at openjdk.java.net Mon Jun 28 14:04:07 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 28 Jun 2021 14:04:07 GMT Subject: RFR: 8268642: Expand the javafx.beans.property.Property documentation [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 01:53:53 GMT, Michael Strau? wrote: >> * Expand the `Property.bind` and `Property.bindBidirectional` documentation >> * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable") > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes as per review I like this change, it makes the binding framework doc much more clear. But I agree with Nir, I think 'the' reads better then 'a' on the occurrences. ------------- PR: https://git.openjdk.java.net/jfx/pull/533 From mhanl at openjdk.java.net Mon Jun 28 14:44:15 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 28 Jun 2021 14:44:15 GMT Subject: RFR: 8269244: [IDE] Dependency verification of *-sources.jar fails when doing gradle sync Message-ID: This PR fixes the issue identified and discussed in PR https://github.com/openjdk/jfx/pull/506 which will make the gradle sync in IntelliJ fail because of the failing dependency verification for source files. Gradle provides a way to skip the verification of source files, documented here: https://docs.gradle.org/current/userguide/dependency_verification.html#sec:skipping-javadocs Also the **README.txt** file is adjusted to include the instructions neccessary when updating the **verification-metadata.xml** file. ------------- Commit messages: - Fixed dependency verification of *-sources.jar fails when doing gradle sync Changes: https://git.openjdk.java.net/jfx/pull/549/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=549&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269244 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/549.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/549/head:pull/549 PR: https://git.openjdk.java.net/jfx/pull/549 From fastegal at openjdk.java.net Mon Jun 28 15:51:05 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 28 Jun 2021 15:51:05 GMT Subject: RFR: 8240506: TextFieldSkin/Behavior: misbehavior on switching skin In-Reply-To: <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com> References: <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com> Message-ID: On Mon, 28 Jun 2021 12:55:47 GMT, Marius Hanl wrote: >> The issue is about memory leaks and side-effects (like NPEs) when switching skins. >> >> Details (copied from issue for convenience): >> >> memory leak in TextInputControlBehavior: >> - listener accidentally added twice (removed once) >> - keyPad mappings not properly installed/disposed >> >> memory leak TextFieldBehavior: >> - listeners to scene/focusOwner property not removed, >> >> memory leak in TextInputControlSkin: >> - event handlers related to inputMethods not removed >> >> issues in TextFieldSkin: >> - memory leak due to behavior leaking >> - memory leaks due to manually added change/invalidation listeners that are not removed >> - memory leaks due to not removing children with strong references to skin >> - side-effects (f.i. NPEs) due to listeners/bindings that are still active after dispose >> >> Fix was to properly install/remove those listeners/handlers. Added tests that failed/passed before/after the fix, respectively, also added tests passing before that must pass after the fix. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java line 75: > >> 73: } >> 74: >> 75: focusListener = (observable, oldValue, newValue) -> { > > Shouldn't this focusListener also be wrapped in a weakListener? Also this lambda expression can be a one-liner (no braces needed) we are a bit inconsistent in wrapping (or not) listeners into their weak counterparts - behaviors tend to not :) That's okay - and less crowded by additional code - as long as they are removed properly, IMO. But just seeing: good question, as the focusOwner listener is wrapped, need to consult my notes. Thanks for the heads up! As to the single vs. multiple lines: ersonally, I tend to not change more than absolutely needed - it had the brackets before the fix so I kept them. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 389: > >> 387: /** {@inheritDoc} */ >> 388: @Override public void dispose() { >> 389: if (getSkinnable() == null) return; > > Just curious: Can the skinnable be null here? And is it fine then to never call **super.dispose()** ? dispose has no precondition - it can be called multiple times (explicitly specified in its javadoc), so has to guard itself against having cleaned already. And super is called the first time. ------------- PR: https://git.openjdk.java.net/jfx/pull/534 From fastegal at openjdk.java.net Mon Jun 28 15:57:05 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 28 Jun 2021 15:57:05 GMT Subject: RFR: 8240506: TextFieldSkin/Behavior: misbehavior on switching skin In-Reply-To: <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com> References: <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com> Message-ID: On Mon, 28 Jun 2021 13:18:38 GMT, Marius Hanl wrote: >> The issue is about memory leaks and side-effects (like NPEs) when switching skins. >> >> Details (copied from issue for convenience): >> >> memory leak in TextInputControlBehavior: >> - listener accidentally added twice (removed once) >> - keyPad mappings not properly installed/disposed >> >> memory leak TextFieldBehavior: >> - listeners to scene/focusOwner property not removed, >> >> memory leak in TextInputControlSkin: >> - event handlers related to inputMethods not removed >> >> issues in TextFieldSkin: >> - memory leak due to behavior leaking >> - memory leaks due to manually added change/invalidation listeners that are not removed >> - memory leaks due to not removing children with strong references to skin >> - side-effects (f.i. NPEs) due to listeners/bindings that are still active after dispose >> >> Fix was to properly install/remove those listeners/handlers. Added tests that failed/passed before/after the fix, respectively, also added tests passing before that must pass after the fix. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 390: > >> 388: @Override public void dispose() { >> 389: if (getSkinnable() == null) return; >> 390: getChildren().removeAll(textGroup, handleGroup); > > Also curious: Most of the skins don't remove their children in **dispose()**. Are they all wrong, or is this a special case here? they are all wrong ;) When starting with the cleanup, we (me at least ;) weren't yet entirely certain - but not removing them let them hang in the hierarchy, reachable by strong references from their parent. Which in itself isn't pretty (and might lead to unwanted side-effects) - but if they in turn have any references to the skin (even not so obvious - for me again - like being a not static nested class of the skin ;) the skin is strongly reachable as well, making it leaky. > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/behavior/BehaviorCleanupTest.java line 162: > >> 160: secondStage.hide(); >> 161: } >> 162: > > minor: this empty line can be removed yeah, can do .. but do we have conventions about vertical whitespace? Tend to keep what suits my eyes :) ------------- PR: https://git.openjdk.java.net/jfx/pull/534 From philip.race at oracle.com Mon Jun 28 19:47:04 2021 From: philip.race at oracle.com (Philip Race) Date: Mon, 28 Jun 2021 12:47:04 -0700 Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: Yes .. we still need to deal with it until it is actually removed. Its going to be here for all the life of JDK 17 LTS which I expect FX will want to support for all that time. -phil. On 6/25/21 6:42 PM, Eric Bresie wrote: >> security manager > That?s not the same security manager being discussed as being deprecated for Java 17 and beyond is it? > > Eric Bresie > Ebresie at gmail.com (mailto:Ebresie at gmail.com) > >> On June 25, 2021 at 4:20:03 PM CDT, Kevin Rushforth wrote: >> On Thu, 24 Jun 2021 23:00:42 GMT, Phil Race wrote: >> >> Overall the new API and functionality looks good, and fills a void that was discussed [in this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-May/023292.html) a couple years ago. >> >> General comments: >> >> The first, which is the one we had been discussing, is where the URL is a valid file URL, but the program can't write to it, either because we are running with a security manager and the application doesn't have permission, or because we can't write to the output file (e.g., the path doesn't exist or is read-only). >> >> PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Mon Jun 28 19:47:39 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 28 Jun 2021 19:47:39 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v4] In-Reply-To: References: Message-ID: > This enhancement adds the String property outputFileProperty() to the JobSettings class. > The value should be a string that references a local file encoded as a URL. > If this is non-null and set to a location that the user has permission to write to, > then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. > The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. > > A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8223717: javafx printing: Support Specifying Print to File in the API ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/543/files - new: https://git.openjdk.java.net/jfx/pull/543/files/8050d5f9..34221a95 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=02-03 Stats: 85 lines in 3 files changed: 21 ins; 38 del; 26 mod Patch: https://git.openjdk.java.net/jfx/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/543/head:pull/543 PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Mon Jun 28 19:47:44 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 28 Jun 2021 19:47:44 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 04:08:30 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8223717: javafx printing: Support Specifying Print to File in the API > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java line 352: > >> 350: try { >> 351: settings.setOutputFile(dest.getURI().toURL().toString()); >> 352: } catch (MalformedURLException e) { > > I guess in 2D RasterPrinterJob, if there is any exception, we try to form a default file "out.prn" [https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L1137] > and try to print there. Can't we do it here too? I am going to just change to support file so this becomes a non-issue > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java line 356: > >> 354: } else { >> 355: settings.setOutputFile(""); >> 356: } > > Actually in 2D , it seems if dest is null, we redirect printing to actual printer instead of file. Not sure if that is what we need to do here too!! > [https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L1148] that is what we are doing .. > modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 485: > >> 483: *

    >> 484: * If the application does not have permission to write to the specified >> 485: * file, a {@code SecurityException} may be thrown when printing. > > As I see in 2D atleast in Win32PrintService, if there is a SecurityException for creating a Destination object from a URI, it retries again by creating a new URL with default file "file:out.prn" > Is it not needed here? > [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/sun/print/Win32PrintService.java#L1181] No. We are doing our own checking if a SM is running and disallow it. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Mon Jun 28 19:47:46 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 28 Jun 2021 19:47:46 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 21:20:53 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java line 839: >> >>> 837: security.checkPrintJobAccess(); >>> 838: String file = settings.getOutputFile(); >>> 839: if (!file.isEmpty()) { >> >> Don't we need to check for file!= null? > > The default value for the property is the empty string. But it does bring up a good point that we should either check and throw NPE if `setOutputFile` is called with `null` or we should map null to the empty string. we do remap null to the empty string .. the code in JobSettings.outputFileProperty() does it. So this will never be null ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Mon Jun 28 19:47:46 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 28 Jun 2021 19:47:46 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v4] In-Reply-To: References: <0OhFEFnNt5rSW2l_NfW2pmM0ZHuCIic_zGtWquq3eqw=.038b55ea-b49a-45ff-ad5f-4c96cb24c85a@github.com> Message-ID: On Fri, 25 Jun 2021 21:08:31 GMT, Kevin Rushforth wrote: >> I agree with @kevinrushforth that if a String without protocol is passed, it should be treated as a file (absolute or relative to ?) >> I'm also not sure that the URL should be exposed here. I understand it's needed in the lower-level print API but you already do the conversion in the `syncOutputFile` method. Hence, since only the file protocol is supported, it might be easier for API users to pass the location of the file instead of a URL. >> In case later other URL protocols are supported, a property `outputURL` might be introduced? > > I like the flexibility and consistency of defining it as a URL, as long as we also interpret a url without a scheme as a file name. Borrowing language from the Image docs, perhaps something like this? > > > The URL string can either be a URL with a "file:" protocol that can be resolved > by @link java.net.URL} or a file path that can be resolved by {@link java.io.File}. I am changing it to be just a file path. We can extend it later if ever needed. It does simplify the code and the potential for errors. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Mon Jun 28 19:47:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 28 Jun 2021 19:47:47 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v4] In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 22:53:33 GMT, Phil Race wrote: >> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 490: >> >>> 488: * setting will be ignored. >>> 489: * If the URL specifies a non-existent path, or does not specify >>> 490: * a writable file it may be ignored, or a SecurityException may be thrown. >> >> I want to look at what we do for other properties like this. I'm not sure how feasible it is to throw an exception back to the application. And I wouldn't want to single out a security exception (what about a read-only file system?). I think that whatever the reason, if the file can't be written to, we should treat it consistently. Probably by ignoring the request. I presume that's what will happen if the print driver doesn't support print-to-file? > > Not easy to specify exactly. We are handing it off to 2D > We aren't doing any up-front verification here, but I don't want to copy 2D behaviour into the docs, even if I could be sure about that .. I may just want to be more waffly about what happens. > Could be printed to the printer, could be a failed job, could be an exception of some kind if some nice piece of Java code recognises a problem up-front So the SE will occur only if there is a SM and the code in J2DPrinterJob.checkPermission() rejects it. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Mon Jun 28 19:47:53 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 28 Jun 2021 19:47:53 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 21:13:31 GMT, Kevin Rushforth wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8223717: javafx printing: Support Specifying Print to File in the API > > modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 492: > >> 490: * a writable file it may be ignored, or a SecurityException may be thrown. >> 491: * The default value is an empty string, which is interpreted as unset, >> 492: * which means output is sent to the printer. > > Can you add a `* @defaultValue empty string` javadoc tag? will do .. > tests/manual/printing/PrintToFileTest.java line 134: > >> 132: job.printPage(printNode); >> 133: job.endJob(); >> 134: if (f.exists()) { > > I have only tried this on Windows. This check is failing for me when I run the test, and yet the file is created correctly. If I add a short sleep, it works (so the printing is likely being done on a different thread). interesting. I guess I will have to add a sleep as you did. > tests/manual/printing/PrintToFileTest.java line 137: > >> 135: System.out.println("created file"); >> 136: passed = true; >> 137: f.delete(); > > Maybe leave the file? I found it useful to verify its contents. ok ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Mon Jun 28 19:47:54 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 28 Jun 2021 19:47:54 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v2] In-Reply-To: References: <9XHiBWyQ4u6hoTf88a6jvNoAZBMymNgfw3kOT2a0XNE=.a3bfa36b-740d-46c8-a1a8-6b877a1310d4@github.com> Message-ID: On Fri, 25 Jun 2021 21:10:16 GMT, Kevin Rushforth wrote: >> But the JobSettings class is final .. is it still necessary ? > > It's still a good idea to follow the pattern, so yes let's make the new methods final. We can file a cleanup bug for the existing ones (and since the class is final, we can do it without compatibility concerns). > > Also, I built the docs, and it is better to not add any javadoc comments on the setter and getter. I'll file a clean up bug ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Mon Jun 28 21:58:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Jun 2021 21:58:01 GMT Subject: RFR: 8269244: [IDE] Dependency verification of *-sources.jar fails when doing gradle sync In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 14:38:32 GMT, Marius Hanl wrote: > This PR fixes the issue identified and discussed in PR https://github.com/openjdk/jfx/pull/506 which will make the gradle sync in IntelliJ fail because of the failing dependency verification for source files. > > Gradle provides a way to skip the verification of source files, documented here: > https://docs.gradle.org/current/userguide/dependency_verification.html#sec:skipping-javadocs > > Also the **README.txt** file is adjusted to include the instructions neccessary when updating the **verification-metadata.xml** file. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/549 From kcr at openjdk.java.net Mon Jun 28 22:06:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Jun 2021 22:06:05 GMT Subject: RFR: 8194924: Checking for selection size before update In-Reply-To: <1LUKuxbU1WR9kHFTKIyDkqi-nV4aGvh30wCcoj2ReLI=.a62fb7f0-ea6e-4660-b3b2-5ce99948496d@github.com> References: <1LUKuxbU1WR9kHFTKIyDkqi-nV4aGvh30wCcoj2ReLI=.a62fb7f0-ea6e-4660-b3b2-5ce99948496d@github.com> Message-ID: On Thu, 24 Jun 2021 11:29:23 GMT, Alexander Shaklein wrote: > It is possible situation when `clearSelection()` is invoked during `onChange()` notify. In such case `selectedCellsSeq` is clearing and possible `IndexOutOfBoundsException` on `GenericAddRemoveChange` creation. > So we should check it to create correct `GenericAddRemoveChange`. As mentioned above, and also in the JBS issue, it is likely that we will close the bug as "not an issue", in which case this PR should be closed (withdrawn). ------------- PR: https://git.openjdk.java.net/jfx/pull/542 From tsayao at openjdk.java.net Mon Jun 28 23:20:20 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 28 Jun 2021 23:20:20 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v26] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Small compilation fix for ubuntu 16.04 - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master Merge master - Fix bug in content oriented child windows - Small compilation fix for ubuntu 16.04 - Replace the window size & positining code Default to 320x200 if no size is assigned Hopefully fix all "extra resize" problems due to frame extents. Small change to reuse get_net_frame_extents_atom() Fix more tests (restore 1 behaviour) More test fixes Partial progress Adjust positioning (not 100% yet) It's looking good. Except for fixed initial extents, but it seems a reasonable fix due to nature o frame extents. It's probably good now One more small issue - Merge pull request #17 from openjdk/master Pull from origin - Merge pull request #16 from openjdk/master Update - Merge pull request #15 from openjdk/master Update from jfx - Merge pull request #14 from openjdk/master Merge master - ... and 10 more: https://git.openjdk.java.net/jfx/compare/78179be1...f4a13314 ------------- Changes: https://git.openjdk.java.net/jfx/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=25 Stats: 615 lines in 7 files changed: 150 ins; 311 del; 154 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Mon Jun 28 23:50:31 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 28 Jun 2021 23:50:31 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix build gtk_widget_set_sensitive has no effect ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/f4a13314..9ff5a7b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=26 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=25-26 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From nlisker at openjdk.java.net Tue Jun 29 02:45:01 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 29 Jun 2021 02:45:01 GMT Subject: RFR: 8269244: [IDE] Dependency verification of *-sources.jar fails when doing gradle sync In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 14:38:32 GMT, Marius Hanl wrote: > This PR fixes the issue identified and discussed in PR https://github.com/openjdk/jfx/pull/506 which will make the gradle sync in IntelliJ fail because of the failing dependency verification for source files. > > Gradle provides a way to skip the verification of source files, documented here: > https://docs.gradle.org/current/userguide/dependency_verification.html#sec:skipping-javadocs > > Also the **README.txt** file is adjusted to include the instructions neccessary when updating the **verification-metadata.xml** file. I tested this on Eclipse and it resolves the error of not finding the JUnit source jar file during dependency verification. Eclipse Buildship is happy now. ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/549 From almatvee at openjdk.java.net Tue Jun 29 03:12:16 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 29 Jun 2021 03:12:16 GMT Subject: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc Message-ID: Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of cycle is reached regardless if it is repeating or not. ------------- Commit messages: - 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc Changes: https://git.openjdk.java.net/jfx/pull/552/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=552&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268683 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/552.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/552/head:pull/552 PR: https://git.openjdk.java.net/jfx/pull/552 From nlisker at openjdk.java.net Tue Jun 29 04:01:04 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 29 Jun 2021 04:01:04 GMT Subject: RFR: 8269259: Remove obsolete apps, tests, and scripts In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 14:59:00 GMT, Kevin Rushforth wrote: > This PR deletes the following applications, tests, and scripts that are either obsolete > or unmaintained: > > apps/performance/* > > apps/tests/HelloTest > > apps/toys/FXSlideShow > apps/toys/Industrial > apps/toys/Shape3DToy > apps/toys/StretchyGrid > apps/toys/TouchSuite > > tests/functional/* > tests/performance/VMPerformance > > tools/* > > See the JBS issue and [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030894.html) on the openjfx-dev mailing list for more info. > > There are two commits for ease of review. The first one is generated by doing a "git rm -r" on each of the above listed directories. The second is to remove any remaining references to the removed directories. Looks fine. I don't know which of these are used frequently and which aren't, but I tested that there are no errors as a result of this patch. Under tests/system/src there are several projects called "testappN". Are they named cryptically on purpose? ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/545 From github.com+26318329+cheesterx3 at openjdk.java.net Tue Jun 29 04:45:00 2021 From: github.com+26318329+cheesterx3 at openjdk.java.net (Alexander Shaklein) Date: Tue, 29 Jun 2021 04:45:00 GMT Subject: Withdrawn: 8194924: Checking for selection size before update In-Reply-To: <1LUKuxbU1WR9kHFTKIyDkqi-nV4aGvh30wCcoj2ReLI=.a62fb7f0-ea6e-4660-b3b2-5ce99948496d@github.com> References: <1LUKuxbU1WR9kHFTKIyDkqi-nV4aGvh30wCcoj2ReLI=.a62fb7f0-ea6e-4660-b3b2-5ce99948496d@github.com> Message-ID: <3qKCaIhDovYgHRMrqvfv0HfsmhCPod-q4I50qfPMJcA=.1ab821aa-a688-4f91-9c7f-8ebd25de5b33@github.com> On Thu, 24 Jun 2021 11:29:23 GMT, Alexander Shaklein wrote: > It is possible situation when `clearSelection()` is invoked during `onChange()` notify. In such case `selectedCellsSeq` is clearing and possible `IndexOutOfBoundsException` on `GenericAddRemoveChange` creation. > So we should check it to create correct `GenericAddRemoveChange`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/542 From mhanl at openjdk.java.net Tue Jun 29 05:32:00 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 29 Jun 2021 05:32:00 GMT Subject: Integrated: 8269244: [IDE] Dependency verification of *-sources.jar fails when doing gradle sync In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 14:38:32 GMT, Marius Hanl wrote: > This PR fixes the issue identified and discussed in PR https://github.com/openjdk/jfx/pull/506 which will make the gradle sync in IntelliJ fail because of the failing dependency verification for source files. > > Gradle provides a way to skip the verification of source files, documented here: > https://docs.gradle.org/current/userguide/dependency_verification.html#sec:skipping-javadocs > > Also the **README.txt** file is adjusted to include the instructions neccessary when updating the **verification-metadata.xml** file. This pull request has now been integrated. Changeset: 98e51669 Author: Marius Hanl Committer: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/98e516698f02bfd3484ca5721c014dae8ddf80c9 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod 8269244: [IDE] Dependency verification of *-sources.jar fails when doing gradle sync Reviewed-by: kcr, nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/549 From arapte at openjdk.java.net Tue Jun 29 10:28:57 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 29 Jun 2021 10:28:57 GMT Subject: RFR: 8269259: Remove obsolete apps, tests, and scripts In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 14:59:00 GMT, Kevin Rushforth wrote: > This PR deletes the following applications, tests, and scripts that are either obsolete > or unmaintained: > > apps/performance/* > > apps/tests/HelloTest > > apps/toys/FXSlideShow > apps/toys/Industrial > apps/toys/Shape3DToy > apps/toys/StretchyGrid > apps/toys/TouchSuite > > tests/functional/* > tests/performance/VMPerformance > > tools/* > > See the JBS issue and [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030894.html) on the openjfx-dev mailing list for more info. > > There are two commits for ease of review. The first one is generated by doing a "git rm -r" on each of the above listed directories. The second is to remove any remaining references to the removed directories. Build and sanity testing looks good. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/545 From kcr at openjdk.java.net Tue Jun 29 12:06:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 12:06:03 GMT Subject: Integrated: 8269424: Some SuppressWarnings annotations can be more localized In-Reply-To: References: Message-ID: On Sat, 26 Jun 2021 13:01:15 GMT, Kevin Rushforth wrote: > This is a follow-on fix to [JDK-8264139](https://bugs.openjdk.java.net/browse/JDK-8264139), which added `@SuppressWarning` annotations to usages of deprecated security manager methods. @wangweij noticed that there was one pattern where the automated tool added the warning at a higher level than was needed. This fix moves the annotation down to be more localized in the two places that were affected. This pull request has now been integrated. Changeset: 50ed890f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/50ed890f55e073ba1abe457dfaaba5cd7c84e8b9 Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod 8269424: Some SuppressWarnings annotations can be more localized Co-authored-by: Weijun Wang Reviewed-by: aghaisas, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/546 From kcr at openjdk.java.net Tue Jun 29 12:07:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 12:07:05 GMT Subject: Integrated: 8269259: Remove obsolete apps, tests, and scripts In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 14:59:00 GMT, Kevin Rushforth wrote: > This PR deletes the following applications, tests, and scripts that are either obsolete > or unmaintained: > > apps/performance/* > > apps/tests/HelloTest > > apps/toys/FXSlideShow > apps/toys/Industrial > apps/toys/Shape3DToy > apps/toys/StretchyGrid > apps/toys/TouchSuite > > tests/functional/* > tests/performance/VMPerformance > > tools/* > > See the JBS issue and [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030894.html) on the openjfx-dev mailing list for more info. > > There are two commits for ease of review. The first one is generated by doing a "git rm -r" on each of the above listed directories. The second is to remove any remaining references to the removed directories. This pull request has now been integrated. Changeset: 12fb4daa Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/12fb4daa36f6f3b13049d32c5a95317ed9a8168e Stats: 33646 lines in 196 files changed: 0 ins; 33645 del; 1 mod 8269259: Remove obsolete apps, tests, and scripts Reviewed-by: nlisker, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/545 From kcr at openjdk.java.net Tue Jun 29 12:12:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 12:12:02 GMT Subject: RFR: 8269259: Remove obsolete apps, tests, and scripts In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 03:58:10 GMT, Nir Lisker wrote: > Under tests/system/src there are several projects called "testappN". Are they named cryptically on purpose? Not really, no. They are all added to `build.gradle` as separate source sets [here](https://github.com/openjdk/jfx/blob/master/build.gradle#L3643), but we don't take advantage of the naming. They just need to be difference from the primary `test` source set. ------------- PR: https://git.openjdk.java.net/jfx/pull/545 From tsayao at openjdk.java.net Tue Jun 29 12:16:16 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 29 Jun 2021 12:16:16 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves corretly In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 16:56:44 GMT, Thiago Milczarek Sayao wrote: > The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. It's odd that glass `Window.java` defines `enterModal` but it seems to be never called. Modality is handled by calling `setEnabled(false)` on other windows. I would refactor that some day :) ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From tsayao at openjdk.java.net Tue Jun 29 12:16:16 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 29 Jun 2021 12:16:16 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves corretly Message-ID: The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. This is passed on WindowStage.java:198 as a mask. The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. ------------- Commit messages: - Only if not WINDOW_MODAL - Fix for JDK-8210973 - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - Merge pull request #16 from openjdk/master - Merge pull request #15 from openjdk/master - Merge pull request #14 from openjdk/master - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - ... and 8 more: https://git.openjdk.java.net/jfx/compare/78179be1...7b483449 Changes: https://git.openjdk.java.net/jfx/pull/551/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=551&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269429 Stats: 14 lines in 3 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/551/head:pull/551 PR: https://git.openjdk.java.net/jfx/pull/551 From tsayao at openjdk.java.net Tue Jun 29 12:32:01 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 29 Jun 2021 12:32:01 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves corretly In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 16:56:44 GMT, Thiago Milczarek Sayao wrote: > The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. It's working as expected: If there's two APPLICATION_MODAL (*1) and (*2) and a WINDOW_MODAL (*3) as a child of the primary stage the order of the windows on the screen will be (*2) (*1) (*3). Will run the tests and post here. ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From fastegal at openjdk.java.net Tue Jun 29 12:40:10 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 29 Jun 2021 12:40:10 GMT Subject: RFR: 8240506: TextFieldSkin/Behavior: misbehavior on switching skin In-Reply-To: References: <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com> Message-ID: On Mon, 28 Jun 2021 15:42:47 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java line 75: >> >>> 73: } >>> 74: >>> 75: focusListener = (observable, oldValue, newValue) -> { >> >> Shouldn't this focusListener also be wrapped in a weakListener? Also this lambda expression can be a one-liner (no braces needed) > > we are a bit inconsistent in wrapping (or not) listeners into their weak counterparts - behaviors tend to not :) That's okay - and less crowded by additional code - as long as they are removed properly, IMO. But just seeing: good question, as the focusOwner listener is wrapped, need to consult my notes. Thanks for the heads up! > > As to the single vs. multiple lines: ersonally, I tend to not change more than absolutely needed - it had the brackets before the fix so I kept them. Okay, went through listener registrations in all behaviors - and they are indeed inconsistent: - some listen to control properties like focused (f.i. Button, Combo): adding strong, often inline listeners - some listen to control path properties like selection/Model/Indices (f.i. ListView, TreeView): adding weak (inline or field) wrappers - cleanup for all guarantees to make those listeners removable (without touching their type) and actually remove them in dispose So I tend to follow that approach here as well, opinions? ------------- PR: https://git.openjdk.java.net/jfx/pull/534 From jvos at openjdk.java.net Tue Jun 29 14:06:12 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Jun 2021 14:06:12 GMT Subject: RFR: 8269593: Different fontname on macos Message-ID: <7yKAEMYVzjEexg8QT14Z8Fn_uoZ219e82DaQipSSiFk=.504733aa-d66b-4698-a012-ad97da4cf99d@github.com> Make sure the returned fullName of a created font matches the requested name. Since the name is used as a key/identifier in some cases, some internal code relies on this. Added a test to check the case of "System Font Regular" on MacOS, which fails before and succeeds after the patch. ------------- Commit messages: - Fix for JDK-8269593 Changes: https://git.openjdk.java.net/jfx/pull/553/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=553&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269593 Stats: 25 lines in 3 files changed: 24 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/553.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/553/head:pull/553 PR: https://git.openjdk.java.net/jfx/pull/553 From jvos at openjdk.java.net Tue Jun 29 14:20:30 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Jun 2021 14:20:30 GMT Subject: RFR: 8269593: Different fontname on macos [v2] In-Reply-To: <7yKAEMYVzjEexg8QT14Z8Fn_uoZ219e82DaQipSSiFk=.504733aa-d66b-4698-a012-ad97da4cf99d@github.com> References: <7yKAEMYVzjEexg8QT14Z8Fn_uoZ219e82DaQipSSiFk=.504733aa-d66b-4698-a012-ad97da4cf99d@github.com> Message-ID: > Make sure the returned fullName of a created font matches the requested name. Since the name is used as a key/identifier in some cases, some internal code relies on this. > Added a test to check the case of "System Font Regular" on MacOS, which fails before and succeeds after the patch. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: rename test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/553/files - new: https://git.openjdk.java.net/jfx/pull/553/files/a5eb0676..f1c0d7da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=553&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=553&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/553.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/553/head:pull/553 PR: https://git.openjdk.java.net/jfx/pull/553 From jvos at openjdk.java.net Tue Jun 29 14:57:15 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Jun 2021 14:57:15 GMT Subject: RFR: 8269601: Increase gcc-10 version for github workflow Message-ID: install latest version of gcc/g++ (older specific versions are not available anymore) ------------- Commit messages: - fix #8269601 Changes: https://git.openjdk.java.net/jfx/pull/555/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=555&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269601 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/555.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/555/head:pull/555 PR: https://git.openjdk.java.net/jfx/pull/555 From kcr at openjdk.java.net Tue Jun 29 16:15:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 16:15:07 GMT Subject: RFR: 8269601: Increase gcc-10 version for github workflow In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 14:52:28 GMT, Johan Vos wrote: > install latest version of gcc/g++ (older specific versions are not available anymore) Looks good, thanks for taking care of this. I note that [JDK-8266224](https://bugs.openjdk.java.net/browse/JDK-8266224) was already filed for this. I just assigned it to you. Perhaps you could change the title of this PR to use that bug ID instead? (and close the one you just filed as a duplicate). ------------- PR: https://git.openjdk.java.net/jfx/pull/555 From kcr at openjdk.java.net Tue Jun 29 17:15:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 17:15:08 GMT Subject: RFR: 8266224: GitHub actions: use gcc 10.3 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 14:52:28 GMT, Johan Vos wrote: > install latest version of gcc/g++ (older specific versions are not available anymore) Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/555 From kcr at openjdk.java.net Tue Jun 29 17:20:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 17:20:09 GMT Subject: RFR: 8269593: Different fontname on macos [v2] In-Reply-To: References: <7yKAEMYVzjEexg8QT14Z8Fn_uoZ219e82DaQipSSiFk=.504733aa-d66b-4698-a012-ad97da4cf99d@github.com> Message-ID: <_Ud-PtRGsA1on3Csev0V9bFzUm7mvS12dP-V9xQVvvQ=.b8c33742-9cf7-4eda-b6c4-f35cba3341c4@github.com> On Tue, 29 Jun 2021 14:20:30 GMT, Johan Vos wrote: >> Make sure the returned fullName of a created font matches the requested name. Since the name is used as a key/identifier in some cases, some internal code relies on this. >> Added a test to check the case of "System Font Regular" on MacOS, which fails before and succeeds after the patch. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > rename test @prrace can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/553 From jvos at openjdk.java.net Tue Jun 29 17:28:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 29 Jun 2021 17:28:08 GMT Subject: Integrated: 8266224: GitHub actions: use gcc 10.3 on Linux In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 14:52:28 GMT, Johan Vos wrote: > install latest version of gcc/g++ (older specific versions are not available anymore) This pull request has now been integrated. Changeset: b0d15862 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/b0d158629ed5f9c92cbcc39a7099f2d37e34ecf7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8266224: GitHub actions: use gcc 10.3 on Linux Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/555 From kcr at openjdk.java.net Tue Jun 29 21:08:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 21:08:06 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves corretly In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 16:56:44 GMT, Thiago Milczarek Sayao wrote: > The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. I tried the test program attached to the JBS bug, and I'm not seeing the problem. Are there any special steps I need to take to see the bug? I also left a question about `WINDOW_MODAL` vs `APPLICATION_MODAL` windows. Regarding the `{enter/exit/is}Modal` methods in `Window.java`, it looks like they stubs that are never called. Modality is handled by the toolkit using (as you found out) only the `setEnabled` method. Finally, you have a typo in the title of both this PR and the JBS bug: `corretly` --> `correctly` modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 741: > 739: } else if (modal) { > 740: //this is used for APPLICATION_MODAL > 741: gtk_window_set_keep_above(GTK_WINDOW(gtk_widget), TRUE); Won't this also be set for `WINDOW_MODAL` windows? And if so, is this really what we want? ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From tsayao at openjdk.java.net Tue Jun 29 21:58:36 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 29 Jun 2021 21:58:36 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2] In-Reply-To: References: Message-ID: > The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Reuse existing set_modal (which was previously unused). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/551/files - new: https://git.openjdk.java.net/jfx/pull/551/files/7b483449..612a61ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=551&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=551&range=00-01 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/551/head:pull/551 PR: https://git.openjdk.java.net/jfx/pull/551 From tsayao at openjdk.java.net Tue Jun 29 21:58:38 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 29 Jun 2021 21:58:38 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 21:05:06 GMT, Kevin Rushforth wrote: > I tried the test program attached to the JBS bug, and I'm not seeing the problem. Are there any special steps I need to take to see the bug? I also left a question about `WINDOW_MODAL` vs `APPLICATION_MODAL` windows. > > Regarding the `{enter/exit/is}Modal` methods in `Window.java`, it looks like they stubs that are never called. Modality is handled by the toolkit using (as you found out) only the `setEnabled` method. > > Finally, you have a typo in the title of both this PR and the JBS bug: `corretly` --> `correctly` - Added steps to reproduce on JBS. Basically the window manager will let you click the window in the back (primary stage in the example) and the APPLICATION_MODAL will go behind it, still blocking events; - Fixed the typo. > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 741: > >> 739: } else if (modal) { >> 740: //this is used for APPLICATION_MODAL >> 741: gtk_window_set_keep_above(GTK_WINDOW(gtk_widget), TRUE); > > Won't this also be set for `WINDOW_MODAL` windows? And if so, is this really what we want? Yes. I have refactored it. ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From kcr at openjdk.java.net Tue Jun 29 22:10:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 22:10:07 GMT Subject: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 03:07:11 GMT, Alexander Matveev wrote: > Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of cycle is reached regardless if it is repeating or not. This looks like a good fix, but should have a CSR, since it changes the specification. ------------- PR: https://git.openjdk.java.net/jfx/pull/552 From kcr at openjdk.java.net Tue Jun 29 22:43:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 22:43:04 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v4] In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 19:47:39 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8223717: javafx printing: Support Specifying Print to File in the API The API looks fine now, although I may have some minor wording suggestions after I do another pass tomorrow. Go ahead and file the CSR and move it to proposed as soon as you can to see if Joe has any comments in parallel with our finishing the review. I also need to do some testing on Mac and Linux (the manual test now works as expected on Windows). modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 503: > 501: * If a {@code SecurityManager} is installed and it denies access to the > 502: * specified file a {@code SecurityException} may be thrown. > 503: * @defaultValue an empty String Minor: I recommend either `string` (lower case) or `{@code String}`. Very minor: can you move the `@defaultValue` below the blank like with the other javadoc tags? ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Tue Jun 29 22:43:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 22:43:04 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v2] In-Reply-To: References: <9XHiBWyQ4u6hoTf88a6jvNoAZBMymNgfw3kOT2a0XNE=.a3bfa36b-740d-46c8-a1a8-6b877a1310d4@github.com> Message-ID: On Mon, 28 Jun 2021 18:12:33 GMT, Phil Race wrote: >> It's still a good idea to follow the pattern, so yes let's make the new methods final. We can file a cleanup bug for the existing ones (and since the class is final, we can do it without compatibility concerns). >> >> Also, I built the docs, and it is better to not add any javadoc comments on the setter and getter. > > I'll file a clean up bug I missed the part where you said you would file the bug, so I filed [JDK-8269638](https://bugs.openjdk.java.net/browse/JDK-8269638). ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From kcr at openjdk.java.net Tue Jun 29 22:59:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Jun 2021 22:59:05 GMT Subject: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 03:07:11 GMT, Alexander Matveev wrote: > Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of cycle is reached regardless if it is repeating or not. Looks good with one suggested change. modules/javafx.media/src/main/java/javafx/scene/media/MediaPlayer.java line 117: > 115: * {@link #onRepeatProperty onRepeat} property is invoked. If the stop time is > 116: * reached, then the event handler registered with the {@link #onEndOfMediaProperty onEndOfMedia} > 117: * property is invoked regardless if the cycle is to be repeated or not. I recommend the following wording change: `regardless if the cycle` --> `regardless of whether the cycle` ------------- PR: https://git.openjdk.java.net/jfx/pull/552 From tsayao at openjdk.java.net Tue Jun 29 23:41:10 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 29 Jun 2021 23:41:10 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 21:58:36 GMT, Thiago Milczarek Sayao wrote: >> The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. >> >> This is passed on WindowStage.java:198 as a mask. >> >> The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Reuse existing set_modal (which was previously unused). ![image](https://user-images.githubusercontent.com/30704286/123880825-d1129d80-d919-11eb-8e49-07f18da72dd1.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From tsayao at openjdk.java.net Tue Jun 29 23:45:03 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 29 Jun 2021 23:45:03 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 21:58:36 GMT, Thiago Milczarek Sayao wrote: >> The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. >> >> This is passed on WindowStage.java:198 as a mask. >> >> The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Reuse existing set_modal (which was previously unused). The first approach was to make the window not clickable or not "activable" when `setEnabled(false)` but I did not find a solution for that on Gdk or Gtk. Gtk has `gtk_widget_set_sensitive` but that did not work (probably only if using gtk signals). I did make other attempts with no success. ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From almatvee at openjdk.java.net Wed Jun 30 00:15:26 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 30 Jun 2021 00:15:26 GMT Subject: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2] In-Reply-To: References: Message-ID: > Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of cycle is reached regardless if it is repeating or not. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/552/files - new: https://git.openjdk.java.net/jfx/pull/552/files/1592e86b..68e5df99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=552&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=552&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/552.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/552/head:pull/552 PR: https://git.openjdk.java.net/jfx/pull/552 From almatvee at openjdk.java.net Wed Jun 30 00:15:28 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 30 Jun 2021 00:15:28 GMT Subject: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 22:55:50 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2] > > modules/javafx.media/src/main/java/javafx/scene/media/MediaPlayer.java line 117: > >> 115: * {@link #onRepeatProperty onRepeat} property is invoked. If the stop time is >> 116: * reached, then the event handler registered with the {@link #onEndOfMediaProperty onEndOfMedia} >> 117: * property is invoked regardless if the cycle is to be repeated or not. > > I recommend the following wording change: > > `regardless if the cycle` --> `regardless of whether the cycle` Fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/552 From prr at openjdk.java.net Wed Jun 30 00:48:25 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 30 Jun 2021 00:48:25 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v5] In-Reply-To: References: Message-ID: > This enhancement adds the String property outputFileProperty() to the JobSettings class. > The value should be a string that references a local file encoded as a URL. > If this is non-null and set to a location that the user has permission to write to, > then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. > The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. > > A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. Phil Race has updated the pull request incrementally with three additional commits since the last revision: - 8223717: javafx printing: Support Specifying Print to File in the API - 8223717: javafx printing: Support Specifying Print to File in the API - 8223717: javafx printing: Support Specifying Print to File in the API ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/543/files - new: https://git.openjdk.java.net/jfx/pull/543/files/34221a95..baab574d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=543&range=03-04 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/543/head:pull/543 PR: https://git.openjdk.java.net/jfx/pull/543 From prr at openjdk.java.net Wed Jun 30 00:48:27 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 30 Jun 2021 00:48:27 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v4] In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 19:47:39 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8223717: javafx printing: Support Specifying Print to File in the API CSR: https://bugs.openjdk.java.net/browse/JDK-8269642 ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From mhanl at openjdk.java.net Wed Jun 30 04:19:05 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 30 Jun 2021 04:19:05 GMT Subject: Integrated: 8267418: IntelliJ build and test of JavaFX does not work In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:12:45 GMT, Marius Hanl wrote: > ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ > EDIT: Thank you, Kevin. :) > > This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: > - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. > -> This is the language level shown inside the **Project Structure**. (File -> Project Structure...) > - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize the shims (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) > - EDIT: The projects are now recognized by IntelliJ-gradle (**.idea/gradle.xml**, **.idea/compiler.xml**) > > **-> With this, I can run all normal tests with IntelliJ** > > ### What I couldn't fix yet (When I tried, it looked like IntelliJ is overriding the settings on next gradle reload): > - IntelliJ is not detecting javafx.graphic inside the shims > - All javafx.* dependencies are not found for the system tests > > **-> If someone has a solution, feel free to comment :)** This pull request has now been integrated. Changeset: a1be1d59 Author: Marius Hanl Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/a1be1d591c0bf0bc118ffb8a4d1c4c8cc236b689 Stats: 50 lines in 8 files changed: 30 ins; 13 del; 7 mod 8267418: IntelliJ build and test of JavaFX does not work Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From sykora at openjdk.java.net Wed Jun 30 09:35:08 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Wed, 30 Jun 2021 09:35:08 GMT Subject: RFR: 8269147: Update GStreamer to version 1.18.4 In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. We've also tested the changes on our build infrastructure and it all worked fine. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/541 From kcr at openjdk.java.net Wed Jun 30 13:06:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Jun 2021 13:06:07 GMT Subject: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2] In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 00:15:26 GMT, Alexander Matveev wrote: >> Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of cycle is reached regardless if it is repeating or not. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2] Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/552 From mhanl at openjdk.java.net Wed Jun 30 15:09:22 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 30 Jun 2021 15:09:22 GMT Subject: RFR: 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel Message-ID: This PR fixes 2 NPEs in Choice-and ComboBox, when the selection model is null. ChoiceBox: - Null check in **valueProperty()** listener ComboBox: - Null check in **valueProperty()** listener - Null check in **ComboBoxListViewSkin#updateValue()** The tests checks, that no NPE is printed to the console (JUnit5 has the **assertDoesNotThrow?()** method, but 4 unfortunately has not). They also checks, that the set value is still displayed (either in the ComboBox button cell or the ChoiceBox display label) ------------- Commit messages: - 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel Changes: https://git.openjdk.java.net/jfx/pull/557/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=557&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8089398 Stats: 71 lines in 5 files changed: 62 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/557.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/557/head:pull/557 PR: https://git.openjdk.java.net/jfx/pull/557 From kcr at openjdk.java.net Wed Jun 30 15:15:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Jun 2021 15:15:15 GMT Subject: RFR: 8258499: JavaFX: Move src.zip out of the lib directory Message-ID: The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. It provides a `src.zip` file for use by IDEs in that same `lib` directory. If a developer adds the `lib` directory to their application's module path in the IDE, it will try to load `src.zip` as if it were a jar file, and will fail. This is a pain point for developers using the SDK. The proposed solution is to move the `src.zip` file from the lib directory to the top directory of the SDK. With this fix, the layout of the SDK will be: / bin/ (Windows) (Windows) legal/ ... lib/ *.jar (macOS and Linux) src.zip NOTES: 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by eclipse-efx/efxclipse-eclipse#85. 2. This still needs to be tested on IntelliJ ------------- Commit messages: - 8258499: JavaFX: Move src.zip out of the lib directory Changes: https://git.openjdk.java.net/jfx/pull/558/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=558&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258499 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/558.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/558/head:pull/558 PR: https://git.openjdk.java.net/jfx/pull/558 From mhanl at openjdk.java.net Wed Jun 30 16:13:03 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 30 Jun 2021 16:13:03 GMT Subject: RFR: 8258499: JavaFX: Move src.zip out of the lib directory In-Reply-To: References: Message-ID: <3NLbw-joU1ygLrnvGqIQbzPEDe0F0Wt1wlFPMvEm73c=.a0e679aa-9cf8-449f-be7f-5de53a92c869@github.com> On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. It provides a `src.zip` file for use by IDEs in that same `lib` directory. If a developer adds the `lib` directory to their application's module path in the IDE, it will try to load `src.zip` as if it were a jar file, and will fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ I just tried it with IntelliJ. I did the following steps: 1. I build the PR with **gradle sdk** 2. I copied the content of the sdk folder into an own '**jfx-17-internal**' folder. 3. I added the **lib** folder as library in IntelliJ

    Screenshot![image](https://user-images.githubusercontent.com/66004280/123993257-9158be00-d9cc-11eb-9acd-cefe66daaa32.png)
    4. I navigated into a class file (**Stage** in this case) and clicked on '**Choose sources...**' (top right)
    Screenshot![image](https://user-images.githubusercontent.com/66004280/123993603-dbda3a80-d9cc-11eb-8233-5ac6da3b321e.png)
    5. I chose the **src.zip** which is now inside the root folder
    Screenshot![image](https://user-images.githubusercontent.com/66004280/123994144-60c55400-d9cd-11eb-984d-ea137aa43b22.png)
    6. I can now see the sources (in my case: **Stage**)
    Screenshot ![image](https://user-images.githubusercontent.com/66004280/123995006-2dcf9000-d9ce-11eb-88d1-4e224be959c1.png)
    Is this sufficient/Do I miss something or is this fine as test? ------------- PR: https://git.openjdk.java.net/jfx/pull/558 From kcr at openjdk.java.net Wed Jun 30 16:19:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Jun 2021 16:19:10 GMT Subject: RFR: 8258499: JavaFX: Move src.zip out of the lib directory In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. It provides a `src.zip` file for use by IDEs in that same `lib` directory. If a developer adds the `lib` directory to their application's module path in the IDE, it will try to load `src.zip` as if it were a jar file, and will fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ Thanks for running the test. This is sufficient to show that the changed layout will work with IntelliJ. What happens with the current layout, where src.zip is in the lib dir, if you add the lib dir? Does IntelliJ fail in the same way as NetBeans (complain about duplicates)? ------------- PR: https://git.openjdk.java.net/jfx/pull/558 From mhanl at openjdk.java.net Wed Jun 30 17:22:13 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 30 Jun 2021 17:22:13 GMT Subject: RFR: 8258499: JavaFX: Move src.zip out of the lib directory In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. It provides a `src.zip` file for use by IDEs in that same `lib` directory. If a developer adds the `lib` directory to their application's module path in the IDE, it will try to load `src.zip` as if it were a jar file, and will fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ As documented in a comment, this is fine for IntelliJ. Verified, that the **src.zip** is now in the root of the sdk folder. ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/558 From mhanl at openjdk.java.net Wed Jun 30 17:22:13 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 30 Jun 2021 17:22:13 GMT Subject: RFR: 8258499: JavaFX: Move src.zip out of the lib directory In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 16:16:16 GMT, Kevin Rushforth wrote: > Thanks for running the test. This is sufficient to show that the changed layout will work with IntelliJ. > > What happens with the current layout, where src.zip is in the lib dir, if you add the lib dir? Does IntelliJ fail in the same way as NetBeans (complain about duplicates)? No. It behaves the same as I documented above. So for IntelliJ, nothing really changed but the directory you need to choose the src.zip from. ------------- PR: https://git.openjdk.java.net/jfx/pull/558 From almatvee at openjdk.java.net Wed Jun 30 19:33:05 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 30 Jun 2021 19:33:05 GMT Subject: Integrated: 8269147: Update GStreamer to version 1.18.4 In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. This pull request has now been integrated. Changeset: 098c0f39 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/098c0f393ef0849e140c9efd4d083f3282e1fa0e Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod 8269147: Update GStreamer to version 1.18.4 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/541 From jvos at openjdk.java.net Wed Jun 30 19:45:02 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 30 Jun 2021 19:45:02 GMT Subject: RFR: 8258499: JavaFX: Move src.zip out of the lib directory In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. It provides a `src.zip` file for use by IDEs in that same `lib` directory. If a developer adds the `lib` directory to their application's module path in the IDE, it will try to load `src.zip` as if it were a jar file, and will fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ This indeed makes it easier, at least on NetBeans, to avoid issues with source code and jars in the same directory. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/558 From kcr at openjdk.java.net Wed Jun 30 22:42:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Jun 2021 22:42:08 GMT Subject: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v5] In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 00:48:25 GMT, Phil Race wrote: >> This enhancement adds the String property outputFileProperty() to the JobSettings class. >> The value should be a string that references a local file encoded as a URL. >> If this is non-null and set to a location that the user has permission to write to, >> then the printer output will be spooled there instead of the printer, so long as the platform printing system supports this. >> The user can of course also set a print-to-file destination in the platform printer dialogs which may over-ride what the application set. But now the application can also see what it was set to, and cancel or alter it if necessary. >> >> A simple manual test is provided, manual mainly because the few real printing functional tests are all manual as they are only useful if run with a printer configured. > > Phil Race has updated the pull request incrementally with three additional commits since the last revision: > > - 8223717: javafx printing: Support Specifying Print to File in the API > - 8223717: javafx printing: Support Specifying Print to File in the API > - 8223717: javafx printing: Support Specifying Print to File in the API I've added my final comments on the API docs. Some of them are pretty nit-picky, so take them as suggestions. modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 481: > 479: * such as Postscript or PDF, and the application intends to distribute > 480: * the result instead of printing it, or for some other reason the > 481: * application does not want physical media (paper) emitted by the printer. Very minor: maybe consider combining the first three paragraphs into a single paragraph? modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 486: > 484: * equivalent to null, which means output is sent to the printer. > 485: * So in order to reset to print to the printer, clear the value of > 486: * this property by setting it to null or an empty string. This doesn't flow as well as it could. I think you only need to mention once that `null` is the same as an empty string, and then you can just say "empty string". Maybe something like this? The default value is an empty string, which means output is sent to the printer. So in order to reset to print to the printer, clear the value of this property by setting it to an empty string. A value of {@code null} is treated as an empty string. modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 489: > 487: *

    > 488: * Additionally if the application displays a printer dialog which allows > 489: * the user to specify a file destination including altering an application Minor: I think there should be a comma between `destination` and `including`. modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 491: > 489: * the user to specify a file destination including altering an application > 490: * specified file destination, the value of this property will reflect that > 491: * user-specified choice, including clearing it to re-set to print to `reset` is one word (no need to hyphenate). modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 500: > 498: * a user writable file, when printing the results are platform-dependent, including > 499: * replacement with a default output file location, printing to the printer instead, > 500: * or a platform printing error. This sentence is a bit awkward and hard to parse. Maybe break it into two sentences? Perhaps something like this: If the specified name specifies a non-existent path, or does not specify a user writable file, the results when printing are platform-dependent. Possible behavior might include replacement with a default output file location, printing to the printer instead, or a platform printing error. ------------- PR: https://git.openjdk.java.net/jfx/pull/543 From almatvee at openjdk.java.net Wed Jun 30 23:43:03 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 30 Jun 2021 23:43:03 GMT Subject: Integrated: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc In-Reply-To: References: Message-ID: On Tue, 29 Jun 2021 03:07:11 GMT, Alexander Matveev wrote: > Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of cycle is reached regardless if it is repeating or not. This pull request has now been integrated. Changeset: cfa60ff7 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/cfa60ff7a54edcfd099f08585df71e1f7fc09ddb Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/552 From mik3hall at gmail.com Wed Jun 30 23:44:50 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 30 Jun 2021 18:44:50 -0500 Subject: Button label text garbled - OS/X Catalina Message-ID: <11EA5A5D-A34C-49CB-9F0D-7ECC6872788D@gmail.com> I was looking at some JavaFX introductions. HelloWorld type things. In this case literally? https://docs.oracle.com/javafx/2/get_started/hello_world.htm The button labels show garbled text. Googling shows a number of similar examples. I found one issue indicating something very similar showing as resolved. https://bugs.openjdk.java.net/browse/JDK-8234916 If you try to setFont you get about the same messages like? java -cp . --module-path ~/Documents/javafx-sdk-11.0-2.2/lib --add-modules javafx.base,javafx.controls helloworld.HelloWorld 2021-06-30 17:52:22.790 java[4142:207281] CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. 2021-06-30 17:52:22.790 java[4142:207281] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug. 2021-06-30 17:52:22.792 java[4142:207281] CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. 2021-06-30 17:52:22.896 java[4142:207311] CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. Hello World! Should I open an issue on this someplace or is it still open somewhere? Or is there something I should do different to avoid it?