From almatvee at openjdk.java.net Thu Apr 1 01:39:17 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 1 Apr 2021 01:39:17 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: References: Message-ID: <_vdajZtvbKmn0FvI8owNTnAby4DBnupiq9fiHkod6Ew=.51940492-315c-408e-9a45-514f2c2413ca@github.com> On Wed, 31 Mar 2021 19:25:09 GMT, Kevin Rushforth wrote: >> - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 >> - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. > > I get a compilation error on Linux: > > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c: In function 'gst_audio_buffer_map': > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: error: implicit declaration of function 'memset' [-Werror=implicit-function-declaration] > 158 | memset (buffer->map_infos, 0, > | ^~~~~~ > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: warning: incompatible implicit declaration of built-in function 'memset' > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:26:1: note: include '' or provide a declaration of 'memset' > ... > cc1: some warnings being treated as errors > Makefile:270: recipe for target 'modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o' failed > make: *** [modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o] Error 1 > > This is with the gcc 10.2 compiler used for production builds. I cannot reproduce build failure on Linux. ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From jvos at openjdk.java.net Thu Apr 1 08:11:14 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 1 Apr 2021 08:11:14 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: <_vdajZtvbKmn0FvI8owNTnAby4DBnupiq9fiHkod6Ew=.51940492-315c-408e-9a45-514f2c2413ca@github.com> References: <_vdajZtvbKmn0FvI8owNTnAby4DBnupiq9fiHkod6Ew=.51940492-315c-408e-9a45-514f2c2413ca@github.com> Message-ID: On Thu, 1 Apr 2021 01:36:01 GMT, Alexander Matveev wrote: >> I get a compilation error on Linux: >> >> ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c: In function 'gst_audio_buffer_map': >> ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: error: implicit declaration of function 'memset' [-Werror=implicit-function-declaration] >> 158 | memset (buffer->map_infos, 0, >> | ^~~~~~ >> ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: warning: incompatible implicit declaration of built-in function 'memset' >> ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:26:1: note: include '' or provide a declaration of 'memset' >> ... >> cc1: some warnings being treated as errors >> Makefile:270: recipe for target 'modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o' failed >> make: *** [modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o] Error 1 >> >> This is with the gcc 10.2 compiler used for production builds. > > I cannot reproduce build failure on Linux. It compiles for me (on gcc-9, 10.1 and 10.2) but I can imagine it doesn't compile on all configurations. `memset` is declared in `string.h` and that may or may not be included. Running gcc -H shows that on my system, `string.h` is included by `glib-2.0/glib/gtestutils.h` (which is included by `glib-2.0/glib.h`) but on other systems, that might not be the case. Since this PR introduces `memset` in the `audio-buffer.c` file, I think it is safest to include `string.h` in this file as well, as this removes the dependency on that file to be included indirectly. ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From kcr at openjdk.java.net Thu Apr 1 11:07:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 11:07:14 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: References: <_vdajZtvbKmn0FvI8owNTnAby4DBnupiq9fiHkod6Ew=.51940492-315c-408e-9a45-514f2c2413ca@github.com> Message-ID: On Thu, 1 Apr 2021 08:07:56 GMT, Johan Vos wrote: >> I cannot reproduce build failure on Linux. > > It compiles for me (on gcc-9, 10.1 and 10.2) but I can imagine it doesn't compile on all configurations. `memset` is declared in `string.h` and that may or may not be included. > Running gcc -H shows that on my system, `string.h` is included by `glib-2.0/glib/gtestutils.h` (which is included by `glib-2.0/glib.h`) but on other systems, that might not be the case. > Since this PR introduces `memset` in the `audio-buffer.c` file, I think it is safest to include `string.h` in this file as well, as this removes the dependency on that file to be included indirectly. Alexander tried it on our CI build machine yesterday and it builds fine there, too. I should add that I was building on a very old Ubuntu 16.04 system. > Since this PR introduces memset in the audio-buffer.c file, I think it is safest to include string.h in this file as well, as this removes the dependency on that file to be included indirectly. I was thinking the same thing. There is one more file that should include ``: `qtdemux_tags.c` uses `strlen`and fails to compile on my system. With the change to include `string.h` in those two files, the build now passes on my system. ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From kcr at openjdk.java.net Thu Apr 1 11:24:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 11:24:14 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 21:49:21 GMT, John Hendrikx wrote: >> Small fix to clear a reference to a removed node left by Scene$MouseHandler. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test compile dependency on :base for :graphics Looks good. I confirm that the new test fails without your fix and passes with your fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/448 From fastegal at openjdk.java.net Thu Apr 1 12:08:15 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 1 Apr 2021 12:08:15 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 14:04:42 GMT, Marius Hanl wrote: >> This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. >> This bug only occurs, when a fixed cell size is set to the table. >> >> I also added 3 more tests beside the mandatory test, which tests my fix. >> 1 alternative test, which tests the same with no fixed cell size set. >> The other 2 tests are testing the same, but the table columns are set invisible instead. >> >> -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. >> Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). >> See also: TableRowSkinBase#updateCells(boolean) > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8258663: Changes based of the code review looks good :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/444 From kcr at openjdk.java.net Thu Apr 1 12:22:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 12:22:14 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: References: <_vdajZtvbKmn0FvI8owNTnAby4DBnupiq9fiHkod6Ew=.51940492-315c-408e-9a45-514f2c2413ca@github.com> Message-ID: On Thu, 1 Apr 2021 11:04:35 GMT, Kevin Rushforth wrote: >> It compiles for me (on gcc-9, 10.1 and 10.2) but I can imagine it doesn't compile on all configurations. `memset` is declared in `string.h` and that may or may not be included. >> Running gcc -H shows that on my system, `string.h` is included by `glib-2.0/glib/gtestutils.h` (which is included by `glib-2.0/glib.h`) but on other systems, that might not be the case. >> Since this PR introduces `memset` in the `audio-buffer.c` file, I think it is safest to include `string.h` in this file as well, as this removes the dependency on that file to be included indirectly. > > Alexander tried it on our CI build machine yesterday and it builds fine there, too. I should add that I was building on a very old Ubuntu 16.04 system. > >> Since this PR introduces memset in the audio-buffer.c file, I think it is safest to include string.h in this file as well, as this removes the dependency on that file to be included indirectly. > > I was thinking the same thing. There is one more file that should include ``: `qtdemux_tags.c` uses `strlen`and fails to compile on my system. With the change to include `string.h` in those two files, the build now passes on my system. All my testing looks good on all three platforms. I'll take a look at the diffs next. One thing I did spot is that you need to update `gstreamer.md` and `glib.md` to bump the version numbers. ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From jhendrikx at openjdk.java.net Thu Apr 1 12:53:21 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 1 Apr 2021 12:53:21 GMT Subject: Integrated: 8264330: Scene MouseHandler is referencing removed nodes In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:36:06 GMT, John Hendrikx wrote: > Small fix to clear a reference to a removed node left by Scene$MouseHandler. This pull request has now been integrated. Changeset: 015dad07 Author: John Hendrikx Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/015dad07 Stats: 52 lines in 3 files changed: 50 ins; 0 del; 2 mod 8264330: Scene MouseHandler is referencing removed nodes Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From kcr at openjdk.java.net Thu Apr 1 13:27:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 13:27:08 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 09:53:55 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > xxInvalidationListener: changed doc as per review One comment on the API that should be resolved before submitting the CSR. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 270: > 268: * may be {@code null} > 269: * @return a composed consumer that performs all removed operations, or > 270: * {@code null} if none have been registered or the observable is {@code null} Somehow my comment seems to have been deleted, so here it is again, slightly modified, along with a suggestion. I haven't gone back and done a detailed review yet, but I like the overall changes. The one thing I did notice is that the language used to describe the return value of `unregisterInvalidationListeners` and `unregisterListChangeListeners` is different: unregisterInvalidationListeners: * @return a composed consumer that performs all removed operations, or * {@code null} if none have been registered or the observable is {@code null} unregisterListChangeListeners: * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through * {@link #registerListChangeListener(ObservableList, Consumer)}. If no consumers have been registered on this * list, null will be returned. I find it confusing to say that the returned list "performs all removed operations". Some might interpret this to mean that is is somehow necessary to call the returned chained consumer as part of the removal, which isn't what you meant to say. How about something like this for both newly added unregister methods? * @return a composed consumer consisting of all previously registered consumers, or * {@code null} if none have been registered or the observable is {@code null} ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From github.com+43553916+mstr2 at openjdk.java.net Thu Apr 1 13:50:40 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Thu, 1 Apr 2021 13:50:40 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value Message-ID: The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. The following program shows the problem for HBox: Region r1 = new Region(); Region r2 = new Region(); Region r3 = new Region(); Region r4 = new Region(); Region r5 = new Region(); Region r6 = new Region(); r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); r1.setPrefWidth(25.3); r2.setPrefWidth(25.3); r3.setPrefWidth(25.4); r4.setPrefWidth(25.3); r5.setPrefWidth(25.3); r6.setPrefWidth(25.4); r1.setMaxHeight(30); r2.setMaxHeight(30); r3.setMaxHeight(30); r4.setMaxHeight(30); r5.setMaxHeight(30); r6.setMaxHeight(30); HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); hbox1.setPrefHeight(40); r1 = new Region(); r2 = new Region(); r3 = new Region(); r4 = new Region(); r5 = new Region(); r6 = new Region(); r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); r1.setPrefWidth(25.3); r2.setPrefWidth(25.3); r3.setPrefWidth(25.4); r4.setPrefWidth(25.3); r5.setPrefWidth(25.3); r6.setPrefWidth(25.4); r1.setMaxHeight(30); r2.setMaxHeight(30); r3.setMaxHeight(30); r4.setMaxHeight(30); r5.setMaxHeight(30); r6.setMaxHeight(30); HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); hbox2.setPrefHeight(40); hbox2.setPrefWidth(152); VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); root.setSpacing(20); Scene scene = new Scene(root, 500, 250); primaryStage.setScene(scene); primaryStage.show(); Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. ------------- Commit messages: - Fix pixel-snapping glitches in VBox/HBox - Failing test Changes: https://git.openjdk.java.net/jfx/pull/445/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=445&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264591 Stats: 306 lines in 5 files changed: 215 ins; 19 del; 72 mod Patch: https://git.openjdk.java.net/jfx/pull/445.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/445/head:pull/445 PR: https://git.openjdk.java.net/jfx/pull/445 From kcr at openjdk.java.net Thu Apr 1 13:50:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 13:50:40 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 19:57:17 GMT, mstr2 wrote: > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); > root.setSpacing(20); > Scene scene = new Scene(root, 500, 250); > > primaryStage.setScene(scene); > primaryStage.show(); > > Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. > ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) > > I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. The bug is posted here: [JDK-8264591](https://bugs.openjdk.java.net/browse/JDK-8264591): HBox/VBox child widths pixel-snap to wrong value ------------- PR: https://git.openjdk.java.net/jfx/pull/445 From fastegal at openjdk.java.net Thu Apr 1 14:44:11 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 1 Apr 2021 14:44:11 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: <4sMuGaAW87f-lxLMt-13WyjuGsEZpuv3SAtgZnKd-VI=.17ae6bc1-b071-46eb-80c1-6216909d0642@github.com> References: <4sMuGaAW87f-lxLMt-13WyjuGsEZpuv3SAtgZnKd-VI=.17ae6bc1-b071-46eb-80c1-6216909d0642@github.com> Message-ID: On Wed, 31 Mar 2021 09:25:28 GMT, Florian Kirmaier wrote: > > > I don't think B is right. > I would expect a editCancel event when the index of an editing cell is changed. > If there would be another cell, which will get the index 1 (which isn't the case in this artifical test) then i would expect another editStart event. well, I see your point but think it's arguable :) - editEvent not/firing on cell re-use is not really specified (even overall edit spec is .. suboptimal, see [my oldish summary](https://github.com/kleopatra/swingempire-fx/wiki/CellEditEvents)) - without that spec, we might feel free to fire - from the perspective of edit handlers, that editCancel (and the assumed editStart - suspect it doesn't happen, didn't test though) are just spurious events - they are not really interested in volatile state changes, just introduced by an implementation detail like cell re-use. As to the scope of this: as I understand it, its goal is to keep the cell's editing state (flag and visual state) in sync with listview's editingIndex when updating the cell index. That should include both directions - index == editingIndex -> index != editingIndex - index != editingIndex -> index == editingIndex The first is already handled (modulo our disagreement on editEvents :), the second is not. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fastegal at openjdk.java.net Thu Apr 1 15:06:16 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 1 Apr 2021 15:06:16 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: References: Message-ID: <7RNOwM87fMcslFIFDFMxk6SQfs2x_7YKL5zaopEenk4=.09f1e9f4-6a72-44e5-8927-2ce31697745e@github.com> On Thu, 1 Apr 2021 13:22:47 GMT, Kevin Rushforth wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> xxInvalidationListener: changed doc as per review > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 270: > >> 268: * may be {@code null} >> 269: * @return a composed consumer that performs all removed operations, or >> 270: * {@code null} if none have been registered or the observable is {@code null} > > Somehow my comment seems to have been deleted, so here it is again, slightly modified, along with a suggestion. > > I haven't gone back and done a detailed review yet, but I like the overall changes. The one thing I did notice is that the language used to describe the return value of `unregisterInvalidationListeners` and `unregisterListChangeListeners` is different: > > unregisterInvalidationListeners: > * @return a composed consumer that performs all removed operations, or > * {@code null} if none have been registered or the observable is {@code null} > > unregisterListChangeListeners: > * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through > * {@link #registerListChangeListener(ObservableList, Consumer)}. If no consumers have been registered on this > * list, null will be returned. > > I find it confusing to say that the returned list "performs all removed operations". Some might interpret this to mean that is is somehow necessary to call the returned chained consumer as part of the removal, which isn't what you meant to say. > > How about something like this for both newly added unregister methods? > > * @return a composed consumer consisting of all previously registered consumers, or > * {@code null} if none have been registered or the observable is {@code null} @Kevin don't worry, I have seen your comment (and been thinking about it :) - but also can't find it right now (nor can I find Nir's comment which started the overhaul ..), no idea what happened. Seeing your suggestion, it's similar to what keeps running in my mind. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Thu Apr 1 15:12:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 15:12:13 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: <7RNOwM87fMcslFIFDFMxk6SQfs2x_7YKL5zaopEenk4=.09f1e9f4-6a72-44e5-8927-2ce31697745e@github.com> References: <7RNOwM87fMcslFIFDFMxk6SQfs2x_7YKL5zaopEenk4=.09f1e9f4-6a72-44e5-8927-2ce31697745e@github.com> Message-ID: On Thu, 1 Apr 2021 15:03:27 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 270: >> >>> 268: * may be {@code null} >>> 269: * @return a composed consumer that performs all removed operations, or >>> 270: * {@code null} if none have been registered or the observable is {@code null} >> >> Somehow my comment seems to have been deleted, so here it is again, slightly modified, along with a suggestion. >> >> I haven't gone back and done a detailed review yet, but I like the overall changes. The one thing I did notice is that the language used to describe the return value of `unregisterInvalidationListeners` and `unregisterListChangeListeners` is different: >> >> unregisterInvalidationListeners: >> * @return a composed consumer that performs all removed operations, or >> * {@code null} if none have been registered or the observable is {@code null} >> >> unregisterListChangeListeners: >> * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through >> * {@link #registerListChangeListener(ObservableList, Consumer)}. If no consumers have been registered on this >> * list, null will be returned. >> >> I find it confusing to say that the returned list "performs all removed operations". Some might interpret this to mean that is is somehow necessary to call the returned chained consumer as part of the removal, which isn't what you meant to say. >> >> How about something like this for both newly added unregister methods? >> >> * @return a composed consumer consisting of all previously registered consumers, or >> * {@code null} if none have been registered or the observable is {@code null} > > @Kevin > > don't worry, I have seen your comment (and been thinking about it :) - but also can't find it right now (nor can I find Nir's comment which started the overhaul ..), no idea what happened. > > Seeing your suggestion, it's similar to what keeps running in my mind. Maybe GitHub decided to prune it. ?? Btw, you tagged the wrong "Kevin" above. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From jgneff at openjdk.java.net Thu Apr 1 15:48:08 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 1 Apr 2021 15:48:08 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Wed, 31 Mar 2021 23:08:38 GMT, John Neffenger wrote: >> I recommend trying this with the following gradle flags, to match the settings for production builds: >> >> -PCONF=Release -PPROMOTED_BUILD_NUMBER=NNN -PHUDSON_BUILD_NUMBER=MMM -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true >> >> where `NNN` is the promoted build number that is being built (usually taken from the repo tag) and `MMM` is the CI build number. You can just pick any two positive numbers for your test builds. >> >> Note that this will build the native media libraries and the native webkit library. > >> I recommend trying this with the following gradle flags, to match the settings for production builds: > > Thanks, Kevin. Good news so far. I'm posting the Linux results while I run the macOS and Windows builds. > > #### Linux > > I ran the following commands twice, moving the `build` directory to `build1` and then `build2` to save their output: > > $ bash gradlew clean > $ bash gradlew -PCONF=Release -PPROMOTED_BUILD_NUMBER=5 \ > -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx \ > -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true \ > -PBUILD_LIBAV_STUBS=true sdk jmods javadoc > > Then I changed the Hudson job number with `-PHUDSON_BUILD_NUMBER=102`, ran the build a third time, and moved `build` to `build3`. I also ran `strip-nondeterminism` as shown in the first comment of this pull request. > > The first result is as hoped, and the second result is as expected: > > $ diff -qr build1 build2 > $ diff -qr build2 build3 > Files build2/jmods/javafx.base.jmod > and build3/jmods/javafx.base.jmod > differ > Files build2/modular-sdk/modules/javafx.base/com/sun/javafx/runtime/VersionInfo.class > and build3/modular-sdk/modules/javafx.base/com/sun/javafx/runtime/VersionInfo.class > differ > Files build2/modular-sdk/modules_src/javafx.base/com/sun/javafx/runtime/VersionInfo.java > and build3/modular-sdk/modules_src/javafx.base/com/sun/javafx/runtime/VersionInfo.java > differ > Files build2/publications/javafx.base-linux.jar > and build3/publications/javafx.base-linux.jar > differ > Files build2/sdk/lib/javafx.base.jar > and build3/sdk/lib/javafx.base.jar > differ > Files build2/sdk/lib/src.zip > and build3/sdk/lib/src.zip > differ > > You have to appreciate the irony of adding all this information to the build ? the time, the path, even the job number ? so that we can uniquely identify a build by its output. Meanwhile, if we didn't add this information, our builds could be uniquely identified by a single Git tag. There's good news and bad news. Good news first. #### macOS The two comparisons of the three builds on macOS were similar to those on Linux: $ diff -qr build1 build2 $ diff -qr build2 build3 Files build2/jmods/javafx.base.jmod and build3/jmods/javafx.base.jmod differ Files build2/modular-sdk/modules/javafx.base/com/sun/javafx/runtime/VersionInfo.class and build3/modular-sdk/modules/javafx.base/com/sun/javafx/runtime/VersionInfo.class differ Files build2/modular-sdk/modules_src/javafx.base/com/sun/javafx/runtime/VersionInfo.java and build3/modular-sdk/modules_src/javafx.base/com/sun/javafx/runtime/VersionInfo.java differ Files build2/publications/javafx.base-mac.jar and build3/publications/javafx.base-mac.jar differ Files build2/sdk/lib/javafx.base.jar and build3/sdk/lib/javafx.base.jar differ Files build2/sdk/lib/src.zip and build3/sdk/lib/src.zip differ #### Windows The Windows build, on the other hand, failed to produce identical copies of the media and WebKit shared libraries: $ diff -qr build1 build2 Files build1/jmods/javafx.media.jmod and build2/jmods/javafx.media.jmod differ Files build1/jmods/javafx.web.jmod and build2/jmods/javafx.web.jmod differ Files build1/modular-sdk/modules_libs/javafx.media/fxplugins.dll and build2/modular-sdk/modules_libs/javafx.media/fxplugins.dll differ Files build1/modular-sdk/modules_libs/javafx.media/glib-lite.dll and build2/modular-sdk/modules_libs/javafx.media/glib-lite.dll differ Files build1/modular-sdk/modules_libs/javafx.media/gstreamer-lite.dll and build2/modular-sdk/modules_libs/javafx.media/gstreamer-lite.dll differ Files build1/modular-sdk/modules_libs/javafx.media/jfxmedia.dll and build2/modular-sdk/modules_libs/javafx.media/jfxmedia.dll differ Files build1/modular-sdk/modules_libs/javafx.web/jfxwebkit.dll and build2/modular-sdk/modules_libs/javafx.web/jfxwebkit.dll differ Files build1/publications/javafx.media-win.jar and build2/publications/javafx.media-win.jar differ Files build1/publications/javafx.web-win.jar and build2/publications/javafx.web-win.jar differ Files build1/sdk/bin/fxplugins.dll and build2/sdk/bin/fxplugins.dll differ Files build1/sdk/bin/glib-lite.dll and build2/sdk/bin/glib-lite.dll differ Files build1/sdk/bin/gstreamer-lite.dll and build2/sdk/bin/gstreamer-lite.dll differ Files build1/sdk/bin/jfxmedia.dll and build2/sdk/bin/jfxmedia.dll differ Files build1/sdk/bin/jfxwebkit.dll and build2/sdk/bin/jfxwebkit.dll differ I didn't bother running the third build with `-PHUDSON_BUILD_NUMBER=102`. I assume CMake would be the same across platforms. I'm hoping it's just a missing `/experimental:deterministic` somewhere for the Windows linker. I'll track it down. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Thu Apr 1 16:53:11 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 1 Apr 2021 16:53:11 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Wed, 31 Mar 2021 13:59:12 GMT, Kevin Rushforth wrote: >>> I think there might be a Skara bug. >> >> No, no bug. Sorry about that. I just don't know how GitHub works. :frowning_face: The pre-submit tests ran two days ago when I pushed the branch to GitHub, so by the time I submitted the pull request, they had finished long ago. > > I recommend trying this with the following gradle flags, to match the settings for production builds: > > -PCONF=Release -PPROMOTED_BUILD_NUMBER=NNN -PHUDSON_BUILD_NUMBER=MMM -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true > > where `NNN` is the promoted build number that is being built (usually taken from the repo tag) and `MMM` is the CI build number. You can just pick any two positive numbers for your test builds. > > Note that this will build the native media libraries and the native webkit library. @kevinrushforth I found the Makefiles building the media libraries for Windows. I can fix those, but there's also `libxml` and `libxslt` that invoke the Windows linker here: modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/Makefile.msvc modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/win32/Makefile.msvc They both state at the top, "There should never be a need to modify anything below this line." Are those files directly from their upstream sources? If so, what's our policy on patching them while waiting for fixes? ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Thu Apr 1 17:25:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 17:25:09 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Thu, 1 Apr 2021 16:50:31 GMT, John Neffenger wrote: >> I recommend trying this with the following gradle flags, to match the settings for production builds: >> >> -PCONF=Release -PPROMOTED_BUILD_NUMBER=NNN -PHUDSON_BUILD_NUMBER=MMM -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true >> >> where `NNN` is the promoted build number that is being built (usually taken from the repo tag) and `MMM` is the CI build number. You can just pick any two positive numbers for your test builds. >> >> Note that this will build the native media libraries and the native webkit library. > > @kevinrushforth I found the Makefiles building the media libraries for Windows. I can fix those, but there's also `libxml` and `libxslt` that invoke the Windows linker here: > > modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/Makefile.msvc > modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/win32/Makefile.msvc > > They both state at the top, "There should never be a need to modify anything below this line." Are those files directly from their upstream sources? If so, what's our policy on patching them while waiting for fixes? The WebKit build is complicated (to say the least). All of the WebKit components, including the additional third-party dependencies in `/Source/ThirdParty`, are built using cmake. I think any changes would involve passing flags to cmake in `build.gradle`. @arun-Joseph might be able to comment on that. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Thu Apr 1 17:36:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 17:36:16 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Thu, 1 Apr 2021 17:22:16 GMT, Kevin Rushforth wrote: >> @kevinrushforth I found the Makefiles building the media libraries for Windows. I can fix those, but there's also `libxml` and `libxslt` that invoke the Windows linker here: >> >> modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/Makefile.msvc >> modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/win32/Makefile.msvc >> >> They both state at the top, "There should never be a need to modify anything below this line." Are those files directly from their upstream sources? If so, what's our policy on patching them while waiting for fixes? > > The WebKit build is complicated (to say the least). All of the WebKit components, including the additional third-party dependencies in `/Source/ThirdParty`, are built using cmake. I think any changes would involve passing flags to cmake in `build.gradle`. > > @arun-Joseph might be able to comment on that. I should add that if changes are needed to the `Makefile.msvc` files to accept extra link flags to be passed in, then it would be fine to modify them. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From ajoseph at openjdk.java.net Thu Apr 1 17:48:08 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 1 Apr 2021 17:48:08 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Thu, 1 Apr 2021 17:33:35 GMT, Kevin Rushforth wrote: >> The WebKit build is complicated (to say the least). All of the WebKit components, including the additional third-party dependencies in `/Source/ThirdParty`, are built using cmake. I think any changes would involve passing flags to cmake in `build.gradle`. >> >> @arun-Joseph might be able to comment on that. > > I should add that if changes are needed to the `Makefile.msvc` files to accept extra link flags to be passed in, then it would be fine to modify them. It would be better to add the flag in `libxml/CMakeLists.txt` or in `build.gradle` via `cmakeArgs`. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Thu Apr 1 17:53:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 17:53:12 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Thu, 1 Apr 2021 17:44:58 GMT, Arun Joseph wrote: >> I should add that if changes are needed to the `Makefile.msvc` files to accept extra link flags to be passed in, then it would be fine to modify them. > > It would be better to add the flag in `libxml/CMakeLists.txt` or in `build.gradle` via `cmakeArgs`. Ideally the latter, if feasible, so that the logic to handle `SOURCE_DATE_EPOCH` is more localized. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Thu Apr 1 19:14:37 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 1 Apr 2021 19:14:37 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2] 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 incrementally with one additional commit since the last revision: 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 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/446/files - new: https://git.openjdk.java.net/jfx/pull/446/files/ad46dc38..afeb3fe0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=00-01 Stats: 25 lines in 4 files changed: 22 ins; 0 del; 3 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 github.com+637990+bmwiedemann at openjdk.java.net Thu Apr 1 19:41:16 2021 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Thu, 1 Apr 2021 19:41:16 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: <1_0-ppU3gW2x-JNM2e1ZdM1UCQOffdDnIuGCDkPIwpo=.5def9e21-9d4e-4615-8d37-f5213f8ed3b5@github.com> On Thu, 1 Apr 2021 17:50:47 GMT, Kevin Rushforth wrote: >> It would be better to add the flag in `libxml/CMakeLists.txt` or in `build.gradle` via `cmakeArgs`. > > Ideally the latter, if feasible, so that the logic to handle `SOURCE_DATE_EPOCH` is more localized. IMHO, it would make sense to merge any clear improvement of the status-quo and debug+fix more in a later PR. "Perfect is the enemy of good." Regarding Webkit, I know of https://bugs.webkit.org/show_bug.cgi?id=174540 https://bugs.webkit.org/show_bug.cgi?id=188738 https://build.opensuse.org/request/show/667729 but your version is probably not *that* old. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Thu Apr 1 20:10:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 20:10:13 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: <1_0-ppU3gW2x-JNM2e1ZdM1UCQOffdDnIuGCDkPIwpo=.5def9e21-9d4e-4615-8d37-f5213f8ed3b5@github.com> References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> <1_0-ppU3gW2x-JNM2e1ZdM1UCQOffdDnIuGCDkPIwpo=.5def9e21-9d4e-4615-8d37-f5213f8ed3b5@github.com> Message-ID: <8LjRGoYm31KbRmlMFaj-_6gU9oVmUrpEz6YKKYce9NI=.fa612b1d-421f-425c-91dd-291ae9d130bc@github.com> On Thu, 1 Apr 2021 19:38:18 GMT, Bernhard M. Wiedemann wrote: >> Ideally the latter, if feasible, so that the logic to handle `SOURCE_DATE_EPOCH` is more localized. > > IMHO, it would make sense to merge any clear improvement of the status-quo and debug+fix more in a later PR. "Perfect is the enemy of good." > > Regarding Webkit, I know of > https://bugs.webkit.org/show_bug.cgi?id=174540 > https://bugs.webkit.org/show_bug.cgi?id=188738 > https://build.opensuse.org/request/show/667729 > but your version is probably not *that* old. Given the level of effort to test this, I would recommend minimizing the number of separate fixes for this enhancement. If WebKit turns out to be too big a can of worms, then it might make sense to do everything else with this fix and file a follow-on for WebKit. > Regarding Webkit...but your version is probably not that old. Right, we aren't nearly that old. We just updated WebKit a little over 2 months ago with recent sources (we update WebKit every six months). ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jpereda at openjdk.java.net Thu Apr 1 20:17:07 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 1 Apr 2021 20:17:07 GMT Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: <75_kkdXsJ_j-xQ59icTOdZQlm2uOGdpa63J7cLOMabc=.e3a47368-bf1a-4e02-a95b-617f558469e1@github.com> References: <5E9pnxme_BB3V0mKbjtppP-pAGvE05e5CCyA6Mt8DXM=.d148de57-434e-438d-85bd-e4d8e6ab4686@github.com> <75_kkdXsJ_j-xQ59icTOdZQlm2uOGdpa63J7cLOMabc=.e3a47368-bf1a-4e02-a95b-617f558469e1@github.com> Message-ID: <9zUM0CSE0GugrbMbfeRg4iUxewMrMSvh_k9LwEHRaAo=.0f91929c-9c01-46c3-91cd-4e3a94d6d6e1@github.com> On Thu, 25 Mar 2021 03:17:37 GMT, Hsiafan wrote: >> I'll review this. The fix seems fine at first glance. With your patch it uses a similar mechanism to the attributed string case; I'm curious why copying the string is needed in that case, but not in this case. >> >> What testing have you done to ensure that this will not cause any regressions? >> >> Perhaps @prrace or @jperedadnr or @johanvos could be a second reviewer? > > I've test on macOS 11.2.3 with Chinese input method, including ascii chars, CJK chars, emojis, and inputing ascii/cjk chars+emojis together. All works as expected. > > The memory allocation in NSAttributedString could be eliminated either, AFAIK. I haven't tested it, do not know how to input a NSAttributedString. As mentioned earlier, the fix works fine for me on macOS 10.15.6. About the case of `NSAttributedString`, yes it could be refactored too. However, I couldn't test it either, as I'm not sure how we could get "rich text" typed into a JavaFX input control. In any case, maybe it is better to do it in a follow-up issue? ------------- PR: https://git.openjdk.java.net/jfx/pull/436 From jgneff at openjdk.java.net Thu Apr 1 20:21:07 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 1 Apr 2021 20:21:07 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: <1_0-ppU3gW2x-JNM2e1ZdM1UCQOffdDnIuGCDkPIwpo=.5def9e21-9d4e-4615-8d37-f5213f8ed3b5@github.com> References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> <1_0-ppU3gW2x-JNM2e1ZdM1UCQOffdDnIuGCDkPIwpo=.5def9e21-9d4e-4615-8d37-f5213f8ed3b5@github.com> Message-ID: On Thu, 1 Apr 2021 19:38:18 GMT, Bernhard M. Wiedemann wrote: > IMHO, it would make sense to merge any clear improvement of the status-quo and debug+fix more in a later PR. I agree that we will have to draw the line somewhere, but right now I'm down to just one file on one operating system out of 10,633 files in the build output! (It's just `jfxwebkit.dll` on Windows.) It would be a shame to give up now. I would, though, like to postpone tests of static builds and builds for Android and iOS. My priorities for this pull request are: 1. Linux distributions building JavaFX 2. Developers building JavaFX from the repository source with the build defaults 3. Oracle, Gluon, and BellSoft building JavaFX for their customers and for downloading I would be happy to satisfy just the first group, but we might be close to getting all three. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Thu Apr 1 20:22:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 20:22:18 GMT Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: <9zUM0CSE0GugrbMbfeRg4iUxewMrMSvh_k9LwEHRaAo=.0f91929c-9c01-46c3-91cd-4e3a94d6d6e1@github.com> References: <5E9pnxme_BB3V0mKbjtppP-pAGvE05e5CCyA6Mt8DXM=.d148de57-434e-438d-85bd-e4d8e6ab4686@github.com> <75_kkdXsJ_j-xQ59icTOdZQlm2uOGdpa63J7cLOMabc=.e3a47368-bf1a-4e02-a95b-617f558469e1@github.com> <9zUM0CSE0GugrbMbfeRg4iUxewMrMSvh_k9LwEHRaAo=.0f91929c-9c01-46c3-91cd-4e3a94d6d6e1@github.com> Message-ID: On Thu, 1 Apr 2021 20:13:56 GMT, Jose Pereda wrote: >> I've test on macOS 11.2.3 with Chinese input method, including ascii chars, CJK chars, emojis, and inputing ascii/cjk chars+emojis together. All works as expected. >> >> The memory allocation in NSAttributedString could be eliminated either, AFAIK. I haven't tested it, do not know how to input a NSAttributedString. > > As mentioned earlier, the fix works fine for me on macOS 10.15.6. > > About the case of `NSAttributedString`, yes it could be refactored too. However, I couldn't test it either, as I'm not sure how we could get "rich text" typed into a JavaFX input control. In any case, maybe it is better to do it in a follow-up issue? Yeah, I don't recommend doing anything for the attributed string case. It's a largely-unrelated change that I only mentioned earlier because I noticed that the new code was different in that regard. If we do anything at all with the attributed string case, it would definitely want to be done in a follow-up issue (and I don't really see a need to do anything). ------------- PR: https://git.openjdk.java.net/jfx/pull/436 From jpereda at openjdk.java.net Thu Apr 1 20:27:15 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 1 Apr 2021 20:27:15 GMT Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 04:13:48 GMT, Hsiafan wrote: > The convertNSStringToJString function convert NSString to Java String using NewStringUTF?NewStringUTF accept modified-UTF8 encoded str?This fix using UTF-16 encoding for converting. Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/436 From kcr at openjdk.java.net Thu Apr 1 20:45:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 20:45:08 GMT Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 04:13:48 GMT, Hsiafan wrote: > The convertNSStringToJString function convert NSString to Java String using NewStringUTF?NewStringUTF accept modified-UTF8 encoded str?This fix using UTF-16 encoding for converting. Looks good to me. I can confirm the exception prior to the fix, and that it works after the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/436 From kcr at openjdk.java.net Thu Apr 1 21:29:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 21:29:09 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> <1_0-ppU3gW2x-JNM2e1ZdM1UCQOffdDnIuGCDkPIwpo=.5def9e21-9d4e-4615-8d37-f5213f8ed3b5@github.com> Message-ID: <2roPp8v4ktoIbW2a8U5GdxEEUSJ9-366AZkxM20dlHA=.5b9a5e61-130d-4330-9c73-022417209f72@github.com> On Thu, 1 Apr 2021 20:18:03 GMT, John Neffenger wrote: >> IMHO, it would make sense to merge any clear improvement of the status-quo and debug+fix more in a later PR. "Perfect is the enemy of good." >> >> Regarding Webkit, I know of >> https://bugs.webkit.org/show_bug.cgi?id=174540 >> https://bugs.webkit.org/show_bug.cgi?id=188738 >> https://build.opensuse.org/request/show/667729 >> but your version is probably not *that* old. > >> IMHO, it would make sense to merge any clear improvement of the status-quo and debug+fix more in a later PR. > > I agree that we will have to draw the line somewhere, but right now I'm down to just one file on one operating system out of 10,633 files in the build output! (It's just `jfxwebkit.dll` on Windows.) It would be a shame to give up now. > > I would, though, like to postpone tests of static builds and builds for Android and iOS. My priorities for this pull request are: > > 1. Linux distributions building JavaFX > 2. Developers building JavaFX from the repository source with the build defaults > 3. Oracle, Gluon, and BellSoft building JavaFX for their customers and for downloading > > I would be happy to satisfy just the first group, but we might be close to getting all three. @sashamatveev Can you look at the changes to the media Makefiles? ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From almatvee at openjdk.java.net Thu Apr 1 23:17:58 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 1 Apr 2021 23:17:58 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 [v2] In-Reply-To: References: Message-ID: > - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 > - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: Updated .md files and added missing include files ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/447/files - new: https://git.openjdk.java.net/jfx/pull/447/files/341eb765..77640795 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=447&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=447&range=00-01 Stats: 14 lines in 4 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/447.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/447/head:pull/447 PR: https://git.openjdk.java.net/jfx/pull/447 From almatvee at openjdk.java.net Thu Apr 1 23:25:17 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 1 Apr 2021 23:25:17 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 19:14:37 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 incrementally with one additional commit since the last revision: > > 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 Media makefiles look fine. ------------- Marked as reviewed by almatvee (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Thu Apr 1 23:26:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 23:26:10 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> Message-ID: On Wed, 31 Mar 2021 14:09:40 GMT, Kevin Rushforth wrote: >>> Are all of them actually needed? >> >> Just to follow up on that question, all of them are in fact downloaded during the build, at least. I removed the Gradle directory `$HOME/.gradle` and ran the build as follows. Then I compared the list of downloaded artifacts with the ones listed in the dependency verification file. >> >> $ rm -r $HOME/.gradle >> $ bash gradlew sdk jmods javadoc apps test -x :web:test >> ... >> $ find ~/.gradle/caches/modules-2 ( -name "*.jar" -o -name "*.pom" ) \ >> -exec basename {} ; | sort > downloaded.log >> $ grep '/\1/' \ >> | sort > verified.log >> $ diff downloaded.log verified.log >> 31a32 >>> org.eclipse.swt.cocoa.macosx.x86_64_3.105.3.v20170228-0512-.jar >> 32a34 >>> org.eclipse.swt.win32.win32.x86_64_3.105.3.v20170228-0512-.jar >> >> A total of 36 artifacts (14 JAR files and 22 POM files) are downloaded during the build. The SWT libraries for macOS and Windows were not downloaded because I ran the build on Linux. > > We have a few in-flight or imminent updates that will impact this PR. There is a tight deadline on one of them (an ICU data file dependency), so I'd prefer to wait on integrating this until after they are done. > > It's still worth continuing the review in the mean time. I noticed that the libav bundles are missing on Linux. To ensure that you aren't missing any dependencies, can you add the following gradle flags to your build? > > -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true > > This will build the native media libraries, including the libav stubs (the latter is Linux only). Eventually, you will need to include WebKit, but that's not needed for now. When you build media with libav stubs on Linux, you should see the following 5 new entries: ffmpeg-3.3.3-.tar.gz ffmpeg-4.0.2-.tar.gz libav-11.4-.tar.gz libav-12.1-.tar.gz libav-9.14-.tar.gz And I was right about the additional internal tools that I would need to add. Here is the list: cmake-3.13.3-Darwin-x86_64.tar.gz cmake-3.13.3-Linux-x86_64.tar.gz cmake-3.13.3-win32-x86.zip devkit-linux_x64-gcc10.2.0-OL6.4+1.0.tar.gz devkit-macosx_x64-Xcode11.3.1-MacOSX10.15+1.0.tar.gz devkit-windows_x64-VS2019-16.7.2+1.0.tar.gz jfx-devkit-gcc-patch+1.1.tar.gz ninja-win.zip When you build media with libav stubs on Linux, you should see the following 5 new entries: ffmpeg-3.3.3-.tar.gz ffmpeg-4.0.2-.tar.gz libav-11.4-.tar.gz libav-12.1-.tar.gz libav-9.14-.tar.gz And I was right about the additional tools that I would need to add (as a bonus I found an unused tool that I will eliminate). Here is the list: cmake-3.13.3-Darwin-x86_64.tar.gz cmake-3.13.3-Linux-x86_64.tar.gz cmake-3.13.3-win32-x86.zip devkit-linux_x64-gcc10.2.0-OL6.4+1.0.tar.gz devkit-macosx_x64-Xcode11.3.1-MacOSX10.15+1.0.tar.gz devkit-windows_x64-VS2019-16.7.2+1.0.tar.gz jfx-devkit-gcc-patch+1.1.tar.gz ninja-win.zip And here is one that will show up after PR #450 is integrated: icudt-64l.zip And here is one that will show up after PR #450 is integrated: icudt-64l.zip ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From kcr at openjdk.java.net Thu Apr 1 23:35:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 23:35:18 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> Message-ID: On Thu, 1 Apr 2021 23:23:37 GMT, Kevin Rushforth wrote: >> We have a few in-flight or imminent updates that will impact this PR. There is a tight deadline on one of them (an ICU data file dependency), so I'd prefer to wait on integrating this until after they are done. >> >> It's still worth continuing the review in the mean time. I noticed that the libav bundles are missing on Linux. To ensure that you aren't missing any dependencies, can you add the following gradle flags to your build? >> >> -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true >> >> This will build the native media libraries, including the libav stubs (the latter is Linux only). Eventually, you will need to include WebKit, but that's not needed for now. > > When you build media with libav stubs on Linux, you should see the following 5 new entries: > > ffmpeg-3.3.3-.tar.gz > ffmpeg-4.0.2-.tar.gz > libav-11.4-.tar.gz > libav-12.1-.tar.gz > libav-9.14-.tar.gz > > And I was right about the additional internal tools that I would need to add. Here is the list: > > cmake-3.13.3-Darwin-x86_64.tar.gz > cmake-3.13.3-Linux-x86_64.tar.gz > cmake-3.13.3-win32-x86.zip > devkit-linux_x64-gcc10.2.0-OL6.4+1.0.tar.gz > devkit-macosx_x64-Xcode11.3.1-MacOSX10.15+1.0.tar.gz > devkit-windows_x64-VS2019-16.7.2+1.0.tar.gz > jfx-devkit-gcc-patch+1.1.tar.gz > ninja-win.zip > > When you build media with libav stubs on Linux, you should see the following 5 new entries: > > ffmpeg-3.3.3-.tar.gz > ffmpeg-4.0.2-.tar.gz > libav-11.4-.tar.gz > libav-12.1-.tar.gz > libav-9.14-.tar.gz > > And I was right about the additional tools that I would need to add (as a bonus I found an unused tool that I will eliminate). Here is the list: > > cmake-3.13.3-Darwin-x86_64.tar.gz > cmake-3.13.3-Linux-x86_64.tar.gz > cmake-3.13.3-win32-x86.zip > devkit-linux_x64-gcc10.2.0-OL6.4+1.0.tar.gz > devkit-macosx_x64-Xcode11.3.1-MacOSX10.15+1.0.tar.gz > devkit-windows_x64-VS2019-16.7.2+1.0.tar.gz > jfx-devkit-gcc-patch+1.1.tar.gz > ninja-win.zip > > And here is one that will show up after PR #450 is integrated: > > icudt-64l.zip > > > And here is one that will show up after PR #450 is integrated: > > icudt-64l.zip When you build media with libav stubs on Linux, you should see the following 5 new entries: ffmpeg-3.3.3-.tar.gz ffmpeg-4.0.2-.tar.gz libav-11.4-.tar.gz libav-12.1-.tar.gz libav-9.14-.tar.gz I'll let you add them. And I was right about the additional internal tools that I would need to add. Here is the list: cmake-3.13.3-Darwin-x86_64.tar.gz cmake-3.13.3-Linux-x86_64.tar.gz cmake-3.13.3-win32-x86.zip devkit-linux_x64-gcc10.2.0-OL6.4+1.0.tar.gz devkit-macosx_x64-Xcode11.3.1-MacOSX10.15+1.0.tar.gz devkit-windows_x64-VS2019-16.7.2+1.0.tar.gz jfx-devkit-gcc-patch+1.1.tar.gz ninja-win.zip I'll provide the sha256 sums once I've tested this (probably next week). Speaking of which, we will do a compiler update shortly after JDK 17 does theirs (should be pretty soon for Mac and Windows anyway), which will update the devkits. (as a bonus I found an unused tool that I will eliminate) And here is one more for WebKit that will show up after PR #450 is integrated: icudt-64l.zip This, and then its successor when we update ICU, are the main reason I want to hold off on this for 2-3 more weeks. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From kcr at openjdk.java.net Thu Apr 1 23:50:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 23:50:13 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: References: <_vdajZtvbKmn0FvI8owNTnAby4DBnupiq9fiHkod6Ew=.51940492-315c-408e-9a45-514f2c2413ca@github.com> Message-ID: On Thu, 1 Apr 2021 12:19:40 GMT, Kevin Rushforth wrote: >> Alexander tried it on our CI build machine yesterday and it builds fine there, too. I should add that I was building on a very old Ubuntu 16.04 system. >> >>> Since this PR introduces memset in the audio-buffer.c file, I think it is safest to include string.h in this file as well, as this removes the dependency on that file to be included indirectly. >> >> I was thinking the same thing. There is one more file that should include ``: `qtdemux_tags.c` uses `strlen`and fails to compile on my system. With the change to include `string.h` in those two files, the build now passes on my system. > > All my testing looks good on all three platforms. I'll take a look at the diffs next. > > One thing I did spot is that you need to update `gstreamer.md` and `glib.md` to bump the version numbers. It now builds for me on my old Linux box. And the changes to the /legal/ files looks good. One more thing I just thought of: we should do a test build on macOS aarch64. I have no reason to believe that there will be a problem, but worth double-checking. ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From github.com+66004280+maran23 at openjdk.java.net Thu Apr 1 23:53:14 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Thu, 1 Apr 2021 23:53:14 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2Oi qSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com> Message-ID: On Thu, 10 Sep 2020 15:49:59 GMT, yosbits wrote: >> @yososs Please file a new JBS issue for this. You will need to prove that your proposed change is functionally equivalent (or that any perceived changes are incidental and still conform to the spec). You should also think about whether your proposed change needs additional tests. > > Because it is such a small correction > Problem from me I feel that it is not easy to register, but I will try to register. > > It has passed two existing tests for compatibility: > > * gradle base:test > * gradle controls:test > > I have just reported it as an enhancement proposal. Any news for this PR? Can I help somewhere? ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From nlisker at gmail.com Fri Apr 2 06:47:44 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 2 Apr 2021 09:47:44 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> Message-ID: Hi John, I've had my eyes set on ReactFX enhancements for a while too, especially as a replacement for the unsafe "select" mechanism. One of the things that kept me from going forward with this is seeing what Valhalla will bring. Generic specialization might save a lot of duplication work on something like this, and Tomas touched another related issue [1], but since it could be a long time before that happens, it's worth planning what we can extract from ReactFX currently. I think that we should break the enhancements into parts. The first that I would advise to look at are the additions to properties/observables. Tomas had to create Val and Var because he couldn't change the core interfaces, but we can. Fitting them with the Optional methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. `flatMap` etc.; and `select` and friends, is already a good start that will address many common requirements. The second part is related to listeners. The subscription model and event streams try to solve the memory issues with hard and weak references, and allow better composition. The third part is for collections - things like transformation lists (LiveList) and for other collections. Since these share behavior under the hood, we need to look ahead, but in terms of functionality, I think we should take smaller steps. It will also be easier to propose these then. - Nir [1] https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx wrote: > I just wanted to draw some attention to a recent proof of concept I made > in this pull request: https://github.com/openjdk/jfx/pull/434 > > It is based on the work I did in > https://github.com/hjohn/hs.jfx.eventstream which is in part based on > work done in ReactFX by Tomas Mikula. The PR itself however shares no > code with ReactFX and is > completely written by me. > > If there is interest, I'm willing to invest more time in smoothing out > the API and documentation, investigating further how this would interact > with the primitive types and adding unit test coverage (I have extensive > tests, but thesea are written in JUnit 5, so they would require > conversion or JavaFX could move to support JUnit 5). > > What follows below is the text of the PR for easy reading. Feedback is > appreciated. > > ================ > > This is a proof of concept of how fluent bindings could be introduced to > JavaFX. The main benefit of fluent bindings are ease of use, type safety > and less surprises. Features: > > Flexible Mappings > Map the contents of a property any way you like with map, or map nested > properties with flatMap. > > Lazy > The bindings created are lazy, which means they are always invalid when > not themselves observed. This allows for easier garbage collection (once > the last observer is removed, a chain of bindings will stop observing > their parents) and less listener management when dealing with nested > properties. Furthermore, this allows inclusion of such bindings in > classes such as Node without listeners being created when the binding > itself is not used (this would allow for the inclusion of a > treeShowingProperty in Node without creating excessive listeners, see > this fix I did in an earlier PR: #185) > > Null Safe > The map and flatMap methods are skipped, similar to java.util.Optional > when the value they would be mapping is null. This makes mapping nested > properties with flatMap trivial as the null case does not need to be > taken into account in a chain like this: > node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). > > Instead a default can be provided with orElse or orElseGet. > > Conditional Bindings > Bindings can be made conditional using the conditionOn method. A > conditional binding retains its last value when its condition is false. > Conditional bindings donot observe their source when the condition is > false, allowing developers to automatically stop listening to properties > when a certain condition is met. A major use of this feature is to have > UI components that need to keep models updated which may outlive the UI > conditionally update the long lived model only when the UI is showing. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> > text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > > label.textProperty().bind(text.length().negate().add(100).asString().concat(" > > characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + > " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), > "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > void updateLongLivedModelWhileAvoidingMemoryLeaks() { > // Standard JavaFX: naive, memory leak; UI won't get garbage collected > listView.getSelectionModel().selectedItemProperty().addListener( > (obs, old, current) -> > longLivedModel.lastSelectedProperty().set(current) > ); > > // Standard JavaFX: no leak, but stops updating after a while > listView.getSelectionModel().selectedItemProperty().addListener( > new WeakChangeListener<>( > (obs, old, current) -> > longLivedModel.lastSelectedProperty().set(current) > ) > ); > > // Standard JavaFX: fixed version > listenerReference = (obs, old, current) -> > longLivedModel.lastSelectedProperty().set(current); > > listView.getSelectionModel().selectedItemProperty().addListener( > new WeakChangeListener<>(listenerReference) > ); > > // Fluent: naive, memory leak... fluent won't solve this... > listView.getSelectionModel().selectedItemProperty() > .subscribe(longLivedModel.lastSelectedProperty()::set); > > // Fluent: conditional update when control visible > > // Create a property which is only true when the UI is visible: > ObservableValue showing = listView.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false); > > // Use showing property to automatically disconnect long lived model > // allowing garbage collection of the UI: > listView.getSelectionModel().selectedItemProperty() > .conditionOn(showing) > .subscribe(longLivedModel.lastSelectedProperty()::set); > > // Note that the 'showing' property can be provided in multiple ways: > // - create manually (can be re-used for multiple bindings though) > // - create with a helper: Nodes.showing(Node node) -> > ObservableValue > // - make it part of the Node class; as the fluent bindings only bind > themselves > // to their source when needed (lazy binding), this won't create > overhead > // for each node in the scene > } > Note that this is based on ideas in ReactFX and my own experiments in > https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion > that this is much better directly integrated into JavaFX, and I'm hoping > this proof of concept will be able to move such an effort forward. > > --John > From github.com+7517141+yososs at openjdk.java.net Fri Apr 2 10:48:18 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 2 Apr 2021 10:48:18 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2Oi qSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com> Message-ID: <_mKtK6hkxEdctEMw2vAIys2-CYjTKyJ6GNJRhw2frzU=.3763bf2e-5253-4b5c-a188-b92edff1fc12@github.com> On Thu, 1 Apr 2021 23:50:12 GMT, Marius Hanl wrote: >> Because it is such a small correction >> Problem from me I feel that it is not easy to register, but I will try to register. >> >> It has passed two existing tests for compatibility: >> >> * gradle base:test >> * gradle controls:test >> >> I have just reported it as an enhancement proposal. > > Any news for this PR? Can I help somewhere? It seems that performance improvement PR often needs to make up for the lack of existing unit tests. However, this addition of unit tests should not be included in the same PR as it needs to be tested to meet the specifications before and after the change. **I think we need a step to fix the lack of unit tests before the performance improvement patch.** And care must be taken not to rely on internal implementations for this unit test so as not to hinder performance improvement. Some existing unit test code depends on the internal implementation, so some test changes may be needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+1498664+hsiafan at openjdk.java.net Fri Apr 2 11:34:10 2021 From: github.com+1498664+hsiafan at openjdk.java.net (Hsiafan) Date: Fri, 2 Apr 2021 11:34:10 GMT Subject: Integrated: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 04:13:48 GMT, Hsiafan wrote: > The convertNSStringToJString function convert NSString to Java String using NewStringUTF?NewStringUTF accept modified-UTF8 encoded str?This fix using UTF-16 encoding for converting. This pull request has now been integrated. Changeset: 052e9f7d Author: dongliu Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/052e9f7d Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8258381: [macos] Exception when input emoji using Chinese input method Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/436 From ebresie at gmail.com Fri Apr 2 13:20:34 2021 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 2 Apr 2021 08:20:34 -0500 Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: 2roPp8v4ktoIbW2a8U5GdxEEUSJ9-366AZkxM20dlHA=.5b9a5e61-130d-4330-9c73-022417209f72@github.com References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> <1_0-ppU3gW2x-JNM2e1ZdM1UCQOffdDnIuGCDkPIwpo=.5def9e21-9d4e-4615-8d37-f5213f8ed3b5@github.com> nb-UJDQlpJim7husAz4aqI9ndyKX04UbGUL0U4g4-FQ=.fae6882d-d6f5-43c6-abe6-7cf3fc5ca858@github.com Message-ID: <314dc7f8-fbbd-4779-bb3c-159f9e1be791@Erics-iPhone-12-Pro-Max> Silly question, is the difference with Windows just the nature of the native support on each platform (Unix based vs Windows) and libraries used as part of that? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On April 1, 2021 at 4:29:09 PM CDT, Kevin Rushforth wrote: > On Thu, 1 Apr 2021 20:18:03 GMT, John Neffenger wrote: > > > > IMHO, it would make sense to merge any clear improvement of the status-quo and debug+fix more in a later PR. "Perfect is the enemy of good." > > > > > > Regarding Webkit, I know of > > > https://bugs.webkit.org/show_bug.cgi?id=174540 > > > https://bugs.webkit.org/show_bug.cgi?id=188738 > > > https://build.opensuse.org/request/show/667729 > > > but your version is probably not *that* old. > > > > > IMHO, it would make sense to merge any clear improvement of the status-quo and debug+fix more in a later PR. > > > > I agree that we will have to draw the line somewhere, but right now I'm down to just one file on one operating system out of 10,633 files in the build output! (It's just `jfxwebkit.dll` on Windows.) It would be a shame to give up now. > > > > I would, though, like to postpone tests of static builds and builds for Android and iOS. My priorities for this pull request are: > > > > 1. Linux distributions building JavaFX > > 2. Developers building JavaFX from the repository source with the build defaults > > 3. Oracle, Gluon, and BellSoft building JavaFX for their customers and for downloading > > > > I would be happy to satisfy just the first group, but we might be close to getting all three. > > @sashamatveev Can you look at the changes to the media Makefiles? > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/446 From kevin.rushforth at oracle.com Fri Apr 2 14:51:14 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 2 Apr 2021 07:51:14 -0700 Subject: [External] : Re: Consistent baseline layout algorithm In-Reply-To: References: <7de4d41d-e341-0b6d-2e54-15c5b905c383@oracle.com> Message-ID: <97e36c88-838d-e931-4c21-d15a55bf39d3@oracle.com> Circling back to this: Do any JavaFX application developers on this list have any thoughts? I think this is a good idea, and it seems worth moving this forward, but it will require a fair bit of effort. I'd like to hear buy-in from other developers -- particularly those who develop or use custom controls. A few additional comments: * Regarding the threshold, I like the idea of logging at a fine (or finer) level if it goes beyond a smaller number, say 3 or 4, passes, but continuing further to iterate. I wonder if 100 might be too large for the default limit, though. It seems likely that the control is unstable and will never converge if it gets to that many layout passes. If there were a way to analyze what a reasonable limit is that would be better (if not, we can probably live with a fairly high value, if it really is an unlikely pathological case). Assuming a reasonably high threshold, logging at a warning level would be good if it doesn't converge. * Documentation: I do think we will want to document the overall concept of layout needing multiple passes to converge in some cases, along with documenting the threshold. I also think that Node::getBaselineOffset should mention the preference of text nodes. The concept of "text" nodes needs to be on Node, if for no other reason than that Text doesn't inherit from Parent. * This will need to be very well tested, both to ensure no regressions in behavior, and with many new tests added to validate the new functionality, including testing the threshold logic. -- Kevin On 3/20/2021 6:42 AM, Michael Strau? wrote: > 1) Pathological cases: So far, I haven't been able to produce > pathological cases that exceed 3 layout passes by using standard > layout containers and controls. If we need to have a threshold > substantially higher than that depends on whether or not there are > indeed legitimate cases where some kind of layout requires more passes > to converge. Maybe we could log at a very fine level when a control > takes more than 3 passes to converge, but still continue processing up > to a substantially higher number of passes. This would allow > developers to debug and optimize their custom controls, but still > produce a valid solution if a particular control is generally stable, > but just very poorly optimized. > > 2) I believe that the multi-pass layout algorithm shouldn't need > additional documentation since it could be considered an > implementation detail. There is no 1:1 correspondence between pulses > and layout passes currently, and there won't be with the new > algorithm. Also, any layout pass with the current algorithm can > potentially trigger another layout pass, so that's not fundamentally > different either. For control authors, we might need to document that > it is generally okay to rely on circular dependencies between size > hints, baseline offset and child nodes, as long as those dependencies > allow the layout to settle. The fact that text nodes are preferred > with respect to baseline computation is documented in > Parent.getBaselineOffset(), maybe Node.getBaselineOffset() should also > mention this. We might also add a section on baseline computation to > the javafx.scene.layout package documentation, where I think it is > most relevant (and currently entirely undocumented). > > 3) New API on Node: in order for this idea to work, there needs to be > an abstract concept of "text node". Since the "baseline" concept is > introduced on Node, I thought this would also be the appropriate place > to introduce the "text node" concept; however, it could also be > introduced on Parent instead. Note that the "text node" concept is > introduced at a lower level than actual text controls like Labeled, > because layout containers (which are not controls) need this > information. Also, the definition of what constitutes "text" is left > to control authors. In a very contrived example, a control might > display an image, but declare itself to be "text". > > > > Am Fr., 19. M?rz 2021 um 23:26 Uhr schrieb Kevin Rushforth > : >> I'd be interested to hear from app developers on this list. >> >> Here are a few quick thoughts I have. >> >> As you note, this is a long-standing problem with layout in FX. You >> mention in the performance considerations that for most cases this will >> iterate quickly. It would be interesting to know what some of the corner >> cases are, so we can see how bad the pathological case will be. I see >> that you propose to iterate up to 100 times. Maybe a lower threshold >> would be better? We already run layout passes 3 times in many cases. So >> also running 3 (or maybe 4 or 5) times seems reasonable, especially when >> your testing shows that most of the time it converges in <= 2 passes. So >> a smaller threshold than 100 would seem to make sense. If a control >> doesn't converge, you might consider logging it (in case an app >> developer wants to debug it) perhaps at a "fine" level so it isn't shown >> by default. >> >> How do you propose to document this behavioral change -- not so much the >> fact that it will (usually) get the right answer now instead of the >> wrong one, but more about the multi-pass nature of it, and the fact that >> nodes with text will be "preferred". Related to that, how necessary is a >> new public API on Node? >> >> -- Kevin >> From swpalmer at gmail.com Fri Apr 2 15:29:31 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 2 Apr 2021 11:29:31 -0400 Subject: [External] : Re: Consistent baseline layout algorithm In-Reply-To: <97e36c88-838d-e931-4c21-d15a55bf39d3@oracle.com> References: <97e36c88-838d-e931-4c21-d15a55bf39d3@oracle.com> Message-ID: <48E4876A-0F8A-428B-A20D-75AC57E1332F@gmail.com> I haven?t done much in terms of custom controls, but I do see this issue a lot in my primary application. It would be nice to have it fixed as the layout looks rather sloppy without it. Any time I see the layout ?correct? itself when I interact with a control or tweak the size of a window it is also distracting. When I saw this fix proposed here my first thought was, ?finally!? So I for one am looking forward to this. It seems that the number of iterations will be very low for most cases, so I?m not terribly concerned about any sort of performance impact. But that is my only worry, as I have had issues with layout/CSS taking a lot of time in the past, so in some cases even a single extra iteration may lead to a perceptible delay. (I was mostly working with FX 8 when I had those issues, so hopefully things are better in recent versions, I haven?t measured.) I agree that the default limit could probably be reduced, 10 iterations would likely be plenty more than needed. As you say, something is probably wrong with your control if it goes that far. Regards, Scott > On Apr 2, 2021, at 10:51 AM, Kevin Rushforth wrote: > > ?Circling back to this: Do any JavaFX application developers on this list have any thoughts? I think this is a good idea, and it seems worth moving this forward, but it will require a fair bit of effort. I'd like to hear buy-in from other developers -- particularly those who develop or use custom controls. > > A few additional comments: > > * Regarding the threshold, I like the idea of logging at a fine (or finer) level if it goes beyond a smaller number, say 3 or 4, passes, but continuing further to iterate. I wonder if 100 might be too large for the default limit, though. It seems likely that the control is unstable and will never converge if it gets to that many layout passes. If there were a way to analyze what a reasonable limit is that would be better (if not, we can probably live with a fairly high value, if it really is an unlikely pathological case). Assuming a reasonably high threshold, logging at a warning level would be good if it doesn't converge. > > * Documentation: I do think we will want to document the overall concept of layout needing multiple passes to converge in some cases, along with documenting the threshold. I also think that Node::getBaselineOffset should mention the preference of text nodes. The concept of "text" nodes needs to be on Node, if for no other reason than that Text doesn't inherit from Parent. > > * This will need to be very well tested, both to ensure no regressions in behavior, and with many new tests added to validate the new functionality, including testing the threshold logic. > > -- Kevin > > >> On 3/20/2021 6:42 AM, Michael Strau? wrote: >> 1) Pathological cases: So far, I haven't been able to produce >> pathological cases that exceed 3 layout passes by using standard >> layout containers and controls. If we need to have a threshold >> substantially higher than that depends on whether or not there are >> indeed legitimate cases where some kind of layout requires more passes >> to converge. Maybe we could log at a very fine level when a control >> takes more than 3 passes to converge, but still continue processing up >> to a substantially higher number of passes. This would allow >> developers to debug and optimize their custom controls, but still >> produce a valid solution if a particular control is generally stable, >> but just very poorly optimized. >> >> 2) I believe that the multi-pass layout algorithm shouldn't need >> additional documentation since it could be considered an >> implementation detail. There is no 1:1 correspondence between pulses >> and layout passes currently, and there won't be with the new >> algorithm. Also, any layout pass with the current algorithm can >> potentially trigger another layout pass, so that's not fundamentally >> different either. For control authors, we might need to document that >> it is generally okay to rely on circular dependencies between size >> hints, baseline offset and child nodes, as long as those dependencies >> allow the layout to settle. The fact that text nodes are preferred >> with respect to baseline computation is documented in >> Parent.getBaselineOffset(), maybe Node.getBaselineOffset() should also >> mention this. We might also add a section on baseline computation to >> the javafx.scene.layout package documentation, where I think it is >> most relevant (and currently entirely undocumented). >> >> 3) New API on Node: in order for this idea to work, there needs to be >> an abstract concept of "text node". Since the "baseline" concept is >> introduced on Node, I thought this would also be the appropriate place >> to introduce the "text node" concept; however, it could also be >> introduced on Parent instead. Note that the "text node" concept is >> introduced at a lower level than actual text controls like Labeled, >> because layout containers (which are not controls) need this >> information. Also, the definition of what constitutes "text" is left >> to control authors. In a very contrived example, a control might >> display an image, but declare itself to be "text". >> >> >> >>> Am Fr., 19. M?rz 2021 um 23:26 Uhr schrieb Kevin Rushforth >>> : >>> I'd be interested to hear from app developers on this list. >>> >>> Here are a few quick thoughts I have. >>> >>> As you note, this is a long-standing problem with layout in FX. You >>> mention in the performance considerations that for most cases this will >>> iterate quickly. It would be interesting to know what some of the corner >>> cases are, so we can see how bad the pathological case will be. I see >>> that you propose to iterate up to 100 times. Maybe a lower threshold >>> would be better? We already run layout passes 3 times in many cases. So >>> also running 3 (or maybe 4 or 5) times seems reasonable, especially when >>> your testing shows that most of the time it converges in <= 2 passes. So >>> a smaller threshold than 100 would seem to make sense. If a control >>> doesn't converge, you might consider logging it (in case an app >>> developer wants to debug it) perhaps at a "fine" level so it isn't shown >>> by default. >>> >>> How do you propose to document this behavioral change -- not so much the >>> fact that it will (usually) get the right answer now instead of the >>> wrong one, but more about the multi-pass nature of it, and the fact that >>> nodes with text will be "preferred". Related to that, how necessary is a >>> new public API on Node? >>> >>> -- Kevin >>> > From ajoseph at openjdk.java.net Fri Apr 2 16:47:29 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 2 Apr 2021 16:47:29 GMT Subject: RFR: 8259555: Webkit crashes on Apple Silicon Message-ID: WebKit crashes during JavaScriptCore initialization code for Apple Silicon. ------------- Commit messages: - 8259555: Webkit crashes on Apple Silicon Changes: https://git.openjdk.java.net/jfx/pull/452/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=452&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259555 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/452.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/452/head:pull/452 PR: https://git.openjdk.java.net/jfx/pull/452 From jvos at openjdk.java.net Fri Apr 2 17:35:15 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 2 Apr 2021 17:35:15 GMT Subject: RFR: 8259555: Webkit crashes on Apple Silicon In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 15:37:38 GMT, Arun Joseph wrote: > WebKit crashes during JavaScriptCore initialization code for Apple Silicon. This works, as long as MACOSX_MIN_VERSION is set to 11. I guess we don't want to commit that in the build.gradle, as we only require that for a build on Apple Silicon. ------------- PR: https://git.openjdk.java.net/jfx/pull/452 From kcr at openjdk.java.net Fri Apr 2 17:39:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Apr 2021 17:39:11 GMT Subject: RFR: 8259555: Webkit crashes on Apple Silicon In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 17:32:41 GMT, Johan Vos wrote: >> WebKit crashes during JavaScriptCore initialization code for Apple Silicon. > > This works, as long as MACOSX_MIN_VERSION is set to 11. I guess we don't want to commit that in the build.gradle, as we only require that for a build on Apple Silicon. Any changes to minimum OS version in `mac.gradle` would need to be qualified by a check for the target architecture. It might make sense to do that in connection with other needed build changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/452 From kcr at openjdk.java.net Fri Apr 2 17:44:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Apr 2021 17:44:11 GMT Subject: RFR: 8259555: Webkit crashes on Apple Silicon In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 15:37:38 GMT, Arun Joseph wrote: > WebKit crashes during JavaScriptCore initialization code for Apple Silicon. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/452 From jgneff at openjdk.java.net Fri Apr 2 17:48:18 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Fri, 2 Apr 2021 17:48:18 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 23:21:55 GMT, Alexander Matveev wrote: >> John Neffenger has updated the pull request incrementally with one additional commit since the last revision: >> >> 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 > > Media makefiles look fine. > Silly question, is the difference with Windows just the nature of the native support on each platform (Unix based vs Windows) and libraries used as part of that? That's a good question. I'm hoping the answer is no. So far, the difference with Windows is the linker. The other systems use the GNU linker where it's enough to sort the input object files. The Microsoft linker, though, creates reproducible builds with the flag `/experimental:deterministic` (or `-experimental:deterministic`). So on Windows, we just need to figure out where to put the flag. I'm finding that to be a challenge for the WebKit library. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jvos at openjdk.java.net Fri Apr 2 17:53:20 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 2 Apr 2021 17:53:20 GMT Subject: RFR: 8259555: Webkit crashes on Apple Silicon In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 15:37:38 GMT, Arun Joseph wrote: > WebKit crashes during JavaScriptCore initialization code for Apple Silicon. The other required changes required to build for M1 can easily be passed as build parameters using gradlew -P Hence, this change contains all that is needed to be changed in the repository. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/452 From ajoseph at openjdk.java.net Fri Apr 2 17:59:11 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 2 Apr 2021 17:59:11 GMT Subject: Integrated: 8259555: Webkit crashes on Apple Silicon In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 15:37:38 GMT, Arun Joseph wrote: > WebKit crashes during JavaScriptCore initialization code for Apple Silicon. This pull request has now been integrated. Changeset: b2f842de Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/b2f842de Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259555: Webkit crashes on Apple Silicon Co-authored-by: Peter Zhelezniakov Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/452 From github.com+43553916+mstr2 at openjdk.java.net Fri Apr 2 19:51:34 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Fri, 2 Apr 2021 19:51:34 GMT Subject: RFR: 8137323: Incorrect parsing of mnemonic in controls text Message-ID: This PR fixes incorrect parsing of mnemonic symbols in the following cases: 1. an escaped double underscore incorrectly shows up as a double underscore in displayed text 2. an extended mnemonic incorrectly removes a part of adjacent text As a side effect, this PR also fixes another undocumented issue for multiline text where text metrics calculations incorrectly operate on text for which mnemonic symbols have not been processed. This can lead to a glitch where the mnemonic underscore makes a text just long enough to wrap to a new line, but when the text is rendered, the second line shows up entirely empty. The reason for this is that for rendering, the text is laid out _after_ mnemonic symbols have been removed. The solution is to _always_ use processed text ("_clean text_") when laying out text. ------------- Commit messages: - Additional test - Fix mnemonic processing in LabeledSkinBase - Add failing tests Changes: https://git.openjdk.java.net/jfx/pull/453/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=453&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8137323 Stats: 251 lines in 3 files changed: 120 ins; 51 del; 80 mod Patch: https://git.openjdk.java.net/jfx/pull/453.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/453/head:pull/453 PR: https://git.openjdk.java.net/jfx/pull/453 From almatvee at openjdk.java.net Fri Apr 2 22:30:14 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 2 Apr 2021 22:30:14 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: References: <_vdajZtvbKmn0FvI8owNTnAby4DBnupiq9fiHkod6Ew=.51940492-315c-408e-9a45-514f2c2413ca@github.com> Message-ID: <-SWeYH8jlxAzQVrzgYEDBLUq7egr-6TG8pFleoqedzg=.011f077c-65b7-4269-8084-afe4046b39b9@github.com> On Thu, 1 Apr 2021 23:47:15 GMT, Kevin Rushforth wrote: >> All my testing looks good on all three platforms. I'll take a look at the diffs next. >> >> One thing I did spot is that you need to update `gstreamer.md` and `glib.md` to bump the version numbers. > > It now builds for me on my old Linux box. And the changes to the /legal/ files looks good. > > One more thing I just thought of: we should do a test build on macOS aarch64. I have no reason to believe that there will be a problem, but worth double-checking. It builds fine on macOS aarch64 and I did minor testing as well. No issues. ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From jgneff at openjdk.java.net Sat Apr 3 01:52:09 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 3 Apr 2021 01:52:09 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 17:45:38 GMT, John Neffenger wrote: >> Media makefiles look fine. > >> Silly question, is the difference with Windows just the nature of the native support on each platform (Unix based vs Windows) and libraries used as part of that? > > That's a good question. I'm hoping the answer is no. So far, the difference with Windows is the linker. The other systems use the GNU linker where it's enough to sort the input object files. The Microsoft linker, though, creates reproducible builds with the flag `/experimental:deterministic` (or `-experimental:deterministic`). So on Windows, we just need to figure out where to put the flag. I'm finding that to be a challenge for the WebKit library. > /contributor add ... @bmwiedemann I added you as co-author of pull request #422, which is my continuation of your pull request #99 from last year. This pull request #446 temporarily includes our co-authored commit, but those changes will disappear when #422 is integrated and I merge the master branch into this one. Sorry for the confusion. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jvos at openjdk.java.net Sat Apr 3 07:20:16 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 3 Apr 2021 07:20:16 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 23:17:58 GMT, Alexander Matveev wrote: >> - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 >> - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > Updated .md files and added missing include files Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From fkirmaier at openjdk.java.net Sat Apr 3 15:04:36 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 3 Apr 2021 15:04:36 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v2] In-Reply-To: References: Message-ID: > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: - 8264127: removed accidentally commited line - 8264127: Added another test for ListCell, now when updating the index of the ListCell to the editingIndex ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/a40b0253..e2f12cb0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=00-01 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From kcr at openjdk.java.net Sat Apr 3 15:11:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 3 Apr 2021 15:11:17 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 23:17:58 GMT, Alexander Matveev wrote: >> - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 >> - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > Updated .md files and added missing include files Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/447 From fkirmaier at openjdk.java.net Sat Apr 3 15:23:16 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 3 Apr 2021 15:23:16 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: <4sMuGaAW87f-lxLMt-13WyjuGsEZpuv3SAtgZnKd-VI=.17ae6bc1-b071-46eb-80c1-6216909d0642@github.com> Message-ID: On Thu, 1 Apr 2021 14:41:46 GMT, Jeanette Winzenburg wrote: >> I don't think B is right. >> I would expect a editCancel event when the index of an editing cell is changed. >> If there would be another cell, which will get the index 1 (which isn't the case in this artifical test) then i would expect another editStart event. >> >> On the perspective of the ListView, the index never changes, but it's more relevant that some of the cells cancel/start the editing. If one would want to avoid the cancelEdit, when the index is not changing, then the solution should be to make sure, the index of editing cells never changes, which isn't the scope of this PR. > >> >> >> I don't think B is right. >> I would expect a editCancel event when the index of an editing cell is changed. >> If there would be another cell, which will get the index 1 (which isn't the case in this artifical test) then i would expect another editStart event. > > well, I see your point but think it's arguable :) > > - editEvent not/firing on cell re-use is not really specified (even overall edit spec is .. suboptimal, see [my oldish summary](https://github.com/kleopatra/swingempire-fx/wiki/CellEditEvents)) - without that spec, we might feel free to fire > - from the perspective of edit handlers, that editCancel (and the assumed editStart - suspect it doesn't happen, didn't test though) are just spurious events - they are not really interested in volatile state changes, just introduced by an implementation detail like cell re-use. > > As to the scope of this: as I understand it, its goal is to keep the cell's editing state (flag and visual state) in sync with listview's editingIndex when updating the cell index. That should include both directions > > - index == editingIndex -> index != editingIndex > - index != editingIndex -> index == editingIndex > > The first is already handled (modulo our disagreement on editEvents :), the second is not. @kleopatra I've added another test for the case, when index changes in such a way, that the cell should no longer be in the editing state, and the test seems to work. Do I miss something? About the Events, when i think about it, I was a bit of biased so I don't have to change anything. So I don't really have an opinion about it. But the PR should only fix the case, which is obviously wrong, and i don't really want to change anything in the event logic. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Sat Apr 3 15:39:29 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 3 Apr 2021 15:39:29 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false Message-ID: Fixing leak in ProgressIndicator when treeShowing is false ------------- Commit messages: - 8264677 Changes: https://git.openjdk.java.net/jfx/pull/455/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=455&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264677 Stats: 40 lines in 2 files changed: 39 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/455.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/455/head:pull/455 PR: https://git.openjdk.java.net/jfx/pull/455 From kcr at openjdk.java.net Sat Apr 3 15:44:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 3 Apr 2021 15:44:16 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:35:19 GMT, Florian Kirmaier wrote: > Fixing leak in ProgressIndicator when treeShowing is false Is this a recent regression, or has this case been failing for a long time? ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From fkirmaier at openjdk.java.net Sat Apr 3 15:54:09 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 3 Apr 2021 15:54:09 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:41:18 GMT, Kevin Rushforth wrote: >> Fixing leak in ProgressIndicator when treeShowing is false > > Is this a recent regression, or has this case been failing for a long time? I think it's failing since a long time. But i haven't tested it. It must be, because before the other leak should "shadow" this leak. ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From fkirmaier at openjdk.java.net Sat Apr 3 15:59:15 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 3 Apr 2021 15:59:15 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false In-Reply-To: References: Message-ID: <3OFYvR950LIdzAx8HnGAmcDb1T4-4mhmyaYQ3uKAULo=.e6b0747d-1631-4249-8f92-bfb4f560d70d@github.com> On Sat, 3 Apr 2021 15:51:11 GMT, Florian Kirmaier wrote: >> Is this a recent regression, or has this case been failing for a long time? > > I think it's failing since a long time. But i haven't tested it. > It must be, because before the other leak should "shadow" this leak. Before, ProgressIndicator was basically leaking every time, this is a very rare special case. Because very few people add invisible ProgressIndicators. I think in the application, it was put slightly delayed visible, but because the task was finished even faster, it never became really visible. So in the affected project it was basically triggered by a rare timing. ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From hjohn at xs4all.nl Sun Apr 4 09:42:46 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 4 Apr 2021 11:42:46 +0200 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> Message-ID: <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> On 02/04/2021 08:47, Nir Lisker wrote: > Hi John, > > I've had my eyes set on ReactFX enhancements for a while too, especially as > a replacement for the unsafe "select" mechanism. One of the things that > kept me from going forward with this is seeing what Valhalla will bring. > Generic specialization might save a lot of duplication work on something > like this, and Tomas touched another related issue [1], but since it could > be a long time before that happens, it's worth planning what we can extract > from ReactFX currently. Agreed, Valhalla is certainly a highly anticipated feature but I fear it is still a couple of years away. Even without any initial support for dealing with "? extends Number" from the various ObservableValue specializations I think looking into this can already be tremendous help. The proof of concept mainly requires you convert the Number to a suitable type when reading the property but has no problems in the other direction: label.widthProperty().map(Number::doubleValue).map(x -> x + 1); Not pretty, but certainly workable. Specific methods could be introduced (even at a later time) to make this more streamlined, similar to what the Stream API offers with 'mapToDouble' etc. > I think that we should break the enhancements into parts. > The first that I would advise to look at are the additions to > properties/observables. Tomas had to create Val and Var because he couldn't > change the core interfaces, but we can. Fitting them with the Optional > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. `flatMap` etc.; > and `select` and friends, is already a good start that will address many > common requirements. Yes, Val/Var had to be created for that reason, and also because properties don't quite behave the same as streams -- streams with a "toBinding" method results in things people didn't quite expect. As far as the Optional methods go, I'm not entirely sure properties would benefit from all of them. Properties are not immutable like Optional and it may make less sense to fit them with 'isPresent', 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to behave similar to 'addListener' or 'subscribe'). In the PoC I made I specifically also disallowed 'null' as an input for functions like 'map' and 'flatMap' (opting to use 'orElse' semantics for 'null'), as this for allows much cleaner mapping (and especially flat mapping when selecting nested properties). If 'null' were to be allowed, I think at a minimum we'd need to add another method to allow for easy selecting of nested properties to avoid: obs.flatMap(x -> x == null ? null : x.otherProperty()) > The second part is related to listeners. The subscription model and event > streams try to solve the memory issues with hard and weak references, and > allow better composition. Not entirely sure what you mean by this. JavaFX's current model uses weak references which was I think an unfortunate decision as it can result in huge confusion. For example, a direct binding will work, but with an indirection step a binding stops working: button.textProperty() .concat("World") // weak binding used here .addListener((obs, old, cur) -> System.out.println(cur)); The above stops working, but without the 'concat' it keeps working. I think the use of weak listeners should be avoided and instead other mechanisms should be provided to make cleaning up easier. This is the main reason for 'conditionOn' and why ReactFX even had a specialized version of it: 'conditionOnShowing(Node)'. > The third part is for collections - things like transformation lists > (LiveList) and for other collections. This is indeed best saved for last. The problems there I think are less of an issue for now. > Since these share behavior under the hood, we need to look ahead, but in > terms of functionality, I think we should take smaller steps. It will also > be easier to propose these then. I've for this reason kept the PoC small with only the most basic functionality. I did however add some work for a different subscription model, mainly because the internals of this code benefits greatly from it. It is however kept to a minimum. I'd be happy to spend more time and work on this. Perhaps it would be possible to collaborate on this? --John > > - Nir > > [1] > https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx wrote: > >> I just wanted to draw some attention to a recent proof of concept I made >> in this pull request: https://github.com/openjdk/jfx/pull/434 >> >> It is based on the work I did in >> https://github.com/hjohn/hs.jfx.eventstream which is in part based on >> work done in ReactFX by Tomas Mikula. The PR itself however shares no >> code with ReactFX and is >> completely written by me. >> >> If there is interest, I'm willing to invest more time in smoothing out >> the API and documentation, investigating further how this would interact >> with the primitive types and adding unit test coverage (I have extensive >> tests, but thesea are written in JUnit 5, so they would require >> conversion or JavaFX could move to support JUnit 5). >> >> What follows below is the text of the PR for easy reading. Feedback is >> appreciated. >> >> ================ >> >> This is a proof of concept of how fluent bindings could be introduced to >> JavaFX. The main benefit of fluent bindings are ease of use, type safety >> and less surprises. Features: >> >> Flexible Mappings >> Map the contents of a property any way you like with map, or map nested >> properties with flatMap. >> >> Lazy >> The bindings created are lazy, which means they are always invalid when >> not themselves observed. This allows for easier garbage collection (once >> the last observer is removed, a chain of bindings will stop observing >> their parents) and less listener management when dealing with nested >> properties. Furthermore, this allows inclusion of such bindings in >> classes such as Node without listeners being created when the binding >> itself is not used (this would allow for the inclusion of a >> treeShowingProperty in Node without creating excessive listeners, see >> this fix I did in an earlier PR: #185) >> >> Null Safe >> The map and flatMap methods are skipped, similar to java.util.Optional >> when the value they would be mapping is null. This makes mapping nested >> properties with flatMap trivial as the null case does not need to be >> taken into account in a chain like this: >> node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). >> >> Instead a default can be provided with orElse or orElseGet. >> >> Conditional Bindings >> Bindings can be made conditional using the conditionOn method. A >> conditional binding retains its last value when its condition is false. >> Conditional bindings donot observe their source when the condition is >> false, allowing developers to automatically stop listening to properties >> when a certain condition is met. A major use of this feature is to have >> UI components that need to keep models updated which may outlive the UI >> conditionally update the long lived model only when the UI is showing. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> >> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" >> >> characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + >> " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), >> "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { >> // Standard JavaFX: naive, memory leak; UI won't get garbage collected >> listView.getSelectionModel().selectedItemProperty().addListener( >> (obs, old, current) -> >> longLivedModel.lastSelectedProperty().set(current) >> ); >> >> // Standard JavaFX: no leak, but stops updating after a while >> listView.getSelectionModel().selectedItemProperty().addListener( >> new WeakChangeListener<>( >> (obs, old, current) -> >> longLivedModel.lastSelectedProperty().set(current) >> ) >> ); >> >> // Standard JavaFX: fixed version >> listenerReference = (obs, old, current) -> >> longLivedModel.lastSelectedProperty().set(current); >> >> listView.getSelectionModel().selectedItemProperty().addListener( >> new WeakChangeListener<>(listenerReference) >> ); >> >> // Fluent: naive, memory leak... fluent won't solve this... >> listView.getSelectionModel().selectedItemProperty() >> .subscribe(longLivedModel.lastSelectedProperty()::set); >> >> // Fluent: conditional update when control visible >> >> // Create a property which is only true when the UI is visible: >> ObservableValue showing = listView.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false); >> >> // Use showing property to automatically disconnect long lived model >> // allowing garbage collection of the UI: >> listView.getSelectionModel().selectedItemProperty() >> .conditionOn(showing) >> .subscribe(longLivedModel.lastSelectedProperty()::set); >> >> // Note that the 'showing' property can be provided in multiple ways: >> // - create manually (can be re-used for multiple bindings though) >> // - create with a helper: Nodes.showing(Node node) -> >> ObservableValue >> // - make it part of the Node class; as the fluent bindings only bind >> themselves >> // to their source when needed (lazy binding), this won't create >> overhead >> // for each node in the scene >> } >> Note that this is based on ideas in ReactFX and my own experiments in >> https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion >> that this is much better directly integrated into JavaFX, and I'm hoping >> this proof of concept will be able to move such an effort forward. >> >> --John >> > From jgneff at openjdk.java.net Sun Apr 4 16:36:27 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sun, 4 Apr 2021 16:36:27 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] 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 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. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/446/files - new: https://git.openjdk.java.net/jfx/pull/446/files/afeb3fe0..cb8510c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=01-02 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 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 Sun Apr 4 17:46:34 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sun, 4 Apr 2021 17:46:34 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 01:49:47 GMT, John Neffenger wrote: >>> Silly question, is the difference with Windows just the nature of the native support on each platform (Unix based vs Windows) and libraries used as part of that? >> >> That's a good question. I'm hoping the answer is no. So far, the difference with Windows is the linker. The other systems use the GNU linker where it's enough to sort the input object files. The Microsoft linker, though, creates reproducible builds with the flag `/experimental:deterministic` (or `-experimental:deterministic`). So on Windows, we just need to figure out where to put the flag. I'm finding that to be a challenge for the WebKit library. > >> /contributor add ... > > @bmwiedemann I added you as co-author of pull request #422, which is my continuation of your pull request #99 from last year. This pull request #446 temporarily includes our co-authored commit, but those changes will disappear when #422 is integrated and I merge the master branch into this one. Sorry for the confusion. > It would be better to add the flag in `libxml/CMakeLists.txt` or in `build.gradle` via `cmakeArgs`. Thank you, Arun, for that helpful suggestion. I updated this pull request for the WebKit library on Windows and ran my tests again, as described below. I saved the output of the first build in the `build1.log` file and the `build1` directory: $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) $ bash gradlew -PCONF=Release -PPROMOTED_BUILD_NUMBER=5 \ -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true \ -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true sdk jmods javadoc \ | tee build1.log $ mv build build1 Then I ran another clean build, this time saving the output in the `build2.log` file and the `build2` directory: $ bash gradlew cleanAll $ bash gradlew -PCONF=Release -PPROMOTED_BUILD_NUMBER=5 \ -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true \ -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true sdk jmods javadoc \ | tee build2.log $ mv build build2 I copied the builds to my Linux workstation and ran the following command on the JMOD files for each pair of builds: $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build?/jmods/*.jmod Normalizing build1/jmods/javafx.base.jmod Normalizing build1/jmods/javafx.controls.jmod Normalizing build1/jmods/javafx.fxml.jmod Normalizing build1/jmods/javafx.graphics.jmod Normalizing build1/jmods/javafx.media.jmod Normalizing build1/jmods/javafx.swing.jmod Normalizing build1/jmods/javafx.web.jmod Normalizing build2/jmods/javafx.base.jmod Normalizing build2/jmods/javafx.controls.jmod Normalizing build2/jmods/javafx.fxml.jmod Normalizing build2/jmods/javafx.graphics.jmod Normalizing build2/jmods/javafx.media.jmod Normalizing build2/jmods/javafx.swing.jmod Normalizing build2/jmods/javafx.web.jmod After normalizing the JMOD files, the output of the two builds on each of the three operating systems is identical: $ diff -qr linux/build1 linux/build2 $ diff -qr macos/build1 macos/build2 $ diff -qr win10/build1 win10/build2 $ The following commands show the count of identical output files for each system: $ diff -sr linux/build1 linux/build2 | wc -l 10676 $ diff -sr macos/build1 macos/build2 | wc -l 10680 $ diff -sr win10/build1 win10/build2 | wc -l 10633 Considering the time it takes to run all these builds, I'd like to take a week to get feedback and mull over the code changes before anyone spends a lot of time testing. I wish the changes for Windows were not so scattered about, for example. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From aghaisas at openjdk.java.net Mon Apr 5 07:31:14 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 5 Apr 2021 07:31:14 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: On Thu, 18 Mar 2021 14:38:18 GMT, Marius Hanl wrote: > When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. > This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). > Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From aghaisas at openjdk.java.net Mon Apr 5 11:43:42 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 5 Apr 2021 11:43:42 GMT Subject: RFR: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 13:38:27 GMT, Kevin Rushforth wrote: > If the macOS system settings for opening documents as tabs is set to "Always", then all JavaFX windows, including Dialogs, are opened as tabs, unless they are child windows (that is, a Window with an owner). > > This is a real problem for certain types of dialogs, such as `APPLICATION_MODAL` dialogs, regardless of whether the app uses `show()` or uses `showAndWait()` to spin up a nested event loop. Also, if the dialog is of a different size that the main window, it will resize itself when switching tabs (which is visually jarring), and will not be sized correctly. Even for ordinary stages, this isn't the desired behavior. > > The fix is to disallow opening in tabs for all JavaFX windows. There are a couple existing tests that fail when the setting for opening documents in tabs is set to "Always", but I also added a new explicit test for this by creating two Stages and verifying that both are active at the same time. Marked as reviewed by aghaisas (Reviewer). I tested on macOS 10.15.7. With suggested system setting set, the test fails without fix and passes with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/440 From jpereda at openjdk.java.net Mon Apr 5 19:03:34 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 5 Apr 2021 19:03:34 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 Message-ID: This PR filters out `GDK_TOUCH_EVENT_MASK` from `GDK_ALL_EVENTS_MASK` to prevent touch events from being used instead of regular mouse events on Linux platforms. Note that the touch events will be delivered as mouse pressed/dragged events. Since we still compile with GTK 2.x the bit flag (that was introduced in GTK 3.4) needs to be defined. This PR has been tested on Ubuntu 20.04 with a touch enabled display. ------------- Commit messages: - Filter out GDK_TOUCH_MASK events Changes: https://git.openjdk.java.net/jfx/pull/457/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=457&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8217955 Stats: 15 lines in 3 files changed: 10 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/457.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/457/head:pull/457 PR: https://git.openjdk.java.net/jfx/pull/457 From kcr at openjdk.java.net Mon Apr 5 22:29:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 5 Apr 2021 22:29:17 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:59:52 GMT, Jose Pereda wrote: > This PR filters out `GDK_TOUCH_EVENT_MASK` from `GDK_ALL_EVENTS_MASK` to prevent touch events from being used instead of regular mouse events on Linux platforms. Note that the touch events will be delivered as mouse pressed/dragged events. > > Since we still compile with GTK 2.x the bit flag (that was introduced in GTK 3.4) needs to be defined. > > This PR has been tested on Ubuntu 20.04 with a touch enabled display. @pankaj-bansal It looks OK to me, but can you also take a look at this? ------------- PR: https://git.openjdk.java.net/jfx/pull/457 From kcr at openjdk.java.net Mon Apr 5 22:42:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 5 Apr 2021 22:42:12 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false In-Reply-To: <3OFYvR950LIdzAx8HnGAmcDb1T4-4mhmyaYQ3uKAULo=.e6b0747d-1631-4249-8f92-bfb4f560d70d@github.com> References: <3OFYvR950LIdzAx8HnGAmcDb1T4-4mhmyaYQ3uKAULo=.e6b0747d-1631-4249-8f92-bfb4f560d70d@github.com> Message-ID: On Sat, 3 Apr 2021 15:56:12 GMT, Florian Kirmaier wrote: >> I think it's failing since a long time. But i haven't tested it. >> It must be, because before the other leak should "shadow" this leak. > > Before, ProgressIndicator was basically leaking every time, this is a very rare special case. > Because very few people add invisible ProgressIndicators. > I think in the application, it was put slightly delayed visible, but because the task was finished even faster, it never became really visible. So in the affected project it was basically triggered by a rare timing. I see. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From kcr at openjdk.java.net Mon Apr 5 22:51:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 5 Apr 2021 22:51:13 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:35:19 GMT, Florian Kirmaier wrote: > Fixing leak in ProgressIndicator when treeShowing is false I haven't run it yet, but noticed a couple things during a quick code review. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 746: > 744: ((Timeline)indeterminateTransition).getKeyFrames().setAll(keyFrames); > 745: > 746: if(NodeHelper.isTreeShowing(control)) { Minor: space after `if`. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 748: > 746: if(NodeHelper.isTreeShowing(control)) { > 747: indeterminateTransition.playFromStart(); > 748: } In the case where `isTreeShowing` is false, and later goes to true, there will be a slight change in behavior, since `updateAnimation` will call `play` in that case. To make sure that the behavior is the same, I recommend calling `indeterminateTransition.jumpTo(Duration.ZERO);` in an `else` block here. ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From kcr at openjdk.java.net Mon Apr 5 23:04:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 5 Apr 2021 23:04:10 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: On Thu, 18 Mar 2021 14:38:18 GMT, Marius Hanl wrote: > When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. > This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). > Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. I have one question on the fix (see below). Also, have you run all of the unit tests (not just the new one)? modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 1062: > 1060: boolean hasDefault = false; > 1061: for (ButtonType cmd : getButtonTypes()) { > 1062: Node button = buttonNodes.get(cmd); Why was this change needed? ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From almatvee at openjdk.java.net Mon Apr 5 23:35:14 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 5 Apr 2021 23:35:14 GMT Subject: Integrated: 8262366: Update glib to version 2.66.7 In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:15:20 GMT, Alexander Matveev wrote: > - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 > - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. This pull request has now been integrated. Changeset: e63931e6 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/e63931e6 Stats: 39567 lines in 441 files changed: 23434 ins; 5427 del; 10706 mod 8262366: Update glib to version 2.66.7 8262365: Update GStreamer to version 1.18.3 Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From github.com+66004280+maran23 at openjdk.java.net Tue Apr 6 06:16:11 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 6 Apr 2021 06:16:11 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: <8P1NOYZSfDx_0UmB_OrY0lMCAvgyWI2tGY8LooKjeJo=.693ee057-9486-467b-a4d7-dd4043e6c176@github.com> On Mon, 5 Apr 2021 22:58:47 GMT, Kevin Rushforth wrote: >> When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. >> This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). >> Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. > > modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 1062: > >> 1060: boolean hasDefault = false; >> 1061: for (ButtonType cmd : getButtonTypes()) { >> 1062: Node button = buttonNodes.get(cmd); > > Why was this change needed? This change is not needed for the fix. I removed it, because #computeIfAbsent() isn't needed anymore. The (now) first listener will run and create/remove buttons based off the changes to #getButtonTypes(). The second listener (which is calling this method) will use all created buttons (to put them inside the ButtonBar). -> So only a simple #get() is needed. #computeIfAbsent() basically masked this bug before, as it was also creating a button, if missing. But as mentionend, when we are here, all buttons should be already created by the first listener. ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From pbansal at openjdk.java.net Tue Apr 6 06:27:11 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 6 Apr 2021 06:27:11 GMT Subject: RFR: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 13:38:27 GMT, Kevin Rushforth wrote: > If the macOS system settings for opening documents as tabs is set to "Always", then all JavaFX windows, including Dialogs, are opened as tabs, unless they are child windows (that is, a Window with an owner). > > This is a real problem for certain types of dialogs, such as `APPLICATION_MODAL` dialogs, regardless of whether the app uses `show()` or uses `showAndWait()` to spin up a nested event loop. Also, if the dialog is of a different size that the main window, it will resize itself when switching tabs (which is visually jarring), and will not be sized correctly. Even for ordinary stages, this isn't the desired behavior. > > The fix is to disallow opening in tabs for all JavaFX windows. There are a couple existing tests that fail when the setting for opening documents in tabs is set to "Always", but I also added a new explicit test for this by creating two Stages and verifying that both are active at the same time. Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/440 From github.com+66004280+maran23 at openjdk.java.net Tue Apr 6 06:29:19 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 6 Apr 2021 06:29:19 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: On Mon, 5 Apr 2021 23:01:25 GMT, Kevin Rushforth wrote: > > > I have one question on the fix (see below). Also, have you run all of the unit tests (not just the new one)? I did run all the normal tests and ever dialog related system test. Everything passed. Isn't jcheck running all the tests anyway? ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From kcr at openjdk.java.net Tue Apr 6 12:01:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 12:01:16 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: <7FpsFfPdHs9BkmhmSGFZ58-EV83oi7cRhumBD59hRbo=.c4029cdc-964b-4b5d-b7dd-ab2f2f028854@github.com> On Tue, 6 Apr 2021 06:26:46 GMT, Marius Hanl wrote: >> I have one question on the fix (see below). Also, have you run all of the unit tests (not just the new one)? > >> >> >> I have one question on the fix (see below). Also, have you run all of the unit tests (not just the new one)? > > I did run all the normal tests and ever dialog related system test. Everything passed. > Isn't jcheck running all the tests anyway? Thanks for the explanation. I'll finish my review shortly. > Isn't jcheck running all the tests anyway? You mean GitHub Actions (jcheck doesn't build or run any tests). It would, but for two things: 1. You used the `master` branch of your repo, which is not recommended, and will cause problems for you if you ever do another pull request. See [this comment](https://github.com/openjdk/jfx/pull/432#issuecomment-801982830) added by the Skara bot. 2. You haven't enabled GitHub action on your personal fork of the `jfx` repository. See [wiki.openjdk.java.net/display/SKARA/Testing](https://wiki.openjdk.java.net/display/SKARA/Testing) for information on how to enable it. ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From kcr at openjdk.java.net Tue Apr 6 12:13:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 12:13:13 GMT Subject: Integrated: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 13:38:27 GMT, Kevin Rushforth wrote: > If the macOS system settings for opening documents as tabs is set to "Always", then all JavaFX windows, including Dialogs, are opened as tabs, unless they are child windows (that is, a Window with an owner). > > This is a real problem for certain types of dialogs, such as `APPLICATION_MODAL` dialogs, regardless of whether the app uses `show()` or uses `showAndWait()` to spin up a nested event loop. Also, if the dialog is of a different size that the main window, it will resize itself when switching tabs (which is visually jarring), and will not be sized correctly. Even for ordinary stages, this isn't the desired behavior. > > The fix is to disallow opening in tabs for all JavaFX windows. There are a couple existing tests that fail when the setting for opening documents in tabs is set to "Always", but I also added a new explicit test for this by creating two Stages and verifying that both are active at the same time. This pull request has now been integrated. Changeset: 58988582 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/58988582 Stats: 174 lines in 2 files changed: 174 ins; 0 del; 0 mod 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set Reviewed-by: aghaisas, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/440 From kcr at openjdk.java.net Tue Apr 6 12:21:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 12:21:12 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: On Thu, 18 Mar 2021 14:38:18 GMT, Marius Hanl wrote: > When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. > This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). > Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. The fix and test look fine. There is one needed change as noted below. modules/javafx.controls/src/test/java/test/javafx/scene/control/DialogPaneTest.java line 2: > 1: /* > 2: * Copyright (c) 2021, 2021, Oracle and/or its affiliates. All rights reserved. You need to revert this change. There must be only a single year listed if the start year and last modified year are the same. ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From fkirmaier at openjdk.java.net Tue Apr 6 12:24:36 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 6 Apr 2021 12:24:36 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v2] In-Reply-To: References: Message-ID: > Fixing leak in ProgressIndicator when treeShowing is false Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264677 changes based on code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/455/files - new: https://git.openjdk.java.net/jfx/pull/455/files/8e539d34..1a49a354 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=455&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=455&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/455.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/455/head:pull/455 PR: https://git.openjdk.java.net/jfx/pull/455 From fkirmaier at openjdk.java.net Tue Apr 6 12:24:36 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 6 Apr 2021 12:24:36 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 22:47:54 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264677 >> changes based on code review > > I haven't run it yet, but noticed a couple things during a quick code review. I've done the 2 changes from the code review! ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From kcr at openjdk.java.net Tue Apr 6 12:26:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 12:26:11 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:53:35 GMT, Florian Kirmaier wrote: >> I reviewed the CSR, and it is now ready for you to Finalize. > > I've clicked now the finalize button. @FlorianKirmaier The CSR needs to be updated (fixVersion set to `openjfx17`) and moved to Finalize again. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Tue Apr 6 12:38:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 6 Apr 2021 12:38:11 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:23:28 GMT, Kevin Rushforth wrote: >> I've clicked now the finalize button. > > @FlorianKirmaier The CSR needs to be updated (fixVersion set to `openjfx17`) and moved to Finalize again. The fixVersion is now openfjx17 and it's moved to "Finalized" ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fastegal at openjdk.java.net Tue Apr 6 13:33:11 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 6 Apr 2021 13:33:11 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: <4sMuGaAW87f-lxLMt-13WyjuGsEZpuv3SAtgZnKd-VI=.17ae6bc1-b071-46eb-80c1-6216909d0642@github.com> Message-ID: On Sat, 3 Apr 2021 15:20:33 GMT, Florian Kirmaier wrote: > @kleopatra > I've added another test for the case, when index changes in such a way, that the cell should no longer be in the editing state, > and the test seems to work. Do I miss something? hmm .. that's weird: your test (cell 1 -> listEdit 0 -> cell 0) indeed passes, doing it the other way round (cell 0 -> listEdit 1 -> cell 1) fails @Test public void testChangeCellIndex0ToListEditingIndex1() { assertChangeIndexToEditing(0, 1); } @Test public void testChangeCellIndex1ToListEditingIndex0() { assertChangeIndexToEditing(1, 0); } private void assertChangeIndexToEditing(int initialCellIndex, int listEditingIndex) { list.setEditable(true); cell.updateListView(list); cell.updateIndex(initialCellIndex); list.edit(listEditingIndex); assertEquals("sanity: list editingIndex ", listEditingIndex, list.getEditingIndex()); assertFalse("sanity: cell must not be editing", cell.isEditing()); cell.updateIndex(listEditingIndex); assertEquals("sanity: index updated ", listEditingIndex, cell.getIndex()); assertEquals("list editingIndex unchanged by cell", listEditingIndex, list.getEditingIndex()); assertTrue(cell.isEditing()); } Something obvious that I missed or a bummer in the test setup or what else? Any ideas? ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From github.com+43553916+mstr2 at openjdk.java.net Tue Apr 6 13:40:29 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Tue, 6 Apr 2021 13:40:29 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing Message-ID: The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. I've filed a bug report with the same title. ------------- Commit messages: - BidirectionalBinding uses InvalidationListener to prevent boxing conversions Changes: https://git.openjdk.java.net/jfx/pull/454/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264770 Stats: 111 lines in 3 files changed: 42 ins; 5 del; 64 mod Patch: https://git.openjdk.java.net/jfx/pull/454.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/454/head:pull/454 PR: https://git.openjdk.java.net/jfx/pull/454 From kcr at openjdk.java.net Tue Apr 6 13:40:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 13:40:29 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:20:41 GMT, mstr2 wrote: > The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). > > However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. > > ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). > > The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. > > This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. > > I've filed a bug report with the same title. I don't see this or any similar bug filed in our incident tracker. Did the submission complete to the point where you have an internal tracking number? Is there a measurable benefit in doing this? For example, do you have a benchmark of some sort that shows garbage generation has been reduced or performance has been improved? ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From github.com+43553916+mstr2 at openjdk.java.net Tue Apr 6 13:40:29 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Tue, 6 Apr 2021 13:40:29 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 21:54:40 GMT, Kevin Rushforth wrote: >> The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). >> >> However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. >> >> ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). >> >> The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. >> >> This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. >> >> I've filed a bug report with the same title. > > I don't see this or any similar bug filed in our incident tracker. Did the submission complete to the point where you have an internal tracking number? > > Is there a measurable benefit in doing this? For example, do you have a benchmark of some sort that shows garbage generation has been reduced or performance has been improved? Seems like I forgot to hit the send button on the webform. Here's the tracking number: 9069787. I've used the following manual benchmark, which bidirectionally binds two properties and then produces a billion change notifications. DoubleProperty property1 = new SimpleDoubleProperty(); DoubleProperty property2 = new SimpleDoubleProperty(); property2.bindBidirectional(property1); long start = System.nanoTime(); for (int i = 0; i < 1000000000; ++i) { property1.set((i % 2 == 0) ? 12345.0 : 54321.0); } long end = System.nanoTime(); System.out.println("Time elapsed (ms): " + (end - start) / 1000000); And these are the results I got (time elapsed, in milliseconds): | | before | after | | ------------|--------|-------| | Test run 1: | 28608 | 9122 | | Test run 2: | 27928 | 9065 | | Test run 3: | 31140 | 9181 | | Test run 4: | 28041 | 9127 | | Test run 5: | 28730 | 9181 | So in this synthetic benchmark, the new implementation has a 3x performance improvement compared to the old implementation. ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From kcr at openjdk.java.net Tue Apr 6 13:40:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 13:40:29 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 23:16:53 GMT, mstr2 wrote: > Seems like I forgot to hit the send button on the webform. Here's the tracking number: 9069787. I see it now. And thanks for providing the benchmark. That's what I was looking for. ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From kcr at openjdk.java.net Tue Apr 6 13:40:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 13:40:30 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 23:38:29 GMT, Kevin Rushforth wrote: >> Seems like I forgot to hit the send button on the webform. Here's the tracking number: 9069787. >> >> I've used the following manual benchmark, which bidirectionally binds two properties and then produces a billion change notifications. >> DoubleProperty property1 = new SimpleDoubleProperty(); >> DoubleProperty property2 = new SimpleDoubleProperty(); >> property2.bindBidirectional(property1); >> >> long start = System.nanoTime(); >> >> for (int i = 0; i < 1000000000; ++i) { >> property1.set((i % 2 == 0) ? 12345.0 : 54321.0); >> } >> >> long end = System.nanoTime(); >> >> System.out.println("Time elapsed (ms): " + (end - start) / 1000000); >> >> And these are the results I got (time elapsed, in milliseconds): >> >> | | before | after | >> | ------------|--------|-------| >> | Test run 1: | 28608 | 9122 | >> | Test run 2: | 27928 | 9065 | >> | Test run 3: | 31140 | 9181 | >> | Test run 4: | 28041 | 9127 | >> | Test run 5: | 28730 | 9181 | >> >> So in this synthetic benchmark, the new implementation has a 3x performance improvement compared to the old implementation. > >> Seems like I forgot to hit the send button on the webform. Here's the tracking number: 9069787. > > I see it now. And thanks for providing the benchmark. That's what I was looking for. The bug is now visible here: https://bugs.openjdk.java.net/browse/JDK-8264770 ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From fastegal at openjdk.java.net Tue Apr 6 14:05:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 6 Apr 2021 14:05:42 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v6] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: changed javadoc of unregister (invalidation only) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/cf3a0228..e7849b21 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Tue Apr 6 14:05:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 14:05:43 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: <014m7xF1F5SFx9g65ycNZLQy812dowU8jf3LrYED878=.9f6cf419-7e75-4e59-a75c-7b5ec1496ffd@github.com> References: <7RNOwM87fMcslFIFDFMxk6SQfs2x_7YKL5zaopEenk4=.09f1e9f4-6a72-44e5-8927-2ce31697745e@github.com> <014m7xF1F5SFx9g65ycNZLQy812dowU8jf3LrYED878=.9f6cf419-7e75-4e59-a75c-7b5ec1496ffd@github.com> Message-ID: On Thu, 1 Apr 2021 15:10:45 GMT, Jeanette Winzenburg wrote: >> Maybe GitHub decided to prune it. ?? >> >> Btw, you tagged the wrong "Kevin" above. > > ahh .. looks like you marked the conversation that contained the original comment as resolved: https://github.com/openjdk/jfx/pull/409#discussion_r604387696 .. I guess I didn't look closely enough. Mystery solved, though. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Tue Apr 6 14:05:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 6 Apr 2021 14:05:42 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: References: <7RNOwM87fMcslFIFDFMxk6SQfs2x_7YKL5zaopEenk4=.09f1e9f4-6a72-44e5-8927-2ce31697745e@github.com> Message-ID: <014m7xF1F5SFx9g65ycNZLQy812dowU8jf3LrYED878=.9f6cf419-7e75-4e59-a75c-7b5ec1496ffd@github.com> On Thu, 1 Apr 2021 15:09:34 GMT, Kevin Rushforth wrote: >> @Kevin >> >> don't worry, I have seen your comment (and been thinking about it :) - but also can't find it right now (nor can I find Nir's comment which started the overhaul ..), no idea what happened. >> >> Seeing your suggestion, it's similar to what keeps running in my mind. > > Maybe GitHub decided to prune it. ?? > > Btw, you tagged the wrong "Kevin" above. ahh .. looks like you marked the conversation that contained the original comment as resolved: https://github.com/openjdk/jfx/pull/409#discussion_r604387696 .. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Tue Apr 6 14:20:24 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 6 Apr 2021 14:20:24 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: References: <7RNOwM87fMcslFIFDFMxk6SQfs2x_7YKL5zaopEenk4=.09f1e9f4-6a72-44e5-8927-2ce31697745e@github.com> <014m7xF1F5SFx9g65ycNZLQy812dowU8jf3LrYED878=.9f6cf419-7e75-4e59-a75c-7b5ec1496ffd@github.com> Message-ID: On Thu, 1 Apr 2021 15:14:15 GMT, Kevin Rushforth wrote: >> ahh .. looks like you marked the conversation that contained the original comment as resolved: https://github.com/openjdk/jfx/pull/409#discussion_r604387696 .. > > I guess I didn't look closely enough. Mystery solved, though. > I haven't gone back and done a detailed review yet, but I like the overall changes. The one thing I did notice is that the language used to describe the return value of `unregisterInvalidationListeners` and `unregisterListChangeListeners` is different: > just a side-note: technically, both are different because neither the new listChangeListener nor the old changeListener methods are updated yet (we are still at the first bullet of the plan, lazy me will update all to the same as the invalidationListener wording, once we agree on it :) So what we are arguing right now is the difference between new (= invalidationListener) and old (= listChangeListener == c&p from changeListener) method doc. > ``` > unregisterInvalidationListeners: > * @return a composed consumer that performs all removed operations, or > * {@code null} if none have been registered or the observable is {@code null} > ``` > > ``` > unregisterListChangeListeners: > * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through > * {@link #registerListChangeListener(ObservableList, Consumer)}. If no consumers have been registered on this > * list, null will be returned. > ``` > > I find it confusing to say that the returned list "performs all removed operations". Some might interpret this to mean that is is somehow necessary to call the returned chained consumer as part of the removal, which isn't what you meant to say. > > How about something like this for both newly added unregister methods? > > ``` > * @return a composed consumer consisting of all previously registered consumers, or > * {@code null} if none have been registered or the observable is {@code null} > ``` agree: the _performs_ might be misleading. And I like your suggestion, though I modified it a bit to be consistent with the rest of the changed doc which focuses on "operations" (a term taken from Consumer api): * @return a composed consumer representing all previously registered operations, or * {@code null} if none have been registered or the observable is {@code null} ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From nlisker at openjdk.java.net Tue Apr 6 14:32:12 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 6 Apr 2021 14:32:12 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:08:39 GMT, Kevin Rushforth wrote: >>> Seems like I forgot to hit the send button on the webform. Here's the tracking number: 9069787. >> >> I see it now. And thanks for providing the benchmark. That's what I was looking for. > > The bug is now visible here: https://bugs.openjdk.java.net/browse/JDK-8264770 The benchmark might not tell the real story. To test these sorts of performance changes you have to use JMH. There's too much relating to JIT optimizations and JVM startup to be able to rely on the current benchmark. The theoretical point about invalidation listeners not boxing in comparison to change listeners is sound, so it won't be worse, but if we are looking for performance metrics, they need to be proper ones. ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From kcr at openjdk.java.net Tue Apr 6 14:57:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 14:57:14 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: References: <7RNOwM87fMcslFIFDFMxk6SQfs2x_7YKL5zaopEenk4=.09f1e9f4-6a72-44e5-8927-2ce31697745e@github.com> <014m7xF1F5SFx9g65ycNZLQy812dowU8jf3LrYED878=.9f6cf419-7e75-4e59-a75c-7b5ec1496ffd@github.com> Message-ID: On Tue, 6 Apr 2021 14:16:03 GMT, Jeanette Winzenburg wrote: >> I guess I didn't look closely enough. Mystery solved, though. > >> I haven't gone back and done a detailed review yet, but I like the overall changes. The one thing I did notice is that the language used to describe the return value of `unregisterInvalidationListeners` and `unregisterListChangeListeners` is different: >> > > just a side-note: technically, both are different because neither the new listChangeListener nor the old changeListener methods are updated yet (we are still at the first bullet of the plan, lazy me will update all to the same as the invalidationListener wording, once we agree on it :) > > So what we are arguing right now is the difference between new (= invalidationListener) and old (= listChangeListener == c&p from changeListener) method doc. > >> ``` >> unregisterInvalidationListeners: >> * @return a composed consumer that performs all removed operations, or >> * {@code null} if none have been registered or the observable is {@code null} >> ``` >> >> ``` >> unregisterListChangeListeners: >> * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through >> * {@link #registerListChangeListener(ObservableList, Consumer)}. If no consumers have been registered on this >> * list, null will be returned. >> ``` >> >> I find it confusing to say that the returned list "performs all removed operations". Some might interpret this to mean that is is somehow necessary to call the returned chained consumer as part of the removal, which isn't what you meant to say. >> >> How about something like this for both newly added unregister methods? >> >> ``` >> * @return a composed consumer consisting of all previously registered consumers, or >> * {@code null} if none have been registered or the observable is {@code null} >> ``` > > agree: the _performs_ might be misleading. And I like your suggestion, though I modified it a bit to be consistent with the rest of the changed doc which focuses on "operations" (a term taken from Consumer api): > > * @return a composed consumer representing all previously registered operations, or > * {@code null} if none have been registered or the observable is {@code null} I like this version, using "registered operations". ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From github.com+43553916+mstr2 at openjdk.java.net Tue Apr 6 15:29:13 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Tue, 6 Apr 2021 15:29:13 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 14:29:28 GMT, Nir Lisker wrote: > The benchmark might not tell the real story. To test these sorts of performance changes you have to use JMH. There's too much relating to JIT optimizations and JVM startup to be able to rely on the current benchmark. > The theoretical point about invalidation listeners not boxing in comparison to change listeners is sound, so it won't be worse, but if we are looking for performance metrics, they need to be proper ones. While true, my main motivation for this issue was that the original code is wrongly implemented because it claims to do one thing, but doesn't do that thing. So it's not primarily a question of optimization, but of correctness of the implementation. Anyway, here's a comparison benchmark done with JMH: @State(Scope.Benchmark) public class BindingBenchmark { DoubleProperty property1 = new SimpleDoubleProperty(); DoubleProperty property2 = new SimpleDoubleProperty(); public BindingBenchmark() { property2.bindBidirectional(property1); } @Benchmark public void benchmark() { for (int i = 0; i < 10000000; ++i) { property1.set((i % 2 == 0) ? 12345.0 : 54321.0); } } } | Benchmark | Mode | Cnt | Score | Error | Units | |-----------|------|-----|-------|-------|--------| | before | thrpt | 5 | 3.455| 0.029 | ops/s | | after | thrpt | 5 | 10.322 | 0.790 | ops/s | ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From github.com+66004280+maran23 at openjdk.java.net Tue Apr 6 15:43:43 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 6 Apr 2021 15:43:43 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button [v2] In-Reply-To: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: > When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. > This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). > Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8263807: Code review changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/432/files - new: https://git.openjdk.java.net/jfx/pull/432/files/f3dd7a2a..dc65db19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=432&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=432&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/432.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/432/head:pull/432 PR: https://git.openjdk.java.net/jfx/pull/432 From github.com+66004280+maran23 at openjdk.java.net Tue Apr 6 15:43:44 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 6 Apr 2021 15:43:44 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button [v2] In-Reply-To: References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: <06uX9jFuq22BHcQ71BNXcE3wIZyN8AnGknDVuleGuDg=.1683163b-8435-4422-a650-53197f759d9a@github.com> On Tue, 6 Apr 2021 12:06:05 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263807: Code review changes > > modules/javafx.controls/src/test/java/test/javafx/scene/control/DialogPaneTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, 2021, Oracle and/or its affiliates. All rights reserved. > > You need to revert this change. There must be only a single year listed if the start year and last modified year are the same. done ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From github.com+66004280+maran23 at openjdk.java.net Tue Apr 6 15:58:10 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 6 Apr 2021 15:58:10 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button [v2] In-Reply-To: References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: On Tue, 6 Apr 2021 12:18:49 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263807: Code review changes > > The fix and test look fine. There is one needed change as noted below. > > > Thanks for the explanation. I'll finish my review shortly. > > > Isn't jcheck running all the tests anyway? > > You mean GitHub Actions (jcheck doesn't build or run any tests). It would, but for two things: > > 1. You used the `master` branch of your repo, which is not recommended, and will cause problems for you if you ever do another pull request. See [this comment](https://github.com/openjdk/jfx/pull/432#issuecomment-801982830) added by the Skara bot. > > 2. You haven't enabled GitHub action on your personal fork of the `jfx` repository. See [wiki.openjdk.java.net/display/SKARA/Testing](https://wiki.openjdk.java.net/display/SKARA/Testing) for information on how to enable it. Oh okay, thanks for the clarification. Interesting enough I don't need to enable Github actions, they are already enabled for all other branches I pushed. I think because I forked OpenJFX after you added them. But as you mentioned they are not running for master. I pushed a separate branch based of master (so only this 2 commits made by me), the Github actions were successful: https://github.com/Maran23/jfx/actions/runs/723063232 ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From kcr at openjdk.java.net Tue Apr 6 16:06:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 16:06:12 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button [v2] In-Reply-To: References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: <85ab3opDXmLXTr_ZNpYiDAHYGAKKc8RYOKGkn69CTMQ=.e8b3bcab-b036-44f6-a743-a3f2a6465ff0@github.com> On Tue, 6 Apr 2021 15:43:43 GMT, Marius Hanl wrote: >> When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. >> This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). >> Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8263807: Code review changes Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From kcr at openjdk.java.net Tue Apr 6 16:06:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 6 Apr 2021 16:06:12 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button [v2] In-Reply-To: <85ab3opDXmLXTr_ZNpYiDAHYGAKKc8RYOKGkn69CTMQ=.e8b3bcab-b036-44f6-a743-a3f2a6465ff0@github.com> References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> <85ab3opDXmLXTr_ZNpYiDAHYGAKKc8RYOKGkn69CTMQ=.e8b3bcab-b036-44f6-a743-a3f2a6465ff0@github.com> Message-ID: On Tue, 6 Apr 2021 16:01:15 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263807: Code review changes > > Marked as reviewed by kcr (Lead). > Interesting enough I don't need to enable Github actions, they are already enabled for all other branches I pushed. I think because I forked OpenJFX after you added them. Yes, if you fork after GitHub actions were added, then no additional action should be needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From tsayao at openjdk.java.net Tue Apr 6 23:36:14 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 6 Apr 2021 23:36:14 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 22:25:55 GMT, Kevin Rushforth wrote: >> This PR filters out `GDK_TOUCH_EVENT_MASK` from `GDK_ALL_EVENTS_MASK` to prevent touch events from being used instead of regular mouse events on Linux platforms. Note that the touch events will be delivered as mouse pressed/dragged events. >> >> Since we still compile with GTK 2.x the bit flag (that was introduced in GTK 3.4) needs to be defined. >> >> This PR has been tested on Ubuntu 20.04 with a touch enabled display. > > @pankaj-bansal It looks OK to me, but can you also take a look at this? If anyone would implement touch events, the change would need to be rolled back? If you catch and consume touch events, would it also work? I don't own a touch device and `GTK_DEBUG=touchscreen` seems to work only with gtk signals (not gdk events). ------------- PR: https://git.openjdk.java.net/jfx/pull/457 From nlisker at gmail.com Wed Apr 7 01:41:33 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 7 Apr 2021 04:41:33 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> Message-ID: > > In the PoC I made I specifically also disallowed 'null' as an input > I like the way ReactFX does it where the property is empty. I think that this is also what you mean by disallowing `null` (in other contexts, "disallowing null" would mean throwing an exception). Not entirely sure what you mean by this. > Basically, what you said. My point was that this is a different API section. The first deals with expanding the observables/properties methods. The second with listeners methods. Even if mapping a property requires a new listening model, like subscriptions, this is done under the hood. Exposing this API should be a separate step. At least that's how I see it. I'd be happy to spend more time and work on this. Perhaps it would be > possible to collaborate on this? > That would be good. I will need to re-review the ReactFX internals and see how your proposal differs exactly. By the way, do you make a distinction between ReactFX's Val and Var in your proposal (one being read-only)? On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx wrote: > > > On 02/04/2021 08:47, Nir Lisker wrote: > > Hi John, > > > > I've had my eyes set on ReactFX enhancements for a while too, especially > as > > a replacement for the unsafe "select" mechanism. One of the things that > > kept me from going forward with this is seeing what Valhalla will bring. > > Generic specialization might save a lot of duplication work on something > > like this, and Tomas touched another related issue [1], but since it > could > > be a long time before that happens, it's worth planning what we can > extract > > from ReactFX currently. > > Agreed, Valhalla is certainly a highly anticipated feature but I fear it > is still a couple of years away. > > Even without any initial support for dealing with "? extends Number" > from the various ObservableValue specializations I think looking into > this can already be tremendous help. > > The proof of concept mainly requires you convert the Number to a > suitable type when reading the property but has no problems in the other > direction: > > label.widthProperty().map(Number::doubleValue).map(x -> x + 1); > > Not pretty, but certainly workable. Specific methods could be introduced > (even at a later time) to make this more streamlined, similar to what > the Stream API offers with 'mapToDouble' etc. > > > I think that we should break the enhancements into parts. > > The first that I would advise to look at are the additions to > > properties/observables. Tomas had to create Val and Var because he > couldn't > > change the core interfaces, but we can. Fitting them with the Optional > > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. `flatMap` etc.; > > and `select` and friends, is already a good start that will address many > > common requirements. > > Yes, Val/Var had to be created for that reason, and also because > properties don't quite behave the same as streams -- streams with a > "toBinding" method results in things people didn't quite expect. > > As far as the Optional methods go, I'm not entirely sure properties > would benefit from all of them. Properties are not immutable like > Optional and it may make less sense to fit them with 'isPresent', > 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to behave > similar to 'addListener' or 'subscribe'). > > In the PoC I made I specifically also disallowed 'null' as an input for > functions like 'map' and 'flatMap' (opting to use 'orElse' semantics for > 'null'), as this for allows much cleaner mapping (and especially flat > mapping when selecting nested properties). If 'null' were to be allowed, > I think at a minimum we'd need to add another method to allow for easy > selecting of nested properties to avoid: > > obs.flatMap(x -> x == null ? null : x.otherProperty()) > > > The second part is related to listeners. The subscription model and event > > streams try to solve the memory issues with hard and weak references, and > > allow better composition. > > Not entirely sure what you mean by this. JavaFX's current model uses > weak references which was I think an unfortunate decision as it can > result in huge confusion. For example, a direct binding will work, but > with an indirection step a binding stops working: > > button.textProperty() > .concat("World") // weak binding used here > .addListener((obs, old, cur) -> System.out.println(cur)); > > The above stops working, but without the 'concat' it keeps working. > > I think the use of weak listeners should be avoided and instead other > mechanisms should be provided to make cleaning up easier. This is the > main reason for 'conditionOn' and why ReactFX even had a specialized > version of it: 'conditionOnShowing(Node)'. > > > The third part is for collections - things like transformation lists > > (LiveList) and for other collections. > > This is indeed best saved for last. The problems there I think are less > of an issue for now. > > > Since these share behavior under the hood, we need to look ahead, but in > > terms of functionality, I think we should take smaller steps. It will > also > > be easier to propose these then. > > I've for this reason kept the PoC small with only the most basic > functionality. I did however add some work for a different subscription > model, mainly because the internals of this code benefits greatly from > it. It is however kept to a minimum. > > I'd be happy to spend more time and work on this. Perhaps it would be > possible to collaborate on this? > > --John > > > > > - Nir > > > > [1] > > > https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue > > > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx wrote: > > > >> I just wanted to draw some attention to a recent proof of concept I made > >> in this pull request: https://github.com/openjdk/jfx/pull/434 > >> > >> It is based on the work I did in > >> https://github.com/hjohn/hs.jfx.eventstream which is in part based on > >> work done in ReactFX by Tomas Mikula. The PR itself however shares no > >> code with ReactFX and is > >> completely written by me. > >> > >> If there is interest, I'm willing to invest more time in smoothing out > >> the API and documentation, investigating further how this would interact > >> with the primitive types and adding unit test coverage (I have extensive > >> tests, but thesea are written in JUnit 5, so they would require > >> conversion or JavaFX could move to support JUnit 5). > >> > >> What follows below is the text of the PR for easy reading. Feedback is > >> appreciated. > >> > >> ================ > >> > >> This is a proof of concept of how fluent bindings could be introduced to > >> JavaFX. The main benefit of fluent bindings are ease of use, type safety > >> and less surprises. Features: > >> > >> Flexible Mappings > >> Map the contents of a property any way you like with map, or map nested > >> properties with flatMap. > >> > >> Lazy > >> The bindings created are lazy, which means they are always invalid when > >> not themselves observed. This allows for easier garbage collection (once > >> the last observer is removed, a chain of bindings will stop observing > >> their parents) and less listener management when dealing with nested > >> properties. Furthermore, this allows inclusion of such bindings in > >> classes such as Node without listeners being created when the binding > >> itself is not used (this would allow for the inclusion of a > >> treeShowingProperty in Node without creating excessive listeners, see > >> this fix I did in an earlier PR: #185) > >> > >> Null Safe > >> The map and flatMap methods are skipped, similar to java.util.Optional > >> when the value they would be mapping is null. This makes mapping nested > >> properties with flatMap trivial as the null case does not need to be > >> taken into account in a chain like this: > >> > node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). > >> > >> Instead a default can be provided with orElse or orElseGet. > >> > >> Conditional Bindings > >> Bindings can be made conditional using the conditionOn method. A > >> conditional binding retains its last value when its condition is false. > >> Conditional bindings donot observe their source when the condition is > >> false, allowing developers to automatically stop listening to properties > >> when a certain condition is met. A major use of this feature is to have > >> UI components that need to keep models updated which may outlive the UI > >> conditionally update the long lived model only when the UI is showing. > >> > >> Some examples: > >> > >> void mapProperty() { > >> // Standard JavaFX: > >> label.textProperty().bind(Bindings.createStringBinding(() -> > >> text.getValueSafe().toUpperCase(), text)); > >> > >> // Fluent: much more compact, no need to handle null > >> label.textProperty().bind(text.map(String::toUpperCase)); > >> } > >> > >> void calculateCharactersLeft() { > >> // Standard JavaFX: > >> > >> > label.textProperty().bind(text.length().negate().add(100).asString().concat(" > >> > >> characters left")); > >> > >> // Fluent: slightly more compact and more clear (no negate needed) > >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + > >> " characters left")); > >> } > >> > >> void mapNestedValue() { > >> // Standard JavaFX: > >> label.textProperty().bind(Bindings.createStringBinding( > >> () -> employee.get() == null ? "" > >> : employee.get().getCompany() == null ? "" > >> : employee.get().getCompany().getName(), > >> employee > >> )); > >> > >> // Fluent: no need to handle nulls everywhere > >> label.textProperty().bind( > >> employee.map(Employee::getCompany) > >> .map(Company::getName) > >> .orElse("") > >> ); > >> } > >> > >> void mapNestedProperty() { > >> // Standard JavaFX: > >> label.textProperty().bind( > >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), > >> "window", "showing")) > >> .then("Visible") > >> .otherwise("Not Visible") > >> ); > >> > >> // Fluent: type safe > >> label.textProperty().bind(label.sceneProperty() > >> .flatMap(Scene::windowProperty) > >> .flatMap(Window::showingProperty) > >> .orElse(false) > >> .map(showing -> showing ? "Visible" : "Not Visible") > >> ); > >> } > >> > >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { > >> // Standard JavaFX: naive, memory leak; UI won't get garbage > collected > >> listView.getSelectionModel().selectedItemProperty().addListener( > >> (obs, old, current) -> > >> longLivedModel.lastSelectedProperty().set(current) > >> ); > >> > >> // Standard JavaFX: no leak, but stops updating after a while > >> listView.getSelectionModel().selectedItemProperty().addListener( > >> new WeakChangeListener<>( > >> (obs, old, current) -> > >> longLivedModel.lastSelectedProperty().set(current) > >> ) > >> ); > >> > >> // Standard JavaFX: fixed version > >> listenerReference = (obs, old, current) -> > >> longLivedModel.lastSelectedProperty().set(current); > >> > >> listView.getSelectionModel().selectedItemProperty().addListener( > >> new WeakChangeListener<>(listenerReference) > >> ); > >> > >> // Fluent: naive, memory leak... fluent won't solve this... > >> listView.getSelectionModel().selectedItemProperty() > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > >> > >> // Fluent: conditional update when control visible > >> > >> // Create a property which is only true when the UI is visible: > >> ObservableValue showing = listView.sceneProperty() > >> .flatMap(Scene::windowProperty) > >> .flatMap(Window::showingProperty) > >> .orElse(false); > >> > >> // Use showing property to automatically disconnect long lived model > >> // allowing garbage collection of the UI: > >> listView.getSelectionModel().selectedItemProperty() > >> .conditionOn(showing) > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > >> > >> // Note that the 'showing' property can be provided in multiple ways: > >> // - create manually (can be re-used for multiple bindings though) > >> // - create with a helper: Nodes.showing(Node node) -> > >> ObservableValue > >> // - make it part of the Node class; as the fluent bindings only bind > >> themselves > >> // to their source when needed (lazy binding), this won't create > >> overhead > >> // for each node in the scene > >> } > >> Note that this is based on ideas in ReactFX and my own experiments in > >> https://github.com/hjohn/hs.jfx.eventstream. I've come to the > conclusion > >> that this is much better directly integrated into JavaFX, and I'm hoping > >> this proof of concept will be able to move such an effort forward. > >> > >> --John > >> > > > From jvos at openjdk.java.net Wed Apr 7 08:11:12 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 7 Apr 2021 08:11:12 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 23:32:53 GMT, Thiago Milczarek Sayao wrote: > If anyone would implement touch events, the change would need to be rolled back? Yes, *if* touch events would be implemented properly at a native level, this change will need to be rolled back. This can be a follow-up issue, but it seems less urgent to me than this particular fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/457 From tom.schindl at bestsolution.at Wed Apr 7 08:53:54 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 7 Apr 2021 10:53:54 +0200 Subject: javafx-swt not deployed on maven central Message-ID: Hi, I'm not sure where to report this but it looks like the javafx-swt.jar is not deployed on maven central. Is there a reason? Tom From fastegal at openjdk.java.net Wed Apr 7 11:06:53 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 7 Apr 2021 11:06:53 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v7] In-Reply-To: References: Message-ID: <9K3FbeFmuWLvkCDrbudGSj7CO6GzTIHCiT9CkQeft3U=.ff87ac37-1aae-427c-ba03-cff4cf3e6865@github.com> > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: updated doc of list/Change methods that of invalidation methods ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/e7849b21..0736fe52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=05-06 Stats: 37 lines in 1 file changed: 5 ins; 4 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From github.com+17347324+torbuntu at openjdk.java.net Wed Apr 7 11:26:15 2021 From: github.com+17347324+torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Wed, 7 Apr 2021 11:26:15 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 08:08:40 GMT, Johan Vos wrote: >> If anyone would implement touch events, the change would need to be rolled back? >> >> If you catch and consume touch events, would it also work? >> >> I mean on `GlassApplication.cpp` -> `process_events`: >> >> case GDK_TOUCH_BEGIN: >> case GDK_TOUCH_UPDATE: >> case GDK_TOUCH_END: >> case GDK_TOUCH_CANCEL: >> gtk_main_do_event(event); >> >> >> >> >> I don't own a touch device and `GTK_DEBUG=touchscreen` seems to work only with gtk signals (not gdk events). > >> If anyone would implement touch events, the change would need to be rolled back? > > Yes, *if* touch events would be implemented properly at a native level, this change will need to be rolled back. This can be a follow-up issue, but it seems less urgent to me than this particular fix. I've started working on trying to get the touch support available on Linux, and have a branch started here: https://github.com/torbuntu/jfx/tree/touch-support Still trying to get everything wired up properly. ------------- PR: https://git.openjdk.java.net/jfx/pull/457 From fkirmaier at openjdk.java.net Wed Apr 7 11:37:23 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 7 Apr 2021 11:37:23 GMT Subject: Integrated: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 21:49:36 GMT, Florian Kirmaier wrote: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup This pull request has now been integrated. Changeset: 9796a83f Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/9796a83f Stats: 280 lines in 9 files changed: 280 ins; 0 del; 0 mod 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From arapte at openjdk.java.net Wed Apr 7 11:44:17 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 7 Apr 2021 11:44:17 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v4] In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 12:02:40 GMT, Florian Kirmaier wrote: >> Fixing a memory leak. >> A node hard references its old parent after CSS layout and getting removed. >> This shouldn't be the case, this is very counterintuitive. >> >> The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. >> This should be fine because the CSS should only depend on it if it's still the real parent. >> In that case, it doesn't get collected. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8263402 > Minor cleanup based on codereview looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Wed Apr 7 11:56:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 7 Apr 2021 11:56:25 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:35:02 GMT, Florian Kirmaier wrote: >> @FlorianKirmaier The CSR needs to be updated (fixVersion set to `openjfx17`) and moved to Finalize again. > > The fixVersion is now openfjx17 and it's moved to "Finalized" Looks like the Skara bot is in a loop continually reprocessing the `sponsor` command it already processed. I filed [SKARA-956](https://bugs.openjdk.java.net/browse/SKARA-956) to track this. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Apr 7 12:36:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 7 Apr 2021 12:36:37 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:59:52 GMT, Jose Pereda wrote: > This PR filters out `GDK_TOUCH_EVENT_MASK` from `GDK_ALL_EVENTS_MASK` to prevent touch events from being used instead of regular mouse events on Linux platforms. Note that the touch events will be delivered as mouse pressed/dragged events. > > Since we still compile with GTK 2.x the bit flag (that was introduced in GTK 3.4) needs to be defined. > > This PR has been tested on Ubuntu 20.04 with a touch enabled display. I think we can proceed with this PR. It can be adjusted (or reverted) if touch support is added in the future. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/457 From jvos at openjdk.java.net Wed Apr 7 12:40:37 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 7 Apr 2021 12:40:37 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:59:52 GMT, Jose Pereda wrote: > This PR filters out `GDK_TOUCH_EVENT_MASK` from `GDK_ALL_EVENTS_MASK` to prevent touch events from being used instead of regular mouse events on Linux platforms. Note that the touch events will be delivered as mouse pressed/dragged events. > > Since we still compile with GTK 2.x the bit flag (that was introduced in GTK 3.4) needs to be defined. > > This PR has been tested on Ubuntu 20.04 with a touch enabled display. This fixes a current issue, and while a solution that adds native touch-event support is highly encouraged, this fix will already improve the current situation. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/457 From jpereda at openjdk.java.net Wed Apr 7 12:46:33 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 7 Apr 2021 12:46:33 GMT Subject: Integrated: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:59:52 GMT, Jose Pereda wrote: > This PR filters out `GDK_TOUCH_EVENT_MASK` from `GDK_ALL_EVENTS_MASK` to prevent touch events from being used instead of regular mouse events on Linux platforms. Note that the touch events will be delivered as mouse pressed/dragged events. > > Since we still compile with GTK 2.x the bit flag (that was introduced in GTK 3.4) needs to be defined. > > This PR has been tested on Ubuntu 20.04 with a touch enabled display. This pull request has now been integrated. Changeset: cc94e967 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/cc94e967 Stats: 15 lines in 3 files changed: 10 ins; 0 del; 5 mod 8217955: Problems with touch input and JavaFX 11 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/457 From nlisker at openjdk.java.net Wed Apr 7 13:14:19 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 7 Apr 2021 13:14:19 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v7] In-Reply-To: <9K3FbeFmuWLvkCDrbudGSj7CO6GzTIHCiT9CkQeft3U=.ff87ac37-1aae-427c-ba03-cff4cf3e6865@github.com> References: <9K3FbeFmuWLvkCDrbudGSj7CO6GzTIHCiT9CkQeft3U=.ff87ac37-1aae-427c-ba03-cff4cf3e6865@github.com> Message-ID: On Wed, 7 Apr 2021 11:06:53 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > updated doc of list/Change methods that of invalidation methods modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 221: > 219: * may be {@code null} > 220: */ > 221: protected final void registerChangeListener(ObservableValue property, Consumer> operation) { Maybe instead of `property` use `observable` like with the invalidation methods to not confuse it with the `Property` interface. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From ajoseph at openjdk.java.net Wed Apr 7 13:32:49 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 7 Apr 2021 13:32:49 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 Message-ID: We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. http://site.icu-project.org/home ------------- Commit messages: - Add UPDATING.txt file - Update license - Modify exec files - Add icudt68l repo - Remove icudt file - 8260245: Update ICU4C to version 68.2 Changes: https://git.openjdk.java.net/jfx/pull/456/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=456&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260245 Stats: 45770 lines in 673 files changed: 24662 ins; 8082 del; 13026 mod Patch: https://git.openjdk.java.net/jfx/pull/456.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/456/head:pull/456 PR: https://git.openjdk.java.net/jfx/pull/456 From kcr at openjdk.java.net Wed Apr 7 13:32:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 7 Apr 2021 13:32:49 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:14:36 GMT, Arun Joseph wrote: > We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. > http://site.icu-project.org/home Overall this looks good. I'll review / test it in detail later. Quick comments on the PR: 1. You need to update the version number in `.../legal/icu_web.md` 2. Related to the above, can you create a new `UPDATING.txt` file in `.../native/Source/ThirdParty/icu` with instructions as to what needs to be updated when updating to a new ICU version, specifically including the changes to `build.gradle`, `.../legal/icu_web.md`, and `/native/Source/ThirdParty/icu/CMakeLists.txt` regarding updating the version number, along with anything else that isn't obvious (although I think the rest is straight-forward)? 3. Will the changes in core WebKit code (e.g., `TRUE` --> `true`) cause merge conflicts in the future? Also, since this also addresses [JDK-8232379](https://bugs.openjdk.java.net/browse/JDK-8232379), can you add it to this PR with `/issue add 8232379`? ------------- PR: https://git.openjdk.java.net/jfx/pull/456 From ajoseph at openjdk.java.net Wed Apr 7 13:32:50 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 7 Apr 2021 13:32:50 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 19:09:19 GMT, Kevin Rushforth wrote: >> We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. >> http://site.icu-project.org/home > > Overall this looks good. I'll review / test it in detail later. > > Quick comments on the PR: > > 1. You need to update the version number in `.../legal/icu_web.md` > 2. Related to the above, can you create a new `UPDATING.txt` file in `.../native/Source/ThirdParty/icu` with instructions as to what needs to be updated when updating to a new ICU version, specifically including the changes to `build.gradle`, `.../legal/icu_web.md`, and `/native/Source/ThirdParty/icu/CMakeLists.txt` regarding updating the version number, along with anything else that isn't obvious (although I think the rest is straight-forward)? > 3. Will the changes in core WebKit code (e.g., `TRUE` --> `true`) cause merge conflicts in the future? > > Also, since this also addresses [JDK-8232379](https://bugs.openjdk.java.net/browse/JDK-8232379), can you add it to this PR with `/issue add 8232379`? The other WebKit changes are present in the upstream repo as well (https://bugs.webkit.org/show_bug.cgi?id=218522). ------------- PR: https://git.openjdk.java.net/jfx/pull/456 From kcr at openjdk.java.net Wed Apr 7 13:42:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 7 Apr 2021 13:42:16 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v4] In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 12:02:40 GMT, Florian Kirmaier wrote: >> Fixing a memory leak. >> A node hard references its old parent after CSS layout and getting removed. >> This shouldn't be the case, this is very counterintuitive. >> >> The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. >> This should be fine because the CSS should only depend on it if it's still the real parent. >> In that case, it doesn't get collected. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8263402 > Minor cleanup based on codereview The fix looks OK, although I left a question below about ensuring that there cannot be an NPE. The test doesn't catch the bug on my system (Windows 10). Even when I run it without your fix, it passes. Is it platform-specific? modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 355: > 353: /* This is the first Styleable parent (of Node this StyleHelper belongs to) > 354: * having a valid StyleHelper */ > 355: private WeakReference firstStyleableAncestor = null; Since `firstStyleableAncestor` is initialized to `null`, rather than `new WeakReference(null)`, it might be possible for a call to `firstStyleableAncestor.get()` to throw an NPE. Can you comment on what analysis and testing you've done to ensure that this won't happen in some situations? A quick look shows that in the two places a `CssStyleHelper` object is created, `firstStyleableAncestor` is set shortly after, but it wouldn't hurt to take a closer look. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Wed Apr 7 13:49:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 7 Apr 2021 13:49:15 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:10:29 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263402 >> Minor cleanup based on codereview > > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 355: > >> 353: /* This is the first Styleable parent (of Node this StyleHelper belongs to) >> 354: * having a valid StyleHelper */ >> 355: private WeakReference firstStyleableAncestor = null; > > Since `firstStyleableAncestor` is initialized to `null`, rather than `new WeakReference(null)`, it might be possible for a call to `firstStyleableAncestor.get()` to throw an NPE. Can you comment on what analysis and testing you've done to ensure that this won't happen in some situations? A quick look shows that in the two places a `CssStyleHelper` object is created, `firstStyleableAncestor` is set shortly after, but it wouldn't hurt to take a closer look. One solution would be to create an `EMPTY_NODE` singleton and initialize it to that: private static final WeakReference EMPTY_NODE = new WeakReference<>(null); private WeakReference firstStyleableAncestor = EMPTY_NODE; ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From jvos at openjdk.java.net Wed Apr 7 13:50:15 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 7 Apr 2021 13:50:15 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:14:36 GMT, Arun Joseph wrote: > We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. > http://site.icu-project.org/home build.gradle line 1914: > 1912: } > 1913: patternLayout { > 1914: artifact "download/release-68-2/[artifact].[ext]" shouldn't 68-2 be a property? ------------- PR: https://git.openjdk.java.net/jfx/pull/456 From arapte at openjdk.java.net Wed Apr 7 15:28:31 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 7 Apr 2021 15:28:31 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v2] In-Reply-To: References: Message-ID: <8oNU4aPYxct986B-ayRWzPFTLwLfhiGjLfEWkT0Bn98=.16f410cf-9984-4686-bd12-4f10e6db37e6@github.com> On Tue, 6 Apr 2021 12:24:36 GMT, Florian Kirmaier wrote: >> Fixing leak in ProgressIndicator when treeShowing is false > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264677 > changes based on code review Suggested a minor change. The test file has an existing test `memoryTest()`. The `AfterClass` and `BeforeClass` methods are specific to this test, and not related to the new test. It looks little unstructured with addition of this new test. Not sure if it is worth to change the helper methods and existing test. otherwise the fix and test looks good. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 93: > 91: > 92: @Test > 93: public void treeNotShowing() throws Exception { Minor: recommend changing name, may be `stageLeakWhenTreeNotShowing` ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From hjohn at xs4all.nl Wed Apr 7 20:30:27 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 7 Apr 2021 22:30:27 +0200 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> Message-ID: <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> On 07/04/2021 03:41, Nir Lisker wrote: > In the PoC I made I specifically also disallowed 'null' as an input > > > I like the way ReactFX does it where the property is empty. I think that > this is also what you mean by disallowing `null` (in other contexts, > "disallowing null" would mean throwing an exception). Yes, it is the same concept as ReactFX calling a property "empty", but I was hesitant to call this as `null` is a valid value for many JavaFX properties (a Scene can be null, a String can be null, etc.) which I don't think means the same as it being empty (in the Optional sense). But as long as the documentation is clear, I don't mind calling it either. > > Not entirely sure what you mean by this. > > > Basically, what you said. My point was that this is a different API > section. The first deals with expanding the observables/properties > methods. The second with listeners methods. Even if mapping a property > requires a new listening model, like subscriptions, this is done under > the hood. Exposing this API should be a separate step. At least that's > how I see it. Yes, I think it is good to limit new API as much as possible to reduce scope and increase the chances of its acceptance. The subscription parts can be designed separately and do not need to be public at this point. They can be moved to a helper, or the implementation can take the extra effort to use standard listeners. > > I'd be happy to spend more time and work on this. Perhaps it would be > possible to collaborate on this? > > > That would be good. I will need to re-review the ReactFX internals and > see how your proposal differs exactly. Yes, I think that would be good to do. I've done some comparisons myself and didn't find a difference in functionality with `Val` (so far). It is a new implementation though, I didn't really look at how `Val` was done internally as implementing it directly into JavaFX is quite different (I had to make a few minor changes in `ObjectBinding` to allow for the choice of lazy binding). I was also initially more focused on Streams only to realize at a later point that having a Stream implement ObservableValue was not going to be pretty (I suspect this also happened when ReactFX was created, which is why Val/Var were later introduced in 2.x). Both the PoC and Val do lazy binding and are null safe and provide methods to deal with null/empty. The main thing I didn't do yet is provide a `filter` method. Filtering properties that you want to use for bindings seems awkard as a binding should always have some kind of value. The `filter` method in ReactFX basically maps the value to `null` when it doesn't match the filter. I've left this out as you can easily achieve this with `map` and `filter` seems to be too easy to misunderstand. Aside from that, ReactFX's Val offers a lot of other methods that are I think a bit too specialized to consider at this point, like the `animate`, `pin`, `mapDynamic` and `suspendable` methods. Val also has all the other `Optional` methods (ifPresent, isPresent, isEmpty) but I think they may make the API a bit confusing (an observable value is not the same as an optional). I've also not had a need for these so far in practice and you can easily convert the current value to get this functionality with `Optional.ofNullable`. Finally Val offers a few methods to convert to ReactFX's streams. While convenient, I think static methods like `Values.of`, `Invalidations.of` or `Changes.of` would make for a less cluttered API to do stream conversions -- this would also make it possible to leave this part of the API up to a 3rd party. > By the way, do you make a distinction between ReactFX's Val and Var in > your proposal (one being read-only)? No, `ObservableValue` is basically the same as `Val`, and the equivalent to `Var` is `ObjectProperty`. Aside from it being a good companion to `Val` (and less typing), I don't see a reason to implement `Var`. --John > > On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx > wrote: > > > > On 02/04/2021 08:47, Nir Lisker wrote: > > Hi John, > > > > I've had my eyes set on ReactFX enhancements for a while too, > especially as > > a replacement for the unsafe "select" mechanism. One of the things > that > > kept me from going forward with this is seeing what Valhalla will > bring. > > Generic specialization might save a lot of duplication work on > something > > like this, and Tomas touched another related issue [1], but since > it could > > be a long time before that happens, it's worth planning what we > can extract > > from ReactFX currently. > > Agreed, Valhalla is certainly a highly anticipated feature but I > fear it > is still a couple of years away. > > Even without any initial support for dealing with "? extends Number" > from the various ObservableValue specializations I think looking into > this can already be tremendous help. > > The proof of concept mainly requires you convert the Number to a > suitable type when reading the property but has no problems in the > other > direction: > > label.widthProperty().map(Number::doubleValue).map(x -> x + 1); > > Not pretty, but certainly workable. Specific methods could be > introduced > (even at a later time) to make this more streamlined, similar to what > the Stream API offers with 'mapToDouble' etc. > > > I think that we should break the enhancements into parts. > > The first that I would advise to look at are the additions to > > properties/observables. Tomas had to create Val and Var because he > couldn't > > change the core interfaces, but we can. Fitting them with the Optional > > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. `flatMap` > etc.; > > and `select` and friends, is already a good start that will > address many > > common requirements. > > Yes, Val/Var had to be created for that reason, and also because > properties don't quite behave the same as streams -- streams with a > "toBinding" method results in things people didn't quite expect. > > As far as the Optional methods go, I'm not entirely sure properties > would benefit from all of them. Properties are not immutable like > Optional and it may make less sense to fit them with 'isPresent', > 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to behave > similar to 'addListener' or 'subscribe'). > > In the PoC I made I specifically also disallowed 'null' as an input for > functions like 'map' and 'flatMap' (opting to use 'orElse' semantics > for > 'null'), as this for allows much cleaner mapping (and especially flat > mapping when selecting nested properties). If 'null' were to be > allowed, > I think at a minimum we'd need to add another method to allow for easy > selecting of nested properties to avoid: > > obs.flatMap(x -> x == null ? null : x.otherProperty()) > > > The second part is related to listeners. The subscription model > and event > > streams try to solve the memory issues with hard and weak > references, and > > allow better composition. > > Not entirely sure what you mean by this. JavaFX's current model uses > weak references which was I think an unfortunate decision as it can > result in huge confusion. For example, a direct binding will work, but > with an indirection step a binding stops working: > > button.textProperty() > .concat("World") // weak binding used here > .addListener((obs, old, cur) -> System.out.println(cur)); > > The above stops working, but without the 'concat' it keeps working. > > I think the use of weak listeners should be avoided and instead other > mechanisms should be provided to make cleaning up easier. This is the > main reason for 'conditionOn' and why ReactFX even had a specialized > version of it: 'conditionOnShowing(Node)'. > > > The third part is for collections - things like transformation lists > > (LiveList) and for other collections. > > This is indeed best saved for last. The problems there I think are less > of an issue for now. > > > Since these share behavior under the hood, we need to look ahead, > but in > > terms of functionality, I think we should take smaller steps. It > will also > > be easier to propose these then. > > I've for this reason kept the PoC small with only the most basic > functionality. I did however add some work for a different > subscription > model, mainly because the internals of this code benefits greatly from > it. It is however kept to a minimum. > > I'd be happy to spend more time and work on this. Perhaps it would be > possible to collaborate on this? > > --John > > > > > - Nir > > > > [1] > > > https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue > > > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx > wrote: > > > >> I just wanted to draw some attention to a recent proof of concept > I made > >> in this pull request: https://github.com/openjdk/jfx/pull/434 > >> > >> It is based on the work I did in > >> https://github.com/hjohn/hs.jfx.eventstream which is in part based on > >> work done in ReactFX by Tomas Mikula. The PR itself however shares no > >> code with ReactFX and is > >> completely written by me. > >> > >> If there is interest, I'm willing to invest more time in > smoothing out > >> the API and documentation, investigating further how this would > interact > >> with the primitive types and adding unit test coverage (I have > extensive > >> tests, but thesea are written in JUnit 5, so they would require > >> conversion or JavaFX could move to support JUnit 5). > >> > >> What follows below is the text of the PR for easy reading. > Feedback is > >> appreciated. > >> > >> ================ > >> > >> This is a proof of concept of how fluent bindings could be > introduced to > >> JavaFX. The main benefit of fluent bindings are ease of use, type > safety > >> and less surprises. Features: > >> > >> Flexible Mappings > >> Map the contents of a property any way you like with map, or map > nested > >> properties with flatMap. > >> > >> Lazy > >> The bindings created are lazy, which means they are always > invalid when > >> not themselves observed. This allows for easier garbage > collection (once > >> the last observer is removed, a chain of bindings will stop observing > >> their parents) and less listener management when dealing with nested > >> properties. Furthermore, this allows inclusion of such bindings in > >> classes such as Node without listeners being created when the binding > >> itself is not used (this would allow for the inclusion of a > >> treeShowingProperty in Node without creating excessive listeners, see > >> this fix I did in an earlier PR: #185) > >> > >> Null Safe > >> The map and flatMap methods are skipped, similar to > java.util.Optional > >> when the value they would be mapping is null. This makes mapping > nested > >> properties with flatMap trivial as the null case does not need to be > >> taken into account in a chain like this: > >> > node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). > >> > >> Instead a default can be provided with orElse or orElseGet. > >> > >> Conditional Bindings > >> Bindings can be made conditional using the conditionOn method. A > >> conditional binding retains its last value when its condition is > false. > >> Conditional bindings donot observe their source when the condition is > >> false, allowing developers to automatically stop listening to > properties > >> when a certain condition is met. A major use of this feature is > to have > >> UI components that need to keep models updated which may outlive > the UI > >> conditionally update the long lived model only when the UI is > showing. > >> > >> Some examples: > >> > >> void mapProperty() { > >> // Standard JavaFX: > >> label.textProperty().bind(Bindings.createStringBinding(() -> > >> text.getValueSafe().toUpperCase(), text)); > >> > >> // Fluent: much more compact, no need to handle null > >> label.textProperty().bind(text.map(String::toUpperCase)); > >> } > >> > >> void calculateCharactersLeft() { > >> // Standard JavaFX: > >> > >> > label.textProperty().bind(text.length().negate().add(100).asString().concat(" > >> > >> characters left")); > >> > >> // Fluent: slightly more compact and more clear (no negate needed) > >> label.textProperty().bind(text.orElse("").map(v -> 100 - > v.length() + > >> " characters left")); > >> } > >> > >> void mapNestedValue() { > >> // Standard JavaFX: > >> label.textProperty().bind(Bindings.createStringBinding( > >> () -> employee.get() == null ? "" > >> : employee.get().getCompany() == null ? "" > >> : employee.get().getCompany().getName(), > >> employee > >> )); > >> > >> // Fluent: no need to handle nulls everywhere > >> label.textProperty().bind( > >> employee.map(Employee::getCompany) > >> .map(Company::getName) > >> .orElse("") > >> ); > >> } > >> > >> void mapNestedProperty() { > >> // Standard JavaFX: > >> label.textProperty().bind( > >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), > >> "window", "showing")) > >> .then("Visible") > >> .otherwise("Not Visible") > >> ); > >> > >> // Fluent: type safe > >> label.textProperty().bind(label.sceneProperty() > >> .flatMap(Scene::windowProperty) > >> .flatMap(Window::showingProperty) > >> .orElse(false) > >> .map(showing -> showing ? "Visible" : "Not Visible") > >> ); > >> } > >> > >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { > >> // Standard JavaFX: naive, memory leak; UI won't get garbage > collected > >> listView.getSelectionModel().selectedItemProperty().addListener( > >> (obs, old, current) -> > >> longLivedModel.lastSelectedProperty().set(current) > >> ); > >> > >> // Standard JavaFX: no leak, but stops updating after a while > >> listView.getSelectionModel().selectedItemProperty().addListener( > >> new WeakChangeListener<>( > >> (obs, old, current) -> > >> longLivedModel.lastSelectedProperty().set(current) > >> ) > >> ); > >> > >> // Standard JavaFX: fixed version > >> listenerReference = (obs, old, current) -> > >> longLivedModel.lastSelectedProperty().set(current); > >> > >> listView.getSelectionModel().selectedItemProperty().addListener( > >> new WeakChangeListener<>(listenerReference) > >> ); > >> > >> // Fluent: naive, memory leak... fluent won't solve this... > >> listView.getSelectionModel().selectedItemProperty() > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > >> > >> // Fluent: conditional update when control visible > >> > >> // Create a property which is only true when the UI is visible: > >> ObservableValue showing = listView.sceneProperty() > >> .flatMap(Scene::windowProperty) > >> .flatMap(Window::showingProperty) > >> .orElse(false); > >> > >> // Use showing property to automatically disconnect long lived > model > >> // allowing garbage collection of the UI: > >> listView.getSelectionModel().selectedItemProperty() > >> .conditionOn(showing) > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > >> > >> // Note that the 'showing' property can be provided in > multiple ways: > >> // - create manually (can be re-used for multiple bindings though) > >> // - create with a helper: Nodes.showing(Node node) -> > >> ObservableValue > >> // - make it part of the Node class; as the fluent bindings > only bind > >> themselves > >> // to their source when needed (lazy binding), this won't create > >> overhead > >> // for each node in the scene > >> } > >> Note that this is based on ideas in ReactFX and my own experiments in > >> https://github.com/hjohn/hs.jfx.eventstream. I've come to the > conclusion > >> that this is much better directly integrated into JavaFX, and I'm > hoping > >> this proof of concept will be able to move such an effort forward. > >> > >> --John > >> > > > From kcr at openjdk.java.net Wed Apr 7 23:30:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 7 Apr 2021 23:30:16 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:14:36 GMT, Arun Joseph wrote: > We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. > http://site.icu-project.org/home I did a review of all change not in the ThirdParty/icu. All looks good to me. There is one more instance of the hard-coded `68.2` that could be defined as a property. I've done sanity testing on Windows and and Mac. No problems that I can see. I'll do a bit more testing. build.gradle line 3383: > 3381: dependencies { > 3382: if (IS_COMPILE_WEBKIT) { > 3383: icu name: "icu4c-68.2-data-bin-l", ext: "zip" I think the `68.2` could also be a property. ------------- PR: https://git.openjdk.java.net/jfx/pull/456 From aghaisas at openjdk.java.net Thu Apr 8 11:56:13 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 8 Apr 2021 11:56:13 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button [v2] In-Reply-To: References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: On Tue, 6 Apr 2021 15:43:43 GMT, Marius Hanl wrote: >> When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. >> This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). >> Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8263807: Code review changes Marked as reviewed by aghaisas (Reviewer). Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From jvos at openjdk.java.net Thu Apr 8 12:23:27 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 8 Apr 2021 12:23:27 GMT Subject: RFR: 8264886: WebKit native to Java invocations on wrong thread Message-ID: <2D_bRgHchnLscPscKBCoIAlkicrx0lLO3BrLII2WqIc=.763f994e-6d56-44f7-a6c4-19052e09d761@github.com> Fix for JDK-8264886 ------------- Commit messages: - Use env->AttachCurrentThread before making invocations from native to Java Changes: https://git.openjdk.java.net/jfx/pull/459/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=459&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264886 Stats: 21 lines in 1 file changed: 11 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/459.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/459/head:pull/459 PR: https://git.openjdk.java.net/jfx/pull/459 From github.com+2179736+matthiasblaesing at openjdk.java.net Thu Apr 8 12:30:12 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Thu, 8 Apr 2021 12:30:12 GMT Subject: RFR: 8264886: WebKit native to Java invocations on wrong thread In-Reply-To: <2D_bRgHchnLscPscKBCoIAlkicrx0lLO3BrLII2WqIc=.763f994e-6d56-44f7-a6c4-19052e09d761@github.com> References: <2D_bRgHchnLscPscKBCoIAlkicrx0lLO3BrLII2WqIc=.763f994e-6d56-44f7-a6c4-19052e09d761@github.com> Message-ID: On Thu, 8 Apr 2021 12:18:59 GMT, Johan Vos wrote: > Fix for JDK-8264886 Please have a look at https://github.com/openjdk/jfx/pull/458 - the solution there is identical, but also fixes fetching the FileSystem class. ------------- PR: https://git.openjdk.java.net/jfx/pull/459 From ajoseph at openjdk.java.net Thu Apr 8 13:01:27 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 8 Apr 2021 13:01:27 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 [v2] In-Reply-To: References: Message-ID: > We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. > http://site.icu-project.org/home Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add icuVersion ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/456/files - new: https://git.openjdk.java.net/jfx/pull/456/files/c66fbd74..351e02b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=456&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=456&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/456.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/456/head:pull/456 PR: https://git.openjdk.java.net/jfx/pull/456 From jvos at openjdk.java.net Thu Apr 8 13:13:11 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 8 Apr 2021 13:13:11 GMT Subject: RFR: 8264886: WebKit native to Java invocations on wrong thread In-Reply-To: References: <2D_bRgHchnLscPscKBCoIAlkicrx0lLO3BrLII2WqIc=.763f994e-6d56-44f7-a6c4-19052e09d761@github.com> Message-ID: On Thu, 8 Apr 2021 12:27:02 GMT, Matthias Bl?sing wrote: >> Fix for JDK-8264886 > > Please have a look at https://github.com/openjdk/jfx/pull/458 - the solution there is identical, but also fixes fetching the FileSystem class. > Please have a look at #458 - the solution there is identical, but also fixes fetching the FileSystem class. True, I think I can close this PR ------------- PR: https://git.openjdk.java.net/jfx/pull/459 From jvos at openjdk.java.net Thu Apr 8 14:01:16 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 8 Apr 2021 14:01:16 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:01:27 GMT, Arun Joseph wrote: >> We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. >> http://site.icu-project.org/home > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Add icuVersion Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/456 From aghaisas at openjdk.java.net Thu Apr 8 14:23:14 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 8 Apr 2021 14:23:14 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 14:04:42 GMT, Marius Hanl wrote: >> This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. >> This bug only occurs, when a fixed cell size is set to the table. >> >> I also added 3 more tests beside the mandatory test, which tests my fix. >> 1 alternative test, which tests the same with no fixed cell size set. >> The other 2 tests are testing the same, but the table columns are set invisible instead. >> >> -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. >> Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). >> See also: TableRowSkinBase#updateCells(boolean) > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8258663: Changes based of the code review Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From github.com+66004280+maran23 at openjdk.java.net Thu Apr 8 15:19:10 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Thu, 8 Apr 2021 15:19:10 GMT Subject: Integrated: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> References: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> Message-ID: On Thu, 18 Mar 2021 14:38:18 GMT, Marius Hanl wrote: > When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. > This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all and the 'buttonNodes' list will recreate the dialog button(s). > Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. This pull request has now been integrated. Changeset: 28475cb2 Author: Marius Hanl Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/28475cb2 Stats: 52 lines in 2 files changed: 45 ins; 3 del; 4 mod 8263807: Button types of a DialogPane are set twice, returns a wrong button Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/432 From github.com+66004280+maran23 at openjdk.java.net Thu Apr 8 15:53:13 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Thu, 8 Apr 2021 15:53:13 GMT Subject: Integrated: 8258663: Fixed size TableCells are not removed from sene graph when column is removed In-Reply-To: References: Message-ID: On Sun, 28 Mar 2021 23:13:22 GMT, Marius Hanl wrote: > This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. > This bug only occurs, when a fixed cell size is set to the table. > > I also added 3 more tests beside the mandatory test, which tests my fix. > 1 alternative test, which tests the same with no fixed cell size set. > The other 2 tests are testing the same, but the table columns are set invisible instead. > > -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. > Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). > See also: TableRowSkinBase#updateCells(boolean) This pull request has now been integrated. Changeset: d808dd1e Author: Marius Hanl Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/d808dd1e Stats: 133 lines in 2 files changed: 126 ins; 1 del; 6 mod 8258663: Fixed size TableCells are not removed from sene graph when column is removed Reviewed-by: fastegal, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From kcr at openjdk.java.net Thu Apr 8 19:59:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Apr 2021 19:59:08 GMT Subject: RFR: 8260245: Update ICU4C to version 68.2 [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:01:27 GMT, Arun Joseph wrote: >> We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. >> http://site.icu-project.org/home > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Add icuVersion Testing looks good (all platforms). So do the changes. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/456 From kcr at openjdk.java.net Thu Apr 8 21:17:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 8 Apr 2021 21:17:22 GMT Subject: RFR: 8264928: Update to Xcode 12.4 Message-ID: This updates the compiler used to build JavaFX on macOS to Xcode 12.4 (which includes the MacOSX11.1 sdk), which matches the compiler that will be used to build JDK 17, once openjdk/jdk#3388 is integrated. As noted in the bug report, Xcode 12.4 needs macOS 10.15.4 (Catalina) or later to build. The produced artifacts will be able to run on earlier versions of macOS (for x86_64 systems anyway). ------------- Commit messages: - 8264928: Update to Xcode 12.4 Changes: https://git.openjdk.java.net/jfx/pull/460/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=460&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264928 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/460.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/460/head:pull/460 PR: https://git.openjdk.java.net/jfx/pull/460 From arapte at openjdk.java.net Fri Apr 9 05:43:37 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 9 Apr 2021 05:43:37 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v4] In-Reply-To: References: Message-ID: > The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. > Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). > > Fix is to remove the listener when MenuItem is removed. > Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. > Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. > With fix, the count is always same as number of MenuItems in scenegraph. > > Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. > This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. > Added a comment explaining this behavior in place of the TODO. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: add runFinalization() ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/429/files - new: https://git.openjdk.java.net/jfx/pull/429/files/62344c7e..88b5e25d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/429.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/429/head:pull/429 PR: https://git.openjdk.java.net/jfx/pull/429 From arapte at openjdk.java.net Fri Apr 9 06:14:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 9 Apr 2021 06:14:40 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v5] In-Reply-To: References: Message-ID: > The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. > Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). > > Fix is to remove the listener when MenuItem is removed. > Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. > Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. > With fix, the count is always same as number of MenuItems in scenegraph. > > Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. > This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. > Added a comment explaining this behavior in place of the TODO. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review correction in test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/429/files - new: https://git.openjdk.java.net/jfx/pull/429/files/88b5e25d..91d43d8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=03-04 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/429.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/429/head:pull/429 PR: https://git.openjdk.java.net/jfx/pull/429 From arapte at openjdk.java.net Fri Apr 9 06:18:07 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 9 Apr 2021 06:18:07 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 15:03:36 GMT, Kevin Rushforth wrote: > Is there a way to test it more directly? `ControlTestUtils` provides a way to get the number of listeners added to a property. Please check the updated test. With this direct way, should we keep the indirect way of testing which uses `changeListenerMap` ? ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From ajoseph at openjdk.java.net Fri Apr 9 06:51:15 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 9 Apr 2021 06:51:15 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] In-Reply-To: References: Message-ID: On Sun, 4 Apr 2021 16:36:27 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 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. Changes looks good. Verified the build on all 3 platforms. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/446 From ajoseph at openjdk.java.net Fri Apr 9 07:11:19 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 9 Apr 2021 07:11:19 GMT Subject: Integrated: 8260245: Update ICU4C to version 68.2 In-Reply-To: References: Message-ID: <1kwiaIBRoaeIcpw3P2b7H2fejvXX5saznv4hRUFSutM=.88f50b63-8888-41e6-8f7e-0e84ec31978a@github.com> On Mon, 5 Apr 2021 18:14:36 GMT, Arun Joseph wrote: > We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. > http://site.icu-project.org/home This pull request has now been integrated. Changeset: 808b1078 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/808b1078 Stats: 45773 lines in 673 files changed: 24665 ins; 8082 del; 13026 mod 8260245: Update ICU4C to version 68.2 8232379: Need to remove large icudt64l.zip binary file from source repository Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/456 From fkirmaier at openjdk.java.net Fri Apr 9 10:43:10 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 9 Apr 2021 10:43:10 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: <4sMuGaAW87f-lxLMt-13WyjuGsEZpuv3SAtgZnKd-VI=.17ae6bc1-b071-46eb-80c1-6216909d0642@github.com> Message-ID: On Tue, 6 Apr 2021 13:30:46 GMT, Jeanette Winzenburg wrote: >> @kleopatra >> I've added another test for the case, when index changes in such a way, that the cell should no longer be in the editing state, >> and the test seems to work. Do I miss something? >> >> About the Events, when i think about it, I was a bit of biased so I don't have to change anything. So I don't really have an opinion about it. But the PR should only fix the case, which is obviously wrong, and i don't really want to change anything in the event logic. > >> @kleopatra >> I've added another test for the case, when index changes in such a way, that the cell should no longer be in the editing state, >> and the test seems to work. Do I miss something? > > hmm .. that's weird: your test (cell 1 -> listEdit 0 -> cell 0) indeed passes, doing it the other way round (cell 0 -> listEdit 1 -> cell 1) fails > > @Test > public void testChangeCellIndex0ToListEditingIndex1() { > assertChangeIndexToEditing(0, 1); > } > > @Test > public void testChangeCellIndex1ToListEditingIndex0() { > assertChangeIndexToEditing(1, 0); > } > > private void assertChangeIndexToEditing(int initialCellIndex, int listEditingIndex) { > list.setEditable(true); > cell.updateListView(list); > cell.updateIndex(initialCellIndex); > list.edit(listEditingIndex); > assertEquals("sanity: list editingIndex ", listEditingIndex, list.getEditingIndex()); > assertFalse("sanity: cell must not be editing", cell.isEditing()); > cell.updateIndex(listEditingIndex); > assertEquals("sanity: index updated ", listEditingIndex, cell.getIndex()); > assertEquals("list editingIndex unchanged by cell", listEditingIndex, list.getEditingIndex()); > assertTrue(cell.isEditing()); > } > > Something obvious that I missed or a bummer in the test setup or what else? Any ideas? I've looked into it. This is somehow linked to the fact, that the default focusIndex for the list is 0 instead of -1. If you change the updateDefaultFocus methods in ListView, then it works. The tests are somehow synthetic and don't reflect the real world. So it's probably ok to leave it as it is. A better test which reflects the real world would be better, but that's probably way harder. Then we would have to get the ListCells from the ListView ... Which would basically be reasonable for all of these tests, but i don't think it should be done as part of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Fri Apr 9 11:39:35 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 9 Apr 2021 11:39:35 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v2] In-Reply-To: <8oNU4aPYxct986B-ayRWzPFTLwLfhiGjLfEWkT0Bn98=.16f410cf-9984-4686-bd12-4f10e6db37e6@github.com> References: <8oNU4aPYxct986B-ayRWzPFTLwLfhiGjLfEWkT0Bn98=.16f410cf-9984-4686-bd12-4f10e6db37e6@github.com> Message-ID: On Wed, 7 Apr 2021 15:25:05 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264677 >> changes based on code review > > Suggested a minor change. > The test file has an existing test `memoryTest()`. The `AfterClass` and `BeforeClass` methods are specific to this test, and not related to the new test. It looks little unstructured with addition of this new test. Not sure if it is worth to change the helper methods and existing test. > otherwise the fix and test looks good. I've now reworked the old test. The initialization of JavaFX is now seperated of the old test. The old test is now also much simpler. It no longer "jumps around" between different methods. The waiting for the Stage to be shown is also no longer necessary, which simplifies it even more. ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From fkirmaier at openjdk.java.net Fri Apr 9 11:39:35 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 9 Apr 2021 11:39:35 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v2] In-Reply-To: References: <8oNU4aPYxct986B-ayRWzPFTLwLfhiGjLfEWkT0Bn98=.16f410cf-9984-4686-bd12-4f10e6db37e6@github.com> Message-ID: <-azBEAUWXwVjZL8XtP8MjmxDqxTUYPiKA0lqzUBSXBk=.6b3c796c-4c81-4d99-afb0-b184c086e21b@github.com> On Fri, 9 Apr 2021 11:35:01 GMT, Florian Kirmaier wrote: >> Suggested a minor change. >> The test file has an existing test `memoryTest()`. The `AfterClass` and `BeforeClass` methods are specific to this test, and not related to the new test. It looks little unstructured with addition of this new test. Not sure if it is worth to change the helper methods and existing test. >> otherwise the fix and test looks good. > > I've now reworked the old test. The initialization of JavaFX is now seperated of the old test. > The old test is now also much simpler. It no longer "jumps around" between different methods. > The waiting for the Stage to be shown is also no longer necessary, which simplifies it even more. Also no longer WeakReferences are needed for the test due to the new memory tests. No more worrying whether it can become null at the wrong moment. ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From fkirmaier at openjdk.java.net Fri Apr 9 11:39:34 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 9 Apr 2021 11:39:34 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v3] In-Reply-To: References: Message-ID: > Fixing leak in ProgressIndicator when treeShowing is false Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264677 Updated naming of the test, reworked the old test. It now has a much smaller scope and is easier to reason about, the initialization of JavaFX is now seperated from the test itself. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/455/files - new: https://git.openjdk.java.net/jfx/pull/455/files/1a49a354..15fae375 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=455&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=455&range=01-02 Stats: 51 lines in 1 file changed: 18 ins; 27 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/455.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/455/head:pull/455 PR: https://git.openjdk.java.net/jfx/pull/455 From arapte at openjdk.java.net Fri Apr 9 12:51:11 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 9 Apr 2021 12:51:11 GMT Subject: RFR: 8264928: Update to Xcode 12.4 In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:21:43 GMT, Kevin Rushforth wrote: > This updates the compiler used to build JavaFX on macOS to Xcode 12.4 (which includes the MacOSX11.1 sdk), which matches the compiler that will be used to build JDK 17, once openjdk/jdk#3388 is integrated. > > As noted in the bug report, Xcode 12.4 needs macOS 10.15.4 (Catalina) or later to build. The produced artifacts will be able to run on earlier versions of macOS (for x86_64 systems anyway). looks good to me. Verified build and sanity test. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/460 From kcr at openjdk.java.net Fri Apr 9 13:14:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 13:14:08 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 11:39:34 GMT, Florian Kirmaier wrote: >> Fixing leak in ProgressIndicator when treeShowing is false > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264677 > Updated naming of the test, > reworked the old test. It now has a much smaller scope and is easier to reason about, the initialization of JavaFX is now seperated from the test itself. The fix looks good. So does the newly added test, and I like the refactoring of the tests that you've done. I left one question about existing test. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 79: > 77: indicator.setProgress(1.0); > 78: checker.assertCollectable(detIndicator); > 79: stage.show(); Now that you are no longer waiting for `Stage::onShown`, isn't it possible for the test to miss a potential leak? Can you explain why you think it's not needed? ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From github.com+17347324+torbuntu at openjdk.java.net Fri Apr 9 15:53:09 2021 From: github.com+17347324+torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Fri, 9 Apr 2021 15:53:09 GMT Subject: RFR: 8217955: Problems with touch input and JavaFX 11 In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:37:35 GMT, Johan Vos wrote: > This fixes a current issue, and while a solution that adds native touch-event support is highly encouraged, this fix will already improve the current situation. What would be the protocol for requesting guidance on this? Since as I mentioned I am trying to [implement touch-event support ](https://github.com/torbuntu/jfx/tree/touch-support)so that JavaFX can be used out of the box on devices such as PinePhone and PineTab running aarch64 linux. ------------- PR: https://git.openjdk.java.net/jfx/pull/457 From kcr at openjdk.java.net Fri Apr 9 19:05:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 19:05:22 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> Message-ID: <9WCsJnl_NmH-mSpEw-xx-r9pgd-2wg4dVW-my5eQo5U=.4cbe5887-33a4-4d07-9793-e0fe2581c85e@github.com> On Fri, 26 Mar 2021 13:58:30 GMT, Nir Lisker wrote: >> I think I corrected the GL pipeline issue. The dot product should have used the negative light direction. It worked for me because I was testing in the -1 z direction instead of the +1. I still don't know why Mac and Linux would have given different results. This is what I get after the commit: >> >> ![Screenshot from 2021-03-25 03-59-57](https://user-images.githubusercontent.com/37422899/112407458-c941cc80-8d1e-11eb-85c2-468508e5018a.png) > > If you want to test aiming the light with transforms instead of a direction vector, I modified the `NGSpotLight` and `AttenLightingSample` files to use the rotation transforms. > > [transforms.zip](https://github.com/openjdk/jfx/files/6212221/transforms.zip) The problem with the hole in the spotlight on Mac is fixed. The remaining problems seem to be related to the way range is treated. Maybe there is a problem with a scale somewhere? This is on a retina display with 2x scaling. Here are two sample pictures that illustrate what I mean. The first is on Windows, and the second is on Mac. ![SpotLight-range-Windows](https://user-images.githubusercontent.com/34689748/114226633-ade2de00-9928-11eb-8d24-0efcaf7f059a.png) SpotLight-range-macOS Also, I still see some unrelated problems on Linux, but since it is a VirtualBox guest running on my Windows host, I'm not sure how valid a test it is. I have to set `-Dprism.forceGPU=true` to get any 3D on that machine. @arapte was going to try it on a different system (also a VM image, but different system and graphics card). I'm less worried about this one as long as physical Linux box that actually reports 3D support works correctly. So I think we're down to the range and/or scaling being wrong on Mac. Possibly in retina mode only. As for setting the spot light direction using rotation, I think there are three API choices, and I don't like the third since it is inconsistent, so really two choices. 1. No direction property in the SpotLight API. A vector of `(0,0,1)` is transformed from the local coordinate space of the light into world coordinates and used as the direction. 2. Add a direction property to the SpotLight API, with a default of `(0,0,1)`. That direction vector is transformed from the local coordinate space of the light into world coordinates and used as the direction. 3. Add a direction property to the SpotLight API, with a default of `(0,0,1)`. That vector is use as the direction without regard to any transforms. Option 2 is the most flexible. I think option 1 is fine, since we can always compatibly add a direction vector in the future (giving us option 2 later). As I mentioned, option 3 is inconsistent, so let's not do that one. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Apr 9 19:37:37 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 9 Apr 2021 19:37:37 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview Message-ID: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> The functions from FileSystemJava are called from different threads the root problem manifests because the JNI FindClass function behaves differently when called from a context that is the ancestor of a java frame compared to when called in isolation. A segmentation fault is observed when local storage of a webview is accessed. At that time a new native thread is spun up and that sets up the local storage, by calling into the JVM via WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is invoked to get a referenc to the java implementation of the FileSystem. As this is is called from a new native thread (no java context available), JNI uses the system classloader to locate the class. This fails if the JavaFX modules are not on the boot module/class path. Instead on relying on fetching the class reference everytime it is needed, this change fetches it once when the JavaFX library is loaded and stores it in the WTF namespace. In addition to this it was observed, that there is no attachment to the JVM done when calling into the filesystem. No fault was observed, but the JNI specs indicate, that the JNIEnv interface is only valid when attached. ------------- Commit messages: - Address review comments - 9069811: Fix segfault when accessing local storage in webview - 9069811: Create reproducer for segfault when accessing local storage Changes: https://git.openjdk.java.net/jfx/pull/458/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=458&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264990 Stats: 362 lines in 7 files changed: 325 ins; 7 del; 30 mod Patch: https://git.openjdk.java.net/jfx/pull/458.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/458/head:pull/458 PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Fri Apr 9 19:37:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 19:37:38 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Thu, 8 Apr 2021 06:58:14 GMT, Matthias Bl?sing wrote: > The functions from FileSystemJava are called from different threads the > root problem manifests because the JNI FindClass function behaves > differently when called from a context that is the ancestor of a java > frame compared to when called in isolation. > > A segmentation fault is observed when local storage of a webview is > accessed. At that time a new native thread is spun up and that sets up > the local storage, by calling into the JVM via > WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is > invoked to get a referenc to the java implementation of the FileSystem. > As this is is called from a new native thread (no java context > available), JNI uses the system classloader to locate the class. This > fails if the JavaFX modules are not on the boot module/class path. > > Instead on relying on fetching the class reference everytime it is > needed, this change fetches it once when the JavaFX library is loaded > and stores it in the WTF namespace. > > In addition to this it was observed, that there is no attachment to the > JVM done when calling into the filesystem. No fault was observed, but > the JNI specs indicate, that the JNIEnv interface is only valid when > attached. The fix looks OK to me, although I'd like @arun-Joseph to comfirm. The test needs one change in how the resource (the `.html` file) is located, and I added a couple minor comments on the test. I'll test it after that. modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp line 249: > 247: if (isHandleValid(handle)) { > 248: AttachThreadAsDaemonToJavaEnv autoAttach; > 249: JNIEnv* env = autoAttach.env(); Minor: indentation modules/javafx.web/src/main/native/Source/WTF/wtf/java/JavaEnv.cpp line 144: > 142: // the right one > 143: static JGClass fileSystemRef(env->FindClass("com/sun/webkit/FileSystem")); > 144: WTF::comSunWebkitFileSystem = fileSystemRef; Can you `ASSERT` that the returned class is not null? tests/system/src/testapp7/java/mymod/myapp7/LocalStorageAccessWithModuleLayer.java line 81: > 79: webview.getEngine().getLoadWorker().stateProperty().addListener( > 80: new ChangeListener() { > 81: public void changed(ObservableValue ov, State oldState, State newState) { Suggestion: maybe use a lambda here to make the code more compact? (it's up to you whether to change it) tests/system/src/testapp7/java/mymod/myapp7/LocalStorageAccessWithModuleLayer.java line 92: > 90: } > 91: }); > 92: webview.getEngine().load(LocalStorageAccessWithModuleLayer.class.getResource("/LocalStorageAccess.html").toExternalForm()); This fails to find the resource when I run the test via gradle. I recommend putting it in the same package as the class and removing the leading `/` (e.g., see the FXML resources in `testapp6` or `testscriptapp1`). tests/system/src/testapp7/java/mymod/myapp7/LocalStorageAccessWithModuleLayerLauncher.java line 64: > 62: // Hack to get the classes of this programm into a module layer > 63: List modulePaths = new ArrayList<>(); > 64: for(String workerPath: System.getProperty("module.path").split(File.pathSeparator)) { Minor: missing space after the `for` and also before the `:` ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Apr 9 19:37:39 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 9 Apr 2021 19:37:39 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: <9PIJLE5-7bADSvwkgv6tMMPBwn0911ICpG5l8cP-KMI=.29dac151-8338-4994-9535-38f272577414@github.com> On Thu, 8 Apr 2021 06:58:14 GMT, Matthias Bl?sing wrote: > The functions from FileSystemJava are called from different threads the > root problem manifests because the JNI FindClass function behaves > differently when called from a context that is the ancestor of a java > frame compared to when called in isolation. > > A segmentation fault is observed when local storage of a webview is > accessed. At that time a new native thread is spun up and that sets up > the local storage, by calling into the JVM via > WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is > invoked to get a referenc to the java implementation of the FileSystem. > As this is is called from a new native thread (no java context > available), JNI uses the system classloader to locate the class. This > fails if the JavaFX modules are not on the boot module/class path. > > Instead on relying on fetching the class reference everytime it is > needed, this change fetches it once when the JavaFX library is loaded > and stores it in the WTF namespace. > > In addition to this it was observed, that there is no attachment to the > JVM done when calling into the filesystem. No fault was observed, but > the JNI specs indicate, that the JNIEnv interface is only valid when > attached. The issue reference is the ID I got after I requested a bug to be created - I'm waiting to have it being opened up. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From jvos at openjdk.java.net Fri Apr 9 19:37:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 9 Apr 2021 19:37:39 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: <9PIJLE5-7bADSvwkgv6tMMPBwn0911ICpG5l8cP-KMI=.29dac151-8338-4994-9535-38f272577414@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <9PIJLE5-7bADSvwkgv6tMMPBwn0911ICpG5l8cP-KMI=.29dac151-8338-4994-9535-38f272577414@github.com> Message-ID: On Thu, 8 Apr 2021 12:30:38 GMT, Matthias Bl?sing wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > The issue reference is the ID I got after I requested a bug to be created - I'm waiting to have it being opened up. We have a concurrency issue here, as I created https://bugs.openjdk.java.net/browse/JDK-8264886 and a PR https://github.com/openjdk/jfx/pull/459 . However, I recommend we proceed with this PR, as it also fixes the failure with the WebKitFileSystem class reference (which should indeed be done in the OnLoad). The fix looks good, I'll have a look at the tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Fri Apr 9 19:37:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 19:37:39 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> On Thu, 8 Apr 2021 20:43:57 GMT, Kevin Rushforth wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > The fix looks OK to me, although I'd like @arun-Joseph to comfirm. > > The test needs one change in how the resource (the `.html` file) is located, and I added a couple minor comments on the test. I'll test it after that. To follow up on my earlier comment, if I move `LocalStorageAccess.html` to `tests/system/src/testapp7/resources/mymod/myapp7/` and remove the `/` from the program that loads it, the test is able to load the resource. And I verified that the test fails without your fix and passes with your fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Fri Apr 9 19:37:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 19:37:39 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> Message-ID: On Thu, 8 Apr 2021 21:36:07 GMT, Kevin Rushforth wrote: >> The fix looks OK to me, although I'd like @arun-Joseph to comfirm. >> >> The test needs one change in how the resource (the `.html` file) is located, and I added a couple minor comments on the test. I'll test it after that. > > To follow up on my earlier comment, if I move `LocalStorageAccess.html` to `tests/system/src/testapp7/resources/mymod/myapp7/` and remove the `/` from the program that loads it, the test is able to load the resource. And I verified that the test fails without your fix and passes with your fix. The bug is now available in the JDK project in JBS: https://bugs.openjdk.java.net/browse/JDK-8264990 ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Apr 9 19:37:39 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 9 Apr 2021 19:37:39 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> Message-ID: On Fri, 9 Apr 2021 13:18:21 GMT, Kevin Rushforth wrote: >> To follow up on my earlier comment, if I move `LocalStorageAccess.html` to `tests/system/src/testapp7/resources/mymod/myapp7/` and remove the `/` from the program that loads it, the test is able to load the resource. And I verified that the test fails without your fix and passes with your fix. > > The bug is now available in the JDK project in JBS: > https://bugs.openjdk.java.net/browse/JDK-8264990 @kevinrushforth @johanvos thank you both for review/checking. I pushed an update, that addresses the comments and updated the issue with the final issue id. I did not touch the comments on the original commits, so that history is kept intact (I understand, that skara bot will use the PR message as base for the final squashed commit and ignores the individual commits) ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Apr 9 19:37:40 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 9 Apr 2021 19:37:40 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Thu, 8 Apr 2021 20:27:45 GMT, Kevin Rushforth wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > tests/system/src/testapp7/java/mymod/myapp7/LocalStorageAccessWithModuleLayer.java line 92: > >> 90: } >> 91: }); >> 92: webview.getEngine().load(LocalStorageAccessWithModuleLayer.class.getResource("/LocalStorageAccess.html").toExternalForm()); > > This fails to find the resource when I run the test via gradle. I recommend putting it in the same package as the class and removing the leading `/` (e.g., see the FXML resources in `testapp6` or `testscriptapp1`). Can you tell me how you ran it? I ensured, that the test failed with a segfault before continuing with the fix. While I did that I indeed placed the file in the wrong directory, but currently I see no test failures locally. I run: ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test --tests test.com.sun.webkit.LocalStorageAccessTest to only invoke the new test. I'll move the file to the package, but I'd like to understand where I went wrong. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Fri Apr 9 19:37:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 19:37:40 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Fri, 9 Apr 2021 06:55:55 GMT, Matthias Bl?sing wrote: >> tests/system/src/testapp7/java/mymod/myapp7/LocalStorageAccessWithModuleLayer.java line 92: >> >>> 90: } >>> 91: }); >>> 92: webview.getEngine().load(LocalStorageAccessWithModuleLayer.class.getResource("/LocalStorageAccess.html").toExternalForm()); >> >> This fails to find the resource when I run the test via gradle. I recommend putting it in the same package as the class and removing the leading `/` (e.g., see the FXML resources in `testapp6` or `testscriptapp1`). > > Can you tell me how you ran it? I ensured, that the test failed with a segfault before continuing with the fix. While I did that I indeed placed the file in the wrong directory, but currently I see no test failures locally. I run: > > ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test --tests test.com.sun.webkit.LocalStorageAccessTest > > to only invoke the new test. I'll move the file to the package, but I'd like to understand where I went wrong. That's how I ran it, too. I did it from a clean repo. This was on Windows, but shouldn't matter. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Fri Apr 9 19:37:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 19:37:41 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: <2qPJO19xX2s-Z-6OMemxmiETdmrXkmqOFWkqQrifZPY=.62b2f600-6b4e-4e4c-8e2a-750932a16365@github.com> On Fri, 9 Apr 2021 15:51:05 GMT, Kevin Rushforth wrote: >> Can you tell me how you ran it? I ensured, that the test failed with a segfault before continuing with the fix. While I did that I indeed placed the file in the wrong directory, but currently I see no test failures locally. I run: >> >> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test --tests test.com.sun.webkit.LocalStorageAccessTest >> >> to only invoke the new test. I'll move the file to the package, but I'd like to understand where I went wrong. > > That's how I ran it, too. I did it from a clean repo. This was on Windows, but shouldn't matter. I just tried it on Linux and get the same failure: Caused by: java.lang.NullPointerException: Cannot invoke "java.net.URL.toExternalForm()" because the return value of "java.lang.Class.getResource(String)" is null at mymod/myapp7.LocalStorageAccessWithModuleLayer.start(LocalStorageAccessWithModuleLayer.java:92) at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:849) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(GtkApplication.java:277) ... 1 more ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From jvos at openjdk.java.net Fri Apr 9 19:37:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 9 Apr 2021 19:37:41 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: <2qPJO19xX2s-Z-6OMemxmiETdmrXkmqOFWkqQrifZPY=.62b2f600-6b4e-4e4c-8e2a-750932a16365@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <2qPJO19xX2s-Z-6OMemxmiETdmrXkmqOFWkqQrifZPY=.62b2f600-6b4e-4e4c-8e2a-750932a16365@github.com> Message-ID: On Fri, 9 Apr 2021 16:02:36 GMT, Kevin Rushforth wrote: >> That's how I ran it, too. I did it from a clean repo. This was on Windows, but shouldn't matter. > > I just tried it on Linux and get the same failure: > > Caused by: java.lang.NullPointerException: Cannot invoke "java.net.URL.toExternalForm()" because the return value of "java.lang.Class.getResource(String)" is null > at mymod/myapp7.LocalStorageAccessWithModuleLayer.start(LocalStorageAccessWithModuleLayer.java:92) > at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:849) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) > at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) > at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(GtkApplication.java:277) > ... 1 more I get the same error. For some reason, the resource isn't found when it's on the root. Moving it inside the app7 package work. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Apr 9 19:37:41 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 9 Apr 2021 19:37:41 GMT Subject: RFR: 8264990: Fix segfault when accessing local storage in webview In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <2qPJO19xX2s-Z-6OMemxmiETdmrXkmqOFWkqQrifZPY=.62b2f600-6b4e-4e4c-8e2a-750932a16365@github.com> Message-ID: On Fri, 9 Apr 2021 19:10:13 GMT, Johan Vos wrote: >> I just tried it on Linux and get the same failure: >> >> Caused by: java.lang.NullPointerException: Cannot invoke "java.net.URL.toExternalForm()" because the return value of "java.lang.Class.getResource(String)" is null >> at mymod/myapp7.LocalStorageAccessWithModuleLayer.start(LocalStorageAccessWithModuleLayer.java:92) >> at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:849) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) >> at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) >> at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(GtkApplication.java:277) >> ... 1 more > > I get the same error. For some reason, the resource isn't found when it's on the root. > Moving it inside the app7 package work. Thank you both for checking. I noticed, there were two copies of the HTML present in the `build` folder, which explains the strange behavior. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From nlisker at openjdk.java.net Fri Apr 9 19:55:10 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Apr 2021 19:55:10 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: <9WCsJnl_NmH-mSpEw-xx-r9pgd-2wg4dVW-my5eQo5U=.4cbe5887-33a4-4d07-9793-e0fe2581c85e@github.com> References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> <9WCsJnl_NmH-mSpEw-xx-r9pgd-2wg4dVW-my5eQo5U=.4cbe5887-33a4-4d07-9793-e0fe2581c85e@github.com> Message-ID: On Fri, 9 Apr 2021 19:01:59 GMT, Kevin Rushforth wrote: >> If you want to test aiming the light with transforms instead of a direction vector, I modified the `NGSpotLight` and `AttenLightingSample` files to use the rotation transforms. >> >> [transforms.zip](https://github.com/openjdk/jfx/files/6212221/transforms.zip) > > The problem with the hole in the spotlight on Mac is fixed. The remaining problems seem to be related to the way range is treated. Maybe there is a problem with a scale somewhere? This is on a retina display with 2x scaling. Here are two sample pictures that illustrate what I mean. The first is on Windows, and the second is on Mac. > > ![SpotLight-range-Windows](https://user-images.githubusercontent.com/34689748/114226633-ade2de00-9928-11eb-8d24-0efcaf7f059a.png) > SpotLight-range-macOS > > > Also, I still see some unrelated problems on Linux, but since it is a VirtualBox guest running on my Windows host, I'm not sure how valid a test it is. I have to set `-Dprism.forceGPU=true` to get any 3D on that machine. @arapte was going to try it on a different system (also a VM image, but different system and graphics card). I'm less worried about this one as long as physical Linux box that actually reports 3D support works correctly. > > So I think we're down to the range and/or scaling being wrong on Mac. Possibly in retina mode only. > > As for setting the spot light direction using rotation, I think there are three API choices, and I don't like the third since it is inconsistent, so really two choices. > > 1. No direction property in the SpotLight API. A vector of `(0,0,1)` is transformed from the local coordinate space of the light into world coordinates and used as the direction. > 2. Add a direction property to the SpotLight API, with a default of `(0,0,1)`. That direction vector is transformed from the local coordinate space of the light into world coordinates and used as the direction. > 3. Add a direction property to the SpotLight API, with a default of `(0,0,1)`. That vector is use as the direction without regard to any transforms. > > Option 2 is the most flexible. I think option 1 is fine, since we can always compatibly add a direction vector in the future (giving us option 2 later). As I mentioned, option 3 is inconsistent, so let's not do that one. I will check the range issue on (non-VM) Linux. I don't have a Mac, so not sure what to do if Linux checks out. > As for setting the spot light direction using rotation, I think there are three API choices, and I don't like the third since it is inconsistent, so really two choices. The current patch uses approach 3, and I posted a couple of replacement files in the comment above that use approach 1. If you and Ambarish can compare these, we will have a better idea on what to do. I also think that either 1 or 2 are the best choices, so if you find approach 1 too confusing or 3 very convenient, I will merge them into approach 2. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Fri Apr 9 20:35:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 20:35:15 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> Message-ID: On Fri, 9 Apr 2021 19:32:46 GMT, Matthias Bl?sing wrote: > I pushed an update, that addresses the comments and updated the issue with the final issue id. You also need to adjust the PR title to match the bug title exactly. > I did not touch the comments on the original commits, so that history is kept intact (I understand, that skara bot will use the PR message as base for the final squashed commit and ignores the individual commits) Yes, this is correct. And we prefer contributors to do just what you did for incremental changes. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Apr 9 20:48:15 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 9 Apr 2021 20:48:15 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> Message-ID: On Fri, 9 Apr 2021 20:32:10 GMT, Kevin Rushforth wrote: >> @kevinrushforth @johanvos thank you both for review/checking. I pushed an update, that addresses the comments and updated the issue with the final issue id. I did not touch the comments on the original commits, so that history is kept intact (I understand, that skara bot will use the PR message as base for the final squashed commit and ignores the individual commits) > >> I pushed an update, that addresses the comments and updated the issue with the final issue id. > > You also need to adjust the PR title to match the bug title exactly. > >> I did not touch the comments on the original commits, so that history is kept intact (I understand, that skara bot will use the PR message as base for the final squashed commit and ignores the individual commits) > > Yes, this is correct. And we prefer contributors to do just what you did for incremental changes. Thanks. I'm currently rerunning tests and preparing and update - further analysis showed, that thread attachment is handled in `WebCore::StorageThread::threadEntryPoint()`: https://github.com/openjdk/jfx/blob/808b1078f762a923bd5e74298daffeb88ed108c2/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp#L76-L87 The analysis was triggered by a request from @neilcsmith-net on the netbeans mailing list. He pointed out, that the fault should have happened earlier if the the thread indeed was not attached. In that case `GetEnv` is required to return `NULL`. From the [doc](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#getenv): > If the current thread is not attached to the VM, sets *env to NULL, and returns JNI_EDETACHED. If the specified version is not supported, sets *env to NULL, and returns JNI_EVERSION. Otherwise, sets *env to the appropriate interface, and returns JNI_OK. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Fri Apr 9 20:54:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 20:54:17 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> <9WCsJnl_NmH-mSpEw-xx-r9pgd-2wg4dVW-my5eQo5U=.4cbe5887-33a4-4d07-9793-e0fe2581c85e@github.com> Message-ID: <7NGYErv7OjjacG77a29hytbGYOYkfoUh4eFn3hr2kmI=.3337f1a2-e9a8-4699-b22b-5c287e0d1d21@github.com> On Fri, 9 Apr 2021 19:52:48 GMT, Nir Lisker wrote: > The current patch uses approach 3 Right. > and I posted a couple of replacement files in the comment above that use approach 1. I ran it, but didn't spend any time looking at how convenient it would be from an API point of view. > If you and Ambarish can compare these, we will have a better idea on what to do. I also think that either 1 or 2 are the best choices, so if you find approach 1 too confusing or 3 very convenient, I will merge them into approach 2. I'm sort of leaning towards 2 (as you could probably guess from my comments above). I'd like to hear from Ambarish as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Apr 9 21:10:46 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 9 Apr 2021 21:10:46 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: > The functions from FileSystemJava are called from different threads the > root problem manifests because the JNI FindClass function behaves > differently when called from a context that is the ancestor of a java > frame compared to when called in isolation. > > A segmentation fault is observed when local storage of a webview is > accessed. At that time a new native thread is spun up and that sets up > the local storage, by calling into the JVM via > WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is > invoked to get a referenc to the java implementation of the FileSystem. > As this is is called from a new native thread (no java context > available), JNI uses the system classloader to locate the class. This > fails if the JavaFX modules are not on the boot module/class path. > > Instead on relying on fetching the class reference everytime it is > needed, this change fetches it once when the JavaFX library is loaded > and stores it in the WTF namespace. > > In addition to this it was observed, that there is no attachment to the > JVM done when calling into the filesystem. No fault was observed, but > the JNI specs indicate, that the JNIEnv interface is only valid when > attached. Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Revert changes to thread attachment introduced in second commit Thread attachment is handled in jfx/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp and thus does not need to be modified. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/458/files - new: https://git.openjdk.java.net/jfx/pull/458/files/d7cfc567..c9ec47c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=458&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=458&range=00-01 Stats: 20 lines in 1 file changed: 0 ins; 10 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/458.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/458/head:pull/458 PR: https://git.openjdk.java.net/jfx/pull/458 From nlisker at openjdk.java.net Fri Apr 9 21:11:17 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 9 Apr 2021 21:11:17 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: <7NGYErv7OjjacG77a29hytbGYOYkfoUh4eFn3hr2kmI=.3337f1a2-e9a8-4699-b22b-5c287e0d1d21@github.com> References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> <9WCsJnl_NmH-mSpEw-xx-r9pgd-2wg4dVW-my5eQo5U=.4cbe5887-33a4-4d07-9793-e0fe2581c85e@github.com> <7NGYErv7OjjacG77a29hytbGYOYkfoUh4eF n3hr2kmI=.3337f1a2-e9a8-4699-b22b-5c287e0d1d21@github.com> Message-ID: <9hAxnA00If4ZB_Xa-Sv-ZqBEhgIvte2iBIHYOI64Aug=.8247852e-1182-4a30-af95-e155d70f3872@github.com> On Fri, 9 Apr 2021 20:50:55 GMT, Kevin Rushforth wrote: > I ran it, but didn't spend any time looking at how convenient it would be from an API point of view. I meant convenient for the user. My main concern is that just using rotation transforms will be frustrating because they don't always behave very intuitively. In any case, since we are going to have rotations work anyway, I'll implement option 2 with both rotations and direction, and we can check if the direction helps (leaving the direction at its default is effectively option 1). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Fri Apr 9 22:56:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 9 Apr 2021 22:56:16 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:21:28 GMT, Johan Vos wrote: > This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) > The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. > Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. > This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. I reviewed the code, and tested this, both using automated tests and various manual tests, and it looks good to me. In addition to the simple test attached to the bug report, I can reproduce the bug with `HelloTableView` and the `HorizontalListView` sample of `Ensemble8`. `HelloTableView` 1. Run `HelloTableview` program 2. Sort by first name 3. Slowly scroll down by dragging the thumb BUG: the scrolling jitters slightly when you reach the taller row (Jacob Smith Smith Smith) `Ensemble8` 1. Run `Ensemble8` and select `HorizontalListView` sample 2. Scroll all the way to the right 3. Slowly scroll to the left by dragging the thumb BUG: the scrolling jitters slightly when you reach the wider row (Long Row 3) All three test cases run fine with the fix. I left a few inline questions and comments (mostly about code style w.r.t., inline whitespace, and a couple typos). modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 254: > 252: * The following relation should always be true: > 253: * 0 <= absoluteOffset <= (estimatedSize - viewportLength) > 254: * Based on this relation, he position p is defined as Typo: `the` position p... modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1034: > 1032: */ > 1033: void adjustAbsoluteOffset() { > 1034: absoluteOffset = (estimatedSize - viewportLength)* getPosition(); Minor: missing space before the `*` modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2883: > 2881: double newPosition = Math.min(1.0d, absoluteOffset/(estimatedSize - viewportLength)); > 2882: // estimatedSize changes may result in opposite effect on position > 2883: // in that case, modify current position 1% in the requested direction Have you done testing to show that a 1% adjustment is a good heuristic? modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2892: > 2890: > 2891: // once at 95% of the total estimated size, we want a correct size, not > 2892: // an estimated size anymore. I presume that this is a balance between performance and accuracy? It seems to work well. Have you tried other values? Do you also need to check for `newPosition < 0.05` if you are scrolling backwards? modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2901: > 2899: } > 2900: > 2901: // if we are at or beyond the edge, correct the absolteOffset Typo: should be `absoluteOffset` modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2902: > 2900: > 2901: // if we are at or beyond the edge, correct the absolteOffset > 2902: if (newPosition >= 1.d) { Do you need to also check for `newPosition < 0` if you are scrolling backwards? modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2914: > 2912: double total = 0; > 2913: int currentCellCount = getCellCount(); > 2914: double estSize = estimatedSize/currentCellCount; MInor: missing spaces before and after `/` modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2972: > 2970: // Make sure we have enough space in the cache to store this index > 2971: while (idx >= itemSizeCache.size()) { > 2972: itemSizeCache.add(itemSizeCache.size(), null); Can this be simplified to `itemSizeCache.add(null);`? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1229: > 1227: } > 1228: > 1229: private ArrayLinkedListShim circlelist= new ArrayLinkedListShim(); Minor: missing space before `=` modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1233: > 1231: private VirtualFlowShim createCircleFlow() { > 1232: // The second VirtualFlow we are going to test, with 7 cells. Each cell > 1233: // contains a Circle whith a radius that varies between cells. Minor: indentation modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1305: > 1303: double s1 = s0; > 1304: double position = vf.getPosition(); > 1305: double newPosition =0d; Minor: missing space after `=` modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1336: > 1334: static ArrayList circleList = new ArrayList<>(); > 1335: static { > 1336: circleList.add(new Circle(10)); Minor: Could use `List.of`? (just a suggestion) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1350: > 1348: public GraphicalCellStub() { init(); } > 1349: > 1350: private void init( ) { Minor: can remove extra space between `(` and `)` modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1381: > 1379: double answer = super.computePrefHeight(width); > 1380: if ((idx > -1) && (idx < circleList.size())){ > 1381: answer = 2* circleList.get(idx).getRadius()+ 6; Minor: spacing is a little inconsistent for these two lines. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Sat Apr 10 14:04:14 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 10 Apr 2021 14:04:14 GMT Subject: RFR: 8264928: Update to Xcode 12.4 In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:21:43 GMT, Kevin Rushforth wrote: > This updates the compiler used to build JavaFX on macOS to Xcode 12.4 (which includes the MacOSX11.1 sdk), which matches the compiler that will be used to build JDK 17, once openjdk/jdk#3388 is integrated. > > As noted in the bug report, Xcode 12.4 needs macOS 10.15.4 (Catalina) or later to build. The produced artifacts will be able to run on earlier versions of macOS (for x86_64 systems anyway). Tested with 12.4, all looking good. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/460 From kcr at openjdk.java.net Sat Apr 10 15:01:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 10 Apr 2021 15:01:19 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: <4_t9ECFmYFsOLNS61DySgHNX6qk16ayzUvj65fIDZ1g=.786db064-b10d-4844-9f86-9bcf08e798f0@github.com> On Fri, 9 Apr 2021 06:15:42 GMT, Ambarish Rapte wrote: >> The fix looks good. >> >> The test looks OK as far as it goes, although I note that it is testing for the leak in an indirect way, since it looks at the `changeListenerMap` rather than checking the listeners of `menuitem.acceleratorProperty()` which is what we really care about. Is there a way to test it more directly? If not then I think this is fine. > >> Is there a way to test it more directly? > > `ControlTestUtils` provides a way to get the number of listeners added to a property. Please check the updated test. With this direct way, should we keep the indirect way of testing which uses `changeListenerMap` ? The updated test looks good. I confirm that it fails without the fix and passes with the fix. In order to do that I locally deleted the newly added shim class and comment out all calls to `get_ListenerMapSize`. I'd recommend to get rid of the indirect way of testing, since it will mean you can remove the newly added `ControlAcceleratorSupportShim` class and the `ControlAcceleratorSupport ::testGetListenerMapSize` method. ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From kcr at openjdk.java.net Sat Apr 10 15:04:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 10 Apr 2021 15:04:14 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> Message-ID: On Fri, 9 Apr 2021 20:45:33 GMT, Matthias Bl?sing wrote: >>> I pushed an update, that addresses the comments and updated the issue with the final issue id. >> >> You also need to adjust the PR title to match the bug title exactly. >> >>> I did not touch the comments on the original commits, so that history is kept intact (I understand, that skara bot will use the PR message as base for the final squashed commit and ignores the individual commits) >> >> Yes, this is correct. And we prefer contributors to do just what you did for incremental changes. Thanks. > > I'm currently rerunning tests and preparing and update - further analysis showed, that thread attachment is handled in `WebCore::StorageThread::threadEntryPoint()`: > > https://github.com/openjdk/jfx/blob/808b1078f762a923bd5e74298daffeb88ed108c2/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp#L76-L87 > > The analysis was triggered by a request from @neilcsmith-net on the netbeans mailing list. He pointed out, that the fault should have happened earlier if the the thread indeed was not attached. In that case `GetEnv` is required to return `NULL`. From the [doc](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#getenv): > >> If the current thread is not attached to the VM, sets *env to NULL, and returns JNI_EDETACHED. If the specified version is not supported, sets *env to NULL, and returns JNI_EVERSION. Otherwise, sets *env to the appropriate interface, and returns JNI_OK. That's good since it will simplify the fix to the root cause, which is that looking up the class fails depending on the ClassLoader used to load the JavaFX modules. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From fastegal at openjdk.java.net Sat Apr 10 16:13:15 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 10 Apr 2021 16:13:15 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: <4sMuGaAW87f-lxLMt-13WyjuGsEZpuv3SAtgZnKd-VI=.17ae6bc1-b071-46eb-80c1-6216909d0642@github.com> Message-ID: On Fri, 9 Apr 2021 10:40:19 GMT, Florian Kirmaier wrote: > > > I've looked into it. > This is somehow linked to the fact, that the default focusIndex for the list is 0 instead of -1. > If you change the updateDefaultFocus methods in ListView, then it works. > good dig :) Wouldn't have expected the focus state to have any effect .. so we should make certain it's part of the test setup, f.i. by always setting the focusedIndex (of the model) to -1 (or whatever is required to make all pass) always and document why it's done. > The tests are somehow synthetic and don't reflect the real world. .. true, nevertheless they souldn't fail/pass on some magic number ;) And yet another failing test, when changing cell index from -1 -> listEditingIndex: @Test public void testChangeCellIndexMinusOneToListEditingIndex0() { assertChangeIndexToEditing(-1, 1); } This looks not fixable by pre-setting focusIndex .. Coming back to our disagreement about event firing: I'm still weary with those intermediate events from simple re-use - but found a precedence in [TableCell](https://bugs.openjdk.java.net/browse/JDK-8150525): the same broken cell editing state led to data corruption and was fixed by calling updateEditing (including firing). So doing the same here looks okay after all. Should be documented though, at least by tests (for cancel, B in my very first comment with flipped assertion, similar for start edit). ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Sun Apr 11 15:48:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 11 Apr 2021 15:48:11 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v5] In-Reply-To: References: Message-ID: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still the real parent. > In that case, it doesn't get collected. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8263402 Minor simplification of the code, based on code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/424/files - new: https://git.openjdk.java.net/jfx/pull/424/files/e8063e30..db7e208d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/424.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/424/head:pull/424 PR: https://git.openjdk.java.net/jfx/pull/424 From fkirmaier at openjdk.java.net Sun Apr 11 15:48:12 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 11 Apr 2021 15:48:12 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:39:47 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263402 >> Minor cleanup based on codereview > > The fix looks OK, although I left a question below about ensuring that there cannot be an NPE. > > The test doesn't catch the bug on my system (Windows 10). Even when I run it without your fix, it passes. Is it platform-specific? It shouldn't be platform-specific, but maybe there are some subtle differences in the ordering between CSS/layout/rendering, which can cause OS-specific differences. As suggested, I've now changed the initial value also to be a WeakReference! This way, it's definitely easier to reason that the code still behaves the same. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From fkirmaier at openjdk.java.net Sun Apr 11 15:51:38 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 11 Apr 2021 15:51:38 GMT Subject: RFR: 8264677 MemoryLeak: Progressindicator leaks, when treeShowing is false [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 12:37:07 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264677 >> Updated naming of the test, >> reworked the old test. It now has a much smaller scope and is easier to reason about, the initialization of JavaFX is now seperated from the test itself. > > tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 79: > >> 77: indicator.setProgress(1.0); >> 78: checker.assertCollectable(detIndicator); >> 79: stage.show(); > > Now that you are no longer waiting for `Stage::onShown`, isn't it possible for the test to miss a potential leak? Can you explain why you think it's not needed? That's a good question. OnShown is usually called in about 1 Frame. The memory-leak test takes some times, usually longer as 1 Frame. In the current configuration, it takes up to 1 seconds, with up to 10 checks. Because the check is so much longer, waiting for onShown doesn't really make a difference. ------------- PR: https://git.openjdk.java.net/jfx/pull/455 From jvos at openjdk.java.net Mon Apr 12 07:53:19 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 12 Apr 2021 07:53:19 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> Message-ID: <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> On Sat, 10 Apr 2021 15:01:08 GMT, Kevin Rushforth wrote: >> I'm currently rerunning tests and preparing and update - further analysis showed, that thread attachment is handled in `WebCore::StorageThread::threadEntryPoint()`: >> >> https://github.com/openjdk/jfx/blob/808b1078f762a923bd5e74298daffeb88ed108c2/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp#L76-L87 >> >> The analysis was triggered by a request from @neilcsmith-net on the netbeans mailing list. He pointed out, that the fault should have happened earlier if the the thread indeed was not attached. In that case `GetEnv` is required to return `NULL`. From the [doc](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#getenv): >> >>> If the current thread is not attached to the VM, sets *env to NULL, and returns JNI_EDETACHED. If the specified version is not supported, sets *env to NULL, and returns JNI_EVERSION. Otherwise, sets *env to the appropriate interface, and returns JNI_OK. > > That's good since it will simplify the fix to the root cause, which is that looking up the class fails depending on the ClassLoader used to load the JavaFX modules. I understand the crash would be at a different point, but it would still be a crash, I think? That is, if the method handlers are correctly registered via the OnLoad function, and later a new native thread tries to access a function that is not yet attached, that will still crash, I believe. (at least, the GetEnv will return NULL and that result is used later). So while the 2 issues are not related, I think there are really 2 issues. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From primoz.kokol at gmail.com Mon Apr 12 07:59:21 2021 From: primoz.kokol at gmail.com (=?UTF-8?Q?Primo=C5=BE_Kokol?=) Date: Mon, 12 Apr 2021 09:59:21 +0200 Subject: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: <6F577FB4-A5C6-485A-9BB1-066CB796658B@oracle.com> References: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> <548B61D9-09D6-4871-8A90-771BE5FB8148@oracle.com> <6F577FB4-A5C6-485A-9BB1-066CB796658B@oracle.com> Message-ID: Did the thread dump created using the debug build helped with understanding of what the issue was? ? PrimosK On Tue, 23 Mar 2021 at 18:53, Arun Joseph wrote: > The thread dump doesn?t have enough details to locate where the problem > occurs. Using a debug build with assertions disabled (as mentioned in the > previous mail) may help in generating a thread dump for getting some more > information. > > ? Arun Joseph > > On 18-Mar-2021, at 3:39 PM, Primo? Kokol wrote: > > Thanks for pointing us in the right direction. I wasn't aware that > jfxwebkit.pdb will be > generated also in the case of a production build. > > So after generating a production build we were able to produce a thread > dump (using > jfxwebkit.pdb symbols) at the time when the application freezes. The > complete bug report > including thread dump is there: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788 > > > Could you please just scan through it and let us know whether there is > enough information > to pursue this further or whether any additional information is needed? > > ? PrimosK > > On Tue, 16 Mar 2021 at 13:30, Arun Joseph > wrote: > >> The app is now crashing at InternalFunction which calls jsDynamicCast in >> JSCast.h, which lead to the initial crash. This assert failure occurs >> because the type value is ObjectType instead of InternalFunctionType >> or NullSetterFunctionType. I need to check why this is happens. >> >> NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. >> So, for creating a build without asserts, you can either use the release >> build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a >> minimal debug build. >> >> ? Arun Joseph >> >> On 15-Mar-2021, at 6:08 PM, Primo? Kokol wrote: >> >> I've tried to remove this particular assert statement at "JSCast.h:143": >> // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, >> Target::info())); >> >> ... and now application crashes at different assert statement: >> >> > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> const char * __formal, int __formal) Line 672 C++ Symbols loaded. >> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const >> WTF::String & name, JSC::InternalFunction::NameAdditionMode >> nameAdditionMode) Line 49 C++ Symbols loaded. >> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >> WTF::String & ident) Line 58 C++ Symbols loaded. >> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, >> const WTF::String & name) Line 231 C++ Symbols loaded. >> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >> globalObject, const WTF::String & name, JSC::Bindings::Method * method) >> Line 212 C++ Symbols loaded. >> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * >> globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. >> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) >> Line 124 C++ Symbols loaded. >> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. >> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. >> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ >> Symbols loaded. >> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * >> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >> JSC::JSValue baseValue, const JSC::Identifier & ident, >> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >> const JSC::Instruction * pc) Line 833 C++ Symbols loaded. >> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. >> 00000025dabfaf00() Unknown Non-user code >> 00000025dabfafc0() Unknown Non-user code >> 00000164ca445b4b() Unknown Non-user code >> cccccccccccccccc() Unknown Non-user code >> 00000164ca445b46() Unknown Non-user code >> >> Is there any way we could turn off assertions in general when producing >> debug build? >> >> On Sat, 13 Mar 2021 at 05:41, Arun Joseph >> wrote: >> >>> I?m currently looking into why the native debug build is crashing. This >>> same assert fails while running FileReaderTest using the native debug >>> build. For the time being, you can try building by removing this particular >>> assert statement for debugging. >>> >>> ? Arun Joseph >>> >>> > On 12-Mar-2021, at 11:47 PM, Primo? Kokol >>> wrote: >>> > >>> > Hi Kevin, >>> > >>> > Unfortunately I don't have a test case. We are using various WebViews >>> in >>> > our production application hence we don't know where/why exactly the >>> > application freezes. >>> > >>> > We were hoping that we will be able to identify it using the native >>> debug >>> > build (& attached debugged) but it is now unfortunately crashing with >>> the >>> > above error. >>> > >>> > Side note: >>> > Should I contact Arun directly or is he seeing these messages? >>> > >>> > -- PrimosK >>> > >>> > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth < >>> kevin.rushforth at oracle.com> >>> > wrote: >>> > >>> >> Arun should be able to help you with the crash you are seeing in debug >>> >> mode. >>> >> >>> >> Regarding the hang, do you have a test case that will reproduce it? A >>> >> few different developers have reported similar hangs. We ended up >>> >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >>> >> are) unable to reproduce the hang. >>> >> >>> >> -- Kevin >>> >> >>> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >>> >> >>> >> >>> >> On 3/12/2021 1:06 AM, Primo? Kokol wrote: >>> >>> Hi everyone, >>> >>> >>> >>> I would need some help related to OpenJFX build. >>> >>> >>> >>> I was able to successfully prepare a build following this procedure >>> (from >>> >>> pull/417 request): >>> >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >>> >>> >>> >>> >>> We wanted to use it in our existing application (Java 11.0.10) to >>> debug >>> >> an >>> >>> issue where the application would hang/freeze for no obvious reason >>> >> because >>> >>> of WebKit. >>> >>> >>> >>> In order to use this build we've manually overridden javafx-*.jar >>> files >>> >> in >>> >>> our application with the ones from the above build. >>> >>> We've also placed all produced DLL files in our application's "bin" >>> >> folder >>> >>> so they are properly picked up (I've verified and I can confirm that >>> >>> jfxwebkit.dll produced by our debug build is loaded). >>> >>> >>> >>> After using this native debug build, the application will crash >>> instead >>> >>> with: >>> >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >>> >> Fatal >>> >>> program exit requested. >>> >>> >>> >>> It looks like it happens when JS code calls Java method. >>> >>> >>> >>> There is the call stack at the time when exception happens: >>> >>> >>> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >>> >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >>> >> const >>> >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >>> >>> >>> >>> >>> >> >>> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >>> >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 >>> C++ >>> >>> Symbols loaded. >>> >>> >>> >>> >>> >> >>> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >>> >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >>> >>> jfxwebkit.dll!JSC::jsDynamicCast>> >>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) >>> Line >>> >>> 182 C++ Symbols loaded. >>> >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >>> >> const >>> >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >>> >>> nameAdditionMode) Line 49 C++ Symbols loaded. >>> >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, >>> const >>> >>> WTF::String & ident) Line 58 C++ Symbols loaded. >>> >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & >>> globalData, >>> >>> const WTF::String & name) Line 231 C++ Symbols loaded. >>> >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >>> >>> globalObject, const WTF::String & name, JSC::Bindings::Method * >>> method) >>> >>> Line 212 C++ Symbols loaded. >>> >>> >>> >> >>> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >>> >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >>> >> loaded. >>> >>> >>> >>> >>> >> >>> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >>> >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName >>> propertyName) >>> >>> Line 124 C++ Symbols loaded. >>> >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >>> >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols >>> loaded. >>> >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >>> >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols >>> >> loaded. >>> >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >>> >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 >>> C++ >>> >>> Symbols loaded. >>> >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const >>> JSC::Instruction * >>> >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >>> >>> JSC::JSValue baseValue, const JSC::Identifier & ident, >>> >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >>> >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >>> >> const >>> >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded. >>> >>> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. >>> >>> 000000c7ef8fae90() Unknown Non-user code >>> >>> 000000c7ef8faf50() Unknown Non-user code >>> >>> 0000028d52eeedbb() Unknown Non-user code >>> >>> cccccccccccccccc() Unknown Non-user code >>> >>> 0000028d52eeedb6() Unknown Non-user code >>> >>> >>> >>> ... and partial output from the output console: >>> >>> >>> >>> .... >>> >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow >>> only, >>> >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, >>> (I)solates >>> >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as >>> >> fi(x)ed, >>> >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to >>> >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, >>> >> (t)transformed >>> >>> ancestor >>> >>> Dirty (z)-lists, Dirty (n)ormal flow lists >>> >>> Traversal needs: requirements (t)raversal on descendants, (b)acking >>> or >>> >>> hierarchy traversal on descendants, (r)equirements traversal on all >>> >>> descendants, requirements traversal on all (s)ubsequent layers, >>> >> (h)ierarchy >>> >>> traversal on all descendants, update of paint (o)rder children >>> >>> Update needs: post-(l)ayout requirements, (g)eometry, (k)ids >>> geometry, >>> >>> (c)onfig, layer conne(x)ion, (s)crolling tree >>> >>> Scrolling scope: box contents >>> >>> >>> >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) >>> width=460 >>> >>> height=650 RenderView 0x28d4d4d1cd0 >>> >>> S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) >>> width= >>> >> no >>> >>> compositing work to do >>> >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks >>> >>> >>> >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize >>> >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 >>> >> header >>> >>> height 0 footer height 0 fixed behavior 0 >>> >>> layoutViewport: (0,0) width=460 height=650 >>> >>> visualViewport: (0,0) width=460 height=650 (is override 0) >>> >>> stable origins: min: (0.00,0.00) max: (0.00,0.00) >>> >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time >>> >> 24.89s >>> >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV >>> >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV >>> >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV >>> >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV >>> >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm, >>> Target::info()) >>> >>> >>> >> >>> C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) >>> >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl >>> >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >>> >> Fatal >>> >>> program exit requested. >>> >>> >>> >>> Note that this crash isn't happening with official JavaFX 15, 16, and >>> >>> 17-ea+2 builds (that are at the time of writing this available on the >>> >>> maven), but unfortunately we can't use these for debugging purposes. >>> >>> >>> >>> Does that indicate any issues with the native debug build or is this >>> some >>> >>> regression that was introduced in the current `master` branch >>> recently >>> >>> (after 17-ea+2)? >>> >>> >>> >>> Thanks for any helpful hints/advice in advance! >>> >>> >>> >>> Best regards, >>> >>> PrimosK >>> >> >>> >> >>> >>> >> > From github.com+7517141+yososs at openjdk.java.net Mon Apr 12 08:34:25 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 12 Apr 2021 08:34:25 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow Message-ID: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> https://bugs.openjdk.java.net/browse/JDK-8197991 The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. This greatly improves the response when selecting multiple items in ListView and TableView. However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) ListView * selectAll: 400_000-> 10_000_000 * selectRange: 7_000-> 70_000 TableView * selectAll: 8_000-> 700_000 * selectRange: 7_000-> 50_000 You can see performance improvements in the following applications: ``` SelectListViewTest.java import javafx.application.Application; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListView; import javafx.scene.control.SelectionMode; import javafx.scene.layout.BorderPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class SelectListViewTest extends Application { final int ROW_COUNT = 70_000; // final int ROW_COUNT = 400_000; // final int ROW_COUNT = 10_000_000; // final int ROW_COUNT = 7_000; @Override public void start(Stage stage) { ListView listView = new ListView<>(); listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); ObservableList items = listView.getItems(); for(int i=0; iselectAll(listView)); clearSelection.setOnAction((e)->clearSelection(listView)); selectToStart.setOnAction((e)->selectToStart(listView)); selectToEnd.setOnAction((e)->selectToLast(listView)); selectPrevious.setOnAction((e)->selectPrevious(listView)); selectNext.setOnAction((e)->selectNext(listView)); stage.show(); } private void selectAll(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectAll(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void clearSelection(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().clearSelection(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToStart(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToLast(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectPrevious(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectPrevious(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectNext(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectNext(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } public static void main(String[] args) { Application.launch(args); } } ``` SelectTableViewTest.java import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.SelectionMode; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.layout.BorderPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class SelectTableViewTest extends Application { final int ROW_COUNT = 700_000; // final int ROW_COUNT = 80_000; // final int ROW_COUNT = 50_000; // final int ROW_COUNT = 8_000; final int COL_COUNT = 3; @Override public void start(Stage stage) { TableView tableView = new TableView<>(); tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); final ObservableList> columns = tableView.getColumns(); for(int i=0; i column = new TableColumn<>("Col"+i); final int colIndex=i; column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); column.setPrefWidth(150); columns.add(column); } ObservableList items = tableView.getItems(); for(int i=0; iselectAll(tableView)); clearSelection.setOnAction((e)->clearSelection(tableView)); selectToStart.setOnAction((e)->selectToStart(tableView)); selectToEnd.setOnAction((e)->selectToLast(tableView)); selectPrevious.setOnAction((e)->selectPrevious(tableView)); selectNext.setOnAction((e)->selectNext(tableView)); stage.show(); } private void selectAll(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectAll(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void clearSelection(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().clearSelection(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToStart(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToLast(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectPrevious(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectPrevious(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectNext(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectNext(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } public static void main(String[] args) { Application.launch(args); } } ------------- Commit messages: - 8197991: Fix multi-select performance issues - 8197991: Fix multi-select performance issues Changes: https://git.openjdk.java.net/jfx/pull/127/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 58 lines in 2 files changed: 50 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/127/head:pull/127 PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Mon Apr 12 08:34:27 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 12 Apr 2021 08:34:27 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> Message-ID: On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > ``` SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > > ``` SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } I commented. As an overview, the new implementation can handle selectRange up to 50_000 records. This assumes general manual operation. However, after clearing the selection (a rare operation in manual operation), it is as efficient as selectAll. However, this is a two-time change. The response difference is caused by the next conditional branch (size == 0) of SortedList. This will be the next hotspot to improve as seen by this improvement. I can't include it in this PR because I don't have time to work. I haven't tried it, but changing the call to insertToMapping for each record of this method to setAllToMapping for each range seems to be as efficient as selectAll. javafx.collections.transformation.SortedList.java ``` SortedList.java private void addRemove(Change c) { if (c.getFrom() == 0 && c.getRemovedSize() == size) { removeAllFromMapping(); } else { for (int i = 0, sz = c.getRemovedSize(); i < sz; ++i) { removeFromMapping(c.getFrom(), c.getRemoved().get(i)); } } if (size == 0) { setAllToMapping(c.getList(), c.getTo()); // This is basically equivalent to getAddedSubList // as size is 0, only valid "from" is also 0 } else { for (int i = c.getFrom(), to = c.getTo(); i < to; ++i) { insertToMapping(c.getList().get(i), i); } } } ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From robilad at openjdk.java.net Mon Apr 12 08:34:30 2021 From: robilad at openjdk.java.net (Dalibor Topic) Date: Mon, 12 Apr 2021 08:34:30 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> Message-ID: <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.480948e2-2d6a-4e48-986f-0e4d9b019274@github.com> On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > ``` SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > > ``` SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } Hi, I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+2120116+baumeister at openjdk.java.net Mon Apr 12 08:34:34 2021 From: github.com+2120116+baumeister at openjdk.java.net (Timm) Date: Mon, 12 Apr 2021 08:34:34 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> Message-ID: On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > ``` SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > > ``` SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } Any progress with having this merged? ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From aghaisas at openjdk.java.net Mon Apr 12 08:34:46 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 12 Apr 2021 08:34:46 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> Message-ID: <1pAtd4WAcBklWUnlXeR3ezHWQxE0elZ5omkLCsCUYEM=.47b1a43c-b8b4-4231-b603-a1c73db573a9@github.com> On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > ``` SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > > ``` SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } This is a very good attempt to improve selection performance. I have few review comments. I ran the manual test that you have provided. It does show the improvement. Can you please provide an automated test along with your fix? modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 861: > 859: } > 860: > 861: /** Returns number of true bits in BitSet */ Method description and work done by it is no more matching. Can you please update the comment? modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 881: > 879: Number n = (Number) obj; > 880: int index = n.intValue(); > 881: if(!bitset.get(index)) { Spacing correction needed. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 885: > 883: } > 884: // is left most bit > 885: if(index==0) { Spacing correction needed. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 890: > 888: > 889: // is right most bit > 890: if( index == bitset.length()-1 ){ Spacing correction needed. Correct spacing is : "if (index == bitset.length()-1) {" Please correct at other places in this PR. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 895: > 893: > 894: // count right bit > 895: if( index > bitset.length()/2 ) { Spacing correction needed. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 899: > 897: for (;;) { > 898: index = bitset.nextSetBit(index + 1); > 899: if (index < 0) { As we are checking for nextSetBit, shouldn't we be checking for overflow rather than underflow? Refer - [javadoc](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/BitSet.html#nextSetBit(int)) modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 912: > 910: for(;;){ > 911: index = bitset.previousSetBit(index-1); > 912: if(index<0){ Spacing correction needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From jpereda at openjdk.java.net Mon Apr 12 08:34:53 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 12 Apr 2021 08:34:53 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> Message-ID: On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > ``` SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > > ``` SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } I've run SelectListView and SelectTableView tests and both run fine. As for the SelectTableView test, with 700_000 rows, when there is no selection, pressing SelectToEnd takes around 3.1 seconds, as expected. However, if there is one single row selected, after pressing SelectToEnd, the selection doesn't complete, and I have to abort and quit the app. Instead of: tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); this: int focusedIndex = tableView.getSelectionModel().getFocusedIndex(); tableView.getSelectionModel().clearSelection(); tableView.getSelectionModel().selectRange(focusedIndex, tableView.getItems().size()); seems to work and times are again around 3 seconds or less. Maybe you can check why that is happening? And about the test discussion above, I understand that running the included tests as part of the automated test wouldn't make much sense (as these can take too long). However, maybe these could be added as unit tests with a reduced number of item/rows. Instead of measuring performance (selection times would depend on each machine), I'd say you could simply verify that selection works as expected. While most of the changes are just about caching `size()`, the new implementation of `MultipleSelectionModelBase::indexOf` adds some new code that should be tested, as part of the unit tests, again not for performance, but to assert it returns the expected values. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From kcr at openjdk.java.net Mon Apr 12 08:34:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 08:34:34 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> Message-ID: On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > ``` SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > > ``` SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } @aghaisas can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Mon Apr 12 08:34:52 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 12 Apr 2021 08:34:52 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <1pAtd4WAcBklWUnlXeR3ezHWQxE0elZ5omkLCsCUYEM=.47b1a43c-b8b4-4231-b603-a1c73db573a9@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.d204e59c-c7c2-4101-80b8-327d1ce1d4c2@github.com> <1pAtd4WAcBklWUnlXeR3ezHWQxE0elZ5omkLCsCUYEM=.47b1a43c-b8b4-4231-b603-a1c73db573a9@github.com> Message-ID: On Mon, 14 Sep 2020 10:03:59 GMT, Ajit Ghaisas wrote: > Can you please provide an automated test along with your fix? Automated performance testing should be distinguished from regular testing tasks, as it extends the build time. Is there a task name for that in gradle? Also, didn't you exclude performance testing from automated testing (or Unit Test)? Or, if you want to maintain this test in a repository, you need to tell me the directory where it is stored. The reviewer didn't point out that the There's a little bit of wastage left in the toArray(), so I'm going to push a modified version. > modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 861: > >> 859: } >> 860: >> 861: /** Returns number of true bits in BitSet */ > > Method description and work done by it is no more matching. Can you please update the comment? This comment is correct. this.size is the cache. > modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 899: > >> 897: for (;;) { >> 898: index = bitset.nextSetBit(index + 1); >> 899: if (index < 0) { > > As we are checking for nextSetBit, shouldn't we be checking for overflow rather than underflow? > Refer - [javadoc](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/BitSet.html#nextSetBit(int)) Since it cannot be loaded with a smaller number of items than Integer.MAX_VALUE (it looks like it freezes), overflow does not occur in the actual usage environment. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Mon Apr 12 08:35:59 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 12 Apr 2021 08:35:59 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction Message-ID: If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. `tableView.setFixedCellSize(height)` This proposal includes a fix because the current code does not correctly implement column virtualization. The improvement of this proposal can be seen in the following test program. ``` Java import java.util.Arrays; import java.util.Collections; import javafx.animation.AnimationTimer; import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.layout.BorderPane; import javafx.scene.layout.HBox; import javafx.stage.Stage; public class BigTableViewTest2 extends Application { private static final boolean USE_WIDTH_FIXED_SIZE = false; private static final boolean USE_HEIGHT_FIXED_SIZE = true; // private static final int COL_COUNT=30; // private static final int COL_COUNT=300; // private static final int COL_COUNT=600; private static final int COL_COUNT = 1000; private static final int ROW_COUNT = 1000; @Override public void start(final Stage primaryStage) throws Exception { final TableView tableView = new TableView<>(); // tableView.setTableMenuButtonVisible(true); //too heavy if (USE_HEIGHT_FIXED_SIZE) { tableView.setFixedCellSize(24); } final ObservableList> columns = tableView.getColumns(); for (int i = 0; i < COL_COUNT; i++) { final TableColumn column = new TableColumn<>("Col" + i); final int colIndex = i; column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); columns.add(column); if (USE_WIDTH_FIXED_SIZE) { column.setPrefWidth(60); column.setMaxWidth(60); column.setMinWidth(60); } } final Button load = new Button("load"); load.setOnAction(e -> { final ObservableList items = tableView.getItems(); items.clear(); for (int i = 0; i < ROW_COUNT; i++) { final String[] rec = new String[COL_COUNT]; for (int j = 0; j < rec.length; j++) { rec[j] = i + ":" + j; } items.add(rec); } }); final Button reverse = new Button("reverse columns"); reverse.setOnAction(e -> { final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); Collections.reverse(Arrays.asList(itemsArray)); tableView.getColumns().clear(); tableView.getColumns().addAll(Arrays.asList(itemsArray)); }); final Button hide = new Button("hide % 10"); hide.setOnAction(e -> { for (int i = 0, n = columns.size(); i < n; i++) { if (i % 10 == 0) { columns.get(i).setVisible(false); } } }); final BorderPane root = new BorderPane(tableView); root.setTop(new HBox(8, load, reverse, hide)); final Scene scene = new Scene(root, 800, 800); primaryStage.setScene(scene); primaryStage.show(); this.prepareTimeline(scene); } public static void main(final String[] args) { Application.launch(args); } private void prepareTimeline(final Scene scene) { new AnimationTimer() { @Override public void handle(final long now) { final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); } }.start(); } } ``` Java import javafx.animation.AnimationTimer; import javafx.application.Application; import javafx.application.Platform; import javafx.beans.property.ReadOnlyStringWrapper; import javafx.scene.Scene; import javafx.scene.control.TreeItem; import javafx.scene.control.TreeTableColumn; import javafx.scene.control.TreeTableColumn.CellDataFeatures; import javafx.scene.control.TreeTableView; import javafx.stage.Stage; public class BigTreeTableViewTest extends Application { private static final boolean USE_HEIGHT_FIXED_SIZE = true; // private static final int COL_COUNT = 900; private static final int COL_COUNT = 800; // private static final int COL_COUNT = 600; // private static final int COL_COUNT = 500; // private static final int COL_COUNT = 400; // private static final int COL_COUNT = 300; // private static final int COL_COUNT = 200; // private static final int COL_COUNT = 100; public static void main(final String[] args) { Application.launch(args); } @Override public void start(final Stage stage) { final TreeItem root = new TreeItem<>("Root"); final TreeTableView treeTableView = new TreeTableView<>(root); if (USE_HEIGHT_FIXED_SIZE) { treeTableView.setFixedCellSize(24); } treeTableView.setPrefWidth(800); treeTableView.setPrefHeight(500); stage.setWidth(800); stage.setHeight(500); Platform.runLater(() -> { for (int i = 0; i < 100; i++) { TreeItem child = this.addNodes(root); child = this.addNodes(child); child = this.addNodes(child); child = this.addNodes(child); } }); final TreeTableColumn[] cols = new TreeTableColumn[COL_COUNT + 1]; final TreeTableColumn column = new TreeTableColumn<>("Column"); column.setPrefWidth(150); column.setCellValueFactory( (final CellDataFeatures p) -> new ReadOnlyStringWrapper(p.getValue().getValue())); cols[0] = column; for (int i = 0; i < COL_COUNT; i++) { final TreeTableColumn col = new TreeTableColumn<>(Integer.toString(i)); col.setPrefWidth(60); col.setCellValueFactory(val -> new ReadOnlyStringWrapper(val.getValue().getValue()+":"+val.getTreeTableColumn().getText())); cols[i + 1] = col; } treeTableView.getColumns().addAll(cols); final Scene scene = new Scene(treeTableView, 800, 500); stage.setScene(scene); stage.show(); this.prepareTimeline(scene); } private TreeItem addNodes(final TreeItem parent) { final TreeItem[] childNodes = new TreeItem[20]; for (int i = 0; i < childNodes.length; i++) { childNodes[i] = new TreeItem<>("N" + i); } final TreeItem root = new TreeItem<>("dir"); root.setExpanded(true); root.getChildren().addAll(childNodes); parent.setExpanded(true); parent.getChildren().add(root); return root; } private void prepareTimeline(final Scene scene) { new AnimationTimer() { @Override public void handle(final long now) { final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); } }.start(); } } ------------- Commit messages: - 8185886: Fix scroll performance of TableView with many columns - 8185886: Fix scroll performance of TableView with many columns Changes: https://git.openjdk.java.net/jfx/pull/125/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=125&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8185887 Stats: 237 lines in 5 files changed: 113 ins; 62 del; 62 mod Patch: https://git.openjdk.java.net/jfx/pull/125.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/125/head:pull/125 PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+7517141+yososs at openjdk.java.net Mon Apr 12 08:36:02 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 12 Apr 2021 08:36:02 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction In-Reply-To: References: Message-ID: On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > ``` Java > import java.util.Arrays; > import java.util.Collections; > > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > private static final boolean USE_WIDTH_FIXED_SIZE = false; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=30; > // private static final int COL_COUNT=300; > // private static final int COL_COUNT=600; > private static final int COL_COUNT = 1000; > private static final int ROW_COUNT = 1000; > > @Override > public void start(final Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > // tableView.setTableMenuButtonVisible(true); //too heavy > if (USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > final ObservableList> columns = tableView.getColumns(); > for (int i = 0; i < COL_COUNT; i++) { > final TableColumn column = new TableColumn<>("Col" + i); > final int colIndex = i; > column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if (USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > final Button load = new Button("load"); > load.setOnAction(e -> { > final ObservableList items = tableView.getItems(); > items.clear(); > for (int i = 0; i < ROW_COUNT; i++) { > final String[] rec = new String[COL_COUNT]; > for (int j = 0; j < rec.length; j++) { > rec[j] = i + ":" + j; > } > items.add(rec); > } > }); > > final Button reverse = new Button("reverse columns"); > reverse.setOnAction(e -> { > final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); > Collections.reverse(Arrays.asList(itemsArray)); > tableView.getColumns().clear(); > tableView.getColumns().addAll(Arrays.asList(itemsArray)); > }); > > final Button hide = new Button("hide % 10"); > hide.setOnAction(e -> { > for (int i = 0, n = columns.size(); i < n; i++) { > if (i % 10 == 0) { > columns.get(i).setVisible(false); > } > } > }); > > final BorderPane root = new BorderPane(tableView); > root.setTop(new HBox(8, load, reverse, hide)); > > final Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > this.prepareTimeline(scene); > } > > public static void main(final String[] args) { > Application.launch(args); > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > } > > > ``` Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.application.Platform; > import javafx.beans.property.ReadOnlyStringWrapper; > import javafx.scene.Scene; > import javafx.scene.control.TreeItem; > import javafx.scene.control.TreeTableColumn; > import javafx.scene.control.TreeTableColumn.CellDataFeatures; > import javafx.scene.control.TreeTableView; > import javafx.stage.Stage; > > public class BigTreeTableViewTest extends Application { > > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT = 900; > private static final int COL_COUNT = 800; > // private static final int COL_COUNT = 600; > // private static final int COL_COUNT = 500; > // private static final int COL_COUNT = 400; > // private static final int COL_COUNT = 300; > // private static final int COL_COUNT = 200; > // private static final int COL_COUNT = 100; > > public static void main(final String[] args) { > Application.launch(args); > } > > @Override > public void start(final Stage stage) { > final TreeItem root = new TreeItem<>("Root"); > final TreeTableView treeTableView = new TreeTableView<>(root); > if (USE_HEIGHT_FIXED_SIZE) { > treeTableView.setFixedCellSize(24); > } > treeTableView.setPrefWidth(800); > treeTableView.setPrefHeight(500); > stage.setWidth(800); > stage.setHeight(500); > > Platform.runLater(() -> { > for (int i = 0; i < 100; i++) { > TreeItem child = this.addNodes(root); > child = this.addNodes(child); > child = this.addNodes(child); > child = this.addNodes(child); > } > }); > > final TreeTableColumn[] cols = new TreeTableColumn[COL_COUNT + 1]; > final TreeTableColumn column = new TreeTableColumn<>("Column"); > column.setPrefWidth(150); > column.setCellValueFactory( > (final CellDataFeatures p) -> new ReadOnlyStringWrapper(p.getValue().getValue())); > cols[0] = column; > > for (int i = 0; i < COL_COUNT; i++) { > final TreeTableColumn col = new TreeTableColumn<>(Integer.toString(i)); > col.setPrefWidth(60); > col.setCellValueFactory(val -> new ReadOnlyStringWrapper(val.getValue().getValue()+":"+val.getTreeTableColumn().getText())); > cols[i + 1] = col; > } > treeTableView.getColumns().addAll(cols); > > final Scene scene = new Scene(treeTableView, 800, 500); > stage.setScene(scene); > stage.show(); > this.prepareTimeline(scene); > } > > private TreeItem addNodes(final TreeItem parent) { > > final TreeItem[] childNodes = new TreeItem[20]; > for (int i = 0; i < childNodes.length; i++) { > childNodes[i] = new TreeItem<>("N" + i); > } > final TreeItem root = new TreeItem<>("dir"); > root.setExpanded(true); > root.getChildren().addAll(childNodes); > parent.setExpanded(true); > parent.getChildren().add(root); > return root; > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > > } I'm signed to OCA and already a contributor. My name is "Naohiro Yoshimoto" I have received an approved email on 2019-8-3. 19fabf2eafcb02b519d39a1b0a9dad5b9209db64 * Constructor creates multiple cell nodes, but the Fixed a wasteful problem of creating all cells and deleting out-of-display cells because the fixedCellSize attribute was not initialized in the constructor.. * Reduce the load on ExpressionHelper.removeListener by removing cells outside of the display range from the back of the scrolling operation. When setting the cell height to a fixed value with setFixedCellSize(), column virtualization can improve performance. As the next step, I think it is possible to try to enable column virtualization regardless of whether setFixedCellSize() is set or not. Before doing this step, the direct access validation of the internal structure of the test code needs to be changed via the public API. Since there was a problem that the cell was not updated when the window was maximized, I added a fix to TreeTableViewSkin.java. Added test code (BigTreeTableViewTest) for TreeTableView to the first post. @kleopatra Does the test code I added (BigTreeTableViewTest.java) also have side effects? When the startup time is measured by eye, the impression changes depending on the individual difference. The effect of runLater affects your experience. However, I succeeded in further improving performance by eliminating another bottleneck in TreeTableView. Of course, it also includes improvements in startup time. I plan to commit at a later date. Column virtualization causes shortness of breath when scrolling a large stroke horizontally. This does not happen when stroking on the scrollbar. Looks like a potential problem with VirtualFlow. If you are worried about shortness of breath, the following code will help reduce the problem. ``` Java ?private static final int OVERLAP_MARGIN = 500; private static boolean isOverlap(double start, double end, double start2, double end2){ start = Math.max(start-OVERLAP_MARGIN, start2); end = Math.min(end+OVERLAP_MARGIN, end2); return (start<=end2 && end >= start2); } Below are the answers to JBS's suggestions. > The patch below resolves the issue, but it is not likely the correct solution (we are trying to determine the table width, but we are getting the width and padding on the underlying virtualflow (the width is fine, the padding should really come from tableview directly): You probably mention this part, At least padding refers to Skinnable(TableRow or TreeTableRow). This is the same as before (L683). The width of VirtualFlow is determined by the header of Table. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java#L360-L365 ``` Java final VirtualFlow virtualFlow = getVirtualFlow(); final double scrollX = virtualFlow == null ? 0.0 : virtualFlow.getHbar().getValue(); final Insets padding = getSkinnable().getPadding(); final double vfWidth = virtualFlow == null ? 0.0:virtualFlow.getWidth(); final double headerWidth = vfWidth - (padding.getLeft() + padding.getRight()); For example, can you assume a case that does not work properly? This is the answer to JBS's comment. The BigTreeTableViewTest.java attached to this PR commentary is a modified version of the JDK-8166956 test code. The original test code is good for reproducing the problem, but I have decided that it cannot be used as a test code because the cell values are random and the cell values change randomly with the close / expand operation. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From nlisker at openjdk.java.net Mon Apr 12 08:36:04 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 12 Apr 2021 08:36:04 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction In-Reply-To: References: Message-ID: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.8f66e2b1-245d-47f8-b3eb-dae0499fceed@github.com> On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > ``` Java > import java.util.Arrays; > import java.util.Collections; > > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > private static final boolean USE_WIDTH_FIXED_SIZE = false; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=30; > // private static final int COL_COUNT=300; > // private static final int COL_COUNT=600; > private static final int COL_COUNT = 1000; > private static final int ROW_COUNT = 1000; > > @Override > public void start(final Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > // tableView.setTableMenuButtonVisible(true); //too heavy > if (USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > final ObservableList> columns = tableView.getColumns(); > for (int i = 0; i < COL_COUNT; i++) { > final TableColumn column = new TableColumn<>("Col" + i); > final int colIndex = i; > column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if (USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > final Button load = new Button("load"); > load.setOnAction(e -> { > final ObservableList items = tableView.getItems(); > items.clear(); > for (int i = 0; i < ROW_COUNT; i++) { > final String[] rec = new String[COL_COUNT]; > for (int j = 0; j < rec.length; j++) { > rec[j] = i + ":" + j; > } > items.add(rec); > } > }); > > final Button reverse = new Button("reverse columns"); > reverse.setOnAction(e -> { > final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); > Collections.reverse(Arrays.asList(itemsArray)); > tableView.getColumns().clear(); > tableView.getColumns().addAll(Arrays.asList(itemsArray)); > }); > > final Button hide = new Button("hide % 10"); > hide.setOnAction(e -> { > for (int i = 0, n = columns.size(); i < n; i++) { > if (i % 10 == 0) { > columns.get(i).setVisible(false); > } > } > }); > > final BorderPane root = new BorderPane(tableView); > root.setTop(new HBox(8, load, reverse, hide)); > > final Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > this.prepareTimeline(scene); > } > > public static void main(final String[] args) { > Application.launch(args); > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > } > > > ``` Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.application.Platform; > import javafx.beans.property.ReadOnlyStringWrapper; > import javafx.scene.Scene; > import javafx.scene.control.TreeItem; > import javafx.scene.control.TreeTableColumn; > import javafx.scene.control.TreeTableColumn.CellDataFeatures; > import javafx.scene.control.TreeTableView; > import javafx.stage.Stage; > > public class BigTreeTableViewTest extends Application { > > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT = 900; > private static final int COL_COUNT = 800; > // private static final int COL_COUNT = 600; > // private static final int COL_COUNT = 500; > // private static final int COL_COUNT = 400; > // private static final int COL_COUNT = 300; > // private static final int COL_COUNT = 200; > // private static final int COL_COUNT = 100; > > public static void main(final String[] args) { > Application.launch(args); > } > > @Override > public void start(final Stage stage) { > final TreeItem root = new TreeItem<>("Root"); > final TreeTableView treeTableView = new TreeTableView<>(root); > if (USE_HEIGHT_FIXED_SIZE) { > treeTableView.setFixedCellSize(24); > } > treeTableView.setPrefWidth(800); > treeTableView.setPrefHeight(500); > stage.setWidth(800); > stage.setHeight(500); > > Platform.runLater(() -> { > for (int i = 0; i < 100; i++) { > TreeItem child = this.addNodes(root); > child = this.addNodes(child); > child = this.addNodes(child); > child = this.addNodes(child); > } > }); > > final TreeTableColumn[] cols = new TreeTableColumn[COL_COUNT + 1]; > final TreeTableColumn column = new TreeTableColumn<>("Column"); > column.setPrefWidth(150); > column.setCellValueFactory( > (final CellDataFeatures p) -> new ReadOnlyStringWrapper(p.getValue().getValue())); > cols[0] = column; > > for (int i = 0; i < COL_COUNT; i++) { > final TreeTableColumn col = new TreeTableColumn<>(Integer.toString(i)); > col.setPrefWidth(60); > col.setCellValueFactory(val -> new ReadOnlyStringWrapper(val.getValue().getValue()+":"+val.getTreeTableColumn().getText())); > cols[i + 1] = col; > } > treeTableView.getColumns().addAll(cols); > > final Scene scene = new Scene(treeTableView, 800, 500); > stage.setScene(scene); > stage.show(); > this.prepareTimeline(scene); > } > > private TreeItem addNodes(final TreeItem parent) { > > final TreeItem[] childNodes = new TreeItem[20]; > for (int i = 0; i < childNodes.length; i++) { > childNodes[i] = new TreeItem<>("N" + i); > } > final TreeItem root = new TreeItem<>("dir"); > root.setExpanded(true); > root.getChildren().addAll(childNodes); > parent.setExpanded(true); > parent.getChildren().add(root); > return root; > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > > } The title of your PR should match the title of the JBS issue. Moreover, #108 already tackles this issue with a different approach and 2 PRs on the same issue can't be intetgrated. Since I'm not familiar with this code, I can't advise on who's solution is more suitable. I suggest you discuss both of the approaches on the mailing list. I saw many JBS issues around this performance issue, probably one of them fits (or a new one can be created). ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From robilad at openjdk.java.net Mon Apr 12 08:36:05 2021 From: robilad at openjdk.java.net (Dalibor Topic) Date: Mon, 12 Apr 2021 08:36:05 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction In-Reply-To: References: Message-ID: On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > ``` Java > import java.util.Arrays; > import java.util.Collections; > > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > private static final boolean USE_WIDTH_FIXED_SIZE = false; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=30; > // private static final int COL_COUNT=300; > // private static final int COL_COUNT=600; > private static final int COL_COUNT = 1000; > private static final int ROW_COUNT = 1000; > > @Override > public void start(final Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > // tableView.setTableMenuButtonVisible(true); //too heavy > if (USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > final ObservableList> columns = tableView.getColumns(); > for (int i = 0; i < COL_COUNT; i++) { > final TableColumn column = new TableColumn<>("Col" + i); > final int colIndex = i; > column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if (USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > final Button load = new Button("load"); > load.setOnAction(e -> { > final ObservableList items = tableView.getItems(); > items.clear(); > for (int i = 0; i < ROW_COUNT; i++) { > final String[] rec = new String[COL_COUNT]; > for (int j = 0; j < rec.length; j++) { > rec[j] = i + ":" + j; > } > items.add(rec); > } > }); > > final Button reverse = new Button("reverse columns"); > reverse.setOnAction(e -> { > final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); > Collections.reverse(Arrays.asList(itemsArray)); > tableView.getColumns().clear(); > tableView.getColumns().addAll(Arrays.asList(itemsArray)); > }); > > final Button hide = new Button("hide % 10"); > hide.setOnAction(e -> { > for (int i = 0, n = columns.size(); i < n; i++) { > if (i % 10 == 0) { > columns.get(i).setVisible(false); > } > } > }); > > final BorderPane root = new BorderPane(tableView); > root.setTop(new HBox(8, load, reverse, hide)); > > final Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > this.prepareTimeline(scene); > } > > public static void main(final String[] args) { > Application.launch(args); > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > } > > > ``` Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.application.Platform; > import javafx.beans.property.ReadOnlyStringWrapper; > import javafx.scene.Scene; > import javafx.scene.control.TreeItem; > import javafx.scene.control.TreeTableColumn; > import javafx.scene.control.TreeTableColumn.CellDataFeatures; > import javafx.scene.control.TreeTableView; > import javafx.stage.Stage; > > public class BigTreeTableViewTest extends Application { > > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT = 900; > private static final int COL_COUNT = 800; > // private static final int COL_COUNT = 600; > // private static final int COL_COUNT = 500; > // private static final int COL_COUNT = 400; > // private static final int COL_COUNT = 300; > // private static final int COL_COUNT = 200; > // private static final int COL_COUNT = 100; > > public static void main(final String[] args) { > Application.launch(args); > } > > @Override > public void start(final Stage stage) { > final TreeItem root = new TreeItem<>("Root"); > final TreeTableView treeTableView = new TreeTableView<>(root); > if (USE_HEIGHT_FIXED_SIZE) { > treeTableView.setFixedCellSize(24); > } > treeTableView.setPrefWidth(800); > treeTableView.setPrefHeight(500); > stage.setWidth(800); > stage.setHeight(500); > > Platform.runLater(() -> { > for (int i = 0; i < 100; i++) { > TreeItem child = this.addNodes(root); > child = this.addNodes(child); > child = this.addNodes(child); > child = this.addNodes(child); > } > }); > > final TreeTableColumn[] cols = new TreeTableColumn[COL_COUNT + 1]; > final TreeTableColumn column = new TreeTableColumn<>("Column"); > column.setPrefWidth(150); > column.setCellValueFactory( > (final CellDataFeatures p) -> new ReadOnlyStringWrapper(p.getValue().getValue())); > cols[0] = column; > > for (int i = 0; i < COL_COUNT; i++) { > final TreeTableColumn col = new TreeTableColumn<>(Integer.toString(i)); > col.setPrefWidth(60); > col.setCellValueFactory(val -> new ReadOnlyStringWrapper(val.getValue().getValue()+":"+val.getTreeTableColumn().getText())); > cols[i + 1] = col; > } > treeTableView.getColumns().addAll(cols); > > final Scene scene = new Scene(treeTableView, 800, 500); > stage.setScene(scene); > stage.show(); > this.prepareTimeline(scene); > } > > private TreeItem addNodes(final TreeItem parent) { > > final TreeItem[] childNodes = new TreeItem[20]; > for (int i = 0; i < childNodes.length; i++) { > childNodes[i] = new TreeItem<>("N" + i); > } > final TreeItem root = new TreeItem<>("dir"); > root.setExpanded(true); > root.getChildren().addAll(childNodes); > parent.setExpanded(true); > parent.getChildren().add(root); > return root; > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > > } Hi, I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From fastegal at openjdk.java.net Mon Apr 12 08:36:07 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 08:36:07 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction In-Reply-To: References: Message-ID: On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > ``` Java > import java.util.Arrays; > import java.util.Collections; > > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > private static final boolean USE_WIDTH_FIXED_SIZE = false; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=30; > // private static final int COL_COUNT=300; > // private static final int COL_COUNT=600; > private static final int COL_COUNT = 1000; > private static final int ROW_COUNT = 1000; > > @Override > public void start(final Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > // tableView.setTableMenuButtonVisible(true); //too heavy > if (USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > final ObservableList> columns = tableView.getColumns(); > for (int i = 0; i < COL_COUNT; i++) { > final TableColumn column = new TableColumn<>("Col" + i); > final int colIndex = i; > column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if (USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > final Button load = new Button("load"); > load.setOnAction(e -> { > final ObservableList items = tableView.getItems(); > items.clear(); > for (int i = 0; i < ROW_COUNT; i++) { > final String[] rec = new String[COL_COUNT]; > for (int j = 0; j < rec.length; j++) { > rec[j] = i + ":" + j; > } > items.add(rec); > } > }); > > final Button reverse = new Button("reverse columns"); > reverse.setOnAction(e -> { > final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); > Collections.reverse(Arrays.asList(itemsArray)); > tableView.getColumns().clear(); > tableView.getColumns().addAll(Arrays.asList(itemsArray)); > }); > > final Button hide = new Button("hide % 10"); > hide.setOnAction(e -> { > for (int i = 0, n = columns.size(); i < n; i++) { > if (i % 10 == 0) { > columns.get(i).setVisible(false); > } > } > }); > > final BorderPane root = new BorderPane(tableView); > root.setTop(new HBox(8, load, reverse, hide)); > > final Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > this.prepareTimeline(scene); > } > > public static void main(final String[] args) { > Application.launch(args); > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > } > > > ``` Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.application.Platform; > import javafx.beans.property.ReadOnlyStringWrapper; > import javafx.scene.Scene; > import javafx.scene.control.TreeItem; > import javafx.scene.control.TreeTableColumn; > import javafx.scene.control.TreeTableColumn.CellDataFeatures; > import javafx.scene.control.TreeTableView; > import javafx.stage.Stage; > > public class BigTreeTableViewTest extends Application { > > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT = 900; > private static final int COL_COUNT = 800; > // private static final int COL_COUNT = 600; > // private static final int COL_COUNT = 500; > // private static final int COL_COUNT = 400; > // private static final int COL_COUNT = 300; > // private static final int COL_COUNT = 200; > // private static final int COL_COUNT = 100; > > public static void main(final String[] args) { > Application.launch(args); > } > > @Override > public void start(final Stage stage) { > final TreeItem root = new TreeItem<>("Root"); > final TreeTableView treeTableView = new TreeTableView<>(root); > if (USE_HEIGHT_FIXED_SIZE) { > treeTableView.setFixedCellSize(24); > } > treeTableView.setPrefWidth(800); > treeTableView.setPrefHeight(500); > stage.setWidth(800); > stage.setHeight(500); > > Platform.runLater(() -> { > for (int i = 0; i < 100; i++) { > TreeItem child = this.addNodes(root); > child = this.addNodes(child); > child = this.addNodes(child); > child = this.addNodes(child); > } > }); > > final TreeTableColumn[] cols = new TreeTableColumn[COL_COUNT + 1]; > final TreeTableColumn column = new TreeTableColumn<>("Column"); > column.setPrefWidth(150); > column.setCellValueFactory( > (final CellDataFeatures p) -> new ReadOnlyStringWrapper(p.getValue().getValue())); > cols[0] = column; > > for (int i = 0; i < COL_COUNT; i++) { > final TreeTableColumn col = new TreeTableColumn<>(Integer.toString(i)); > col.setPrefWidth(60); > col.setCellValueFactory(val -> new ReadOnlyStringWrapper(val.getValue().getValue()+":"+val.getTreeTableColumn().getText())); > cols[i + 1] = col; > } > treeTableView.getColumns().addAll(cols); > > final Scene scene = new Scene(treeTableView, 800, 500); > stage.setScene(scene); > stage.show(); > this.prepareTimeline(scene); > } > > private TreeItem addNodes(final TreeItem parent) { > > final TreeItem[] childNodes = new TreeItem[20]; > for (int i = 0; i < childNodes.length; i++) { > childNodes[i] = new TreeItem<>("N" + i); > } > final TreeItem root = new TreeItem<>("dir"); > root.setExpanded(true); > root.getChildren().addAll(childNodes); > parent.setExpanded(true); > parent.getChildren().add(root); > return root; > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > > } this indeed improves scrolling performance considerably (from extremely lagging to smooth following the mouse when dragging the thumb of the vertical scrollbar). As a side-effect, start-up time of TreeTableView seems to increase considerably (at least by a factor of 3 to 4, probably not linear in # of columns) - see f.i. the [example in JDK-8166956](https://bugs.openjdk.java.net/browse/JDK-8166956). Any idea why that might happen? ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From fastegal at openjdk.java.net Mon Apr 12 08:36:09 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 08:36:09 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction In-Reply-To: References: Message-ID: On Mon, 31 Aug 2020 19:16:31 GMT, yosbits wrote: > > > Since there was a problem that the cell was not updated when the window was maximized, I added a fix to TreeTableViewSkin.java. > that's just the added listener to hbar properties (same as in TableViewSkin), or anything else changed? > Added test code (BigTreeTableViewTest) for TreeTableView to the first post. > > @kleopatra > Does the test code I added (BigTreeTableViewTest.java) also have side effects? yeah, but why do you ask me - you could easily see for yourself :) And don't understand why you wrap the hierarchy setup in runlater (which smears a bit over the delay by filling the treeTable content at an unspecific time "later") > > > When the startup time is measured by eye, the impression changes depending on the individual difference. my eye is a precision instrument :) Seriously, who would do such a thingy? Obviously, it must be measured, for zeroth approximation doing so crudely by comparing currentMillis before/after showing is good enough to "see" the tendency. > The effect of runLater affects your experience. that's why you shouldn't do it when trying to gain insight into timing issues ;) > > However, I succeeded in further improving performance by eliminating another bottleneck in TreeTableView. Of course, it also includes improvements in startup time. cool :) ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From kcr at openjdk.java.net Mon Apr 12 08:36:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 08:36:11 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction In-Reply-To: References: Message-ID: On Thu, 3 Sep 2020 07:44:55 GMT, yosbits wrote: >> If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. >> >> `tableView.setFixedCellSize(height)` >> >> This proposal includes a fix because the current code does not correctly implement column virtualization. >> >> The improvement of this proposal can be seen in the following test program. >> >> ``` Java >> import java.util.Arrays; >> import java.util.Collections; >> >> import javafx.animation.AnimationTimer; >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.TableColumn; >> import javafx.scene.control.TableView; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.HBox; >> import javafx.stage.Stage; >> >> public class BigTableViewTest2 extends Application { >> private static final boolean USE_WIDTH_FIXED_SIZE = false; >> private static final boolean USE_HEIGHT_FIXED_SIZE = true; >> // private static final int COL_COUNT=30; >> // private static final int COL_COUNT=300; >> // private static final int COL_COUNT=600; >> private static final int COL_COUNT = 1000; >> private static final int ROW_COUNT = 1000; >> >> @Override >> public void start(final Stage primaryStage) throws Exception { >> final TableView tableView = new TableView<>(); >> >> // tableView.setTableMenuButtonVisible(true); //too heavy >> if (USE_HEIGHT_FIXED_SIZE) { >> tableView.setFixedCellSize(24); >> } >> >> final ObservableList> columns = tableView.getColumns(); >> for (int i = 0; i < COL_COUNT; i++) { >> final TableColumn column = new TableColumn<>("Col" + i); >> final int colIndex = i; >> column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); >> columns.add(column); >> if (USE_WIDTH_FIXED_SIZE) { >> column.setPrefWidth(60); >> column.setMaxWidth(60); >> column.setMinWidth(60); >> } >> } >> >> final Button load = new Button("load"); >> load.setOnAction(e -> { >> final ObservableList items = tableView.getItems(); >> items.clear(); >> for (int i = 0; i < ROW_COUNT; i++) { >> final String[] rec = new String[COL_COUNT]; >> for (int j = 0; j < rec.length; j++) { >> rec[j] = i + ":" + j; >> } >> items.add(rec); >> } >> }); >> >> final Button reverse = new Button("reverse columns"); >> reverse.setOnAction(e -> { >> final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); >> Collections.reverse(Arrays.asList(itemsArray)); >> tableView.getColumns().clear(); >> tableView.getColumns().addAll(Arrays.asList(itemsArray)); >> }); >> >> final Button hide = new Button("hide % 10"); >> hide.setOnAction(e -> { >> for (int i = 0, n = columns.size(); i < n; i++) { >> if (i % 10 == 0) { >> columns.get(i).setVisible(false); >> } >> } >> }); >> >> final BorderPane root = new BorderPane(tableView); >> root.setTop(new HBox(8, load, reverse, hide)); >> >> final Scene scene = new Scene(root, 800, 800); >> primaryStage.setScene(scene); >> primaryStage.show(); >> this.prepareTimeline(scene); >> } >> >> public static void main(final String[] args) { >> Application.launch(args); >> } >> >> private void prepareTimeline(final Scene scene) { >> new AnimationTimer() { >> @Override >> public void handle(final long now) { >> final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); >> ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); >> } >> }.start(); >> } >> } >> >> >> ``` Java >> import javafx.animation.AnimationTimer; >> import javafx.application.Application; >> import javafx.application.Platform; >> import javafx.beans.property.ReadOnlyStringWrapper; >> import javafx.scene.Scene; >> import javafx.scene.control.TreeItem; >> import javafx.scene.control.TreeTableColumn; >> import javafx.scene.control.TreeTableColumn.CellDataFeatures; >> import javafx.scene.control.TreeTableView; >> import javafx.stage.Stage; >> >> public class BigTreeTableViewTest extends Application { >> >> private static final boolean USE_HEIGHT_FIXED_SIZE = true; >> // private static final int COL_COUNT = 900; >> private static final int COL_COUNT = 800; >> // private static final int COL_COUNT = 600; >> // private static final int COL_COUNT = 500; >> // private static final int COL_COUNT = 400; >> // private static final int COL_COUNT = 300; >> // private static final int COL_COUNT = 200; >> // private static final int COL_COUNT = 100; >> >> public static void main(final String[] args) { >> Application.launch(args); >> } >> >> @Override >> public void start(final Stage stage) { >> final TreeItem root = new TreeItem<>("Root"); >> final TreeTableView treeTableView = new TreeTableView<>(root); >> if (USE_HEIGHT_FIXED_SIZE) { >> treeTableView.setFixedCellSize(24); >> } >> treeTableView.setPrefWidth(800); >> treeTableView.setPrefHeight(500); >> stage.setWidth(800); >> stage.setHeight(500); >> >> Platform.runLater(() -> { >> for (int i = 0; i < 100; i++) { >> TreeItem child = this.addNodes(root); >> child = this.addNodes(child); >> child = this.addNodes(child); >> child = this.addNodes(child); >> } >> }); >> >> final TreeTableColumn[] cols = new TreeTableColumn[COL_COUNT + 1]; >> final TreeTableColumn column = new TreeTableColumn<>("Column"); >> column.setPrefWidth(150); >> column.setCellValueFactory( >> (final CellDataFeatures p) -> new ReadOnlyStringWrapper(p.getValue().getValue())); >> cols[0] = column; >> >> for (int i = 0; i < COL_COUNT; i++) { >> final TreeTableColumn col = new TreeTableColumn<>(Integer.toString(i)); >> col.setPrefWidth(60); >> col.setCellValueFactory(val -> new ReadOnlyStringWrapper(val.getValue().getValue()+":"+val.getTreeTableColumn().getText())); >> cols[i + 1] = col; >> } >> treeTableView.getColumns().addAll(cols); >> >> final Scene scene = new Scene(treeTableView, 800, 500); >> stage.setScene(scene); >> stage.show(); >> this.prepareTimeline(scene); >> } >> >> private TreeItem addNodes(final TreeItem parent) { >> >> final TreeItem[] childNodes = new TreeItem[20]; >> for (int i = 0; i < childNodes.length; i++) { >> childNodes[i] = new TreeItem<>("N" + i); >> } >> final TreeItem root = new TreeItem<>("dir"); >> root.setExpanded(true); >> root.getChildren().addAll(childNodes); >> parent.setExpanded(true); >> parent.getChildren().add(root); >> return root; >> } >> >> private void prepareTimeline(final Scene scene) { >> new AnimationTimer() { >> @Override >> public void handle(final long now) { >> final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); >> ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); >> } >> }.start(); >> } >> >> } > > Column virtualization causes shortness of breath when scrolling a large stroke horizontally. > This does not happen when stroking on the scrollbar. Looks like a potential problem with VirtualFlow. > > If you are worried about shortness of breath, the following code will help reduce the problem. > > > ``` Java > ?private static final int OVERLAP_MARGIN = 500; > > private static boolean isOverlap(double start, double end, double start2, double end2){ > start = Math.max(start-OVERLAP_MARGIN, start2); > end = Math.min(end+OVERLAP_MARGIN, end2); > return (start<=end2 && end >= start2); > } @yososs Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have closed [JDK-8185886](https://bugs.openjdk.java.net/browse/JDK-8185886) as a duplicate, and suggested another existing JBS issue for this PR to use. Please change the title to: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From arapte at openjdk.java.net Mon Apr 12 08:40:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 12 Apr 2021 08:40:56 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: References: Message-ID: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> > The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. > Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). > > Fix is to remove the listener when MenuItem is removed. > Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. > Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. > With fix, the count is always same as number of MenuItems in scenegraph. > > Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. > This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. > Added a comment explaining this behavior in place of the TODO. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: remove indirect test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/429/files - new: https://git.openjdk.java.net/jfx/pull/429/files/91d43d8e..4a52e4ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=04-05 Stats: 58 lines in 3 files changed: 0 ins; 57 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/429.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/429/head:pull/429 PR: https://git.openjdk.java.net/jfx/pull/429 From arun.aj.joseph at oracle.com Mon Apr 12 08:47:12 2021 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Mon, 12 Apr 2021 08:47:12 +0000 Subject: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: References: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> <548B61D9-09D6-4871-8A90-771BE5FB8148@oracle.com> <6F577FB4-A5C6-485A-9BB1-066CB796658B@oracle.com> Message-ID: <14CDA006-A139-4B2E-9C53-EB58F2594FA2@oracle.com> I think the issue is caused by the JNI call in isMainThread() function in MainThreadJava.cpp and one solution would be to use the respective native calls for each platforms. I?ll create a PR with the above fix shortly after performing a couple of sanity checks. ? Arun Joseph On 12-Apr-2021, at 1:29 PM, Primo? Kokol > wrote: Did the thread dump created using the debug build helped with understanding of what the issue was? ? PrimosK On Tue, 23 Mar 2021 at 18:53, Arun Joseph > wrote: The thread dump doesn?t have enough details to locate where the problem occurs. Using a debug build with assertions disabled (as mentioned in the previous mail) may help in generating a thread dump for getting some more information. ? Arun Joseph On 18-Mar-2021, at 3:39 PM, Primo? Kokol > wrote: Thanks for pointing us in the right direction. I wasn't aware that jfxwebkit.pdb will be generated also in the case of a production build. So after generating a production build we were able to produce a thread dump (using jfxwebkit.pdb symbols) at the time when the application freezes. The complete bug report including thread dump is there: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788 Could you please just scan through it and let us know whether there is enough information to pursue this further or whether any additional information is needed? ? PrimosK On Tue, 16 Mar 2021 at 13:30, Arun Joseph > wrote: The app is now crashing at InternalFunction which calls jsDynamicCast in JSCast.h, which lead to the initial crash. This assert failure occurs because the type value is ObjectType instead of InternalFunctionType or NullSetterFunctionType. I need to check why this is happens. NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. So, for creating a build without asserts, you can either use the release build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a minimal debug build. ? Arun Joseph On 15-Mar-2021, at 6:08 PM, Primo? Kokol > wrote: I've tried to remove this particular assert statement at "JSCast.h:143": // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, Target::info())); ... and now application crashes at different assert statement: > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 00000025dabfaf00() Unknown Non-user code 00000025dabfafc0() Unknown Non-user code 00000164ca445b4b() Unknown Non-user code cccccccccccccccc() Unknown Non-user code 00000164ca445b46() Unknown Non-user code Is there any way we could turn off assertions in general when producing debug build? On Sat, 13 Mar 2021 at 05:41, Arun Joseph > wrote: I?m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. ? Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primo? Kokol > wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we don't know where/why exactly the > application freezes. > > We were hoping that we will be able to identify it using the native debug > build (& attached debugged) but it is now unfortunately crashing with the > above error. > > Side note: > Should I contact Arun directly or is he seeing these messages? > > -- PrimosK > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth > > wrote: > >> Arun should be able to help you with the crash you are seeing in debug >> mode. >> >> Regarding the hang, do you have a test case that will reproduce it? A >> few different developers have reported similar hangs. We ended up >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> are) unable to reproduce the hang. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> On 3/12/2021 1:06 AM, Primo? Kokol wrote: >>> Hi everyone, >>> >>> I would need some help related to OpenJFX build. >>> >>> I was able to successfully prepare a build following this procedure (from >>> pull/417 request): >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >>> >>> We wanted to use it in our existing application (Java 11.0.10) to debug >> an >>> issue where the application would hang/freeze for no obvious reason >> because >>> of WebKit. >>> >>> In order to use this build we've manually overridden javafx-*.jar files >> in >>> our application with the ones from the above build. >>> We've also placed all produced DLL files in our application's "bin" >> folder >>> so they are properly picked up (I've verified and I can confirm that >>> jfxwebkit.dll produced by our debug build is loaded). >>> >>> After using this native debug build, the application will crash instead >>> with: >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> It looks like it happens when JS code calls Java method. >>> >>> There is the call stack at the time when exception happens: >>> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> const >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ >>> Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::jsDynamicCast>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line >>> 182 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >> const >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >>> nameAdditionMode) Line 49 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >>> WTF::String & ident) Line 58 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, >>> const WTF::String & name) Line 231 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >>> globalObject, const WTF::String & name, JSC::Bindings::Method * method) >>> Line 212 C++ Symbols loaded. >>> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >> loaded. >>> >>> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) >>> Line 124 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols >> loaded. >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ >>> Symbols loaded. >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >>> JSC::JSValue baseValue, const JSC::Identifier & ident, >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >> const >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded. >>> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. >>> 000000c7ef8fae90() Unknown Non-user code >>> 000000c7ef8faf50() Unknown Non-user code >>> 0000028d52eeedbb() Unknown Non-user code >>> cccccccccccccccc() Unknown Non-user code >>> 0000028d52eeedb6() Unknown Non-user code >>> >>> ... and partial output from the output console: >>> >>> .... >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as >> fi(x)ed, >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, >> (t)transformed >>> ancestor >>> Dirty (z)-lists, Dirty (n)ormal flow lists >>> Traversal needs: requirements (t)raversal on descendants, (b)acking or >>> hierarchy traversal on descendants, (r)equirements traversal on all >>> descendants, requirements traversal on all (s)ubsequent layers, >> (h)ierarchy >>> traversal on all descendants, update of paint (o)rder children >>> Update needs: post-(l)ayout requirements, (g)eometry, (k)ids geometry, >>> (c)onfig, layer conne(x)ion, (s)crolling tree >>> Scrolling scope: box contents >>> >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 >>> height=650 RenderView 0x28d4d4d1cd0 >>> S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) width= >> no >>> compositing work to do >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks >>> >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 >> header >>> height 0 footer height 0 fixed behavior 0 >>> layoutViewport: (0,0) width=460 height=650 >>> visualViewport: (0,0) width=460 height=650 (is override 0) >>> stable origins: min: (0.00,0.00) max: (0.00,0.00) >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time >> 24.89s >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) >>> >> C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> Note that this crash isn't happening with official JavaFX 15, 16, and >>> 17-ea+2 builds (that are at the time of writing this available on the >>> maven), but unfortunately we can't use these for debugging purposes. >>> >>> Does that indicate any issues with the native debug build or is this some >>> regression that was introduced in the current `master` branch recently >>> (after 17-ea+2)? >>> >>> Thanks for any helpful hints/advice in advance! >>> >>> Best regards, >>> PrimosK >> >> From jvos at openjdk.java.net Mon Apr 12 09:01:49 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 12 Apr 2021 09:01:49 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. In-Reply-To: References: Message-ID: <6cL1yx_-q7NDfDBZ9IjPKhEP5VclL5xPU0WOWlWal7k=.5670b7de-dc1f-40a6-8e9b-0e8c010cdf2c@github.com> On Fri, 9 Apr 2021 22:27:47 GMT, Kevin Rushforth wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2883: > >> 2881: double newPosition = Math.min(1.0d, absoluteOffset/(estimatedSize - viewportLength)); >> 2882: // estimatedSize changes may result in opposite effect on position >> 2883: // in that case, modify current position 1% in the requested direction > > Have you done testing to show that a 1% adjustment is a good heuristic? This is just a visual aid, so it's hard to test. I tried this with both small and large lists. We really don't want to jump in the wrong direction, but on the other hand, moving too much in the "correct" dimension would increase the discrepancy between where we really are in the list versus where we expected to be, given the information we had before this modification. If we increase this to 10%, the mismatch will be even bigger, and might be visually noticed. The 1% is a compromis between the UI going crazy (backward) and the mathematical correctness (which would go backward). I initially had this to 0% but then there would be no visual change, while we want to give the user some visual confirmation about the direction she is moving. With both small/large lists, this 1% occurs "natural" to me. The lower, the better, but if we change less than 1 pixel, there won't be a visual effect. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Mon Apr 12 09:20:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 12 Apr 2021 09:20:42 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 22:29:39 GMT, Kevin Rushforth wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2892: > >> 2890: >> 2891: // once at 95% of the total estimated size, we want a correct size, not >> 2892: // an estimated size anymore. > > I presume that this is a balance between performance and accuracy? It seems to work well. Have you tried other values? > > Do you also need to check for `newPosition < 0.05` if you are scrolling backwards? For smaller lists, it makes sense to eagerly calculate the remaining values. However, since we always add the calculations for a next cell on every adjustment, we will have all values before we are at 95%. In this case, the 95% is just a safeguard in case the list has very large cells in the beginning, and very small cells near the end. The sooner we know this, the better, but not at a price of drastically dropping performance. For longer lists, decreasing the value will lead to a major performance issue. There might be specific combinations in cell count and sizes that would lead to less ideal results. Lowering the value would lead to a lower performance, so I suggest not doing that. In case of these specific combinations that lead to issues, we can create a new issue and have the `95` being more dynamically calculated (based on total cell count and variations between the sizes of the already known items). A check when moving backwards should not be required, as we should have all the information about the cells before the current one already -- so there can be no surprises about sudden jumps. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Mon Apr 12 09:29:40 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 12 Apr 2021 09:29:40 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 22:32:28 GMT, Kevin Rushforth wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2902: > >> 2900: >> 2901: // if we are at or beyond the edge, correct the absolteOffset >> 2902: if (newPosition >= 1.d) { > > Do you need to also check for `newPosition < 0` if you are scrolling backwards? That can not happen. The only reason we can have `newPosition > 1.d` is when the correction applied to scrolling in the wrong direction would bring the position beyond 1: `newPosition = getPosition()*1.01` The inverse check for this might reduce the position (by `.99`) but it will never render it negative. Note that there is a documentation placeholder in case we want to allow for gravity-alike scrolling ``` // When we're at the top already, we can't move back further, unless we // want to allow for gravity-alike effects. In that case, we might want to use negative values for the position, but that seems a follow-up issue to me (if we want to do that at all, that is) ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Mon Apr 12 09:41:03 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 12 Apr 2021 09:41:03 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: > This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) > The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. > Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. > This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Process reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/398/files - new: https://git.openjdk.java.net/jfx/pull/398/files/248d0f0e..dd792176 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=398&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=398&range=00-01 Stats: 21 lines in 2 files changed: 0 ins; 1 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/398.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/398/head:pull/398 PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Mon Apr 12 09:41:03 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 12 Apr 2021 09:41:03 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:21:28 GMT, Johan Vos wrote: > This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) > The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. > Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. > This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. Thanks for the review. I answered the questions, and corrected the styling errors. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Mon Apr 12 09:41:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 12 Apr 2021 09:41:08 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: <2vjJw-DzXV0z8IU8KPDGceq-ZtrzrhqF2D7aeNDFYCw=.320bd4e2-4bbc-4ea0-84fc-d8b99e3a5166@github.com> On Fri, 9 Apr 2021 22:12:54 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Process reviewer comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 254: > >> 252: * The following relation should always be true: >> 253: * 0 <= absoluteOffset <= (estimatedSize - viewportLength) >> 254: * Based on this relation, he position p is defined as > > Typo: `the` position p... changed > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1034: > >> 1032: */ >> 1033: void adjustAbsoluteOffset() { >> 1034: absoluteOffset = (estimatedSize - viewportLength)* getPosition(); > > Minor: missing space before the `*` changed > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2901: > >> 2899: } >> 2900: >> 2901: // if we are at or beyond the edge, correct the absolteOffset > > Typo: should be `absoluteOffset` changed > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2914: > >> 2912: double total = 0; >> 2913: int currentCellCount = getCellCount(); >> 2914: double estSize = estimatedSize/currentCellCount; > > MInor: missing spaces before and after `/` changed > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2972: > >> 2970: // Make sure we have enough space in the cache to store this index >> 2971: while (idx >= itemSizeCache.size()) { >> 2972: itemSizeCache.add(itemSizeCache.size(), null); > > Can this be simplified to `itemSizeCache.add(null);`? That won't add enough elements. For example, in case idx = 10, and the itemSizeCache has 5 elements, we need to add 5 empty elements to the cache, as they might get queried/pushed, e.g. we might do `itemSizeCache.set(7, 123.45);` > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1229: > >> 1227: } >> 1228: >> 1229: private ArrayLinkedListShim circlelist= new ArrayLinkedListShim(); > > Minor: missing space before `=` changed > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1233: > >> 1231: private VirtualFlowShim createCircleFlow() { >> 1232: // The second VirtualFlow we are going to test, with 7 cells. Each cell >> 1233: // contains a Circle whith a radius that varies between cells. > > Minor: indentation changed > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1305: > >> 1303: double s1 = s0; >> 1304: double position = vf.getPosition(); >> 1305: double newPosition =0d; > > Minor: missing space after `=` changed > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1336: > >> 1334: static ArrayList circleList = new ArrayList<>(); >> 1335: static { >> 1336: circleList.add(new Circle(10)); > > Minor: Could use `List.of`? (just a suggestion) changed > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1350: > >> 1348: public GraphicalCellStub() { init(); } >> 1349: >> 1350: private void init( ) { > > Minor: can remove extra space between `(` and `)` changed > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1381: > >> 1379: double answer = super.computePrefHeight(width); >> 1380: if ((idx > -1) && (idx < circleList.size())){ >> 1381: answer = 2* circleList.get(idx).getRadius()+ 6; > > Minor: spacing is a little inconsistent for these two lines. changed ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From fastegal at openjdk.java.net Mon Apr 12 10:39:07 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 10:39:07 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v8] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: replaced param name in changeListener methods ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/0736fe52..c19c8f92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=06-07 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From arapte at openjdk.java.net Mon Apr 12 11:09:41 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 12 Apr 2021 11:09:41 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v5] In-Reply-To: <4_t9ECFmYFsOLNS61DySgHNX6qk16ayzUvj65fIDZ1g=.786db064-b10d-4844-9f86-9bcf08e798f0@github.com> References: <4_t9ECFmYFsOLNS61DySgHNX6qk16ayzUvj65fIDZ1g=.786db064-b10d-4844-9f86-9bcf08e798f0@github.com> Message-ID: On Sat, 10 Apr 2021 14:58:14 GMT, Kevin Rushforth wrote: > I'd recommend to get rid of the indirect way of testing I have removed the indirect way, please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From fastegal at openjdk.java.net Mon Apr 12 12:01:38 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 12:01:38 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v7] In-Reply-To: References: <9K3FbeFmuWLvkCDrbudGSj7CO6GzTIHCiT9CkQeft3U=.ff87ac37-1aae-427c-ba03-cff4cf3e6865@github.com> Message-ID: On Wed, 7 Apr 2021 13:11:52 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> updated doc of list/Change methods that of invalidation methods > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 221: > >> 219: * may be {@code null} >> 220: */ >> 221: protected final void registerChangeListener(ObservableValue property, Consumer> operation) { > > Maybe instead of `property` use `observable` like with the invalidation methods to not confuse it with the `Property` interface. changed as suggested - hope everybody is happy now :) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Mon Apr 12 12:05:46 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 12:05:46 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v8] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 10:39:07 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > replaced param name in changeListener methods created a csr draft [JDK-8265063](https://bugs.openjdk.java.net/browse/JDK-8265063) - waiting for all monsters in hell breaking out and heavens falling down ;-) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Mon Apr 12 13:07:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 13:07:39 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: <2vjJw-DzXV0z8IU8KPDGceq-ZtrzrhqF2D7aeNDFYCw=.320bd4e2-4bbc-4ea0-84fc-d8b99e3a5166@github.com> References: <2vjJw-DzXV0z8IU8KPDGceq-ZtrzrhqF2D7aeNDFYCw=.320bd4e2-4bbc-4ea0-84fc-d8b99e3a5166@github.com> Message-ID: On Mon, 12 Apr 2021 09:32:27 GMT, Johan Vos wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2972: >> >>> 2970: // Make sure we have enough space in the cache to store this index >>> 2971: while (idx >= itemSizeCache.size()) { >>> 2972: itemSizeCache.add(itemSizeCache.size(), null); >> >> Can this be simplified to `itemSizeCache.add(null);`? > > That won't add enough elements. For example, in case idx = 10, and the itemSizeCache has 5 elements, we need to add 5 empty elements to the cache, as they might get queried/pushed, e.g. we might do > `itemSizeCache.set(7, 123.45);` Sure, that's why you need the `while` loop. What I meant is that the following two calls are equivalent for any list: list.add(list.size(), null); and list.add(null); ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From kcr at openjdk.java.net Mon Apr 12 13:23:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 13:23:43 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 09:41:03 GMT, Johan Vos wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments Thanks for the explanations about the algorithm. I have no more questions on the logic. I think Ajit will review this later this week. Btw, I did another pass over the code and noted a few more formatting inconsistencies (missing spaces). modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1045: > 1043: setPosition(0.); > 1044: } else { > 1045: setPosition(absoluteOffset/(estimatedSize - viewportLength)); Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1591: > 1589: adjustPositionToIndex(index); > 1590: // double offset = - computeOffsetForCell(index); > 1591: // adjustByPixelAmount(offset); I forgot to ask about this last time. Is there a reason to leave the former, now commented-out, code here, as opposed to just removing it? modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1903: > 1901: void setViewportLength(double value) { > 1902: this.viewportLength = value; > 1903: this.absoluteOffset = getPosition() * (estimatedSize -viewportLength); Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2564: > 2562: lengthBar.setVisibleAmount(flowLength / sumCellLength); > 2563: } else { > 2564: lengthBar.setVisibleAmount(viewportLength/estimatedSize); Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2834: > 2832: double p = com.sun.javafx.util.Utils.clamp(0, position, 1); > 2833: double bound = 0d; > 2834: double estSize = estimatedSize/getCellCount(); Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2839: > 2837: double h = getCellSize(i); > 2838: if (h < 0) h = estSize; > 2839: if (bound +h > absoluteOffset) { Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2840: > 2838: if (h < 0) h = estSize; > 2839: if (bound +h > absoluteOffset) { > 2840: return absoluteOffset-bound; Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2854: > 2852: double targetOffset = 0; > 2853: double estSize = estimatedSize/cellCount; > 2854: for (int i = 0; i < index;i++) { Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2881: > 2879: double origAbsoluteOffset = this.absoluteOffset; > 2880: this.absoluteOffset = Math.max(0.d, this.absoluteOffset + numPixels); > 2881: double newPosition = Math.min(1.0d, absoluteOffset/(estimatedSize - viewportLength)); Minor: spacing modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3035: > 3033: } > 3034: } > 3035: this.estimatedSize = cnt == 0 ? 1d: tot * itemCount/cnt; Minor: spacing ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From kcr at openjdk.java.net Mon Apr 12 13:26:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 13:26:35 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v8] In-Reply-To: References: Message-ID: <5SeKot8_h4ocv_mAr6QsVk66zpyJjmqVmbJO19Ur170=.e2a7a29d-bf4b-40a7-8d47-499ff4993c29@github.com> On Mon, 12 Apr 2021 12:02:20 GMT, Jeanette Winzenburg wrote: > created a csr draft [JDK-8265063](https://bugs.openjdk.java.net/browse/JDK-8265063) - waiting for all monsters in hell breaking out and heavens falling down ;-) The Draft CSR looks good, and should keep the monsters contained. ?? Go ahead and move it to Proposed. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Mon Apr 12 13:29:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 13:29:37 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> References: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> Message-ID: On Mon, 12 Apr 2021 08:40:56 GMT, Ambarish Rapte wrote: >> The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. >> Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). >> >> Fix is to remove the listener when MenuItem is removed. >> Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. >> Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. >> With fix, the count is always same as number of MenuItems in scenegraph. >> >> Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. >> This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. >> Added a comment explaining this behavior in place of the TODO. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > remove indirect test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From nlisker at openjdk.java.net Mon Apr 12 14:03:35 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 12 Apr 2021 14:03:35 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v8] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 10:39:07 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > replaced param name in changeListener methods I looked at all the new public docs and they look good (I left one minor comment). I didn't review anything else. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 286: > 284: * Registers an operation to perform when the given {@code observableList} sends a list change event. > 285: * Does nothing if either {@code observableList} or {@code operation} are {@code null}. > 286: * If multiple operations are registered on the same observableList, they will be performed in the For "observableList" I would use "observable list" similar to what was done with the other methods. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From arapte at openjdk.java.net Mon Apr 12 14:33:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 12 Apr 2021 14:33:08 GMT Subject: RFR: [WIP] 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error [v2] In-Reply-To: References: Message-ID: > Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. > > Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. > Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. > - RegionBackgroundImageUITest.unalignedImage > - RegionBackgroundFillUITest.testScenario2 > - RegionBackgroundFillUITest.testScenario3 > > commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. > > One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. > It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) > > This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. > Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). 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 three additional commits since the last revision: - Merge - fix for tests failing on Mac - ideal fix, but causes 3 test fail ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/344/files - new: https://git.openjdk.java.net/jfx/pull/344/files/91791f3a..f270a0bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=344&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=344&range=00-01 Stats: 376323 lines in 7058 files changed: 185953 ins; 125920 del; 64450 mod Patch: https://git.openjdk.java.net/jfx/pull/344.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/344/head:pull/344 PR: https://git.openjdk.java.net/jfx/pull/344 From fastegal at openjdk.java.net Mon Apr 12 14:45:58 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 14:45:58 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v9] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: changed description as suggested in review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/c19c8f92..7e31073a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Mon Apr 12 14:45:59 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 14:45:59 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v8] In-Reply-To: References: Message-ID: <3M1dnAQpnlQcZdRV0Cs9jHzubg4vD2GxMcqkuwX-9tU=.c8288ea7-a4b6-494f-95f7-be8ed00f51dc@github.com> On Mon, 12 Apr 2021 13:59:13 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> replaced param name in changeListener methods > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 286: > >> 284: * Registers an operation to perform when the given {@code observableList} sends a list change event. >> 285: * Does nothing if either {@code observableList} or {@code operation} are {@code null}. >> 286: * If multiple operations are registered on the same observableList, they will be performed in the > > For "observableList" I would use "observable list" similar to what was done with the other methods. changed description as suggested, thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Mon Apr 12 14:49:36 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 12 Apr 2021 14:49:36 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v8] In-Reply-To: <5SeKot8_h4ocv_mAr6QsVk66zpyJjmqVmbJO19Ur170=.e2a7a29d-bf4b-40a7-8d47-499ff4993c29@github.com> References: <5SeKot8_h4ocv_mAr6QsVk66zpyJjmqVmbJO19Ur170=.e2a7a29d-bf4b-40a7-8d47-499ff4993c29@github.com> Message-ID: On Mon, 12 Apr 2021 13:24:18 GMT, Kevin Rushforth wrote: > > The Draft CSR looks good, and should keep the monsters contained. ?? Go ahead and move it to Proposed. thanks, done :) Also updated to the most recent state (including Nir's suggestion). ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Mon Apr 12 16:06:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 16:06:48 GMT Subject: Integrated: 8264928: Update to Xcode 12.4 In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:21:43 GMT, Kevin Rushforth wrote: > This updates the compiler used to build JavaFX on macOS to Xcode 12.4 (which includes the MacOSX11.1 sdk), which matches the compiler that will be used to build JDK 17, once openjdk/jdk#3388 is integrated. > > As noted in the bug report, Xcode 12.4 needs macOS 10.15.4 (Catalina) or later to build. The produced artifacts will be able to run on earlier versions of macOS (for x86_64 systems anyway). This pull request has now been integrated. Changeset: c8384a1b Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/c8384a1b Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8264928: Update to Xcode 12.4 Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/460 From github.com+2179736+matthiasblaesing at openjdk.java.net Mon Apr 12 16:13:37 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Mon, 12 Apr 2021 16:13:37 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> Message-ID: On Mon, 12 Apr 2021 07:50:39 GMT, Johan Vos wrote: > I understand the crash would be at a different point, but it would still be a crash, I think? That is, if the method handlers are correctly registered via the OnLoad function, and later a new native thread tries to access a function that is not yet attached, that will still crash, I believe. (at least, the GetEnv will return NULL and that result is used later). > So while the 2 issues are not related, I think there are really 2 issues. The question is: Is there a second issue? If all threads used in webkit are attached to the VM, any thread can directly fetch an `JNIEnv` instance from the `vm` interface and invoke methods. In this case the thread is correctly attached. The problem here is/was, that the code path is not regularly exercised. My feeling is, that it is common, that the JavaFX modules are loaeded from the module path and loading JavaFX from a module layer / classpath (yes I know that this is not supported) is mostly untested. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+3975960+neilcsmith-net at openjdk.java.net Mon Apr 12 16:13:37 2021 From: github.com+3975960+neilcsmith-net at openjdk.java.net (Neil C Smith) Date: Mon, 12 Apr 2021 16:13:37 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> Message-ID: On Mon, 12 Apr 2021 07:50:39 GMT, Johan Vos wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert changes to thread attachment introduced in second commit >> >> Thread attachment is handled in >> jfx/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp >> and thus does not need to be modified. > > I understand the crash would be at a different point, but it would still be a crash, I think? That is, if the method handlers are correctly registered via the OnLoad function, and later a new native thread tries to access a function that is not yet attached, that will still crash, I believe. (at least, the GetEnv will return NULL and that result is used later). > So while the 2 issues are not related, I think there are really 2 issues. @johanvos a quick comment as Matthias linked me on this. The reason I suggested re-looking is that there is no evidence of thread attachment being behind this problem in the discussion that happened on the NetBeans list, in fact this problem couldn't happen if the thread was unattached. It depends if that discussion was the only basis for assuming an issue with thread attachment exists? ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Mon Apr 12 16:20:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 16:20:46 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> Message-ID: On Mon, 12 Apr 2021 16:09:08 GMT, Matthias Bl?sing wrote: > The question is: Is there a second issue? If we don't have an example where a thread that isn't attached to the JVM already calls into these APIs, then it seems like the second issue is just hypothetical. In any case, it seems best to separate it out. @johanvos Do you have a case where it is actually failing as a result of a thread not being attached? ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+12087024+beldenfox at openjdk.java.net Mon Apr 12 16:38:35 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Mon, 12 Apr 2021 16:38:35 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace error. The question was raised earlier why we can?t just generate the key code based on the typed character. That?s basically the Swing approach and I could evaluate what it would mean to adopt that algorithm in JavaFX. I know it produces some strange results under the hood but have reached the conclusion, based on the bugs I?ve seen, that for keys that generate printable characters we have a lot of leeway as long as Cmd+A through Cmd+Z work. I haven?t seen any documentation on how a developer should set up an accelerator associated with a digit e.g. Cmd+2. Should they use a KeyCharacterCombination, a KeyCodeCombination, or are just not do it? Are there written guidelines on any of this? ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From jgneff at openjdk.java.net Mon Apr 12 18:19:27 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 12 Apr 2021 18:19:27 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] In-Reply-To: References: Message-ID: On Sun, 4 Apr 2021 16:36:27 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 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. Thank you, Alexander and Arun, for looking over the Makefiles and verifying the builds. > I'd like to take a week to get feedback and mull over the code changes ... After realizing how little I knew about Gradle, I did some research last week and took four courses on Groovy, Gradle, and the Gradle Java Plugin. Although I now see a couple things I could change, I'm still happy with the commits as they are. I welcome any comments or questions. Once #422 and this pull request are integrated, I can follow up with changes to make the `all` task reproducible (fixing `javafx-sdk-17.zip`) and to remove the build path from the `.bss` files (fix number 4 in the first comment). ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Mon Apr 12 20:59:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 20:59:13 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 Message-ID: As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). This PR will do the same for JavaFX. To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. ------------- Commit messages: - 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 Changes: https://git.openjdk.java.net/jfx/pull/462/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=462&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265031 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/462.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/462/head:pull/462 PR: https://git.openjdk.java.net/jfx/pull/462 From kevin.rushforth at oracle.com Mon Apr 12 21:11:35 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Apr 2021 14:11:35 -0700 Subject: Bumping the minimum version of macOS on which JavaFX will run to 10.12 Message-ID: <796d59c7-0bb9-8f7d-ed0e-946fa679a0ee@oracle.com> The proposed fix for JDK-8265031 [1], which is under review as PR #462 [2], will bump the minimum version of macOS on which JavaFX will run to 10.12 (for x86_64 systems) to match the minimum version that the JDK will run on. After this fix is integrated, builds of JavaFX will no longer run on macOS 10.10 or 10.11. I don't imagine anyone is still running anything that old, but wanted to make sure the impact of this was understood. This also bumps the minimum version for aarch64 systems to 11.0, which also matches the JDK. Since Apple only added support for aarch64 in macOS 11, this will have no impact. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8265031 [2] https://git.openjdk.java.net/jfx/pull/462 From jgneff at openjdk.java.net Mon Apr 12 21:53:00 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 12 Apr 2021 21:53:00 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v2] In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: On Wed, 24 Mar 2021 19:45:55 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Add a README file and update 'UPDATING-lucene.txt' Thanks for the list, Kevin. Pull request #450 was closed in favor of #456, which was integrated. I'll build with the media and WebKit libraries so Gradle can add their dependencies, and I'll update this pull request with the new verification file. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From kcr at openjdk.java.net Mon Apr 12 22:11:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 12 Apr 2021 22:11:58 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v2] In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: On Wed, 24 Mar 2021 19:45:55 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Add a README file and update 'UPDATING-lucene.txt' Yes, there are two updates: 1. As you noted, PR #450 was withdrawn in favor of PR #456, and the latter is now integrated. As a result, there will be no `icudt-64l.zip` file, but you will see a new download artifact, `icu4c-68.2-data-bin-l.zip` once you merge the lastest master into your branch and do a build with WebKit. 2. With the integration of PR #460 this morning, there is a new devkit for Xcode 12.4. Here is the updated list of internal artifacts: cmake-3.13.3-Darwin-x86_64.tar.gz cmake-3.13.3-Linux-x86_64.tar.gz cmake-3.13.3-win32-x86.zip devkit-linux_x64-gcc10.2.0-OL6.4+1.0.tar.gz devkit-macosx_x64-Xcode11.3.1-MacOSX10.15+1.0.tar.gz devkit-macosx-Xcode12.4+1.0.tar.gz devkit-windows_x64-VS2019-16.7.2+1.0.tar.gz jfx-devkit-gcc-patch+1.1.tar.gz ninja-win.zip Since this should be settled down for now, I'll send you the checksums some time later this week (presuming you have added the media and WebKit artifacts by then). ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From jvos at openjdk.java.net Tue Apr 13 06:48:57 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 13 Apr 2021 06:48:57 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 20:30:55 GMT, Kevin Rushforth wrote: > As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. > > The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). > > This PR will do the same for JavaFX. > > To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/462 From alexsch at openjdk.java.net Tue Apr 13 08:41:12 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 13 Apr 2021 08:41:12 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: References: Message-ID: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> > This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). > > Main changes: > - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition > - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 > - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) > - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. > > I also looked which changes are required to build media module for Windows aarch64. > The main changes could be using: > - `ARCH=arm64` for building media libs in build.gradle file > - `-MACHINE:arm64` LDFLAGS in media make files > - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file > - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port > > In this way the media is build but it is crashed when I run a JavaFX sample with video. > Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Remove mt.exe from win.gradle build script ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/439/files - new: https://git.openjdk.java.net/jfx/pull/439/files/10b3671b..38184783 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=439&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=439&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/439.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/439/head:pull/439 PR: https://git.openjdk.java.net/jfx/pull/439 From alexsch at openjdk.java.net Tue Apr 13 08:45:59 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 13 Apr 2021 08:45:59 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Tue, 13 Apr 2021 08:41:12 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Remove mt.exe from win.gradle build script I removed `ext.MC = cygpath("$winSdkBinDir/mt.exe")` line from `win.gradle` because it was used for building jdk.packager module [openjfx/11-dev/rt/build.gradle](https://hg.openjdk.java.net/openjfx/11-dev/rt/file/81e1980f9d54/build.gradle#l2916) and now jdk.packager is removed from jfx. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From kcr at openjdk.java.net Tue Apr 13 13:21:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 13 Apr 2021 13:21:05 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Tue, 13 Apr 2021 08:41:12 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Remove mt.exe from win.gradle build script I think this is is fine. I did a local build to ensure that x64 builds are not impacted. I left a question and a comment inline. buildSrc/win.gradle line 468: > 466: case "aarch64" : return "arm64" > 467: case "amd64" : return "x64" > 468: default: return arch This looks fine. I recommend to sanity test this on a 32-bit build to ensure that `os.arch` is `x86` (I don't have the ability to do that). buildSrc/win.gradle line 474: > 472: boolean isExecutable(String file) { > 473: try { > 474: Runtime.runtime.exec(file) Is there a way other than to execute the command in question -- `rc` or `fxc` -- to see whether it will execute? I note that `fxc` will print a warning message when run with no arguments (but even with `gradle --info` it isn't printed to the console). ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From jgneff at openjdk.java.net Wed Apr 14 04:32:29 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 04:32:29 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v3] In-Reply-To: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: <-zblqH3jywX3eAs1LEDakYqCn_9_aKYjpHwxsKDUGxk=.f427216c-509d-478b-bf00-341f8c0207df@github.com> > This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: > > * [JDK-8262236][1]: Configure Gradle checksum verification > * [JDK-8263204][2]: Add Gradle Wrapper Validation Action > * [JDK-8264010][3]: Add Gradle dependency verification > > "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: > > * [C?dric Champeau at Devoxx][6] in November 2019 > * [Louis Jacomet at Jfokus][7] in February 2020 > > "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 > [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf > [6]: https://youtu.be/GWGNp3a3hpk > [7]: https://youtu.be/bwiafNatsf0 John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Add dependencies for media and WebKit libraries - Merge branch 'master' into dependency-verification - Add a README file and update 'UPDATING-lucene.txt' - 8264010: Add Gradle dependency verification ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/437/files - new: https://git.openjdk.java.net/jfx/pull/437/files/c7ac7f62..7609914a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=437&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=437&range=01-02 Stats: 87251 lines in 1199 files changed: 49762 ins; 13569 del; 23920 mod Patch: https://git.openjdk.java.net/jfx/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/437/head:pull/437 PR: https://git.openjdk.java.net/jfx/pull/437 From jgneff at openjdk.java.net Wed Apr 14 05:06:02 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 05:06:02 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v3] In-Reply-To: <-zblqH3jywX3eAs1LEDakYqCn_9_aKYjpHwxsKDUGxk=.f427216c-509d-478b-bf00-341f8c0207df@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <-zblqH3jywX3eAs1LEDakYqCn_9_aKYjpHwxsKDUGxk=.f427216c-509d-478b-bf00-341f8c0207df@github.com> Message-ID: On Wed, 14 Apr 2021 04:32:29 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Add dependencies for media and WebKit libraries > - Merge branch 'master' into dependency-verification > - Add a README file and update 'UPDATING-lucene.txt' > - 8264010: Add Gradle dependency verification There's an odd thing happening with some of the artifact names in the dependency file. For example: Gradle creates the artifact name from the component name and version, separated by a hyphen. Because the version attribute is empty, we get an artifact name ending in `-.tar.gz`. It should be `ffmpeg-3.3.3.tar.gz`, but Gradle sees `-3.3.3` as part of the name. This particular name originates from: dependencies { if (IS_BUILD_LIBAV_STUBS) { media name: "libav-9.14", ext: "tar.gz" media name: "libav-11.4", ext: "tar.gz" media name: "libav-12.1", ext: "tar.gz" media name: "ffmpeg-3.3.3", ext: "tar.gz" media name: "ffmpeg-4.0.2", ext: "tar.gz" } compile project(":base") compile project(":graphics") } Other places in the build file seem to depend on having the version as part of the name string, and my initial attempt to separate the two failed. The build works with the names as they are, and these are in fact the names of the files in the Gradle cache. Some day, though, we might want to have better component elements in the dependency file, seeing as it functions also like a software bill of materials. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From fkirmaier at openjdk.java.net Wed Apr 14 11:45:17 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 14 Apr 2021 11:45:17 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v3] In-Reply-To: References: Message-ID: > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264127: Fixed some more testcases ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/e2f12cb0..2e785a1b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=01-02 Stats: 28 lines in 2 files changed: 22 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Wed Apr 14 11:49:00 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 14 Apr 2021 11:49:00 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v3] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 11:45:17 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > Fixed some more testcases I've updated the Fix and the tests. It contains now the 3 cases you've mentioned and all are passing. The test from 0 works with setting the initial focus. The test from -1 works, after updating how the fix works. Now the index is updated, after updating the item. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Wed Apr 14 11:58:14 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 14 Apr 2021 11:58:14 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v4] In-Reply-To: References: Message-ID: > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264127: Added checks, whether the correction ammount of editStart/cancel events are triggered ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/2e785a1b..2cc8c61c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=02-03 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Wed Apr 14 11:58:15 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 14 Apr 2021 11:58:15 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v3] In-Reply-To: References: Message-ID: <2PasoSAq-SQpieHytA853Y1aHWwiptlrQ9k36gTW4UM=.b1cad6d0-5989-4941-8da3-5bff20829e72@github.com> On Wed, 14 Apr 2021 11:45:17 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > Fixed some more testcases I've now expanded the tests, to check for the correct number of events, similar to your case B - just with reverted conditions, like you've suggested. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From arapte at openjdk.java.net Wed Apr 14 12:21:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 14 Apr 2021 12:21:10 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 20:30:55 GMT, Kevin Rushforth wrote: > As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. > > The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). > > This PR will do the same for JavaFX. > > To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. buildSrc/mac.gradle line 59: > 57: // Note that this is not necessarily the same as the preferred SDK version > 58: def isAarch64 = TARGET_ARCH == "aarch64" || TARGET_ARCH == "arm64"; > 59: def macOSMinVersion = (TARGET_ARCH == "aarch64" || TARGET_ARCH == "arm64") ? "11.0" : "10.12"; I guess `isAarch64` was defined to use on line 59 in ternary operator. ------------- PR: https://git.openjdk.java.net/jfx/pull/462 From github.com+6702882+dannygonzalez at openjdk.java.net Wed Apr 14 12:33:23 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Wed, 14 Apr 2021 12:33:23 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic [v2] In-Reply-To: References: Message-ID: <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com> > https://bugs.openjdk.java.net/browse/JDK-8185886 > > Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. > > This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. > > This may alleviate some of the issues seen here: > > TableView has a horrific performance with many columns #409 > https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 > > JDK-8088394 : Huge memory consumption in TableView with too many columns > JDK-8166956: JavaFX TreeTableView slow scroll performance > JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction > > OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns > https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html dannygonzalez has updated the pull request incrementally. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/108/files - new: https://git.openjdk.java.net/jfx/pull/108/files/05c37196..05c37196 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=108&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=108&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/108.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/108/head:pull/108 PR: https://git.openjdk.java.net/jfx/pull/108 From jgneff at openjdk.java.net Wed Apr 14 12:32:19 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 12:32:19 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 02:35:44 GMT, Bernhard M. Wiedemann wrote: > I am currently low on time and my Java-foo is not that great, so I was hoping that someone would pick it up. @bmwiedemann Thank you for getting this important change started. If you can finish this pull request, I'll follow up with some additional changes to support reproducible builds. Otherwise, if you're still short on time, I can pick up where you left off. So far I managed to create reproducible Java artifacts ? all but the native shared libraries (and the `javafx.graphics.jmod` file that includes them). ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From github.com+637990+bmwiedemann at openjdk.java.net Wed Apr 14 12:32:19 2021 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Wed, 14 Apr 2021 12:32:19 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 17:32:20 GMT, John Neffenger wrote: >> Long term, yes. >> >> I am currently low on time and my Java-foo is not that great, so I was hoping that someone would pick it up. > >> I am currently low on time and my Java-foo is not that great, so I was hoping that someone would pick it up. > > @bmwiedemann Thank you for getting this important change started. If you can finish this pull request, I'll follow up with some additional changes to support reproducible builds. Otherwise, if you're still short on time, I can pick up where you left off. So far I managed to create reproducible Java artifacts ? all but the native shared libraries (and the `javafx.graphics.jmod` file that includes them). @jgneff feel free to pick it up. When linking shared libraries, ensure that .o files are listed in deterministic order - i.e. `sort(glob(*.c))` and check if individual .c or .o files vary between builds. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From jgneff at openjdk.java.net Wed Apr 14 12:32:34 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 12:32:34 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: <7i0OcenDZq3estCW35s4Myf8uEmsC_vtE5GBYdBmfrQ=.a188e221-58a3-422d-8a7e-68f3188626d6@github.com> On Tue, 9 Mar 2021 03:11:48 GMT, Bernhard M. Wiedemann wrote: > When linking shared libraries, ensure that .o files are listed in deterministic order - i.e. `sort(glob(*.c))` and check if individual .c or .o files vary between builds. Wow, that tip was priceless! Thank you, Bernhard. It took forever to figure out *where* to add it, but simply adding `.sort()` to the list of object files for the linker did the trick: index 8f1e04a833..9181ccc7fb 100644 --- a/buildSrc/src/main/groovy/com/sun/javafx/gradle/LinkTask.groovy +++ b/buildSrc/src/main/groovy/com/sun/javafx/gradle/LinkTask.groovy @@ -49,7 +49,7 @@ class LinkTask extends DefaultTask { args("$lib"); } // Exclude parfait files (.bc) - args(objectDir.listFiles().findAll{ !it.getAbsolutePath().endsWith(".bc") }); + args(objectDir.listFiles().sort().findAll{ !it.getAbsolutePath().endsWith(".bc") }); if (project.IS_WINDOWS) { args("/out:$lib"); } else { We have reproducible builds! (Well, we have them on Linux, at least, and only after running `strip-nondeterminism` on the JMOD files, but that's still major progress.) I'll follow up with a pull request after checking whether I can get reproducible builds on macOS and Windows, too. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From github.com+637990+bmwiedemann at openjdk.java.net Wed Apr 14 12:32:54 2021 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Wed, 14 Apr 2021 12:32:54 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: <7i0OcenDZq3estCW35s4Myf8uEmsC_vtE5GBYdBmfrQ=.a188e221-58a3-422d-8a7e-68f3188626d6@github.com> References: <7i0OcenDZq3estCW35s4Myf8uEmsC_vtE5GBYdBmfrQ=.a188e221-58a3-422d-8a7e-68f3188626d6@github.com> Message-ID: <-SL4MFCYRgAtJDRf05q_sy6_qhFwV8e6JVV01VN7hWc=.df69fa03-aaf2-43dc-8e0e-4e51bab6665d@github.com> On Fri, 26 Mar 2021 19:19:10 GMT, John Neffenger wrote: > objectDir.listFiles().sort() Now the interesting question is, if it is possible to change `listFiles` to always return deterministic output or if we have to patch an infinite number of callers instead. For those cases where people do not care about order, one could add `listUnsortedFiles` with the old behaviour. There is a small performance impact, but usually that is rather small (below 4%) compared to interacting with the filesystem and processing the files returned. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From jgneff at openjdk.java.net Wed Apr 14 12:32:54 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 12:32:54 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: <-SL4MFCYRgAtJDRf05q_sy6_qhFwV8e6JVV01VN7hWc=.df69fa03-aaf2-43dc-8e0e-4e51bab6665d@github.com> References: <7i0OcenDZq3estCW35s4Myf8uEmsC_vtE5GBYdBmfrQ=.a188e221-58a3-422d-8a7e-68f3188626d6@github.com> <-SL4MFCYRgAtJDRf05q_sy6_qhFwV8e6JVV01VN7hWc=.df69fa03-aaf2-43dc-8e0e-4e51bab6665d@github.com> Message-ID: On Sat, 27 Mar 2021 03:34:11 GMT, Bernhard M. Wiedemann wrote: > Now the interesting question is, if it is possible to change `listFiles` to always return deterministic output ... Yes, that would be interesting, if `listFiles()` were defined by the Gradle build tool. I think it originates, though, in the Java [java.io.File.listFiles][1] API and is made available to Gradle through the Groovy programming language. The API states, "There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order." That API was defined in December 1998 with Java version 1.2, so there's no changing it now. [1]: https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/io/File.html#listFiles() ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From jgneff at openjdk.java.net Wed Apr 14 12:33:32 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 12:33:32 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann wrote: > Allow to override buildDate with `SOURCE_DATE_EPOCH` > in order to make builds reproducible. > See https://reproducible-builds.org/ for why this is good > and https://reproducible-builds.org/specs/source-date-epoch/ > for the definition of this variable. > > This PR was done while working on reproducible builds for openSUSE. By the way, we have reproducible builds on Linux, macOS, and Windows now! (Well, still using `strip-nondeterminism` on the JMOD files, and as long as you build from the same file system path, thanks to `com.sun.javafx.css.parser.Css2Bin`. Sigh. This rabbit hole is deep.) ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From github.com+637990+bmwiedemann at openjdk.java.net Wed Apr 14 12:33:49 2021 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Wed, 14 Apr 2021 12:33:49 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: <7i0OcenDZq3estCW35s4Myf8uEmsC_vtE5GBYdBmfrQ=.a188e221-58a3-422d-8a7e-68f3188626d6@github.com> <-SL4MFCYRgAtJDRf05q_sy6_qhFwV8e6JVV01VN7hWc=.df69fa03-aaf2-43dc-8e0e-4e51bab6665d@github.com> Message-ID: <9-rLgttEwGgKI7Bkk0xXCUznhtbreSZvVKK3rgGm-5s=.8611463e-d0be-440c-a8e5-533feb0dc804@github.com> On Sat, 27 Mar 2021 17:26:21 GMT, John Neffenger wrote: > The API states, "There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order." That API was defined in December 1998 with Java version 1.2, so there's no changing it now. Sorted output still complies with that API, though. If changing it at the Java level is too impactful, there could still be a sort-wrapper in Gradle or some other layer. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From jgneff at openjdk.java.net Wed Apr 14 12:33:49 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 12:33:49 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: <9-rLgttEwGgKI7Bkk0xXCUznhtbreSZvVKK3rgGm-5s=.8611463e-d0be-440c-a8e5-533feb0dc804@github.com> References: <7i0OcenDZq3estCW35s4Myf8uEmsC_vtE5GBYdBmfrQ=.a188e221-58a3-422d-8a7e-68f3188626d6@github.com> <-SL4MFCYRgAtJDRf05q_sy6_qhFwV8e6JVV01VN7hWc=.df69fa03-aaf2-43dc-8e0e-4e51bab6665d@github.com> <9-rLgttEwGgKI7Bkk0xXCUznhtbreSZvVKK3rgGm-5s=.8611463e-d0be-440c-a8e5-533feb0dc804@github.com> Message-ID: On Sat, 27 Mar 2021 18:49:32 GMT, Bernhard M. Wiedemann wrote: > Sorted output still complies with that API, though. Well, that's true. I hadn't thought of it that way. I have tried twice and failed to [add you as a contributor](https://github.com/openjdk/jfx/pull/422#issuecomment-806317783) to my follow-up pull request. The only option left is the syntax "contributor add J. Duke ", but I'm not sure whether you want the e-mail address in your GitHub profile made public. Let me know whether I should pursue the problem. If you're added, it puts your name and address in the commit log with `Co-authored-by` like this example: commit 8adbc673d095607e8a6109fbb951fa17b9d6caad (tag: 17+3) Author: Alexander Matveev Date: Mon Mar 15 20:57:19 2021 +0000 8257895: Allow building of JavaFX media libs for Apple Silicon Co-authored-by: Johan Vos Reviewed-by: jvos, kcr It might be useful to have a previous commit if you plan to contribute to the OpenJFX project in the future. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Wed Apr 14 12:34:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 12:34:06 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann wrote: > Allow to override buildDate with `SOURCE_DATE_EPOCH` > in order to make builds reproducible. > See https://reproducible-builds.org/ for why this is good > and https://reproducible-builds.org/specs/source-date-epoch/ > for the definition of this variable. > > This PR was done while working on reproducible builds for openSUSE. I think PR can be closed now, in favor of PR #422 ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Wed Apr 14 12:40:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 12:40:29 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 [v2] In-Reply-To: References: Message-ID: <4yaPveyXFKqOdvs7Ka_o4I2f1eOjq-0_YctqGVVRB2Q=.f205f9ee-bf2f-4042-a867-f9e4f009ca37@github.com> > As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. > > The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). > > This PR will do the same for JavaFX. > > To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: update to use isAarch64 per review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/462/files - new: https://git.openjdk.java.net/jfx/pull/462/files/218459e2..8980ab6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=462&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=462&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/462.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/462/head:pull/462 PR: https://git.openjdk.java.net/jfx/pull/462 From kcr at openjdk.java.net Wed Apr 14 12:43:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 12:43:17 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 [v2] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 12:18:00 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use isAarch64 per review comments > > buildSrc/mac.gradle line 59: > >> 57: // Note that this is not necessarily the same as the preferred SDK version >> 58: def isAarch64 = TARGET_ARCH == "aarch64" || TARGET_ARCH == "arm64"; >> 59: def macOSMinVersion = (TARGET_ARCH == "aarch64" || TARGET_ARCH == "arm64") ? "11.0" : "10.12"; > > I guess `isAarch64` was defined to use on line 59 in ternary operator. Fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/462 From arapte at openjdk.java.net Wed Apr 14 13:07:21 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 14 Apr 2021 13:07:21 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 [v2] In-Reply-To: <4yaPveyXFKqOdvs7Ka_o4I2f1eOjq-0_YctqGVVRB2Q=.f205f9ee-bf2f-4042-a867-f9e4f009ca37@github.com> References: <4yaPveyXFKqOdvs7Ka_o4I2f1eOjq-0_YctqGVVRB2Q=.f205f9ee-bf2f-4042-a867-f9e4f009ca37@github.com> Message-ID: On Wed, 14 Apr 2021 12:40:29 GMT, Kevin Rushforth wrote: >> As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. >> >> The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). >> >> This PR will do the same for JavaFX. >> >> To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > update to use isAarch64 per review comments Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/462 From pbansal at openjdk.java.net Wed Apr 14 13:18:14 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 14 Apr 2021 13:18:14 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 [v2] In-Reply-To: <4yaPveyXFKqOdvs7Ka_o4I2f1eOjq-0_YctqGVVRB2Q=.f205f9ee-bf2f-4042-a867-f9e4f009ca37@github.com> References: <4yaPveyXFKqOdvs7Ka_o4I2f1eOjq-0_YctqGVVRB2Q=.f205f9ee-bf2f-4042-a867-f9e4f009ca37@github.com> Message-ID: On Wed, 14 Apr 2021 12:40:29 GMT, Kevin Rushforth wrote: >> As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. >> >> The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). >> >> This PR will do the same for JavaFX. >> >> To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > update to use isAarch64 per review comments Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/462 From alexsch at openjdk.java.net Wed Apr 14 13:30:43 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Wed, 14 Apr 2021 13:30:43 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Tue, 13 Apr 2021 13:13:50 GMT, Kevin Rushforth wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove mt.exe from win.gradle build script > > buildSrc/win.gradle line 468: > >> 466: case "aarch64" : return "arm64" >> 467: case "amd64" : return "x64" >> 468: default: return arch > > This looks fine. I recommend to sanity test this on a 32-bit build to ensure that `os.arch` is `x86` (I don't have the ability to do that). Here are some println lines which I added to win.gradle file before building the fix for windows 32 bits println "CPU_BITS: $CPU_BITS, ext.OS_ARCH: ${ext.OS_ARCH}" println "HOST_ARCH: $HOST_ARCH, TARGET_ARCH: ${TARGET_ARCH}, IS_CROSS: ${IS_CROSS}" I built the fix on Windows x86_64 with 32bits java The output was: CPU_BITS: x86, ext.OS_ARCH: x86 HOST_ARCH: x86, TARGET_ARCH: x86, IS_CROSS: false `file` showed that the glass.dll has been build for Intel 80386: file build/sdk/bin/glass.dll build/sdk/bin/glass.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows I built corresponding jdk 16 with `--with-target-bits=32` option and the jfx and was able to successfully run Ensemble8.jar app on Windows 32bits. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From alexsch at openjdk.java.net Wed Apr 14 13:47:39 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Wed, 14 Apr 2021 13:47:39 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Tue, 13 Apr 2021 13:04:53 GMT, Kevin Rushforth wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove mt.exe from win.gradle build script > > buildSrc/win.gradle line 474: > >> 472: boolean isExecutable(String file) { >> 473: try { >> 474: Runtime.runtime.exec(file) > > Is there a way other than to execute the command in question -- `rc` or `fxc` -- to see whether it will execute? I note that `fxc` will print a warning message when run with no arguments (but even with `gradle --info` it isn't printed to the console). There is File.canExecute() method but it looks like it only check that the java program is allowed to run a file rather the file is really executed. `Runtime.runtime.exec(file)` creates a ProcessBuilder and returns a Process object. To get the program output it needs to read the process output and error streams. Here is the program which I used to check File.canExecute() and `Runtime.runtime.exec(file)` methods. File.canExecute() returns true for both x64 and arm64 fxc.exe files. `Runtime.runtime.exec(file)` passes for x64 fxc file and fails for arm64 one on Windows x86_64: import java.io.File; public class CheckFile { public static void main(String[] args) throws Exception { File file = new File(args[0]); System.out.printf("input file : %s%n", file); System.out.printf("file exists: %b%n", file.exists()); System.out.printf("can execute: %b%n", file.canExecute()); Runtime.getRuntime().exec(file.getAbsolutePath()); } } The output is: java CheckFile "c:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x64/fxc.exe" input file : c:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\fxc.exe file exists: true can execute: true java CheckFile "c:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/arm64/fxc.exe" input file : c:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\arm64\fxc.exe file exists: true can execute: true Exception in thread "main" java.io.IOException: Cannot run program "c:\Program": CreateProcess error=193, %1 is not a valid Win32 application ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From kcr at openjdk.java.net Wed Apr 14 14:12:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 14:12:38 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Tue, 13 Apr 2021 08:41:12 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Remove mt.exe from win.gradle build script Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/439 From kcr at openjdk.java.net Wed Apr 14 14:12:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 14:12:39 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Wed, 14 Apr 2021 13:44:49 GMT, Alexander Scherbatiy wrote: >> buildSrc/win.gradle line 474: >> >>> 472: boolean isExecutable(String file) { >>> 473: try { >>> 474: Runtime.runtime.exec(file) >> >> Is there a way other than to execute the command in question -- `rc` or `fxc` -- to see whether it will execute? I note that `fxc` will print a warning message when run with no arguments (but even with `gradle --info` it isn't printed to the console). > > There is File.canExecute() method but it looks like it only checks that the java program is allowed to run a file rather the file is really executed. > > `Runtime.runtime.exec(file)` creates a ProcessBuilder and returns a Process object. To get the program output it needs to read the process output and error streams. > > Here is the program which I used to check File.canExecute() and `Runtime.runtime.exec(file)` methods. > File.canExecute() returns true for both x64 and arm64 fxc.exe files. > `Runtime.runtime.exec(file)` passes for x64 fxc file and fails for arm64 one on Windows x86_64: > > import java.io.File; > > public class CheckFile { > public static void main(String[] args) throws Exception { > > File file = new File(args[0]); > System.out.printf("input file : %s%n", file); > System.out.printf("file exists: %b%n", file.exists()); > System.out.printf("can execute: %b%n", file.canExecute()); > > Runtime.getRuntime().exec(file.getAbsolutePath()); > } > } > > > The output is: > > java CheckFile "c:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x64/fxc.exe" > input file : c:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\fxc.exe > file exists: true > can execute: true > > java CheckFile "c:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/arm64/fxc.exe" > input file : c:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\arm64\fxc.exe > file exists: true > can execute: true > Exception in thread "main" java.io.IOException: Cannot run program "c:\Program": CreateProcess error=193, %1 is not a valid Win32 application That's pretty much what I suspected. Thanks for confirming. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From jvos at openjdk.java.net Wed Apr 14 14:40:40 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 14 Apr 2021 14:40:40 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Tue, 13 Apr 2021 08:41:12 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Remove mt.exe from win.gradle build script buildSrc/win.gradle line 46: > 44: def HOST_ARCH = getWinArch(ext.OS_ARCH) > 45: def TARGET_ARCH = getWinArch(ext.TARGET_ARCH) > 46: def IS_CROSS = HOST_ARCH != TARGET_ARCH can we move this to build.gradle? With the increasing number of supported configurations, there will otherwise be more gradle sub-files that have something similar. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From kcr at openjdk.java.net Wed Apr 14 14:58:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 14:58:44 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: <-RHIkCHejtlZL4ntvl_RPAxqSNOH_rKlVVxPLNz6y3Q=.d87ca0ba-ee48-4984-9329-e3ba20736828@github.com> On Wed, 14 Apr 2021 14:38:05 GMT, Johan Vos wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove mt.exe from win.gradle build script > > buildSrc/win.gradle line 46: > >> 44: def HOST_ARCH = getWinArch(ext.OS_ARCH) >> 45: def TARGET_ARCH = getWinArch(ext.TARGET_ARCH) >> 46: def IS_CROSS = HOST_ARCH != TARGET_ARCH > > can we move this to build.gradle? > With the increasing number of supported configurations, there will otherwise be more gradle sub-files that have something similar. Yes, this does seem like a better plan. Should this be done as a follow-on or do you want to see it done now? One reason I ask is that my PR #462 (which is now approved, but waiting re-review) does something similar to `getWinArch()` to determine whether we are running on aarch64 or not and should be modified as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From jvos at openjdk.java.net Wed Apr 14 15:04:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 14 Apr 2021 15:04:42 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: <-RHIkCHejtlZL4ntvl_RPAxqSNOH_rKlVVxPLNz6y3Q=.d87ca0ba-ee48-4984-9329-e3ba20736828@github.com> References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> <-RHIkCHejtlZL4ntvl_RPAxqSNOH_rKlVVxPLNz6y3Q=.d87ca0ba-ee48-4984-9329-e3ba20736828@github.com> Message-ID: <6igXFNIhO8-SkImfAsU-JtuT_uLUqpl1wHqCWECd8mU=.1daccbf5-48e3-4489-a81f-336c82cf2926@github.com> On Wed, 14 Apr 2021 14:56:16 GMT, Kevin Rushforth wrote: >> buildSrc/win.gradle line 46: >> >>> 44: def HOST_ARCH = getWinArch(ext.OS_ARCH) >>> 45: def TARGET_ARCH = getWinArch(ext.TARGET_ARCH) >>> 46: def IS_CROSS = HOST_ARCH != TARGET_ARCH >> >> can we move this to build.gradle? >> With the increasing number of supported configurations, there will otherwise be more gradle sub-files that have something similar. > > Yes, this does seem like a better plan. Should this be done as a follow-on or do you want to see it done now? One reason I ask is that my PR #462 (which is now approved, but waiting re-review) does something similar to `getWinArch()` to determine whether we are running on aarch64 or not and should be modified as well. In that case, a follow-up seems best (we can tackle mac/win/linux aarch64 simultaneously then) ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From jvos at openjdk.java.net Wed Apr 14 15:05:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 14 Apr 2021 15:05:39 GMT Subject: RFR: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 [v2] In-Reply-To: <4yaPveyXFKqOdvs7Ka_o4I2f1eOjq-0_YctqGVVRB2Q=.f205f9ee-bf2f-4042-a867-f9e4f009ca37@github.com> References: <4yaPveyXFKqOdvs7Ka_o4I2f1eOjq-0_YctqGVVRB2Q=.f205f9ee-bf2f-4042-a867-f9e4f009ca37@github.com> Message-ID: On Wed, 14 Apr 2021 12:40:29 GMT, Kevin Rushforth wrote: >> As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. >> >> The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). >> >> This PR will do the same for JavaFX. >> >> To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > update to use isAarch64 per review comments Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/462 From kcr at openjdk.java.net Wed Apr 14 15:32:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 15:32:39 GMT Subject: Integrated: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 20:30:55 GMT, Kevin Rushforth wrote: > As noted in the JBS bug, the minimum macOS version on which JavaFX will run is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of support, so we should update this minimum. Further, macOS / aarch64 (aka arm64) requires macOS 11.0 as a minimum in order to run. > > The JDK recently updated their minimum for x86_64 to 10.12 and for aarch64 to 11.0. See [make/autoconf/flags.m4#L136](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/make/autoconf/flags.m4#L136). > > This PR will do the same for JavaFX. > > To determine whether we are building on `aarch64`, I check the `TARGET_ARCH` property for either `aarch64` or `arm64`, since we currently use the latter for our builds, although we should proably update our build to consistently use `aarch64` everywhere, and map that to `arm64` on usage where required by native tools. This pull request has now been integrated. Changeset: e8689fef Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e8689fef Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0 Reviewed-by: jvos, arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/462 From kcr at openjdk.java.net Wed Apr 14 15:36:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 14 Apr 2021 15:36:45 GMT Subject: Withdrawn: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: <4Fpyhn8IE_9DLlkKZ2l-sxqISVpyydsZ7rd3eDFhPDw=.b02b5256-c63a-4f32-b0fb-71e8a2eadb9c@github.com> On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann wrote: > Allow to override buildDate with `SOURCE_DATE_EPOCH` > in order to make builds reproducible. > See https://reproducible-builds.org/ for why this is good > and https://reproducible-builds.org/specs/source-date-epoch/ > for the definition of this variable. > > This PR was done while working on reproducible builds for openSUSE. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From jgneff at openjdk.java.net Wed Apr 14 20:58:37 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 14 Apr 2021 20:58:37 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] In-Reply-To: References: Message-ID: On Sun, 4 Apr 2021 16:36:27 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 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. *IEEE Software* just published a good article that describes the problems solved in part by this pull request. The article is called "Reproducible Builds: Increasing the Integrity of Software Supply Chains," by Chris Lamb and Stefano Zacchiroli. It's an easy read of 10 pages, available at the links below: * [IEEE Xplore](https://ieeexplore.ieee.org/document/9403390) - Registration required * [arXiv.org](https://arxiv.org/abs/2104.06020) - Free PDF download ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From nlisker at openjdk.java.net Thu Apr 15 02:21:50 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 15 Apr 2021 02:21:50 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: Message-ID: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Combined rotation and direction ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/7c36639e..3d6cdb19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=12-13 Stats: 27 lines in 3 files changed: 17 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Thu Apr 15 02:24:35 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 15 Apr 2021 02:24:35 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction I update the patch to include rotation transforms applying on the direction vector. When testing, I suggest using the "Boxes" model. You will need to rotate (right/middle mouse buttons) to see model properly as the back wall obscures the camera's initial position. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From ajoseph at openjdk.java.net Thu Apr 15 05:36:33 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 15 Apr 2021 05:36:33 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Fri, 9 Apr 2021 21:10:46 GMT, Matthias Bl?sing wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to thread attachment introduced in second commit > > Thread attachment is handled in > jfx/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp > and thus does not need to be modified. tests/system/src/test/java/test/com/sun/webkit/LocalStorageAccessTest.java line 36: > 34: /** > 35: * @test > 36: * @bug 9069811 The changes looks good. The bug id is not modified at this point. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From arapte at openjdk.java.net Thu Apr 15 07:15:13 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 15 Apr 2021 07:15:13 GMT Subject: RFR: [WIP] 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error [v3] In-Reply-To: References: Message-ID: > Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. > > Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. > Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. > - RegionBackgroundImageUITest.unalignedImage > - RegionBackgroundFillUITest.testScenario2 > - RegionBackgroundFillUITest.testScenario3 > > commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. > > One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. > It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) > > This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. > Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: skip tests that fail on windows with non-integer screen scale ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/344/files - new: https://git.openjdk.java.net/jfx/pull/344/files/f270a0bb..91b8d543 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=344&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=344&range=01-02 Stats: 38 lines in 1 file changed: 37 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/344.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/344/head:pull/344 PR: https://git.openjdk.java.net/jfx/pull/344 From arapte at openjdk.java.net Thu Apr 15 07:15:25 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 15 Apr 2021 07:15:25 GMT Subject: RFR: [WIP] 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error [v2] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 14:33:08 GMT, Ambarish Rapte wrote: >> Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. >> >> Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. >> Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. >> - RegionBackgroundImageUITest.unalignedImage >> - RegionBackgroundFillUITest.testScenario2 >> - RegionBackgroundFillUITest.testScenario3 >> >> commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. >> >> One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. >> It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) >> >> This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. >> Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). > > 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 three additional commits since the last revision: > > - Merge > - fix for tests failing on Mac > - ideal fix, but causes 3 test fail Following tests fail on windows with non-integer screen scale. **30** tests fail with **125%** scale, alignedImage alignedImage_Contain alignedImage_PositionBottomRight alignedImage_PositionBottomRightRepeatX alignedImage_PositionBottomRightRepeatY alignedImage_PositionCenterBottom alignedImage_PositionCenterBottomRepeatX alignedImage_PositionCenterBottomRepeatY alignedImage_PositionCenterFiftyPercentRepeatY alignedImage_PositionCenterLeftRepeatY alignedImage_PositionCenterRepeatY alignedImage_PositionCenterRightRepeatY alignedImage_PositionCenterTopRepeatY alignedImage_RepeatY alignedImage_Round alignedImage_RoundSpace alignedImage_Space unalignedImage unalignedImage_Contain unalignedImage_PositionBottomRightRepeatX unalignedImage_PositionBottomRightRepeatY unalignedImage_PositionCenterBottomRepeatX unalignedImage_PositionCenterBottomRepeatY unalignedImage_PositionCenterFiftyPercentRepeatY unalignedImage_PositionCenterLeftRepeatY unalignedImage_PositionCenterRepeatY unalignedImage_PositionCenterRightRepeatY unalignedImage_PositionCenterTopRepeatY unalignedImage_RepeatY unalignedImage_Round **5** tests fail with **150%** scale, alignedImage_PositionCenterTopRepeatX alignedImage_RepeatX unalignedImage_Cover unalignedImage_PositionCenterTopRepeatX unalignedImage_RepeatX These tests are marked to skip execution when screen scale is non-integer. ------------- PR: https://git.openjdk.java.net/jfx/pull/344 From aghaisas at openjdk.java.net Thu Apr 15 08:02:42 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 15 Apr 2021 08:02:42 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 09:41:03 GMT, Johan Vos wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments Code changes are OK. I have noted a few minor comments. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1305: > 1303: // Otherwise, our goal is to leave the index of the cell at the > 1304: // top consistent, with the same translation etc. > 1305: if (position != 0 && position != 1 && (currentIndex >= cellCount)) { Comparing a double for equality or inequality is not the best coding practice. Anyway, I see this pattern throughout this file. We can live with it for now. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 658: > 656: * laid out properly. > 657: */ > 658: @Test Only new line is added after @Test tag. There are a lot of changes of this type which I presume were done by the IDE. I think, we can revert these safely as not to cause unnecessary diffs. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1233: > 1231: private VirtualFlowShim createCircleFlow() { > 1232: // The second VirtualFlow we are going to test, with 7 cells. Each cell > 1233: // contains a Circle whith a radius that varies between cells. Typo : "whith" -> "with" modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1282: > 1280: flow.scrollPixels(-50); > 1281: double neg = flow.getPosition(); > 1282: assertFalse("Moving in negative direction should not decrease position", neg > pos); "decrease" in log message should be "increase" modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1294: > 1292: vf.scrollPixels(-50); > 1293: double neg = vf.getPosition(); > 1294: assertFalse("Moving in negative direction should not decrease position", neg > pos); "decrease" in log message should be "increase" ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From arapte at openjdk.java.net Thu Apr 15 09:19:00 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 15 Apr 2021 09:19:00 GMT Subject: RFR: [WIP] 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error [v4] In-Reply-To: References: Message-ID: > Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. > > Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. > Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. > - RegionBackgroundImageUITest.unalignedImage > - RegionBackgroundFillUITest.testScenario2 > - RegionBackgroundFillUITest.testScenario3 > > commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. > > One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. > It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) > > This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. > Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: skip test on mac that fails only on mac ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/344/files - new: https://git.openjdk.java.net/jfx/pull/344/files/91b8d543..1a30b63c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=344&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=344&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/344.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/344/head:pull/344 PR: https://git.openjdk.java.net/jfx/pull/344 From aghaisas at openjdk.java.net Thu Apr 15 09:45:35 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 15 Apr 2021 09:45:35 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> References: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> Message-ID: <2goJ-FKBOk7v3QTc8A2peE9K3vt8vPNX-79ZR9nwOJk=.e08f9c26-9840-4d67-aa51-d0e8bd9c501a@github.com> On Mon, 12 Apr 2021 08:40:56 GMT, Ambarish Rapte wrote: >> The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. >> Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). >> >> Fix is to remove the listener when MenuItem is removed. >> Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. >> Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. >> With fix, the count is always same as number of MenuItems in scenegraph. >> >> Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. >> This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. >> Added a comment explaining this behavior in place of the TODO. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > remove indirect test Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From aghaisas at openjdk.java.net Thu Apr 15 10:18:39 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 15 Apr 2021 10:18:39 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 09:41:03 GMT, Johan Vos wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1315: > 1313: s1 = sb.getLayoutY(); > 1314: newDelta = newPosition - position; > 1315: System.err.println("s0 = "+s0+", s1 = "+s1); I suggest to comment out all System.err.println() calls from this loop. It might be useful while debugging individual failing test, but keeping them on for every test run will simply flood the log. Similar logs were fixed for stdout earlier. Please refer - https://bugs.openjdk.java.net/browse/JDK-8255497 ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From fastegal at openjdk.java.net Thu Apr 15 11:58:39 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 15 Apr 2021 11:58:39 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v4] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 11:58:14 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > Added checks, whether the correction ammount of editStart/cancel events are triggered - there's still a failing transition (and not covered by the latest test ;) `cellIndex == editingIndex` to `cellIndex == -1` - as to your fix: don't see a difference between calling `updateEditing `before/after `updateFocus` - simply moving it after the if block seems to solve all toEditing issues That said: I'm aware that getting this right is tedious and a bit hard, not because it's rocket science but because we need to cover the corner cases as completely as possible (and often fail in doing so, me included :) Chances are that if we detect a problem with a transition "-1 -> 1", there's a similar problem in the invers "1 -> -1". Even if there isn't, we should make sure there isn't by adding a test. That's why I personally prefer writing dedicated parameterized tests (vs. adding to the existing general purpose test), here in cell/editingIndex. Don't know if you noticed, yesterday I attached such a test to the issue (had to write it for [JDK-8265206](https://bugs.openjdk.java.net/browse/JDK-8265206) anyway, so no big deal to replace TableCell with ListCell) - whether you take it or adjust yours accordingly doesn't matter, as long as the coverage is complete. BTW, in TableCell the remaining issue (editingIndex -> -1) seems to be related to updateEditing backing out if the current index is -1. It probably should cleanup if in editing state (didn't try yet). ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From arun.aj.joseph at oracle.com Thu Apr 15 12:15:57 2021 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Thu, 15 Apr 2021 12:15:57 +0000 Subject: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: References: Message-ID: <5D49C83F-4E15-4A8B-8722-DE72E24C3DEC@oracle.com> I?m marking the PR (https://github.com/openjdk/jfx/pull/461) as ready for review. You can add your evaluation in the PR. ? Arun Joseph From ajoseph at openjdk.java.net Thu Apr 15 12:21:08 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 15 Apr 2021 12:21:08 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView Message-ID: Issue: Java application (with WebView) will completely freeze after using it for a while. Fix: Use native isMainThread functions instead of JNI call. ------------- Commit messages: - Remove platform check in ThreadingWin - Remove fwkIsMainThread - 8263788: JavaFX application freezes completely after some time when using the WebView Changes: https://git.openjdk.java.net/jfx/pull/461/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=461&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263788 Stats: 38 lines in 3 files changed: 15 ins; 18 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/461.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/461/head:pull/461 PR: https://git.openjdk.java.net/jfx/pull/461 From kcr at openjdk.java.net Thu Apr 15 12:33:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Apr 2021 12:33:45 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v9] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 14:45:58 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changed description as suggested in review I finished reviewing the API changes, and it all looks good. I noted a follow-up bug that I need to file. I'll review the CSR (to make sure it matches exactly the latest API docs in the code) in parallel with reviewing the implementation. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 219: > 217: * @param observable the observable to observe for change events, may be {@code null} > 218: * @param operation the operation to perform when the observable sends a change event, > 219: * may be {@code null} This method is missing the `@since 9` javadoc tag. This is a preexisting bug; this method was missed when [JDK-8135312](https://bugs.openjdk.java.net/browse/JDK-8135312) was fixed. It's tempting to fold it into this RFE, since you are rewriting the API docs for this method, but I'll file a separate bug instead. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Thu Apr 15 12:33:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Apr 2021 12:33:46 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: <2jCKI7kAShxVgTbFqbFHMJpBrcXfZ0H6-hDgeQ11_Nc=.51ebeef8-28a7-49e9-b0ac-55862486b528@github.com> On Wed, 24 Mar 2021 23:30:03 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed missing/incorrect @since tags in new api doc > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 273: > >> 271: * @since 17 >> 272: */ >> 273: protected final Consumer unregisterInvalidationListeners(Observable observable) { > > Is `null` check on `observable` needed? `unregisterInvalidationListeners` does the `null` check ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Thu Apr 15 12:46:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Apr 2021 12:46:34 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v9] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 14:45:58 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changed description as suggested in review I filed [JDK-8265277](https://bugs.openjdk.java.net/browse/JDK-8265277) to add the missing `@since 9` javadoc tag. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Thu Apr 15 12:58:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Apr 2021 12:58:42 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: <1E8YfFdG47jiWnSef5cbVsWX8Zek2tOpSzPI0SlnScg=.acdda3c9-12f9-480a-ac81-52b4c4c84515@github.com> On Wed, 24 Mar 2021 23:51:37 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed missing/incorrect @since tags in new api doc > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 63: > >> 61: */ >> 62: public final class LambdaMultiplePropertyChangeListenerHandler { >> 63: // FIXME: name doesn't fit after widening to support more notification event types > > Maybe `MultipleObservableListenersHandler`? I didn't look at the class too much. I like `MultipleObservableListenersHandler` or `LambdaMultipleObservableListenersHandler` if you want to keep `Lambda` in the name (not sure it matters much). ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From alexsch at openjdk.java.net Thu Apr 15 13:56:12 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 15 Apr 2021 13:56:12 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v3] In-Reply-To: References: Message-ID: > This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). > > Main changes: > - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition > - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 > - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) > - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. > > I also looked which changes are required to build media module for Windows aarch64. > The main changes could be using: > - `ARCH=arm64` for building media libs in build.gradle file > - `-MACHINE:arm64` LDFLAGS in media make files > - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file > - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port > > In this way the media is build but it is crashed when I run a JavaFX sample with video. > Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Add CONVERTED_OS_ARCH and CONVERTED_TARGET_ARCH variables ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/439/files - new: https://git.openjdk.java.net/jfx/pull/439/files/38184783..c266aed4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=439&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=439&range=01-02 Stats: 41 lines in 2 files changed: 19 ins; 9 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/439.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/439/head:pull/439 PR: https://git.openjdk.java.net/jfx/pull/439 From alexsch at openjdk.java.net Thu Apr 15 14:02:38 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 15 Apr 2021 14:02:38 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: <6igXFNIhO8-SkImfAsU-JtuT_uLUqpl1wHqCWECd8mU=.1daccbf5-48e3-4489-a81f-336c82cf2926@github.com> References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> <-RHIkCHejtlZL4ntvl_RPAxqSNOH_rKlVVxPLNz6y3Q=.d87ca0ba-ee48-4984-9329-e3ba20736828@github.com> <6igXFNIhO8-SkImfAsU-JtuT_uLUqpl1wHqCWECd8mU=.1daccbf5-48e3-4489-a81f-336c82cf2926@github.com> Message-ID: On Wed, 14 Apr 2021 15:02:06 GMT, Johan Vos wrote: >> Yes, this does seem like a better plan. Should this be done as a follow-on or do you want to see it done now? One reason I ask is that my PR #462 (which is now approved, but waiting re-review) does something similar to `getWinArch()` to determine whether we are running on aarch64 or not and should be modified as well. > > In that case, a follow-up seems best (we can tackle mac/win/linux aarch64 simultaneously then) I added CONVERTED_OS_ARCH, CONVERTED_TARGET_ARCH variables, and getConvertedOsArch(arch) function to build.gradle. I think there should be the better prefix name for updated os arch but what comes in my mind is converted or unified. Building jfx with the fix on windows 32, 64 bits and arm64 cross compilation outputs the following variables in the log: # Win 32 bits OS_ARCH: x86 TARGET_ARCH: x86 CONVERTED_OS_ARCH: x86 CONVERTED_TARGET_ARCH: x86 # Win 64 bits OS_ARCH: amd64 TARGET_ARCH: amd64 CONVERTED_OS_ARCH: x64 CONVERTED_TARGET_ARCH: x64 # Win arm64 cross compilation OS_ARCH: amd64 TARGET_ARCH: aarch64 CONVERTED_OS_ARCH: x64 CONVERTED_TARGET_ARCH: arm64 ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From fastegal at openjdk.java.net Thu Apr 15 15:00:48 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 15 Apr 2021 15:00:48 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: <1E8YfFdG47jiWnSef5cbVsWX8Zek2tOpSzPI0SlnScg=.acdda3c9-12f9-480a-ac81-52b4c4c84515@github.com> References: <1E8YfFdG47jiWnSef5cbVsWX8Zek2tOpSzPI0SlnScg=.acdda3c9-12f9-480a-ac81-52b4c4c84515@github.com> Message-ID: On Thu, 15 Apr 2021 12:55:56 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 63: >> >>> 61: */ >>> 62: public final class LambdaMultiplePropertyChangeListenerHandler { >>> 63: // FIXME: name doesn't fit after widening to support more notification event types >> >> Maybe `MultipleObservableListenersHandler`? I didn't look at the class too much. > > I like `MultipleObservableListenersHandler` or `LambdaMultipleObservableListenersHandler` if you want to keep `Lambda` in the name (not sure it matters much). sorry, somehow this comment didn't reach my consciousness ;) `MultipleObservableListenersHandler` sounds fine. Would like to extract the rename to a follow-up issue, though, because it's not only used by SkinBase. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Thu Apr 15 15:19:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 15 Apr 2021 15:19:42 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v4] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 11:58:14 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > Added checks, whether the correction ammount of editStart/cancel events are triggered curious: do you understand the dependency of update sequence (updateEditing relative to updateFocus)? What I see is - `focusIndex == cellIndex` and calling updateEditing before updateFocus - all toEditing transitions are failing due to corrupting list editing state (its editingIndex seems to be changed to -1, that is effectively canceling the edit) - `focusIndex == editingIndex` and calling updateEditing after updateFocus - all offEditing transitions are failing due to corrupting list editing state TableCell does the latter and has no dependency on focus state - at least none I can see ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From jvos at openjdk.java.net Thu Apr 15 15:37:38 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 15 Apr 2021 15:37:38 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v3] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 13:56:12 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Add CONVERTED_OS_ARCH and CONVERTED_TARGET_ARCH variables build.gradle line 264: > 262: case "amd64" : return "x64" > 263: default: return arch > 264: } I think a function that gets the "converted" arch is very useful, but I'm not sure what the resulting value should be. In case of arm64/aarch64, I have s slight preference for aarch64, but I'm not against arm64. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From kcr at openjdk.java.net Thu Apr 15 16:00:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Apr 2021 16:00:45 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v3] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 15:34:42 GMT, Johan Vos wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Add CONVERTED_OS_ARCH and CONVERTED_TARGET_ARCH variables > > build.gradle line 264: > >> 262: case "amd64" : return "x64" >> 263: default: return arch >> 264: } > > I think a function that gets the "converted" arch is very useful, but I'm not sure what the resulting value should be. In case of arm64/aarch64, I have s slight preference for aarch64, but I'm not against arm64. This does seem useful, although in this case, wasn't `arm64` chosen for compatibility with the name in the Microsoft VisualStudio distro? If so, then this part of the most recent change might be Windows-specific. It might be better to revert this (going back to your previous fix in `win.gradle`) until we can take a more holistic look at this. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From github.com+2179736+matthiasblaesing at openjdk.java.net Thu Apr 15 16:43:08 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Thu, 15 Apr 2021 16:43:08 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v3] In-Reply-To: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: > The functions from FileSystemJava are called from different threads the > root problem manifests because the JNI FindClass function behaves > differently when called from a context that is the ancestor of a java > frame compared to when called in isolation. > > A segmentation fault is observed when local storage of a webview is > accessed. At that time a new native thread is spun up and that sets up > the local storage, by calling into the JVM via > WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is > invoked to get a referenc to the java implementation of the FileSystem. > As this is is called from a new native thread (no java context > available), JNI uses the system classloader to locate the class. This > fails if the JavaFX modules are not on the boot module/class path. > > Instead on relying on fetching the class reference everytime it is > needed, this change fetches it once when the JavaFX library is loaded > and stores it in the WTF namespace. > > In addition to this it was observed, that there is no attachment to the > JVM done when calling into the filesystem. No fault was observed, but > the JNI specs indicate, that the JNIEnv interface is only valid when > attached. Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Review fix: Use correct bug id ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/458/files - new: https://git.openjdk.java.net/jfx/pull/458/files/c9ec47c9..e1de314d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=458&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=458&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/458.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/458/head:pull/458 PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+2179736+matthiasblaesing at openjdk.java.net Thu Apr 15 16:43:09 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Thu, 15 Apr 2021 16:43:09 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Thu, 15 Apr 2021 05:34:08 GMT, Arun Joseph wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert changes to thread attachment introduced in second commit >> >> Thread attachment is handled in >> jfx/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp >> and thus does not need to be modified. > > tests/system/src/test/java/test/com/sun/webkit/LocalStorageAccessTest.java line 36: > >> 34: /** >> 35: * @test >> 36: * @bug 9069811 > > The changes looks good. The bug id is not modified at this point. Fixed, sorry I missed it after the issue was made public. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From arapte at openjdk.java.net Thu Apr 15 17:01:32 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 15 Apr 2021 17:01:32 GMT Subject: RFR: 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error [v4] In-Reply-To: References: Message-ID: <5KUZM6qEJ77q1aHpVsJy9EBTPNdSdjRbQirjYT3kaAM=.02f907a8-2ce7-45f9-843f-85b394cf5fe8@github.com> On Mon, 2 Nov 2020 14:12:25 GMT, Kevin Rushforth wrote: > this might be a bug in Robot itself It seems like a robot issue. These failures can also be observed without this change and with increased timeout (70000 ms). > The fix for [JDK-8170026](https://bugs.openjdk.java.net/browse/JDK-8170026) addressed this by skipping the tests that were sensitive to screen scale (14 of them). You either need to do something similar for `RegionBackgroundImageUITest` Here also I made same change to skip the failing tests(listed in previous comment). Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/344 From alexsch at openjdk.java.net Thu Apr 15 17:37:08 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 15 Apr 2021 17:37:08 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v4] In-Reply-To: References: Message-ID: > This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). > > Main changes: > - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition > - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 > - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) > - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. > > I also looked which changes are required to build media module for Windows aarch64. > The main changes could be using: > - `ARCH=arm64` for building media libs in build.gradle file > - `-MACHINE:arm64` LDFLAGS in media make files > - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file > - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port > > In this way the media is build but it is crashed when I run a JavaFX sample with video. > Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Revert back fix with CONVERTED_OS_ARCH and CONVERTED_TARGET_ARCH variables ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/439/files - new: https://git.openjdk.java.net/jfx/pull/439/files/c266aed4..b898bb49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=439&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=439&range=02-03 Stats: 41 lines in 2 files changed: 9 ins; 19 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/439.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/439/head:pull/439 PR: https://git.openjdk.java.net/jfx/pull/439 From alexsch at openjdk.java.net Thu Apr 15 17:46:34 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 15 Apr 2021 17:46:34 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v3] In-Reply-To: References: Message-ID: <0N0YrOJ74x4lYwWGXkClU9PD6x4HWjilVcCe_ZsRE4g=.3b01e1fe-63b0-47ad-9ce5-eb62985cf1f4@github.com> On Thu, 15 Apr 2021 15:57:32 GMT, Kevin Rushforth wrote: >> build.gradle line 264: >> >>> 262: case "amd64" : return "x64" >>> 263: default: return arch >>> 264: } >> >> I think a function that gets the "converted" arch is very useful, but I'm not sure what the resulting value should be. In case of arm64/aarch64, I have s slight preference for aarch64, but I'm not against arm64. > > This does seem useful, although in this case, wasn't `arm64` chosen for compatibility with the name in the Microsoft VisualStudio distro? If so, then this part of the most recent change might be Windows-specific. It might be better to revert this (going back to your previous fix in `win.gradle`) until we can take a more holistic look at this. Yes, the arm64 is used as an OS arch for Visual Studio vcvarsall.bat and x64 as a part of a path to arch specific Visual Studio tools on Windows. I reverted the fix with converted os arch variables back. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From jvos at openjdk.java.net Thu Apr 15 18:21:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 15 Apr 2021 18:21:41 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> Message-ID: On Mon, 12 Apr 2021 16:17:37 GMT, Kevin Rushforth wrote: > @johanvos Do you have a case where it is actually failing as a result of a thread not being attached? No, I don't have a usecase for that. Hence, as long as there is no trace that can lead to this, I agree this (calling the Attach/Detach) doesn't need to be added. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Thu Apr 15 23:30:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Apr 2021 23:30:38 GMT Subject: Withdrawn: 8264886: WebKit native to Java invocations on wrong thread In-Reply-To: <2D_bRgHchnLscPscKBCoIAlkicrx0lLO3BrLII2WqIc=.763f994e-6d56-44f7-a6c4-19052e09d761@github.com> References: <2D_bRgHchnLscPscKBCoIAlkicrx0lLO3BrLII2WqIc=.763f994e-6d56-44f7-a6c4-19052e09d761@github.com> Message-ID: On Thu, 8 Apr 2021 12:18:59 GMT, Johan Vos wrote: > Fix for JDK-8264886 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/459 From kcr at openjdk.java.net Thu Apr 15 23:46:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 15 Apr 2021 23:46:35 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. The code changes look good. I still need to test it. Speaking of which, I presume you've tested this on all three platforms? I left one question inline. @johanvos, @arapte, or @guruhb can one of you be the second reviewer? modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp line 45: > 43: #elif OS(WINDOWS) > 44: static ThreadIdentifier mainThread { 0 }; > 45: #endif Both here and below, where the `isMainThread` is defined, assume that `UNIX` and `WINDOWS` are the only two options. I presume this is a valid assumption? ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From michaelstrau2 at gmail.com Fri Apr 16 04:48:11 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 16 Apr 2021 06:48:11 +0200 Subject: [External] : Re: Consistent baseline layout algorithm In-Reply-To: <48E4876A-0F8A-428B-A20D-75AC57E1332F@gmail.com> References: <97e36c88-838d-e931-4c21-d15a55bf39d3@oracle.com> <48E4876A-0F8A-428B-A20D-75AC57E1332F@gmail.com> Message-ID: I've learned a few new things while working on the proposed new layout algorithm, and added a few new APIs: 1. A central concept of the new algorithm was the notion of a text-baseline node, indicated by Node::isTextBaseline(). I've come to realize that this property should percolate upwards in the scene graph: if a node has a text-baseline, the node's parent should also be considered to have a text-baseline. Adding this new behavior works surprisingly well and produces very intuitive layout results. 2. The default behavior of all layout containers is to pick the first text-baseline child to derive their own baseline offset. I've added Node::prefBaselineProperty(), which makes it possible to override this default selection: layout containers now pick the first child that reports Node::isPrefBaseline(), and only if there is no such child, they fall back to Node::isTextBaseline(). Developers can use this property to fine-tune their baseline layouts. 3. Optimization: Controls that contain text will often consist of a container of some sort and a javafx.scene.text.Text node within it. Computing the baseline offset of such a control is very easy with the new layout algorithm: public double getBaselineOffset() { return text.getLayoutBounds().getMinY() + text.getLayoutY() + text.getBaselineOffset(); } This works because changing text.layoutY will automatically schedule another layout pass for all of its parents. Re-layouting all parents is necessary because changing layoutY can change the effective baseline offset, and changing the baseline offset of any node can have layout implications on any of its parents. However, when we consider the Label control (which is probably among the most commonly used controls), this can be a bit excessive. Label controls are often used to display pure text, and as such, we can often "know" the baseline offset without actually needing to schedule a second layout pass. This assumption is only correct if the text within the Label is top-aligned (because if it isn't, the Label baseline offset can not be known in advance of an actual layout pass). To leverage this assumption, I've changed the default alignment for Label to TOP_LEFT (the default alignment of the base class Labeled is CENTER_LEFT). In most cases, there will be no visual difference anyway, because I imagine Label controls will seldomly be set to a minHeight or prefHeight. This specific scenario will enable an optimization where the first layout pass of Label will not schedule a second layout pass. It might be possible to find more such scenarios that can benefit from fast-path optimizations. 4. In order to get a better understanding of the layout process, I added additional logging to track layout passes. Then I compared the current algorithm with the new algorithm by tracking the initial layout after starting a sample program (i.e. all layout activity until the first frame is rendered). In the following log, "cumulative layout passes" means how often layoutChildren() has been invoked on any of the scene graph nodes. The actual log output includes a tree visualization of the entire scene graph that is being layouted, which I've removed for the sake or brevity. Current algorithm log output: INFO: Layouting VBox (triggered by scene out-of-pulse), cumulative layout passes: 49 INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 43 INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 0 New algorithm log output: INFO: Layouting VBox (triggered by scene out-of-pulse), cumulative layout passes: 86 INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 19 A major difference is that the current algorithm will often leave the scene graph in a 'dirty' layout state after running a complete layout cycle, which necessitates another layout cycle as part of the next pulse. The new algorithm, however, leaves the scene graph in a clean layout state after a complete cycle, which takes more work at first, but saves work that would otherwise be done in the next pulse. 5. Since the new layout algorithm will leave the scene graph in a clean state, it is not necessary to repeatedly layout the same thing (like in Node::doLayoutPass()). Cases like these should be identified and may be changed to single layout invocations. Overall, I think there's good reason to assume that the proposed algorithm works and that it produces consistent results for application developers. At this point it would be useful to know whether or not to continue with the effort. From arapte at openjdk.java.net Fri Apr 16 05:05:36 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 16 Apr 2021 05:05:36 GMT Subject: Integrated: 8208088: Memory Leak in ControlAcceleratorSupport In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 17:35:34 GMT, Ambarish Rapte wrote: > The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. > Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). > > Fix is to remove the listener when MenuItem is removed. > Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. > Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. > With fix, the count is always same as number of MenuItems in scenegraph. > > Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. > This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. > Added a comment explaining this behavior in place of the TODO. This pull request has now been integrated. Changeset: 05ab7992 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/05ab7992 Stats: 147 lines in 2 files changed: 135 ins; 10 del; 2 mod 8208088: Memory Leak in ControlAcceleratorSupport Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From jvos at openjdk.java.net Fri Apr 16 08:44:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Apr 2021 08:44:41 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:10:44 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Process reviewer comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1591: > >> 1589: adjustPositionToIndex(index); >> 1590: // double offset = - computeOffsetForCell(index); >> 1591: // adjustByPixelAmount(offset); > > I forgot to ask about this last time. Is there a reason to leave the former, now commented-out, code here, as opposed to just removing it? no reason, corrected. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1903: > >> 1901: void setViewportLength(double value) { >> 1902: this.viewportLength = value; >> 1903: this.absoluteOffset = getPosition() * (estimatedSize -viewportLength); > > Minor: spacing solved this and the previous spacing comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Fri Apr 16 08:44:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Apr 2021 08:44:42 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: <_UUMA0D-8jQckl37KlKZQWvyijAknjmvbn1wHsdp1g8=.44ce00b0-4b29-445f-9d6e-a597a695398f@github.com> On Thu, 15 Apr 2021 07:22:29 GMT, Ajit Ghaisas wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Process reviewer comments > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 658: > >> 656: * laid out properly. >> 657: */ >> 658: @Test > > Only new line is added after @Test tag. There are a lot of changes of this type which I presume were done by the IDE. I think, we can revert these safely as not to cause unnecessary diffs. reverted > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1294: > >> 1292: vf.scrollPixels(-50); >> 1293: double neg = vf.getPosition(); >> 1294: assertFalse("Moving in negative direction should not decrease position", neg > pos); > > "decrease" in log message should be "increase" typos fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Fri Apr 16 08:50:38 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Apr 2021 08:50:38 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: References: Message-ID: <0bpoXatL6L-Wslgurv91sDMBwFMU43er8utBlXynIPI=.07361541-3de4-49ba-afb9-b3206a8524f0@github.com> On Thu, 15 Apr 2021 07:53:50 GMT, Ajit Ghaisas wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Process reviewer comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1305: > >> 1303: // Otherwise, our goal is to leave the index of the cell at the >> 1304: // top consistent, with the same translation etc. >> 1305: if (position != 0 && position != 1 && (currentIndex >= cellCount)) { > > Comparing a double for equality or inequality is not the best coding practice. Anyway, I see this pattern throughout this file. We can live with it for now. The comparison was already in the code. I agree though it is brittle in general, although it can probably be proved that in this case, the value of position will never be e.g. 1+\delta with \delta as small as possible. But it would be good practice for a follow-up issue to remove the equality checks on doubles in this file (and others). > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1315: > >> 1313: s1 = sb.getLayoutY(); >> 1314: newDelta = newPosition - position; >> 1315: System.err.println("s0 = "+s0+", s1 = "+s1); > > I suggest to comment out all System.err.println() calls from this loop. > They might be useful while debugging individual failing test, but keeping them on for every test run will simply flood the log. > Similar logs were fixed for stdout earlier. Please refer - https://bugs.openjdk.java.net/browse/JDK-8255497 System.err.println()s are removed now. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From ajoseph at openjdk.java.net Fri Apr 16 08:52:36 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 16 Apr 2021 08:52:36 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: <93ysfTs2Q0hKjcrZQcnLJlk5nB-Av3z5mKBKTOs5zo0=.66663432-af1a-434f-a1a2-aed9e7a07035@github.com> On Thu, 15 Apr 2021 23:41:02 GMT, Kevin Rushforth wrote: >> Issue: Java application (with WebView) will completely freeze after using it for a while. >> >> Fix: Use native isMainThread functions instead of JNI call. > > modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp line 45: > >> 43: #elif OS(WINDOWS) >> 44: static ThreadIdentifier mainThread { 0 }; >> 45: #endif > > Both here and below, where the `isMainThread` is defined, assume that `UNIX` and `WINDOWS` are the only two options. I presume this is a valid assumption? I've tested in all three platforms. The two options are sufficient as Mac and Linux uses `pthread`. ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From jvos at openjdk.java.net Fri Apr 16 09:00:19 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Apr 2021 09:00:19 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v3] In-Reply-To: References: Message-ID: > This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) > The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. > Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. > This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Process reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/398/files - new: https://git.openjdk.java.net/jfx/pull/398/files/dd792176..91a82c08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=398&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=398&range=01-02 Stats: 16 lines in 2 files changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/398.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/398/head:pull/398 PR: https://git.openjdk.java.net/jfx/pull/398 From arapte at openjdk.java.net Fri Apr 16 09:42:55 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 16 Apr 2021 09:42:55 GMT Subject: RFR: 8234077: Evaluate ignored unit tests in RenderRootTest Message-ID: These are 2 corner case test cases for getRenderRoot() method. 1. `emptyDirtyRegion():` When the dirty region rect is empty i.e. (0, 0, -1, -1) 2. `zeroSizeDirtyRegionWithinOpaqueRegion()`: When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) - emptyDirtyRegion(): When the dirty region rect is empty i.e. (0, 0, -1, -1) See `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` for definition of an empty rect. It seems logical to NOT to perform any rendering when dirty region is an empty rect. But current behavior is that when empty dirty region rect is passed to `root.getRenderRoot()`, it returns the root itself in NodePath. The commit#1 can correct/change this behavior to return an empty NodePath. Commit#1 is only for reference, the change is NGNode.java is a product change which is out of scope of this fix. I shall file a new JBS issue to handle this case. The test `emptyDirtyRegion1` is modified and another variant(`emptyDirtyRegion2`) of test is added. Additionally a new similar test (`invalidDirtyRegionOutsideOpaqueRegion`) is also included which passes an invalid rect. I think the behavior of this case should also be same as that of empty rect. All these three tests shall be ignored using the new JBS. - zeroSizeDirtyRegionWithinOpaqueRegion(): When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) The dirty rect has 0 width and height but from the methods `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` we can infer that the rect(20, 20, 0, 0) is not an empty rect. (It may be considered as a dirty point). So if we consider this rect as a valid dirty region then the current behavior seems valid. I have added a couple more similar tests. ------------- Commit messages: - revert NGNode.java and ignore tests - test correction Changes: https://git.openjdk.java.net/jfx/pull/463/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=463&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234077 Stats: 48 lines in 1 file changed: 43 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/463.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/463/head:pull/463 PR: https://git.openjdk.java.net/jfx/pull/463 From aghaisas at openjdk.java.net Fri Apr 16 10:06:41 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 16 Apr 2021 10:06:41 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v3] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 09:00:19 GMT, Johan Vos wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 237: > 235: * the entire width/height of the VirtualFlow. > 236: */ > 237: @Test This file still has few more unintentional @Test tag followed by newline changes. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 528: > 526: * Tests that changes to the vertical property will clear the maxPrefBreadth > 527: */ > 528: //@Test Is this @Test tag commented unintentionally? ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From aghaisas at openjdk.java.net Fri Apr 16 10:06:42 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 16 Apr 2021 10:06:42 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: <0bpoXatL6L-Wslgurv91sDMBwFMU43er8utBlXynIPI=.07361541-3de4-49ba-afb9-b3206a8524f0@github.com> References: <0bpoXatL6L-Wslgurv91sDMBwFMU43er8utBlXynIPI=.07361541-3de4-49ba-afb9-b3206a8524f0@github.com> Message-ID: On Fri, 16 Apr 2021 08:47:42 GMT, Johan Vos wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1315: >> >>> 1313: s1 = sb.getLayoutY(); >>> 1314: newDelta = newPosition - position; >>> 1315: System.err.println("s0 = "+s0+", s1 = "+s1); >> >> I suggest to comment out all System.err.println() calls from this loop. >> They might be useful while debugging individual failing test, but keeping them on for every test run will simply flood the log. >> Similar logs were fixed for stdout earlier. Please refer - https://bugs.openjdk.java.net/browse/JDK-8255497 > > System.err.println()s are removed now. I still see these printlns in the latest revision. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Fri Apr 16 10:45:18 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Apr 2021 10:45:18 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v4] In-Reply-To: References: Message-ID: > This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) > The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. > Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. > This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Process reviewer comments, uncomment commented test, remove stderr ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/398/files - new: https://git.openjdk.java.net/jfx/pull/398/files/91a82c08..29b682c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=398&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=398&range=02-03 Stats: 50 lines in 1 file changed: 0 ins; 22 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/398.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/398/head:pull/398 PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Fri Apr 16 10:45:22 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Apr 2021 10:45:22 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v3] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 10:03:07 GMT, Ajit Ghaisas wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Process reviewer comments > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 237: > >> 235: * the entire width/height of the VirtualFlow. >> 236: */ >> 237: @Test > > This file still has few more unintentional @Test tag followed by newline changes. I fixed those, except for the ones that have a // comment in between @Test and the method. (Those were already there) ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From aghaisas at openjdk.java.net Fri Apr 16 11:32:42 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 16 Apr 2021 11:32:42 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v4] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 10:45:18 GMT, Johan Vos wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments, uncomment commented test, remove stderr Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From fastegal at openjdk.java.net Fri Apr 16 12:14:35 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 16 Apr 2021 12:14:35 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v4] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 11:58:14 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > Added checks, whether the correction ammount of editStart/cancel events are triggered > > > curious: do you understand the dependency of update sequence (updateEditing relative to updateFocus)? > > [... ] > > * `focusIndex == editingIndex` and calling updateEditing after updateFocus - all offEditing transitions are failing due to corrupting list editing state > > > TableCell does the latter and has no dependency on focus state - at least none I can see ;) actually, TableCell behavior only _appears_ to not depend on focus state .. because the cell is never moved into focused state if its TableRow is null ;) With a setup including updateTableRow, its focused state is updated to false when moving off the editing row which triggers the listener in cell which cancels the edit ... so we basically have the same behavior as in ListCell. To keep the tests focused on editing (vs a mix-in of other properties), we should probably (?) setup focus to -1 always. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From kcr at openjdk.java.net Fri Apr 16 12:23:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 12:23:41 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v2] In-Reply-To: <0bpoXatL6L-Wslgurv91sDMBwFMU43er8utBlXynIPI=.07361541-3de4-49ba-afb9-b3206a8524f0@github.com> References: <0bpoXatL6L-Wslgurv91sDMBwFMU43er8utBlXynIPI=.07361541-3de4-49ba-afb9-b3206a8524f0@github.com> Message-ID: On Fri, 16 Apr 2021 08:46:49 GMT, Johan Vos wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1305: >> >>> 1303: // Otherwise, our goal is to leave the index of the cell at the >>> 1304: // top consistent, with the same translation etc. >>> 1305: if (position != 0 && position != 1 && (currentIndex >= cellCount)) { >> >> Comparing a double for equality or inequality is not the best coding practice. Anyway, I see this pattern throughout this file. We can live with it for now. > > The comparison was already in the code. I agree though it is brittle in general, although it can probably be proved that in this case, the value of position will never be e.g. 1+\delta with \delta as small as possible. > But it would be good practice for a follow-up issue to remove the equality checks on doubles in this file (and others). I agree that this shouldn't be changed as part of this fix, since it is preexisting. Filing one or more follow-on issues to address this more globally seems good. ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From kcr at openjdk.java.net Fri Apr 16 12:39:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 12:39:45 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v4] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 10:45:18 GMT, Johan Vos wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments, uncomment commented test, remove stderr Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From jvos at openjdk.java.net Fri Apr 16 13:41:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 16 Apr 2021 13:41:41 GMT Subject: Integrated: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:21:28 GMT, Johan Vos wrote: > This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) > The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. > Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. > This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. This pull request has now been integrated. Changeset: 8e547571 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/8e547571 Stats: 570 lines in 6 files changed: 427 ins; 92 del; 51 mod 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From kcr at openjdk.java.net Fri Apr 16 14:13:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 14:13:38 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: <21vOYZjjfkTmL0qpbbx3dFV5Yagql3-Uh2o9pyAL594=.d20c3d60-62cf-44d8-b6d8-bb88198450ba@github.com> On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. A non-debug build crashes for me on startup in the `com.sun.webkit.WebPage.twkCreatePage` method on both Windows and Mac. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/461 From swpalmer at gmail.com Fri Apr 16 14:28:50 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 16 Apr 2021 10:28:50 -0400 Subject: [External] : Re: Consistent baseline layout algorithm In-Reply-To: References: Message-ID: ? I've changed the default alignment for Label to TOP_LEFT (the default alignment of the base class Labeled is CENTER_LEFT).? How can you do that without breaking things? Even though it may be uncommon to set minHeight or prefHeight, that isn?t the point. It still breaks existing code. Scott > On Apr 16, 2021, at 12:48 AM, Michael Strau? wrote: > > ?I've learned a few new things while working on the proposed new layout > algorithm, and added a few new APIs: > > > 1. A central concept of the new algorithm was the notion of a > text-baseline node, indicated by Node::isTextBaseline(). I've come to > realize that this property should percolate upwards in the scene > graph: if a node has a text-baseline, the node's parent should also be > considered to have a text-baseline. Adding this new behavior works > surprisingly well and produces very intuitive layout results. > > > 2. The default behavior of all layout containers is to pick the first > text-baseline child to derive their own baseline offset. I've added > Node::prefBaselineProperty(), which makes it possible to override this > default selection: layout containers now pick the first child that > reports Node::isPrefBaseline(), and only if there is no such child, > they fall back to Node::isTextBaseline(). Developers can use this > property to fine-tune their baseline layouts. > > > 3. Optimization: Controls that contain text will often consist of a > container of some sort and a javafx.scene.text.Text node within it. > Computing the baseline offset of such a control is very easy with the > new layout algorithm: > > public double getBaselineOffset() { > return text.getLayoutBounds().getMinY() + text.getLayoutY() + > text.getBaselineOffset(); > } > > This works because changing text.layoutY will automatically schedule > another layout pass for all of its parents. Re-layouting all parents > is necessary because changing layoutY can change the effective > baseline offset, and changing the baseline offset of any node can have > layout implications on any of its parents. > > However, when we consider the Label control (which is probably among > the most commonly used controls), this can be a bit excessive. Label > controls are often used to display pure text, and as such, we can > often "know" the baseline offset without actually needing to schedule > a second layout pass. This assumption is only correct if the text > within the Label is top-aligned (because if it isn't, the Label > baseline offset can not be known in advance of an actual layout pass). > > To leverage this assumption, I've changed the default alignment for > Label to TOP_LEFT (the default alignment of the base class Labeled is > CENTER_LEFT). In most cases, there will be no visual difference > anyway, because I imagine Label controls will seldomly be set to a > minHeight or prefHeight. > > This specific scenario will enable an optimization where the first > layout pass of Label will not schedule a second layout pass. It might > be possible to find more such scenarios that can benefit from > fast-path optimizations. > > > 4. In order to get a better understanding of the layout process, I > added additional logging to track layout passes. Then I compared the > current algorithm with the new algorithm by tracking the initial > layout after starting a sample program (i.e. all layout activity until > the first frame is rendered). In the following log, "cumulative layout > passes" means how often layoutChildren() has been invoked on any of > the scene graph nodes. The actual log output includes a tree > visualization of the entire scene graph that is being layouted, which > I've removed for the sake or brevity. > > Current algorithm log output: > INFO: Layouting VBox (triggered by scene out-of-pulse), cumulative > layout passes: 49 > INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 43 > INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 0 > > New algorithm log output: > INFO: Layouting VBox (triggered by scene out-of-pulse), cumulative > layout passes: 86 > INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 19 > > A major difference is that the current algorithm will often leave the > scene graph in a 'dirty' layout state after running a complete layout > cycle, which necessitates another layout cycle as part of the next > pulse. The new algorithm, however, leaves the scene graph in a clean > layout state after a complete cycle, which takes more work at first, > but saves work that would otherwise be done in the next pulse. > > > 5. Since the new layout algorithm will leave the scene graph in a > clean state, it is not necessary to repeatedly layout the same thing > (like in Node::doLayoutPass()). Cases like these should be identified > and may be changed to single layout invocations. > > > Overall, I think there's good reason to assume that the proposed > algorithm works and that it produces consistent results for > application developers. At this point it would be useful to know > whether or not to continue with the effort. From kcr at openjdk.java.net Fri Apr 16 14:55:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 14:55:39 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: <21vOYZjjfkTmL0qpbbx3dFV5Yagql3-Uh2o9pyAL594=.d20c3d60-62cf-44d8-b6d8-bb88198450ba@github.com> References: <21vOYZjjfkTmL0qpbbx3dFV5Yagql3-Uh2o9pyAL594=.d20c3d60-62cf-44d8-b6d8-bb88198450ba@github.com> Message-ID: On Fri, 16 Apr 2021 14:10:48 GMT, Kevin Rushforth wrote: > A non-debug build crashes for me on startup in the `com.sun.webkit.WebPage.twkCreatePage` method on both Windows and Mac. Never mind. This was a build error on my part. I've correct my mistake and will rerun the test. Sorry for the noise. ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From michaelstrau2 at gmail.com Fri Apr 16 15:58:50 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 16 Apr 2021 17:58:50 +0200 Subject: [External] : Re: Consistent baseline layout algorithm In-Reply-To: References: Message-ID: That's true, and it also seems like outside of synthetic tests, the benefit from this optimization diminishes in larger scene graphs. So I will revert this change. Am Fr., 16. Apr. 2021 um 16:28 Uhr schrieb Scott Palmer : > > ? I've changed the default alignment for > Label to TOP_LEFT (the default alignment of the base class Labeled is > CENTER_LEFT).? > > How can you do that without breaking things? Even though it may be uncommon to set minHeight or prefHeight, that isn?t the point. It still breaks existing code. > > Scott From kevin.rushforth at oracle.com Fri Apr 16 17:08:19 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Apr 2021 10:08:19 -0700 Subject: [External] : Re: Consistent baseline layout algorithm In-Reply-To: References: Message-ID: <7aee5cfa-6fb4-1802-21dc-307f05ed6955@oracle.com> Good, since these are the sort of behavioral changes we almost always avoid. That change in the default behavior likely would not have been approved. As for the rest, I'll need some time to fully understand the impact of the proposed behavior for propagating isTextBaseline up the tree, and how that interacts with prefBaseline. It seem like it might be tricky to document and for app developers to understand all the ramifications. A couple questions: First, I presume you are only proposing to propagate isTextBaseline up the scene graph, meaning that all parents would report textBaseline == true if that parent is a text baseline node (e.g., Labeled, TextFlow) or if any descendant is? Second, given that isTextBaseline is not immutable, have you considered whether it should be a read-only property, so an application could listen for changes or bind to it? There would likely be a performance trade-off in making it a property. -- Kevin On 4/16/2021 8:58 AM, Michael Strau? wrote: > That's true, and it also seems like outside of synthetic tests, the > benefit from this optimization diminishes in larger scene graphs. So I > will revert this change. > > > Am Fr., 16. Apr. 2021 um 16:28 Uhr schrieb Scott Palmer : >> ? I've changed the default alignment for >> Label to TOP_LEFT (the default alignment of the base class Labeled is >> CENTER_LEFT).? >> >> How can you do that without breaking things? Even though it may be uncommon to set minHeight or prefHeight, that isn?t the point. It still breaks existing code. >> >> Scott From kcr at openjdk.java.net Fri Apr 16 17:25:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 17:25:35 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: <93ysfTs2Q0hKjcrZQcnLJlk5nB-Av3z5mKBKTOs5zo0=.66663432-af1a-434f-a1a2-aed9e7a07035@github.com> References: <93ysfTs2Q0hKjcrZQcnLJlk5nB-Av3z5mKBKTOs5zo0=.66663432-af1a-434f-a1a2-aed9e7a07035@github.com> Message-ID: On Fri, 16 Apr 2021 08:49:19 GMT, Arun Joseph wrote: >> modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp line 45: >> >>> 43: #elif OS(WINDOWS) >>> 44: static ThreadIdentifier mainThread { 0 }; >>> 45: #endif >> >> Both here and below, where the `isMainThread` is defined, assume that `UNIX` and `WINDOWS` are the only two options. I presume this is a valid assumption? > > I've tested in all three platforms. The two options are sufficient as Mac and Linux uses `pthread`. That's what I figured. It's only theoretical, in that if we ever add a platform that isn't one of `WINDOWS` or `UNIX` it wouldn't compile, but I imagine we have very many other places where that is also true. ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From kcr at openjdk.java.net Fri Apr 16 18:12:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 18:12:39 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. Tested on all three platforms. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/461 From kcr at openjdk.java.net Fri Apr 16 18:56:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 18:56:40 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v9] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 14:45:58 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changed description as suggested in review The fix and tests looks good, with one suggestion for the test (and a couple minor comments about formatting and one naming question) left inline. I'll review the CSR now, you can then move it to Finalized when you are ready. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 60: > 58: *

> 59: * Disposing removes all listeners added by this handler from all registered observables. > 60: * Minor: you can remove this extra blank line. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 66: > 64: > 65: @SuppressWarnings("rawtypes") > 66: private static final Consumer EMPTY_CONSUMER = e -> {}; Minor: remove extra space between `public` and `static`. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleHandlerTest.java line 51: > 49: * Test support of listChange listeners. > 50: */ > 51: public class LambdaMultipleHandlerTest { Would `LambdaMultipleListHandlerTest ` be a better name for this class? modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleHandlerTest.java line 211: > 209: WeakReference ref = > 210: new WeakReference<>(new LambdaMultiplePropertyChangeListenerHandler()); > 211: ref.get().registerListChangeListener(items, consumer); This is fragile. It is possible, although unlikely, that the referent could be GCed between its construction in the previous statement (after which it goes out of scope), and this statement. If this rare event happened, it would cause an NPE here. I recommend to keep a local reference to the referent and then set it to null after this (and before the `attemptGC`). modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleObservableHandlerTest.java line 217: > 215: WeakReference ref = > 216: new WeakReference<>(new LambdaMultiplePropertyChangeListenerHandler()); > 217: registerListener(ref.get(), p, consumer); Same comment as with previous test. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Fri Apr 16 19:06:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 19:06:39 GMT Subject: RFR: 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 Pending review by @johanvos ------------- PR: https://git.openjdk.java.net/jfx/pull/422 From kcr at openjdk.java.net Fri Apr 16 19:08:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 19:08:39 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] In-Reply-To: References: Message-ID: On Sun, 4 Apr 2021 16:36:27 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 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. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Fri Apr 16 19:04:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 19:04:40 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] In-Reply-To: References: Message-ID: On Sun, 4 Apr 2021 16:36:27 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 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. Pending review by @johanvos -- I bumped the number of reviewers, so he will have a change to review before it is approved. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Fri Apr 16 19:47:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 19:47:40 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v3] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: <486Y-4UqnxLcaebg0rVEsybD4X-E2DREqLk0FDGf3ak=.fc42df1e-58c0-4856-b9b4-fff3934a1c05@github.com> On Thu, 15 Apr 2021 16:43:08 GMT, Matthias Bl?sing wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Review fix: Use correct bug id Looks good. Tested on all three platforms. I verified (on both Mac and Linux) that the new test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/458 From arapte at openjdk.java.net Fri Apr 16 20:27:50 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 16 Apr 2021 20:27:50 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: <-3pQYfaFzDDDaxLFes5JSm93gRpdWWdSfbb_b1AcuVw=.b6a4a21f-7539-4bcc-b765-c0211fbb6149@github.com> On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction Provided few comments on documentation. Have to review and test the code. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 46: > 44: *

> 45: * The light cone is defined by 3 factors: an {@link #innerAngleProperty() inner angle}, an {@link #outerAngleProperty() > 46: * outer angle}, and a {@link #falloffProperty() falloff} factor. For a point whose angle to the light is {@code a}, if -> A {@code SpotLight} is a {@code PointLight} that radiates a cone of light in a specific direction. < p > The direction is defined by the {@link #directionProperty() direction} property. The light cone is defined by 3 properties: an {@link #innerAngleProperty() inner angle}, an {@link #outerAngleProperty() outer angle}, and a {@link #falloffProperty() falloff} property. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 49: > 47: * {@code a < innerAngle} then that point receives maximum illumination, if {@code a > outerAngle} then that point > 48: * receives no illumination, and if {@code innerAngle <= a <= outerAngle} then the illumination is determined by the > 49: * formula -> For a point whose direction vector from the source of light forms an angle {@code theta} with the direction of light, if {@code theta < innerAngle} then that point receives maximum illumination. if {@code theta > outerAngle} then that point receives no illumination. and if {@code innerAngle <= a <= outerAngle} then the illumination received by the point is determined by formula modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 55: > 53: * {@code falloff >= 0}; values outside either of these ranges can produce unexpected results. > 54: *

> 55: * Image of the Spotlight Should we have cone depicted in the diagram ? modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 76: > 74: > 75: { > 76: // To initialize the class helper at the beginning each constructor of this class Minor: missing of: // To initialize the class helper at the beginning **of** each constructor of this class modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 98: > 96: > 97: /** > 98: * The direction the spotlight is facing. The vector need not be normalized. -> The direction vector of the spotlight. The vector need not be normalized. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 130: > 128: * The angle of the spotlight's inner cone. Surfaces whose angle to the light's origin is less than this angle > 129: * receive the full light's intensity. At larger angles, the light intensity starts to drop. The valid range is > 130: * {@code 0 <= innerAngle <= outerAngle}; values outside of this range can produce unexpected results. We should use Point or vertex instead of word surface. Using Point would be consistent with description of class. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Fri Apr 16 20:27:51 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 16 Apr 2021 20:27:51 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <-3pQYfaFzDDDaxLFes5JSm93gRpdWWdSfbb_b1AcuVw=.b6a4a21f-7539-4bcc-b765-c0211fbb6149@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> <-3pQYfaFzDDDaxLFes5JSm93gRpdWWdSfbb_b1AcuVw=.b6a4a21f-7539-4bcc-b765-c0211fbb6149@github.com> Message-ID: On Fri, 16 Apr 2021 10:35:29 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Combined rotation and direction > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 46: > >> 44: *

>> 45: * The light cone is defined by 3 factors: an {@link #innerAngleProperty() inner angle}, an {@link #outerAngleProperty() >> 46: * outer angle}, and a {@link #falloffProperty() falloff} factor. For a point whose angle to the light is {@code a}, if > > -> > A {@code SpotLight} is a {@code PointLight} that radiates a cone of light in a specific direction. > < p > > The direction is defined by the {@link #directionProperty() direction} property. > The light cone is defined by 3 properties: an {@link #innerAngleProperty() inner angle}, an {@link #outerAngleProperty() outer angle}, and a {@link #falloffProperty() falloff} property. Also Will it be illustrative to mention these three properties using li tags with a statement that briefs the use of property. Something like, - {@link #innerAngleProperty() inner angle}: Angle of the inner cone where light intensity is always maximum. - {@link #outerAngleProperty() outer angle}: Angle of the outer cone where light intensity attenuates based on fallof. - {@link #falloffProperty() falloff}: The attenuation factor that controls the attenuation of light intensity from edge of inner cone to the edge of outer cone. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Fri Apr 16 22:18:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 22:18:37 GMT Subject: RFR: 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error [v4] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 09:19:00 GMT, Ambarish Rapte wrote: >> Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. >> >> Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. >> Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. >> - RegionBackgroundImageUITest.unalignedImage >> - RegionBackgroundFillUITest.testScenario2 >> - RegionBackgroundFillUITest.testScenario3 >> >> commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. >> >> One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. >> It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) >> >> This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. >> Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > skip test on mac that fails only on mac Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/344 From kcr at openjdk.java.net Fri Apr 16 22:23:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 22:23:40 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v4] In-Reply-To: References: Message-ID: <3Mhd9selU3ReJ9akKyLxMW5LW6cbO8BA2bhHk7ptHpw=.fcb38c57-ac3a-4705-bbd9-b1f969c54297@github.com> On Thu, 15 Apr 2021 17:37:08 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Revert back fix with CONVERTED_OS_ARCH and CONVERTED_TARGET_ARCH variables Thanks. Let's file a follow-on bug to refactor the parts of the logic that can be made platform independent, and also to rationalize `aarch64` vs `arm64` (the latter is needed on both Windows and macOS for some paths or compiler options, but the former is what we would like to use in the build logic for the name of the platform where we can). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/439 From kcr at openjdk.java.net Fri Apr 16 22:31:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 22:31:40 GMT Subject: RFR: 8234077: Evaluate ignored unit tests in RenderRootTest In-Reply-To: References: Message-ID: <7QXn5G1s0xR0D1_YLLSpHFnMq3CMjjqKkW7LW7a9jzU=.3c547dfe-6d29-43fa-a9bf-8be63bfa7f50@github.com> On Fri, 16 Apr 2021 09:25:47 GMT, Ambarish Rapte wrote: > These are 2 corner case test cases for getRenderRoot() method. > 1. `emptyDirtyRegion():` When the dirty region rect is empty i.e. (0, 0, -1, -1) > 2. `zeroSizeDirtyRegionWithinOpaqueRegion()`: When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) > > - emptyDirtyRegion(): When the dirty region rect is empty i.e. (0, 0, -1, -1) > See `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` for definition of an empty rect. It seems logical to NOT to perform any rendering when dirty region is an empty rect. But current behavior is that when empty dirty region rect is passed to `root.getRenderRoot()`, it returns the root itself in NodePath. > The commit#1 can correct/change this behavior to return an empty NodePath. Commit#1 is only for reference, the change is NGNode.java is a product change which is out of scope of this fix. I shall file a new JBS issue to handle this case. > The test `emptyDirtyRegion1` is modified and another variant(`emptyDirtyRegion2`) of test is added. Additionally a new similar test (`invalidDirtyRegionOutsideOpaqueRegion`) is also included which passes an invalid rect. I think the behavior of this case should also be same as that of empty rect. All these three tests shall be ignored using the new JBS. > > - zeroSizeDirtyRegionWithinOpaqueRegion(): When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) > The dirty rect has 0 width and height but from the methods `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` we can infer that the rect(20, 20, 0, 0) is not an empty rect. (It may be considered as a dirty point). So if we consider this rect as a valid dirty region then the current behavior seems valid. I have added a couple more similar tests. Yes, filing a new bug to evaluate case 1 seems like the best option. We might decide that is a product bug or we might end up deciding that the behavior is correct, in which case it would be a test bug (it seems at least possible that an empty bounds is used to mean "render the whole window", and if so, we would not want to make a change since it would cause a regression). ------------- PR: https://git.openjdk.java.net/jfx/pull/463 From almatvee at openjdk.java.net Sat Apr 17 01:43:57 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 17 Apr 2021 01:43:57 GMT Subject: RFR: 8259356: MediaPlayer's seek freezes video Message-ID: <1UozorcVngWaEbnrgXTUsUF4Xaj3891DHUH4nX-xyMM=.54760fb3-3ae6-4539-b576-6f82c498665b@github.com> This is regression (introduced) by JDK-8199527. JDK-8199527 added fix for HLS streams (unfortunately I was not able to find repro case and more details on why it was added) in gstappsink.c line 659-678 to store current caps which can be lost during seek/flush. However, this workaround broke code in gst_app_sink_render_common() line 939 which was restoring caps if they were flushed, since we set last_caps to non NULL value. Since code in gst_app_sink_render_common() did not work to propagate caps to sample our rendering code was dropping frames without caps. Fixed by setting caps on sample in HLS workaround code. ------------- Commit messages: - 8259356: MediaPlayer's seek freezes video Changes: https://git.openjdk.java.net/jfx/pull/464/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=464&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259356 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/464.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/464/head:pull/464 PR: https://git.openjdk.java.net/jfx/pull/464 From michaelstrau2 at gmail.com Sat Apr 17 03:01:41 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 17 Apr 2021 05:01:41 +0200 Subject: [External] : Re: Consistent baseline layout algorithm In-Reply-To: <7aee5cfa-6fb4-1802-21dc-307f05ed6955@oracle.com> References: <7aee5cfa-6fb4-1802-21dc-307f05ed6955@oracle.com> Message-ID: I've created a small sample app (a screenshot is available in the GitHub PR discussion at https://github.com/openjdk/jfx/pull/433), and it seems to me that, while understanding the intricacies of isTextBaseline and isPrefBaseline might be a bit tricky, from an application developer's perspective it seems to "just work" in most cases that I've tried so far. However, I think the documentation still needs to be improved when the concepts settle. As to your questions: it is true that isTextBaseline generally propagates up the scene graph. Parent::isTextBaseline() reports true if, when computing its own baseline offset, it selects a child that reports isTextBaseline()==true as the baseline source. However, even when text baseline children are available, the selected child might not be a text baseline node if prefBaseline=true was specified on a non-text child node to override the default selection. I think isTextBaseline could reasonably be a read-only property, the performance impact is probably negligible if the property is only initialized when it is actually accessed. Am Fr., 16. Apr. 2021 um 19:08 Uhr schrieb Kevin Rushforth : > > Good, since these are the sort of behavioral changes we almost always > avoid. That change in the default behavior likely would not have been > approved. > > As for the rest, I'll need some time to fully understand the impact of > the proposed behavior for propagating isTextBaseline up the tree, and > how that interacts with prefBaseline. It seem like it might be tricky to > document and for app developers to understand all the ramifications. > > A couple questions: First, I presume you are only proposing to propagate > isTextBaseline up the scene graph, meaning that all parents would report > textBaseline == true if that parent is a text baseline node (e.g., > Labeled, TextFlow) or if any descendant is? Second, given that > isTextBaseline is not immutable, have you considered whether it should > be a read-only property, so an application could listen for changes or > bind to it? There would likely be a performance trade-off in making it a > property. > > -- Kevin From nlisker at openjdk.java.net Sat Apr 17 04:00:38 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 17 Apr 2021 04:00:38 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: <4reDBbTAFF9VpqvSfOPzTkhPluQtquEzgP_NPxejaLY=.c3135270-c326-4ac2-a617-ef6c8ca8541f@github.com> On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction I'll fix the documentation once we establish how the light is rotated. I will need to add notes about the rotation transforms too. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From jvos at openjdk.java.net Sat Apr 17 11:38:46 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 17 Apr 2021 11:38:46 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v4] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 17:37:08 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Revert back fix with CONVERTED_OS_ARCH and CONVERTED_TARGET_ARCH variables I'll do a test in our CI. ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From fastegal at openjdk.java.net Sat Apr 17 13:48:23 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 17 Apr 2021 13:48:23 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v10] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: changed according to review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/7e31073a..99ffcc44 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=08-09 Stats: 12 lines in 3 files changed: 3 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Sat Apr 17 13:48:28 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 17 Apr 2021 13:48:28 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v9] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 12:57:30 GMT, Kevin Rushforth wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> changed description as suggested in review > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 60: > >> 58: *

>> 59: * Disposing removes all listeners added by this handler from all registered observables. >> 60: * > > Minor: you can remove this extra blank line. removed > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 66: > >> 64: >> 65: @SuppressWarnings("rawtypes") >> 66: private static final Consumer EMPTY_CONSUMER = e -> {}; > > Minor: remove extra space between `public` and `static`. removed > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleHandlerTest.java line 51: > >> 49: * Test support of listChange listeners. >> 50: */ >> 51: public class LambdaMultipleHandlerTest { > > Would `LambdaMultipleListHandlerTest ` be a better name for this class? yes - renamed :) > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleHandlerTest.java line 211: > >> 209: WeakReference ref = >> 210: new WeakReference<>(new LambdaMultiplePropertyChangeListenerHandler()); >> 211: ref.get().registerListChangeListener(items, consumer); > > This is fragile. It is possible, although unlikely, that the referent could be GCed between its construction in the previous statement (after which it goes out of scope), and this statement. If this rare event happened, it would cause an NPE here. I recommend to keep a local reference to the referent and then set it to null after this (and before the `attemptGC`). changed as suggested. I used a similar pattern in BehaviorMemoryTest - should I file a testbug to change it in the same way? > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleObservableHandlerTest.java line 217: > >> 215: WeakReference ref = >> 216: new WeakReference<>(new LambdaMultiplePropertyChangeListenerHandler()); >> 217: registerListener(ref.get(), p, consumer); > > Same comment as with previous test. changed ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Sat Apr 17 14:10:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Apr 2021 14:10:40 GMT Subject: RFR: 8259356: MediaPlayer's seek freezes video In-Reply-To: <1UozorcVngWaEbnrgXTUsUF4Xaj3891DHUH4nX-xyMM=.54760fb3-3ae6-4539-b576-6f82c498665b@github.com> References: <1UozorcVngWaEbnrgXTUsUF4Xaj3891DHUH4nX-xyMM=.54760fb3-3ae6-4539-b576-6f82c498665b@github.com> Message-ID: On Sat, 17 Apr 2021 01:39:17 GMT, Alexander Matveev wrote: > This is regression (introduced) by JDK-8199527. JDK-8199527 added fix for HLS streams (unfortunately I was not able to find repro case and more details on why it was added) in gstappsink.c line 659-678 to store current caps which can be lost during seek/flush. However, this workaround broke code in gst_app_sink_render_common() line 939 which was restoring caps if they were flushed, since we set last_caps to non NULL value. Since code in gst_app_sink_render_common() did not work to propagate caps to sample our rendering code was dropping frames without caps. Fixed by setting caps on sample in HLS workaround code. Looks good. I verified on both macOS and Windows that the seek problem is now fixed. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/464 From kcr at openjdk.java.net Sat Apr 17 14:26:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Apr 2021 14:26:39 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v9] In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 13:44:07 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleHandlerTest.java line 211: >> >>> 209: WeakReference ref = >>> 210: new WeakReference<>(new LambdaMultiplePropertyChangeListenerHandler()); >>> 211: ref.get().registerListChangeListener(items, consumer); >> >> This is fragile. It is possible, although unlikely, that the referent could be GCed between its construction in the previous statement (after which it goes out of scope), and this statement. If this rare event happened, it would cause an NPE here. I recommend to keep a local reference to the referent and then set it to null after this (and before the `attemptGC`). > > changed as suggested. I used a similar pattern in BehaviorMemoryTest - should I file a testbug to change it in the same way? Yes, please file a new bug (not high priority, since it is a corner case). I took a look and there are a few other controls tests that use this pattern as well (BehaviorCleanupTest, ListViewTest, TabPaneTest, SkinCleanupTest, SkinLabeledCleanupTest, SkinMemoryLeakTest), so the new bug could cover fixing this for all of them. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Sat Apr 17 14:32:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Apr 2021 14:32:42 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v10] In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 13:48:23 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changed according to review Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/409 From jvos at openjdk.java.net Sat Apr 17 15:51:34 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 17 Apr 2021 15:51:34 GMT Subject: RFR: 8259356: MediaPlayer's seek freezes video In-Reply-To: <1UozorcVngWaEbnrgXTUsUF4Xaj3891DHUH4nX-xyMM=.54760fb3-3ae6-4539-b576-6f82c498665b@github.com> References: <1UozorcVngWaEbnrgXTUsUF4Xaj3891DHUH4nX-xyMM=.54760fb3-3ae6-4539-b576-6f82c498665b@github.com> Message-ID: On Sat, 17 Apr 2021 01:39:17 GMT, Alexander Matveev wrote: > This is regression (introduced) by JDK-8199527. JDK-8199527 added fix for HLS streams (unfortunately I was not able to find repro case and more details on why it was added) in gstappsink.c line 659-678 to store current caps which can be lost during seek/flush. However, this workaround broke code in gst_app_sink_render_common() line 939 which was restoring caps if they were flushed, since we set last_caps to non NULL value. Since code in gst_app_sink_render_common() did not work to propagate caps to sample our rendering code was dropping frames without caps. Fixed by setting caps on sample in HLS workaround code. Marked as reviewed by jvos (Reviewer). Verified on Linux and MacOS, looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/464 From jgneff at openjdk.java.net Sat Apr 17 17:29:34 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 17 Apr 2021 17:29:34 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3] In-Reply-To: References: Message-ID: On Sun, 4 Apr 2021 16:36:27 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 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. > As an alternative, you could close that PR ... and list both issues in this PR ... I prefer to keep them separate because they have distinct attributions and descriptions. Few developers will read #422 if we merge them. They also pose distinct questions for reviewers. The implicit question in #422 is, should we define an external environment variable or just remove the build timestamp entirely? The implicit question in this pull request is, given the environment variable, should we also use it as a flag for reproducible builds? Furthermore, which sources of non-determinism should be removed unconditionally, and which should be conditional on the flag? I chose conservative answers to those questions in my changes, but I'm open to other suggestions. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Sat Apr 17 21:37:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 17 Apr 2021 21:37:36 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v3] In-Reply-To: <-zblqH3jywX3eAs1LEDakYqCn_9_aKYjpHwxsKDUGxk=.f427216c-509d-478b-bf00-341f8c0207df@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <-zblqH3jywX3eAs1LEDakYqCn_9_aKYjpHwxsKDUGxk=.f427216c-509d-478b-bf00-341f8c0207df@github.com> Message-ID: On Wed, 14 Apr 2021 04:32:29 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Add dependencies for media and WebKit libraries > - Merge branch 'master' into dependency-verification > - Add a README file and update 'UPDATING-lucene.txt' > - 8264010: Add Gradle dependency verification Yeah, I noticed that about the names, too. Not sure it's worth worrying about, although it is a little odd. Btw, I have the final list of internal downloads that I'll pass on to you, so you can add them to the PR. I've done a CI build with this version of `verification.xml` and it passes. You can see the diffs here: kevinrushforth/jfx at ce1aefaae76c5197008ab6a7d09ae89b5deb8ba4 ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From nlisker at openjdk.java.net Sat Apr 17 23:11:34 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 17 Apr 2021 23:11:34 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v13] In-Reply-To: <7NGYErv7OjjacG77a29hytbGYOYkfoUh4eFn3hr2kmI=.3337f1a2-e9a8-4699-b22b-5c287e0d1d21@github.com> References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> <9WCsJnl_NmH-mSpEw-xx-r9pgd-2wg4dVW-my5eQo5U=.4cbe5887-33a4-4d07-9793-e0fe2581c85e@github.com> <7NGYErv7OjjacG77a29hytbGYOYkfoUh4eF n3hr2kmI=.3337f1a2-e9a8-4699-b22b-5c287e0d1d21@github.com> Message-ID: On Fri, 9 Apr 2021 20:50:55 GMT, Kevin Rushforth wrote: >> I will check the range issue on (non-VM) Linux. I don't have a Mac, so not sure what to do if Linux checks out. >> >>> As for setting the spot light direction using rotation, I think there are three API choices, and I don't like the third since it is inconsistent, so really two choices. >> >> The current patch uses approach 3, and I posted a couple of replacement files in the comment above that use approach 1. If you and Ambarish can compare these, we will have a better idea on what to do. I also think that either 1 or 2 are the best choices, so if you find approach 1 too confusing or 3 very convenient, I will merge them into approach 2. > >> The current patch uses approach 3 > > Right. > >> and I posted a couple of replacement files in the comment above that use approach 1. > > I ran it, but didn't spend any time looking at how convenient it would be from an API point of view. > >> If you and Ambarish can compare these, we will have a better idea on what to do. I also think that either 1 or 2 are the best choices, so if you find approach 1 too confusing or 3 very convenient, I will merge them into approach 2. > > I'm sort of leaning towards 2 (as you could probably guess from my comments above). I'd like to hear from Ambarish as well. @kevinrushforth I have just tested on Ubuntu 20 and I don't see any issue (at least not something that's different than Windows). If it's an issue with the range property, does it happen with point lights too? Does it happen before this patch (but with the attenuation patch)? Also, does it happen when there is only 1 light turned on or also more (there are different files for the number of lights)? If you can give the exact values for the properties that cause this I will be able to try a direct reproduction. I tested the animating sphere. I suggest to use the Boxes models since they are not animated and the range is constant. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From jgneff at openjdk.java.net Sat Apr 17 23:17:04 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 17 Apr 2021 23:17:04 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v4] In-Reply-To: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: > This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: > > * [JDK-8262236][1]: Configure Gradle checksum verification > * [JDK-8263204][2]: Add Gradle Wrapper Validation Action > * [JDK-8264010][3]: Add Gradle dependency verification > > "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: > > * [C?dric Champeau at Devoxx][6] in November 2019 > * [Louis Jacomet at Jfokus][7] in February 2020 > > "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 > [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf > [6]: https://youtu.be/GWGNp3a3hpk > [7]: https://youtu.be/bwiafNatsf0 John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Add dependencies for internal builds at Oracle ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/437/files - new: https://git.openjdk.java.net/jfx/pull/437/files/7609914a..b0435b29 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=437&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=437&range=02-03 Stats: 45 lines in 1 file changed: 45 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/437/head:pull/437 PR: https://git.openjdk.java.net/jfx/pull/437 From jgneff at openjdk.java.net Sat Apr 17 23:24:36 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 17 Apr 2021 23:24:36 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v4] In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: On Sat, 17 Apr 2021 23:17:04 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Add dependencies for internal builds at Oracle Thanks, Kevin. I added your list to the file and ran just the Linux build followed by tests, all successful: $ gradle -PCONF=Release -PPROMOTED_BUILD_NUMBER=7 \ -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx \ -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true \ sdk jmods javadoc test ... BUILD SUCCESSFUL in 4m 26s 224 actionable tasks: 93 executed, 131 up-to-date ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From fastegal at openjdk.java.net Sun Apr 18 10:26:53 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 18 Apr 2021 10:26:53 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v9] In-Reply-To: References: Message-ID: <68KfhQP7bLEkdAbIIr0T7JeXr6shFw3xr6qJkVR4bC0=.01e58969-9fe2-49f3-b520-b733796d07c0@github.com> On Sat, 17 Apr 2021 14:23:32 GMT, Kevin Rushforth wrote: >> changed as suggested. I used a similar pattern in BehaviorMemoryTest - should I file a testbug to change it in the same way? > > Yes, please file a new bug (not high priority, since it is a corner case). I took a look and there are a few other controls tests that use this pattern as well (BehaviorCleanupTest, ListViewTest, TabPaneTest, SkinCleanupTest, SkinLabeledCleanupTest, SkinMemoryLeakTest), so the new bug could cover fixing this for all of them. done and taken (should cleanup my own dirt ;) [JDK-8265406](https://bugs.openjdk.java.net/browse/JDK-8265406) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From jvos at openjdk.java.net Sun Apr 18 10:57:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 18 Apr 2021 10:57:08 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 26 Feb 2021 16:47:55 GMT, John Neffenger wrote: > > What is the expected behavior? > > I think that's why I never raised the issue. I let the bug train me to avoid it! For better or for worse, I think the only answer to your question is whatever Android and iOS do. I agree it's good looking at how it is done on other platforms. It's still not clear to me (as in: I can't put it in an algorithm): if you say that the button is "fired" only when the release location is very close to the touch-start location, then it occurs to me that somehow there could have been other events that caused the location to change slightly, but don't these events lead to DRAG events? That would then contradict the second statement: whenever a drag is detected, there is no button-fired action at all. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From arapte at openjdk.java.net Sun Apr 18 17:31:43 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sun, 18 Apr 2021 17:31:43 GMT Subject: Integrated: 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error In-Reply-To: References: Message-ID: <1RVEuiZ0F3Y-m_PEyFQQsnucTGEuhiLYZpD1_50z8CM=.49ec814c-d585-4409-a2b4-6e38a63b6531@github.com> On Fri, 30 Oct 2020 16:04:51 GMT, Ambarish Rapte wrote: > Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. > > Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. > Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. > - RegionBackgroundImageUITest.unalignedImage > - RegionBackgroundFillUITest.testScenario2 > - RegionBackgroundFillUITest.testScenario3 > > commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. > > One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. > It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) > > This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. > Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). This pull request has now been integrated. Changeset: 56f2e17f Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/56f2e17f Stats: 70 lines in 3 files changed: 65 ins; 3 del; 2 mod 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/344 From michaelstrau2 at gmail.com Sun Apr 18 17:34:36 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 18 Apr 2021 19:34:36 +0200 Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: Android exposes the "touch slop" value, which is the distance which a touch pointer has to travel before it is considered to be a drag event. It is important to also consider the case where a touch pointer wanders off to another location, and then without releasing, returns back to the start location. In this case, you would not want to interpret that as a "click" event. See: https://developer.android.com/reference/android/view/ViewConfiguration.html#getScaledTouchSlop() Am So., 18. Apr. 2021 um 12:57 Uhr schrieb Johan Vos : > > I agree it's good looking at how it is done on other platforms. It's still not clear to me (as in: I can't put it in an algorithm): if you say that the button is "fired" only when the release location is very close to the touch-start location, then it occurs to me that somehow there could have been other events that caused the location to change slightly, but don't these events lead to DRAG events? > That would then contradict the second statement: whenever a drag is detected, there is no button-fired action at all. > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/406 From aghaisas at openjdk.java.net Mon Apr 19 13:05:03 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 19 Apr 2021 13:05:03 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest Message-ID: This PR enables ignored unit tests from MenuItemTest and fixes them. 4 ignored tests are fixed. 2 ignored tests are removed. 2 new tests are added. **Before fix :** total tests = 89 failures = 0 ignored tests = 6 **After fix :** total tests = 89 failures = 0 ignored tests = 0 ------------- Commit messages: - add missed @Test tag - fix ignored unit tests Changes: https://git.openjdk.java.net/jfx/pull/466/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=466&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265439 Stats: 41 lines in 1 file changed: 16 ins; 18 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/466.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/466/head:pull/466 PR: https://git.openjdk.java.net/jfx/pull/466 From kcr at openjdk.java.net Mon Apr 19 13:53:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 19 Apr 2021 13:53:43 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v4] In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: <0Fx08zTmi_kzdVMxLsetLApO1WvJEy5JuY00tiP0UcQ=.0b29a6ba-092a-4c0c-b292-0cd90ca42f19@github.com> On Sat, 17 Apr 2021 23:17:04 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Add dependencies for internal builds at Oracle Looks good, with one comment on the new `README.txt` file. gradle/README.txt line 10: > 8: dependency verification file as follows: > 9: > 10: $ gradle --write-verification-metadata sha256 help This isn't sufficient for many of the dependencies. Gradle won't try to download external dependencies until the point they are used. For example: the `junit` dependency is downloaded only when running `gradle test`, the icu data dependency is downloaded only when building the sdk with `-PCOMPILE_WEBKIT=true`, the libav media libraries (for Linux) are downloaded only when building the sdk with `-PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true`, etc. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From kcr at openjdk.java.net Mon Apr 19 13:58:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 19 Apr 2021 13:58:40 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 12:51:06 GMT, Ajit Ghaisas wrote: > This PR enables ignored unit tests from MenuItemTest and fixes them. > 4 ignored tests are fixed. > 2 ignored tests are removed. > 2 new tests are added. > > **Before fix :** > total tests = 89 > failures = 0 > ignored tests = 6 > > **After fix :** > total tests = 89 > failures = 0 > ignored tests = 0 It looks like you concluded that the implementation is correct, and that the ignored tests were making bad assumptions. Can you add your evaluation to this PR explaining why the tests are incorrect? ------------- PR: https://git.openjdk.java.net/jfx/pull/466 From ajoseph at openjdk.java.net Mon Apr 19 14:28:40 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 19 Apr 2021 14:28:40 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v3] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Thu, 15 Apr 2021 16:43:08 GMT, Matthias Bl?sing wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Review fix: Use correct bug id The test and changes looks good. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/458 From kcr at openjdk.java.net Mon Apr 19 14:45:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 19 Apr 2021 14:45:39 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Mon, 15 Mar 2021 09:11:41 GMT, Robert Lichtenberger wrote: >> Reverting to the old way of showing the context menu but with application >> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct >> size measurement of the menu. > > Yes I can try to look into this. > > On 3/12/21 2:59 PM, Kevin Rushforth wrote: >> >> This fixes the bug in question, although I see a slight regression in >> behavior on Windows with 125% pixel scaling (it doesn't reproduce with >> any other scaling value that I tried). With the original test case for >> JDK-8228363 , and >> |TOP| as the value of |side|, the initial menu is positioned slightly >> lower (by a few pixels) than it should be. See the attached image. It >> is correct the second and subsequent times the context menu is opened. >> >> Given that this new bug only happens with 125% scaling, it seems >> likely that it is a preexisting bug, and this fix merely exposes it. >> Can you take a look at this? If it is preexisting, then we should file >> a follow-on bug for this. >> >> ContextMenu-125 >> >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> . >> @effad have you had a chance to look at the rendering issues with 125% HiDPI scaling? ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From rlichten at openjdk.java.net Mon Apr 19 14:51:37 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 19 Apr 2021 14:51:37 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Mon, 15 Mar 2021 09:11:41 GMT, Robert Lichtenberger wrote: >> Reverting to the old way of showing the context menu but with application >> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct >> size measurement of the menu. > > Yes I can try to look into this. > > On 3/12/21 2:59 PM, Kevin Rushforth wrote: >> >> This fixes the bug in question, although I see a slight regression in >> behavior on Windows with 125% pixel scaling (it doesn't reproduce with >> any other scaling value that I tried). With the original test case for >> JDK-8228363 , and >> |TOP| as the value of |side|, the initial menu is positioned slightly >> lower (by a few pixels) than it should be. See the attached image. It >> is correct the second and subsequent times the context menu is opened. >> >> Given that this new bug only happens with 125% scaling, it seems >> likely that it is a preexisting bug, and this fix merely exposes it. >> Can you take a look at this? If it is preexisting, then we should file >> a follow-on bug for this. >> >> ContextMenu-125 >> >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> . >> > @effad have you had a chance to look at the rendering issues with 125% HiDPI scaling? Unfortunately no, not yet. I had some troubles setting up the Windows build and a lot of other stuff to do. But I will try to get things going this wednesday. ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From github.com+1519324+primosk at openjdk.java.net Mon Apr 19 15:28:41 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Mon, 19 Apr 2021 15:28:41 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. A production build using this fix doesn't solve it. Application still freezes. We will provide you with updated thread dump generated from debug build including this fix (and with assertions disabled) in the following days. ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From aghaisas at openjdk.java.net Mon Apr 19 16:59:40 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 19 Apr 2021 16:59:40 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 12:51:06 GMT, Ajit Ghaisas wrote: > This PR enables ignored unit tests from MenuItemTest and fixes them. > 4 ignored tests are fixed. > 2 ignored tests are removed. > 2 new tests are added. > > **Before fix :** > total tests = 89 > failures = 0 > ignored tests = 6 > > **After fix :** > total tests = 89 > failures = 0 > ignored tests = 0 modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 240: > 238: @Ignore // calling textProperty will no ensure text value is non null > 239: @Test public void unsetTextButNotNull() { > 240: MenuItem mi2 = new MenuItem(); Test was incorrect. The value of the 'text' property is not set and asserting on not null is incorrect. modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 287: > 285: @Ignore // Again, calling graphicPropery() is not ensuring a non null graphic > 286: // node. > 287: @Test public void unsetGraphicButNotNull() { Test was incorrect. The value of the 'graphic' property is not set and asserting on not null is incorrect. modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 410: > 408: > 409: @Test(expected=NullPointerException.class) > 410: public void setSpecifiedAccelerator_nullKeyCombination1() { Constructing KeyCodeCombination with a null KeyCode & constructing a KeyCharacterCombination with null key character results in NullPointerException as present in KeyCombinationTest.java. These tests were ignored with a comment on similar lines. I have enabled them and added expected NullPointerException. modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 426: > 424: > 425: @Test public void setSpecifiedAccelerator1() { > 426: Modifier[] modifierArray = {}; Added a test case for valid KeyCodeCombination. modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 432: > 430: } > 431: > 432: @Test public void setSpecifiedAccelerator2() { Added a test case for valid KeyCharacterCombination. modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 458: > 456: > 457: @Test public void acceleratorCanBeBound() { > 458: KeyCombination kc = new KeyCharacterCombination("A", KeyCombination.ALT_DOWN); Corrected the test case by creating a valid KeyCombination. modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 464: > 462: } > 463: > 464: @Test public void getUnspecifiedMnemonicParsing() { Test was incorrect. I have corrected it. Default value of mnemonicParsing property of MenuItem is true. ------------- PR: https://git.openjdk.java.net/jfx/pull/466 From kcr at openjdk.java.net Mon Apr 19 17:50:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 19 Apr 2021 17:50:40 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 12:51:06 GMT, Ajit Ghaisas wrote: > This PR enables ignored unit tests from MenuItemTest and fixes them. > 4 ignored tests are fixed. > 2 ignored tests are removed. > 2 new tests are added. > > **Before fix :** > total tests = 89 > failures = 0 > ignored tests = 6 > > **After fix :** > total tests = 89 > failures = 0 > ignored tests = 0 Thanks for the evaluation. I only have one remaining question on the tests that now expect NPE. ------------- PR: https://git.openjdk.java.net/jfx/pull/466 From kcr at openjdk.java.net Mon Apr 19 17:50:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 19 Apr 2021 17:50:41 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 16:48:07 GMT, Ajit Ghaisas wrote: >> This PR enables ignored unit tests from MenuItemTest and fixes them. >> 4 ignored tests are fixed. >> 2 ignored tests are removed. >> 2 new tests are added. >> >> **Before fix :** >> total tests = 89 >> failures = 0 >> ignored tests = 6 >> >> **After fix :** >> total tests = 89 >> failures = 0 >> ignored tests = 0 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 410: > >> 408: >> 409: @Test(expected=NullPointerException.class) >> 410: public void setSpecifiedAccelerator_nullKeyCombination1() { > > Constructing KeyCodeCombination with a null KeyCode & constructing a KeyCharacterCombination with null key character results in NullPointerException as present in KeyCombinationTest.java. > > These tests were ignored with a comment on similar lines. I have enabled them and added expected NullPointerException. Where is the NPE thrown? I see that your change makes the test pass, but if it never gets to the `setAccelerator` call or the `assertEquals` statements maybe you could remove them? ------------- PR: https://git.openjdk.java.net/jfx/pull/466 From almatvee at openjdk.java.net Mon Apr 19 18:07:57 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 19 Apr 2021 18:07:57 GMT Subject: Integrated: 8259356: MediaPlayer's seek freezes video In-Reply-To: <1UozorcVngWaEbnrgXTUsUF4Xaj3891DHUH4nX-xyMM=.54760fb3-3ae6-4539-b576-6f82c498665b@github.com> References: <1UozorcVngWaEbnrgXTUsUF4Xaj3891DHUH4nX-xyMM=.54760fb3-3ae6-4539-b576-6f82c498665b@github.com> Message-ID: On Sat, 17 Apr 2021 01:39:17 GMT, Alexander Matveev wrote: > This is regression (introduced) by JDK-8199527. JDK-8199527 added fix for HLS streams (unfortunately I was not able to find repro case and more details on why it was added) in gstappsink.c line 659-678 to store current caps which can be lost during seek/flush. However, this workaround broke code in gst_app_sink_render_common() line 939 which was restoring caps if they were flushed, since we set last_caps to non NULL value. Since code in gst_app_sink_render_common() did not work to propagate caps to sample our rendering code was dropping frames without caps. Fixed by setting caps on sample in HLS workaround code. This pull request has now been integrated. Changeset: a6835580 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/a6835580 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8259356: MediaPlayer's seek freezes video Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/464 From github.com+2179736+matthiasblaesing at openjdk.java.net Mon Apr 19 18:30:04 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Mon, 19 Apr 2021 18:30:04 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v3] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Mon, 19 Apr 2021 14:25:36 GMT, Arun Joseph wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix: Use correct bug id > > The test and changes looks good. @arun-Joseph @kevinrushforth thank you both for review. Would one of you be kind enough to sponsor this change set? Thank you. ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From jvos at openjdk.java.net Mon Apr 19 18:49:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 19 Apr 2021 18:49:08 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v3] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Thu, 15 Apr 2021 16:43:08 GMT, Matthias Bl?sing wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Review fix: Use correct bug id Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From github.com+2179736+matthiasblaesing at openjdk.java.net Mon Apr 19 18:49:10 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Mon, 19 Apr 2021 18:49:10 GMT Subject: Integrated: 8264990: WebEngine crashes with segfault when not loaded through system classloader In-Reply-To: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> Message-ID: On Thu, 8 Apr 2021 06:58:14 GMT, Matthias Bl?sing wrote: > The functions from FileSystemJava are called from different threads the > root problem manifests because the JNI FindClass function behaves > differently when called from a context that is the ancestor of a java > frame compared to when called in isolation. > > A segmentation fault is observed when local storage of a webview is > accessed. At that time a new native thread is spun up and that sets up > the local storage, by calling into the JVM via > WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is > invoked to get a referenc to the java implementation of the FileSystem. > As this is is called from a new native thread (no java context > available), JNI uses the system classloader to locate the class. This > fails if the JavaFX modules are not on the boot module/class path. > > Instead on relying on fetching the class reference everytime it is > needed, this change fetches it once when the JavaFX library is loaded > and stores it in the WTF namespace. > > In addition to this it was observed, that there is no attachment to the > JVM done when calling into the filesystem. No fault was observed, but > the JNI specs indicate, that the JNIEnv interface is only valid when > attached. This pull request has now been integrated. Changeset: e02cee96 Author: Matthias Bl?sing Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/e02cee96 Stats: 342 lines in 7 files changed: 315 ins; 7 del; 20 mod 8264990: WebEngine crashes with segfault when not loaded through system classloader Reviewed-by: kcr, ajoseph, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From jvos at openjdk.java.net Mon Apr 19 20:02:32 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 19 Apr 2021 20:02:32 GMT Subject: RFR: 8265469: Allow to build media and webkit for Linux-AArch64 Message-ID: Changes that allow to build linux configuration on Linux AArch64 This PR introduces an `IS_AARCH64` parameter in build.gradle. This PR already contains the change from PR #465 so if this one gets integrated, that change needs to removed from this PR. ------------- Commit messages: - Changes that allow to build linux configuration on Linux AArch64 Changes: https://git.openjdk.java.net/jfx/pull/467/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=467&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265469 Stats: 33 lines in 4 files changed: 20 ins; 3 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/467.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/467/head:pull/467 PR: https://git.openjdk.java.net/jfx/pull/467 From johan.vos at gluonhq.com Mon Apr 19 20:06:50 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 19 Apr 2021 22:06:50 +0200 Subject: AArch64 naming conventions Message-ID: Recently, we introduced the option (or are introducing the options) to build OpenJFX for 64-bit ARM CPU's on Mac, Windows and Linux. However, those 3 platforms use different approaches to deal with this arch-specific options. Since the PR's for windows and linux are currently still open, it might be a good opportunity to decide on a standard approach for dealing with architecture names in both the build.gradle as well as the platform-specific gradle files. We have to take into account that the different external libraries we include have their own wishes for accepting CPU architecture info, so even if we standardize internally on a specific name, conversions will still be needed when invoking e.g. building media libraries. See https://github.com/openjdk/jfx/pull/439 for the windows general build PR and https://github.com/openjdk/jfx/pull/467 for the Linux media PR. I am personally not really happy myself with how I deal with it in PR #467, as I would like to have a single "TARGET_ARCH" parameter that specifies the target architecture (also in case we are cross-compiling), rather than doing specific checks on different locations -- but that require a bigger refactory and I'd like to hear more opinions before doing that. I am very open to naming conventions (e.g. arm64 or aarch64), but I can imagine different people have different opinions. - Johan From philip.race at oracle.com Mon Apr 19 20:23:21 2021 From: philip.race at oracle.com (Philip Race) Date: Mon, 19 Apr 2021 13:23:21 -0700 Subject: AArch64 naming conventions In-Reply-To: References: Message-ID: <1e274f31-2f72-c5bb-c19b-a7a1b2a29dcb@oracle.com> FWIW I think on the JDK side folks are converging on aarch64 And also using that name as the "CPU" field in JBS (the alternative there being 'arm'). I'd find it easier if it was consistent across all these places. -phil On 4/19/21 1:06 PM, Johan Vos wrote: > Recently, we introduced the option (or are introducing the options) to > build OpenJFX for 64-bit ARM CPU's on Mac, Windows and Linux. > However, those 3 platforms use different approaches to deal with this > arch-specific options. > Since the PR's for windows and linux are currently still open, it might be > a good opportunity to decide on a standard approach for dealing with > architecture names in both the build.gradle as well as the > platform-specific gradle files. > > We have to take into account that the different external libraries we > include have their own wishes for accepting CPU architecture info, so even > if we standardize internally on a specific name, conversions will still be > needed when invoking e.g. building media libraries. > > See https://github.com/openjdk/jfx/pull/439 for the windows general build > PR and https://github.com/openjdk/jfx/pull/467 for the Linux media PR. > > I am personally not really happy myself with how I deal with it in PR #467, > as I would like to have a single "TARGET_ARCH" parameter that specifies the > target architecture (also in case we are cross-compiling), rather than > doing specific checks on different locations -- but that require a bigger > refactory and I'd like to hear more opinions before doing that. > > I am very open to naming conventions (e.g. arm64 or aarch64), but I can > imagine different people have different opinions. > > - Johan From github.com+1519324+primosk at openjdk.java.net Tue Apr 20 05:23:09 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Tue, 20 Apr 2021 05:23:09 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. Please discard my previous comment. After building a debug version we can't reproduce it anymore. I will try to create another production build and test it out once more. Will let you know how it goes. ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From aghaisas at openjdk.java.net Tue Apr 20 05:45:49 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 20 Apr 2021 05:45:49 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest [v2] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 17:47:14 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuItemTest.java line 410: >> >>> 408: >>> 409: @Test(expected=NullPointerException.class) >>> 410: public void setSpecifiedAccelerator_nullKeyCombination1() { >> >> Constructing KeyCodeCombination with a null KeyCode & constructing a KeyCharacterCombination with null key character results in NullPointerException as present in KeyCombinationTest.java. >> >> These tests were ignored with a comment on similar lines. I have enabled them and added expected NullPointerException. > > Where is the NPE thrown? I see that your change makes the test pass, but if it never gets to the `setAccelerator` call or the `assertEquals` statements maybe you could remove them? You are right. We can remove these test cases. The NPE is thrown from KeyCodeCombination and KeyCharacterCombination constructors and not from the method of MenuItem that is under test. ------------- PR: https://git.openjdk.java.net/jfx/pull/466 From aghaisas at openjdk.java.net Tue Apr 20 05:45:47 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 20 Apr 2021 05:45:47 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest [v2] In-Reply-To: References: Message-ID: > This PR enables ignored unit tests from MenuItemTest and fixes them. > 2 ignored tests are fixed. > 4 ignored tests are removed. > 2 new tests are added. > > **Before fix :** > total tests = 89 > failures = 0 > ignored tests = 6 > > **After fix :** > total tests = 89 > failures = 0 > ignored tests = 0 Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: remove incorrect tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/466/files - new: https://git.openjdk.java.net/jfx/pull/466/files/25516821..49293826 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=466&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=466&range=00-01 Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/466.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/466/head:pull/466 PR: https://git.openjdk.java.net/jfx/pull/466 From tom.schindl at bestsolution.at Tue Apr 20 06:10:34 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 20 Apr 2021 08:10:34 +0200 Subject: javafx-swt not deployed on maven central In-Reply-To: References: Message-ID: <298bf1df-1ce1-93fe-765c-1a64bb9ae25b@bestsolution.at> Hi, So I deployed the Artifact in the meanwhile to our companies public maven repo [1] as I didn't want to pollute maven-central with javafx-swt in a different namespace. Tom [1] https://maven.bestsolution.at/releases/at/bestsolution/openjfx/javafx-swt/ Am 07.04.21 um 10:53 schrieb Tom Schindl: > Hi, > > I'm not sure where to report this but it looks like the javafx-swt.jar > is not deployed on maven central. Is there a reason? > > Tom From rlichten at openjdk.java.net Tue Apr 20 06:23:06 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 20 Apr 2021 06:23:06 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger wrote: > Reverting to the old way of showing the context menu but with application > of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct > size measurement of the menu. I've finally managed to build JavaFX under Windows and tried out MenuShowBug.java from JDK-8228363 under different setups: **JavaFX 16**: Does not contain any fix for JDK-8228363 and thus will always show the menu at the wrong position when opened the first time. **PR-383**: This was the version that used AnchorLocation. When using 125% DPI, it works well, but not perfect, i.e. when only one of my two screens is set to 125% DPI, gaps still appear sometimes. However this solution is unacceptable anyway, due to the issue described in JDK-8261840 (for which this PR is the fix). **PR-410** (i.e.: this PR): I can reproduce the problem of @kevinrushforth (i.e. gap on first click). Since up to JavaFX 16 the first opening of the menu never worked under any DPI setting, this is not a regression but rather another issue that we need to look into. To be on the safe side, I also checked MenuShowBug without any stylesheets: * JavaFX 16: Works perfectly with 100% DPI, menu slightly too low with 125% DPI * PR-410: Works perfectly with 100% DPI, menu slightly too low with 125% DPI i.e. no difference. ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From jvos at openjdk.java.net Tue Apr 20 07:13:05 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 20 Apr 2021 07:13:05 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v4] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 17:37:08 GMT, Alexander Scherbatiy wrote: >> This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). >> >> Main changes: >> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition >> - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 >> - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) >> - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. >> >> I also looked which changes are required to build media module for Windows aarch64. >> The main changes could be using: >> - `ARCH=arm64` for building media libs in build.gradle file >> - `-MACHINE:arm64` LDFLAGS in media make files >> - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file >> - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port >> >> In this way the media is build but it is crashed when I run a JavaFX sample with video. >> Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Revert back fix with CONVERTED_OS_ARCH and CONVERTED_TARGET_ARCH variables Build works fine. Ultimately, we need to standardize on ARCH naming conventions in build.gradle and this will impact the usage of ${HOST_ARCH}_${TARGET_ARCH} but it looks good the way it is currently implemented. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/439 From arapte at openjdk.java.net Tue Apr 20 07:45:33 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 20 Apr 2021 07:45:33 GMT Subject: RFR: 8234077: Evaluate ignored unit tests in RenderRootTest [v2] In-Reply-To: References: Message-ID: > These are 2 corner case test cases for getRenderRoot() method. > 1. `emptyDirtyRegion():` When the dirty region rect is empty i.e. (0, 0, -1, -1) > 2. `zeroSizeDirtyRegionWithinOpaqueRegion()`: When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) > > - emptyDirtyRegion(): When the dirty region rect is empty i.e. (0, 0, -1, -1) > See `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` for definition of an empty rect. It seems logical to NOT to perform any rendering when dirty region is an empty rect. But current behavior is that when empty dirty region rect is passed to `root.getRenderRoot()`, it returns the root itself in NodePath. > The commit#1 can correct/change this behavior to return an empty NodePath. Commit#1 is only for reference, the change is NGNode.java is a product change which is out of scope of this fix. I shall file a new JBS issue to handle this case. > The test `emptyDirtyRegion1` is modified and another variant(`emptyDirtyRegion2`) of test is added. Additionally a new similar test (`invalidDirtyRegionOutsideOpaqueRegion`) is also included which passes an invalid rect. I think the behavior of this case should also be same as that of empty rect. All these three tests shall be ignored using the new JBS. > > - zeroSizeDirtyRegionWithinOpaqueRegion(): When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) > The dirty rect has 0 width and height but from the methods `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` we can infer that the rect(20, 20, 0, 0) is not an empty rect. (It may be considered as a dirty point). So if we consider this rect as a valid dirty region then the current behavior seems valid. I have added a couple more similar tests. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: update ignore tags with jbs id ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/463/files - new: https://git.openjdk.java.net/jfx/pull/463/files/37f83768..a9525f89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=463&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=463&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/463.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/463/head:pull/463 PR: https://git.openjdk.java.net/jfx/pull/463 From arapte at openjdk.java.net Tue Apr 20 07:45:33 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 20 Apr 2021 07:45:33 GMT Subject: RFR: 8234077: Evaluate ignored unit tests in RenderRootTest In-Reply-To: <7QXn5G1s0xR0D1_YLLSpHFnMq3CMjjqKkW7LW7a9jzU=.3c547dfe-6d29-43fa-a9bf-8be63bfa7f50@github.com> References: <7QXn5G1s0xR0D1_YLLSpHFnMq3CMjjqKkW7LW7a9jzU=.3c547dfe-6d29-43fa-a9bf-8be63bfa7f50@github.com> Message-ID: On Fri, 16 Apr 2021 22:29:04 GMT, Kevin Rushforth wrote: > Yes, filing a new bug to evaluate case 1 seems like the best option Thanks for the comment, I have created a new JBS issue and updated id in the ignore tags. ------------- PR: https://git.openjdk.java.net/jfx/pull/463 From johan.vos at gluonhq.com Tue Apr 20 08:27:26 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 20 Apr 2021 10:27:26 +0200 Subject: AArch64 naming conventions In-Reply-To: <1e274f31-2f72-c5bb-c19b-a7a1b2a29dcb@oracle.com> References: <1e274f31-2f72-c5bb-c19b-a7a1b2a29dcb@oracle.com> Message-ID: I'd like to go even further: OpenJDK has a make/autoconf/platform.m4 file which specifies the possible values for CPU_ARCH etc. This allows to uniquely define OPENJDK_BUILD_CPU_ARCH and OPENJDK_TARGET_CPU_ARCH. If we did something similar (in build.gradle), we would be able to be more consistent in build.gradle itself and in the platform-specific gradle files. Currently, this logic is spread over many places. - Johan On Mon, Apr 19, 2021 at 10:23 PM Philip Race wrote: > FWIW I think on the JDK side folks are converging on aarch64 > And also using that name as the "CPU" field in JBS (the alternative > there being 'arm'). > I'd find it easier if it was consistent across all these places. > > -phil > > On 4/19/21 1:06 PM, Johan Vos wrote: > > Recently, we introduced the option (or are introducing the options) to > > build OpenJFX for 64-bit ARM CPU's on Mac, Windows and Linux. > > However, those 3 platforms use different approaches to deal with this > > arch-specific options. > > Since the PR's for windows and linux are currently still open, it might > be > > a good opportunity to decide on a standard approach for dealing with > > architecture names in both the build.gradle as well as the > > platform-specific gradle files. > > > > We have to take into account that the different external libraries we > > include have their own wishes for accepting CPU architecture info, so > even > > if we standardize internally on a specific name, conversions will still > be > > needed when invoking e.g. building media libraries. > > > > See https://github.com/openjdk/jfx/pull/439 for the windows general > build > > PR and https://github.com/openjdk/jfx/pull/467 for the Linux media PR. > > > > I am personally not really happy myself with how I deal with it in PR > #467, > > as I would like to have a single "TARGET_ARCH" parameter that specifies > the > > target architecture (also in case we are cross-compiling), rather than > > doing specific checks on different locations -- but that require a bigger > > refactory and I'd like to hear more opinions before doing that. > > > > I am very open to naming conventions (e.g. arm64 or aarch64), but I can > > imagine different people have different opinions. > > > > - Johan > > From arapte at openjdk.java.net Tue Apr 20 09:17:31 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 20 Apr 2021 09:17:31 GMT Subject: RFR: 8234084: [TEST_BUG] Remove unexecuted performance benchmark tests Message-ID: <-jEhPyqz0SgPNsgyfNPvB12PassctPT112U_X0gqv9Y=.9b069336-dc28-4209-84a4-62d9788ca518@github.com> This PR removes two benchmark tests that are ignored since they were added [here](https://github.com/openjdk/jfx/commit/0dea6d6790ae4eeff3e5ec5a7750251caf91e40b) test.javafx.scene.input.TouchEventTest.saneOrderingBenchmark test.javafx.scene.input.TouchEventTest.crazyOrderingBenchmark Since the tests do not compare but only print the time taken by programmatically generating the touch events and are not executed since the time they were added, It seems reasonable to remove them. ------------- Commit messages: - remove unextecuted benchmark tests Changes: https://git.openjdk.java.net/jfx/pull/468/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=468&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234084 Stats: 187 lines in 1 file changed: 0 ins; 187 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/468.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/468/head:pull/468 PR: https://git.openjdk.java.net/jfx/pull/468 From github.com+1519324+primosk at openjdk.java.net Tue Apr 20 10:35:06 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Tue, 20 Apr 2021 10:35:06 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. We've created another production build and it seems to be working fine! Application doesn't hang anymore! Sorry for false alarm - it looks like our previous production build procedure had flaws (might be I've checked out wrong pull request). BTW - thank you guys for all hard work needed to fix this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From fastegal at openjdk.java.net Tue Apr 20 11:11:38 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 20 Apr 2021 11:11:38 GMT Subject: RFR: 8265513: Openjfx graphics build broken (Eclipse) Message-ID: Issue is usage of JMemoryBuddy in module graphics (SceneTest, added in [JDK-8264330](https://bugs.openjdk.java.net/browse/JDK-8264330). Fix is to add-exports in Eclipse .classpath in graphics (same as done for controls in fix of [JDK-8256184](https://bugs.openjdk.java.net/browse/JDK-8256184) ------------- Commit messages: - 8265513: Openjfx graphics build broken (Eclipse) Changes: https://git.openjdk.java.net/jfx/pull/469/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=469&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265513 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/469.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/469/head:pull/469 PR: https://git.openjdk.java.net/jfx/pull/469 From kcr at openjdk.java.net Tue Apr 20 11:14:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Apr 2021 11:14:02 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 10:31:59 GMT, PrimosK wrote: >> Issue: Java application (with WebView) will completely freeze after using it for a while. >> >> Fix: Use native isMainThread functions instead of JNI call. > > We've created another production build and it seems to be working fine! Application doesn't hang anymore! Sorry for false alarm - it looks like our previous production build procedure had flaws (might be I've checked out wrong pull request). > > BTW - thank you guys for all hard work needed to fix this one. @PrimosK Good to hear. Thank you for your help in verifying the fix. Arun will integrate the fix once a second reviewer has approved it. ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From kcr at openjdk.java.net Tue Apr 20 11:15:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Apr 2021 11:15:07 GMT Subject: RFR: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest [v2] In-Reply-To: References: Message-ID: <1eJcqXaJkEtmN58aCaeAaQLPfOxwuizvxdNdoye71sY=.5956cda6-3b17-40e7-88dc-6dfbfa7d2a21@github.com> On Tue, 20 Apr 2021 05:45:47 GMT, Ajit Ghaisas wrote: >> This PR enables ignored unit tests from MenuItemTest and fixes them. >> 4 ignored tests are fixed. >> 2 ignored tests are removed. >> >> >> **Before fix :** >> total tests = 89 >> failures = 0 >> ignored tests = 6 >> >> **After fix :** >> total tests = 87 >> failures = 0 >> ignored tests = 0 > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > remove incorrect tests Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/466 From kcr at openjdk.java.net Tue Apr 20 11:24:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Apr 2021 11:24:09 GMT Subject: RFR: 8234077: Evaluate ignored unit tests in RenderRootTest [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 07:45:33 GMT, Ambarish Rapte wrote: >> These are 2 corner case test cases for getRenderRoot() method. >> 1. `emptyDirtyRegion():` When the dirty region rect is empty i.e. (0, 0, -1, -1) >> 2. `zeroSizeDirtyRegionWithinOpaqueRegion()`: When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) >> >> - emptyDirtyRegion(): When the dirty region rect is empty i.e. (0, 0, -1, -1) >> See `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` for definition of an empty rect. It seems logical to NOT to perform any rendering when dirty region is an empty rect. But current behavior is that when empty dirty region rect is passed to `root.getRenderRoot()`, it returns the root itself in NodePath. >> The commit#1 can correct/change this behavior to return an empty NodePath. Commit#1 is only for reference, the change is NGNode.java is a product change which is out of scope of this fix. I shall file a new JBS issue to handle this case. >> The test `emptyDirtyRegion1` is modified and another variant(`emptyDirtyRegion2`) of test is added. Additionally a new similar test (`invalidDirtyRegionOutsideOpaqueRegion`) is also included which passes an invalid rect. I think the behavior of this case should also be same as that of empty rect. All these three tests shall be ignored using the new JBS. >> >> - zeroSizeDirtyRegionWithinOpaqueRegion(): When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) >> The dirty rect has 0 width and height but from the methods `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` we can infer that the rect(20, 20, 0, 0) is not an empty rect. (It may be considered as a dirty point). So if we consider this rect as a valid dirty region then the current behavior seems valid. I have added a couple more similar tests. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > update ignore tags with jbs id Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/463 From kcr at openjdk.java.net Tue Apr 20 11:28:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Apr 2021 11:28:05 GMT Subject: RFR: 8234084: [TEST_BUG] Remove unexecuted performance benchmark tests In-Reply-To: <-jEhPyqz0SgPNsgyfNPvB12PassctPT112U_X0gqv9Y=.9b069336-dc28-4209-84a4-62d9788ca518@github.com> References: <-jEhPyqz0SgPNsgyfNPvB12PassctPT112U_X0gqv9Y=.9b069336-dc28-4209-84a4-62d9788ca518@github.com> Message-ID: On Tue, 20 Apr 2021 09:12:40 GMT, Ambarish Rapte wrote: > This PR removes two benchmark tests that are ignored since they were added [here](https://github.com/openjdk/jfx/commit/0dea6d6790ae4eeff3e5ec5a7750251caf91e40b) > > test.javafx.scene.input.TouchEventTest.saneOrderingBenchmark > test.javafx.scene.input.TouchEventTest.crazyOrderingBenchmark > > Since the tests do not compare but only print the time taken by programmatically generating the touch events and > are not executed since the time they were added, It seems reasonable to remove them. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/468 From kcr at openjdk.java.net Tue Apr 20 11:34:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Apr 2021 11:34:06 GMT Subject: RFR: 8265513: Openjfx graphics build broken (Eclipse) In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:06:32 GMT, Jeanette Winzenburg wrote: > Issue is usage of JMemoryBuddy in module graphics (SceneTest, added in [JDK-8264330](https://bugs.openjdk.java.net/browse/JDK-8264330). > > Fix is to add-exports in Eclipse .classpath in graphics (same as done for controls in fix of [JDK-8256184](https://bugs.openjdk.java.net/browse/JDK-8256184) @nlisker Since you are an Eclipse user, can you review this? (it looks obviously correct to me) ------------- PR: https://git.openjdk.java.net/jfx/pull/469 From fastegal at swingempire.de Tue Apr 20 11:39:27 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 20 Apr 2021 13:39:27 +0200 Subject: Local test failure of LocalDateTimeStringConverterTest.testChronologyConsistency Message-ID: <20210420133927.Horde.DlKjsjNYQWh4jKOR8PYgiQ1@webmail.df.eu> the top of the failure trace: org.junit.ComparisonFailure: expected:<...y, January 12, 60 Sh[?]wa, 12:34:56 PM> but was:<...y, January 12, 60 Sh[o]wa, 12:34:56 PM> at org.junit.Assert.assertEquals(Assert.java:123) at org.junit.Assert.assertEquals(Assert.java:145) at test.javafx.util.converter.LocalDateTimeStringConverterTest.testChronologyConsistency(LocalDateTimeStringConverterTest.java:160) looks like some problem with assumptions of Locale-dependent state (my default is German, obviously :). They are always a bit whacky, but am surprised to see it in gradle (which disturbs the final tests before every push now) - should I file a test bug? Or is there something to change locally? -- Jeanette From nlisker at openjdk.java.net Tue Apr 20 11:50:04 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 20 Apr 2021 11:50:04 GMT Subject: RFR: 8265513: Openjfx graphics build broken (Eclipse) In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:06:32 GMT, Jeanette Winzenburg wrote: > Issue is usage of JMemoryBuddy in module graphics (SceneTest, added in [JDK-8264330](https://bugs.openjdk.java.net/browse/JDK-8264330). > > Fix is to add-exports in Eclipse .classpath in graphics (same as done for controls in fix of [JDK-8256184](https://bugs.openjdk.java.net/browse/JDK-8256184) Looks correct, but will take me some time to actually test it. ------------- PR: https://git.openjdk.java.net/jfx/pull/469 From kevin.rushforth at oracle.com Tue Apr 20 11:56:20 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Apr 2021 04:56:20 -0700 Subject: Local test failure of LocalDateTimeStringConverterTest.testChronologyConsistency In-Reply-To: <20210420133927.Horde.DlKjsjNYQWh4jKOR8PYgiQ1@webmail.df.eu> References: <20210420133927.Horde.DlKjsjNYQWh4jKOR8PYgiQ1@webmail.df.eu> Message-ID: Looks like you've discovered another Locale-sensitive test, similar to the one Ajit is working on now: https://bugs.openjdk.java.net/browse/JDK-8264952 We could either file a new bug or expand JDK-8264952 to include this one. I'd probably recommend the latter, since it is in the same general area (a controls unit test that is failing because of a date / time format issue). -- Kevin On 4/20/2021 4:39 AM, Jeanette Winzenburg wrote: > > the top of the failure trace: > > org.junit.ComparisonFailure: expected:<...y, January 12, 60 Sh[?]wa, > 12:34:56 PM> but was:<...y, January 12, 60 Sh[o]wa, 12:34:56 PM> > ????at org.junit.Assert.assertEquals(Assert.java:123) > ????at org.junit.Assert.assertEquals(Assert.java:145) > ????at > test.javafx.util.converter.LocalDateTimeStringConverterTest.testChronologyConsistency(LocalDateTimeStringConverterTest.java:160) > > looks like some problem with assumptions of Locale-dependent state (my > default is German, obviously :). They are always a bit whacky, but am > surprised to see it in gradle (which disturbs the final tests before > every push now) - should I file a test bug? Or is there something to > change locally? > > -- Jeanette > From fastegal at swingempire.de Tue Apr 20 12:06:50 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 20 Apr 2021 14:06:50 +0200 Subject: Local test failure of LocalDateTimeStringConverterTest.testChronologyConsistency In-Reply-To: References: <20210420133927.Horde.DlKjsjNYQWh4jKOR8PYgiQ1@webmail.df.eu> Message-ID: <20210420140650.Horde.7k2jrI6vGBVboGivPqEb6Q4@webmail.df.eu> added a comment to Ajit's issue, thanks :) Zitat von Kevin Rushforth : > Looks like you've discovered another Locale-sensitive test, similar > to the one Ajit is working on now: > > https://bugs.openjdk.java.net/browse/JDK-8264952 > > We could either file a new bug or expand JDK-8264952 to include this > one. I'd probably recommend the latter, since it is in the same > general area (a controls unit test that is failing because of a date > / time format issue). > > -- Kevin > > > On 4/20/2021 4:39 AM, Jeanette Winzenburg wrote: >> >> the top of the failure trace: >> >> org.junit.ComparisonFailure: expected:<...y, January 12, 60 >> Sh[?]wa, 12:34:56 PM> but was:<...y, January 12, 60 Sh[o]wa, >> 12:34:56 PM> >> ????at org.junit.Assert.assertEquals(Assert.java:123) >> ????at org.junit.Assert.assertEquals(Assert.java:145) >> ????at >> test.javafx.util.converter.LocalDateTimeStringConverterTest.testChronologyConsistency(LocalDateTimeStringConverterTest.java:160) >> >> looks like some problem with assumptions of Locale-dependent state >> (my default is German, obviously :). They are always a bit whacky, >> but am surprised to see it in gradle (which disturbs the final >> tests before every push now) - should I file a test bug? Or is >> there something to change locally? >> >> -- Jeanette >> From kcr at openjdk.java.net Tue Apr 20 12:22:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Apr 2021 12:22:09 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger wrote: > Reverting to the old way of showing the context menu but with application > of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct > size measurement of the menu. Marked as reviewed by kcr (Lead). Thank you for your detailed explanation. I filed https://bugs.openjdk.java.net/browse/JDK-8265526 to track the issue of misaligned positioning with 125% scaling. ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From aghaisas at openjdk.java.net Tue Apr 20 14:03:13 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 20 Apr 2021 14:03:13 GMT Subject: Integrated: 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 12:51:06 GMT, Ajit Ghaisas wrote: > This PR enables ignored unit tests from MenuItemTest and fixes them. > 4 ignored tests are fixed. > 2 ignored tests are removed. > > > **Before fix :** > total tests = 89 > failures = 0 > ignored tests = 6 > > **After fix :** > total tests = 87 > failures = 0 > ignored tests = 0 This pull request has now been integrated. Changeset: af75a1fb Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/af75a1fb Stats: 27 lines in 1 file changed: 2 ins; 20 del; 5 mod 8265439: [TestBug] Enable and fix ignored unit tests in MenuItemTest Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/466 From rlichten at openjdk.java.net Tue Apr 20 16:41:10 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 20 Apr 2021 16:41:10 GMT Subject: Integrated: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger wrote: > Reverting to the old way of showing the context menu but with application > of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct > size measurement of the menu. This pull request has now been integrated. Changeset: 67828aeb Author: Robert Lichtenberger Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/67828aeb Stats: 58 lines in 1 file changed: 5 ins; 40 del; 13 mod 8261840: Submenus close to screen borders are no longer repositioned Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From ghb at openjdk.java.net Tue Apr 20 19:14:19 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 20 Apr 2021 19:14:19 GMT Subject: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. Looks good to me . Tested on Windows with Modified WebView which loads multiple URL every 30 seconds (executed for 30 min and didn't find any freeze or crash). ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/461 From ajoseph at openjdk.java.net Tue Apr 20 19:51:07 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 20 Apr 2021 19:51:07 GMT Subject: Integrated: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: References: Message-ID: <5ewtdV0Oult1OJCyBC1C1ufuuh3eX3arW7ai-M82eh0=.f93171f1-8975-4291-bfcd-fe833e99d512@github.com> On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it for a while. > > Fix: Use native isMainThread functions instead of JNI call. This pull request has now been integrated. Changeset: 49d2126e Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/49d2126e Stats: 38 lines in 3 files changed: 15 ins; 18 del; 5 mod 8263788: JavaFX application freezes completely after some time when using the WebView Reviewed-by: kcr, ghb ------------- PR: https://git.openjdk.java.net/jfx/pull/461 From ajoseph at openjdk.java.net Tue Apr 20 20:03:28 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 20 Apr 2021 20:03:28 GMT Subject: RFR: 8262276: Debug build of WebKit fails [v3] In-Reply-To: References: Message-ID: > Fixing the Debug build of WebKit. > > Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test using a simple HelloWebView app. Arun Joseph has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge - Fix InternalFunction crash - 8262276: Debug build of WebKit fails ------------- Changes: https://git.openjdk.java.net/jfx/pull/417/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=417&range=02 Stats: 34 lines in 6 files changed: 21 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/417.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/417/head:pull/417 PR: https://git.openjdk.java.net/jfx/pull/417 From kcr at openjdk.java.net Tue Apr 20 23:42:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 20 Apr 2021 23:42:11 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction I'll try it on macOS with a non-retina display and see if that makes a difference (if so, it could point to a transform issue). I'll also try with the Boxes as you suggest. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Wed Apr 21 00:32:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 21 Apr 2021 00:32:16 GMT Subject: RFR: 8262276: Debug build of WebKit fails [v3] In-Reply-To: References: Message-ID: <2L_QDGRUVvjy60EnxExTKuKeDhFibMwhUbCK5ouZ6_8=.3e783438-cc4e-4575-a5b7-4c8980a46b0b@github.com> On Tue, 20 Apr 2021 20:03:28 GMT, Arun Joseph wrote: >> Fixing the Debug build of WebKit. >> >> Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test using a simple HelloWebView app. > > Arun Joseph has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge > - Fix InternalFunction crash > - 8262276: Debug build of WebKit fails Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From arapte at openjdk.java.net Wed Apr 21 02:10:05 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 21 Apr 2021 02:10:05 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v5] In-Reply-To: References: Message-ID: On Sun, 11 Apr 2021 15:48:11 GMT, Florian Kirmaier wrote: >> Fixing a memory leak. >> A node hard references its old parent after CSS layout and getting removed. >> This shouldn't be the case, this is very counterintuitive. >> >> The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. >> This should be fine because the CSS should only depend on it if it's still the real parent. >> In that case, it doesn't get collected. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8263402 > Minor simplification of the code, based on code review Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From r.lichtenberger at gmail.com Wed Apr 21 05:31:24 2021 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Wed, 21 Apr 2021 07:31:24 +0200 Subject: Unable to import OpenJFX Build into Eclipse In-Reply-To: References: <635de104-69d2-687d-e100-436502bfe92b@gmail.com> <0ba0cda3-600f-fa39-45ad-1f7f05565648@bestsolution.at> Message-ID: I have tried to import OpenJFX to eclipse under Windows today for the first time and having the exakt same problem. Am Mo., 17. Aug. 2020 um 13:52 Uhr schrieb Nir Lisker : > They are not required if you use the command line interface, but I find > that they do make things easier since I can run the gradle command from > Eclipse directly. > > The instructions mention that if you import through gradle, you will need > to replace the Eclipse files with the ones in the repo because at this > point gradle still messes them up. > > On Mon, Aug 17, 2020 at 10:43 AM Tom Schindl > wrote: > > > Hi, > > > > Do we really use the Eclipse-Gradle-Tooling now? I think the reasons we > > checked in all .product/.classpath files is that this did not work in > > the past. > > > > At least my Eclipse install I use for OpenJFX-Development does not have > > the gradle-tooling installed and things work there just fine. > > > > Tom > > > > Am 16.08.20 um 21:49 schrieb Nir Lisker: > > > Hi Andrew, > > > > > > I did the same setup only with Ubuntu 18, which shouldn't matter, and I > > > don't remember having this issue. I can try redoing it next time I boot > > the > > > Ubuntu partition. > > > > > > What looks odd is that the error references the build directory. What > > > happens if you clean the project first? > > > > > > - Nir > > > > > > On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters > wrote: > > > > > >> Hi All, > > >> > > >> > > >> I'm trying to diagnose a bug in OpenJFX that I've been struggling with > > >> on and off for almost a year(!) and I decided to build OpenJFX from > > >> source and use Eclipse to help. I've built a brand new Ubuntu > > >> 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable > OpenJFX > > >> 14. I've run the Gradle build and run the tests and all looks 100%. > > >> > > >> > > >> When importing the root directory (home/jdkdev/dev/jfx) into Eclipse > > >> using the gradle import tool (using the wrapper option as > recommended) I > > >> get this build path error: > > >> > > >> > > >> Cannot nest > > >> > > > 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' > > >> > > >> inside library > > >> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' > > >> > > >> > > >> It seems to be trying to set up a looped import to itself somehow. > I've > > >> tried to edit the build path in eclipse but the fields appear to be > all > > >> non-editable. Has anyone any idea as to what the problem is and how > to > > >> fix it? Has anyone recently done a successful import with these > latest > > >> levels? > > >> > > >> > > >> As this is the base module none of the other modules compile of course > > >> so they too may have other problems once the base module is fixed. > > >> > > >> > > >> I tried the "existing projects" import too but that just appears to > have > > >> even more problems. > > >> > > >> > > >> Thanks, > > >> > > >> Andrew Waters > > >> > > >> UK. > > >> > > >> > > > From arapte at openjdk.java.net Wed Apr 21 06:49:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 21 Apr 2021 06:49:10 GMT Subject: Integrated: 8234084: [TEST_BUG] Remove unexecuted performance benchmark tests In-Reply-To: <-jEhPyqz0SgPNsgyfNPvB12PassctPT112U_X0gqv9Y=.9b069336-dc28-4209-84a4-62d9788ca518@github.com> References: <-jEhPyqz0SgPNsgyfNPvB12PassctPT112U_X0gqv9Y=.9b069336-dc28-4209-84a4-62d9788ca518@github.com> Message-ID: On Tue, 20 Apr 2021 09:12:40 GMT, Ambarish Rapte wrote: > This PR removes two benchmark tests that are ignored since they were added [here](https://github.com/openjdk/jfx/commit/0dea6d6790ae4eeff3e5ec5a7750251caf91e40b) > > test.javafx.scene.input.TouchEventTest.saneOrderingBenchmark > test.javafx.scene.input.TouchEventTest.crazyOrderingBenchmark > > Since the tests do not compare but only print the time taken by programmatically generating the touch events and > are not executed since the time they were added, It seems reasonable to remove them. This pull request has now been integrated. Changeset: 8f0062d7 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/8f0062d7 Stats: 187 lines in 1 file changed: 0 ins; 187 del; 0 mod 8234084: [TEST_BUG] Remove unexecuted performance benchmark tests Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/468 From arapte at openjdk.java.net Wed Apr 21 06:50:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 21 Apr 2021 06:50:08 GMT Subject: Integrated: 8234077: Evaluate ignored unit tests in RenderRootTest In-Reply-To: References: Message-ID: <3hxR3FqVpEtJntVFOne0LJL_6l_PXEbE3OA1yhRlJuo=.468624a4-fae1-4415-837d-64cccccab1d4@github.com> On Fri, 16 Apr 2021 09:25:47 GMT, Ambarish Rapte wrote: > These are 2 corner case test cases for getRenderRoot() method. > 1. `emptyDirtyRegion():` When the dirty region rect is empty i.e. (0, 0, -1, -1) > 2. `zeroSizeDirtyRegionWithinOpaqueRegion()`: When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) > > - emptyDirtyRegion(): When the dirty region rect is empty i.e. (0, 0, -1, -1) > See `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` for definition of an empty rect. It seems logical to NOT to perform any rendering when dirty region is an empty rect. But current behavior is that when empty dirty region rect is passed to `root.getRenderRoot()`, it returns the root itself in NodePath. > The commit#1 can correct/change this behavior to return an empty NodePath. Commit#1 is only for reference, the change is NGNode.java is a product change which is out of scope of this fix. I shall file a new JBS issue to handle this case. > The test `emptyDirtyRegion1` is modified and another variant(`emptyDirtyRegion2`) of test is added. Additionally a new similar test (`invalidDirtyRegionOutsideOpaqueRegion`) is also included which passes an invalid rect. I think the behavior of this case should also be same as that of empty rect. All these three tests shall be ignored using the new JBS. > > - zeroSizeDirtyRegionWithinOpaqueRegion(): When the dirty region rect is of zero dimensions, for example (20, 20, 0, 0) > The dirty rect has 0 width and height but from the methods `RectBounds.makeEmpty()` and `RectBounds.isEmpty()` we can infer that the rect(20, 20, 0, 0) is not an empty rect. (It may be considered as a dirty point). So if we consider this rect as a valid dirty region then the current behavior seems valid. I have added a couple more similar tests. This pull request has now been integrated. Changeset: 86b854dc Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/86b854dc Stats: 48 lines in 1 file changed: 43 ins; 0 del; 5 mod 8234077: Evaluate ignored unit tests in RenderRootTest Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/463 From arapte at openjdk.java.net Wed Apr 21 09:26:15 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 21 Apr 2021 09:26:15 GMT Subject: RFR: 8239880: CSS tests should cleanup any global state they modify Message-ID: The tests that are modified in this PR set a stylesheet using API `StyleManager.getInstance().setDefaultUserAgentStylesheet()`. This is a global state and should be reset after execution of each test. It does not cause any test failures currently, but this has caused a test failure in past reported here [JDK-8239822](https://bugs.openjdk.java.net/browse/JDK-8239822) which was fixed with a similar change like in this PR. A reset method like following seems sufficient to undo the changes made by `StyleManager.getInstance().setDefaultUserAgentStylesheet()`. But this fix uses the same method definition of `resetStyleManager()` like in the [fix](https://git.openjdk.java.net/jfx/commit/c3ee1a30) for [JDK-8239822](https://bugs.openjdk.java.net/browse/JDK-8239822) private static void resetStyleManager() { StyleManager sm = StyleManager.getInstance(); sm.platformUserAgentStylesheetContainers.clear(); sm.hasDefaultUserAgentStylesheet = false; } Fix also has 2 cleanup changes, 1. A minor typo correction in code, `StyleManager.getInstance().getInstance()` is replaced with `StyleManager.getInstance()`. 2. In test file _HonorDeveloperSettingsTest.java_: Unused class `TestWindow` is removed and few line of commented out code(which used the TestWindow class) is removed. ------------- Commit messages: - reset StyleManager after test execution Changes: https://git.openjdk.java.net/jfx/pull/470/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=470&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239880 Stats: 71 lines in 4 files changed: 48 ins; 10 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/470.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/470/head:pull/470 PR: https://git.openjdk.java.net/jfx/pull/470 From jpereda at openjdk.java.net Wed Apr 21 10:46:48 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 21 Apr 2021 10:46:48 GMT Subject: RFR: 8210199: [linux / macOS] fileChooser can't handle emojis Message-ID: Both `GlassDialogs.m` for macOS and `GlassCommonDialogs.c` for Linux use UTF8 encoding for the file names selected via native FileChooser, and this will fail if there are emojis in the file name. This PR uses the same approach as in [JDK-8258381](https://bugs.openjdk.java.net/browse/JDK-8258381) for macOS, using UTF16 encoding. For Linux, the Java `String(byte[] bytes)` constructor with default charset is used instead, preventing the need of using UTF8 encoding. ------------- Commit messages: - Use String(bytes) instead of UTF8 encoding for filenames in Linux - Use UTF16 encoding for URL path in macOS Changes: https://git.openjdk.java.net/jfx/pull/471/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=471&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/jfx/pull/471.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/471/head:pull/471 PR: https://git.openjdk.java.net/jfx/pull/471 From arapte at openjdk.java.net Wed Apr 21 10:53:51 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 21 Apr 2021 10:53:51 GMT Subject: RFR: 8265514: Openjfx controls running tests broken (Eclipse) Message-ID: As mentioned in JBS the unit test execution fails when tests have a duplicate package name. This was introduced by JDK-8204568: it created a test in a new package `test.javafx.css` in controls tests. A similar package already existed in graphics unit tests. This is a simple fix to rename the package. Test is moved to existing package in controls test under `test.javafx.scene.control` ------------- Commit messages: - change test package Changes: https://git.openjdk.java.net/jfx/pull/472/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=472&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265514 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/472.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/472/head:pull/472 PR: https://git.openjdk.java.net/jfx/pull/472 From fastegal at openjdk.java.net Wed Apr 21 11:33:53 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 21 Apr 2021 11:33:53 GMT Subject: RFR: 8265206: Tree-/TableCell: editing state not updated on cell re-use Message-ID: Issue is missing update of Tree-/TableCell's editiable state when changing its index from editingIndex to -1. Seems to be a left-over from fixing cell's editing update - done in [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) - on index change for the special case of new index -1. Fixed by cleaning out editing state in that corner case also, added tests that were failing before and passing after the fix. Note that there are also tests that passed before: the previous fix didn't add any tests, so added them here. ------------- Commit messages: - 8265206: Tree-/TableCell: editing state not updated on cell re-use Changes: https://git.openjdk.java.net/jfx/pull/473/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=473&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265206 Stats: 430 lines in 4 files changed: 410 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/473.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/473/head:pull/473 PR: https://git.openjdk.java.net/jfx/pull/473 From fastegal at openjdk.java.net Wed Apr 21 11:40:37 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 21 Apr 2021 11:40:37 GMT Subject: RFR: 8265514: Openjfx controls running tests broken (Eclipse) In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:49:25 GMT, Ambarish Rapte wrote: > As mentioned in JBS the unit test execution fails when tests have a duplicate package name. > This was introduced by JDK-8204568: it created a test in a new package `test.javafx.css` in controls tests. A similar package already existed in graphics unit tests. > This is a simple fix to rename the package. Test is moved to existing package in controls test under `test.javafx.scene.control` modules/javafx.controls/src/test/java/test/javafx/scene/control/PropertySizeTest.java line 27: > 25: > 26: package test.javafx.scene.control; > 27: ahh .. you moved the test into an existing package - that's fine with me if you are certain that we don't want a dedicated package for css? Locally, I create `test.javafx.scene.control.css` and moved the tests there. But really doesn't matter much :) ------------- PR: https://git.openjdk.java.net/jfx/pull/472 From kcr at openjdk.java.net Wed Apr 21 12:08:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 21 Apr 2021 12:08:37 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v5] In-Reply-To: References: Message-ID: On Sun, 11 Apr 2021 15:48:11 GMT, Florian Kirmaier wrote: >> Fixing a memory leak. >> A node hard references its old parent after CSS layout and getting removed. >> This shouldn't be the case, this is very counterintuitive. >> >> The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. >> This should be fine because the CSS should only depend on it if it's still the real parent. >> In that case, it doesn't get collected. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8263402 > Minor simplification of the code, based on code review Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From jvos at openjdk.java.net Wed Apr 21 13:53:53 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 21 Apr 2021 13:53:53 GMT Subject: RFR: 8265669: AccumCell should not be visible Message-ID: Hide accumCell when the cell is released. Fix for JDK-8265669 ------------- Commit messages: - Hide accumCell when the cell is released. Changes: https://git.openjdk.java.net/jfx/pull/474/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=474&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265669 Stats: 13 lines in 2 files changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/474.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/474/head:pull/474 PR: https://git.openjdk.java.net/jfx/pull/474 From kcr at openjdk.java.net Wed Apr 21 13:53:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 21 Apr 2021 13:53:54 GMT Subject: RFR: 8265669: AccumCell should not be visible In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 13:45:57 GMT, Johan Vos wrote: > Hide accumCell when the cell is released. > Fix for JDK-8265669 It looks simple and safe enough, so 1 reviewer should be fine. I'll let Ajit review it. ------------- PR: https://git.openjdk.java.net/jfx/pull/474 From jvos at openjdk.java.net Wed Apr 21 14:10:37 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 21 Apr 2021 14:10:37 GMT Subject: RFR: 8265206: Tree-/TableCell: editing state not updated on cell re-use In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 11:29:38 GMT, Jeanette Winzenburg wrote: > Issue is missing update of Tree-/TableCell's editiable state when changing its index from editingIndex to -1. > > Seems to be a left-over from fixing cell's editing update - done in [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) - on index change for the special case of new index -1. > > Fixed by cleaning out editing state in that corner case also, added tests that were failing before and passing after the fix. Note that there are also tests that passed before: the previous fix didn't add any tests, so added them here. modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java line 581: > 579: // so that subclasses which override cancelEdit can execute. So, > 580: // I have to use a kind of hacky flag workaround. > 581: updateEditingIndex = false; Do you need to assert on updateEditingIndex being true before this is done? ------------- PR: https://git.openjdk.java.net/jfx/pull/473 From fkirmaier at openjdk.java.net Wed Apr 21 14:25:54 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 21 Apr 2021 14:25:54 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v4] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 11:58:14 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > Added checks, whether the correction ammount of editStart/cancel events are triggered Finally found time to update the PR. 1. As suggested, I've moved the updateIndex method below the if. 2. The test from 1 to -1 is a bit more complicated. Because -1 represents "not editing" the test would be differnt. I've adapted the test to check for "not editing" in the case of -1. With this change the test is green. Honestly im not really aware of the Ordering of the methods. I didn't spend a lot of time understanding the inner works of all the controls - im usually more focused on fixing memory leaks. About the initial focus, i see 3 options: - set it to -1 in testChangeIndexToEditing1_jdk_8264127 - set it to -1 in assertChangeIndexToEditing - set it to -1 in the setup method. All 3 options work. Im fine with keeping it at the concrete test, because it's the only test who needs it, but im fine with any of the 3 options. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Wed Apr 21 14:25:53 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 21 Apr 2021 14:25:53 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v5] In-Reply-To: References: Message-ID: > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264127: Small update to the tests and the fix ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/2cc8c61c..0418a4ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=03-04 Stats: 17 lines in 2 files changed: 12 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From fastegal at openjdk.java.net Wed Apr 21 14:41:37 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 21 Apr 2021 14:41:37 GMT Subject: RFR: 8265206: Tree-/TableCell: editing state not updated on cell re-use In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:07:21 GMT, Johan Vos wrote: >> Issue is missing update of Tree-/TableCell's editiable state when changing its index from editingIndex to -1. >> >> Seems to be a left-over from fixing cell's editing update - done in [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) - on index change for the special case of new index -1. >> >> Fixed by cleaning out editing state in that corner case also, added tests that were failing before and passing after the fix. Note that there are also tests that passed before: the previous fix didn't add any tests, so added them here. > > modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java line 581: > >> 579: // so that subclasses which override cancelEdit can execute. So, >> 580: // I have to use a kind of hacky flag workaround. >> 581: updateEditingIndex = false; > > Do you need to assert on updateEditingIndex being true before this is done? hmm .. don't quite understand your comment: it's a flag to tell cancelEdit to not update control's editing state (that whole block is simply extracted from the pre-fix state .. where it has been for ages ;) So the answer is most probably no :) ------------- PR: https://git.openjdk.java.net/jfx/pull/473 From fastegal at openjdk.java.net Wed Apr 21 15:35:34 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 21 Apr 2021 15:35:34 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v4] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:22:21 GMT, Florian Kirmaier wrote: > > > Finally found time to update the PR. > > 1. As suggested, I've moved the updateIndex method below the if. > looks good :) > 2. The test from 1 to -1 is a bit more complicated. Because -1 represents "not editing" the test would be differnt. I've adapted the test to check for "not editing" in the case of -1. With this change the test is green. > looks like I haven't been clear enough in my recent comments: the list is always really editing (state transitions of list's editingIndex and their effects on a cell at that index seem to be working and have tests), that is `editingIndex > 0`. What I meant is updating the cell index from that editingIndex to -1, here is a test that's still failing @Test public void testUpdateCellIndexOffEditing() { list.setEditable(true); cell.updateListView(list); int editingIndex = 1; // list editing cell.updateIndex(editingIndex); list.edit(editingIndex); // here we are certain that the cell is in editing state assertTrue("sanity: cell must be editing", cell.isEditing()); cell.updateIndex(-1); // change cell index to negative assertFalse("cell must not be editing if cell index is " + cell.getIndex(), cell.isEditing()); } For a fix, have a look at [JDK-8264127](https://bugs.openjdk.java.net/browse/JDK-8264127) - I think it's similar for ListCell updateEditing, though its logic block clouds it a bit (instead of immediately backing out for cellIndex == -1, it doesn't enter the if. > > Honestly im not really aware of the Ordering of the methods. I didn't spend a lot of time understanding the inner works of all the controls - im usually more focused on fixing memory leaks. > > About the initial focus, i see 3 options: > > * set it to -1 in testChangeIndexToEditing1_jdk_8264127 > > * set it to -1 in assertChangeIndexToEditing > > * set it to -1 in the setup method. > All 3 options work. Im fine with keeping it at the concrete test, because it's the only test who needs it, but im fine with any of the 3 options. if you intend to keep the tests in the big-fat ListCellTest, then option 3 would be a bit brittle, IMO: it might lead to unexpected behavior in the other/future tests. Keeping focus on -1 should be done in each of the tests here (otherwise changes in default focus might - or not - break the tests), so I would suggest option 2 and in all whileEditing methods. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From jvos at openjdk.java.net Wed Apr 21 17:56:36 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 21 Apr 2021 17:56:36 GMT Subject: RFR: 8265206: Tree-/TableCell: editing state not updated on cell re-use In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:37:15 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java line 581: >> >>> 579: // so that subclasses which override cancelEdit can execute. So, >>> 580: // I have to use a kind of hacky flag workaround. >>> 581: updateEditingIndex = false; >> >> Do you need to assert on updateEditingIndex being true before this is done? > > hmm .. don't quite understand your comment: it's a flag to tell cancelEdit to not update control's editing state (that whole block is simply extracted from the pre-fix state .. where it has been for ages ;) So the answer is most probably no :) I see the updateEditingIndex is used as a hacky flag as the comment says, and `table.edit(-1, null)` is called conditionally. But my question is about the pre- and postconditions. What would happen if a subclass overrides `cancelEdit` and throws an exception, so that `updateEditingIndex = true` is not called after the `cancelEdit`? In that case, `updateEditingIndex` stays false. I'm not saying this is an issue, just wondering about this as this flag does an important thing -- and I do know this was in the code before the PR, so the PR is definitely an improvement, I'm just thinking that this might be an opportunity to deal with the precondition that updateEditingIndex *should* be true when entering the method and false when leaving the method. ------------- PR: https://git.openjdk.java.net/jfx/pull/473 From jvos at openjdk.java.net Wed Apr 21 17:58:35 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 21 Apr 2021 17:58:35 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) [v2] In-Reply-To: References: <-F2XbLZjjrtSZ6HA1ffPkrTkyP3SJSc-cqU3OoHromk=.3189d0c5-a75a-48e9-a05d-dd0c4812b578@github.com> Message-ID: On Tue, 13 Apr 2021 08:43:07 GMT, Alexander Scherbatiy wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove mt.exe from win.gradle build script > > I removed `ext.MC = cygpath("$winSdkBinDir/mt.exe")` line from `win.gradle` because it was used for building jdk.packager module [openjfx/11-dev/rt/build.gradle](https://hg.openjdk.java.net/openjfx/11-dev/rt/file/81e1980f9d54/build.gradle#l2916) and now jdk.packager is removed from jfx. @AlexanderScherbatiy I think this is good to get in now, can you /integrate it? ------------- PR: https://git.openjdk.java.net/jfx/pull/439 From michaelstrau2 at gmail.com Wed Apr 21 18:17:54 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 21 Apr 2021 20:17:54 +0200 Subject: Support :focus-visible CSS pseudoclass Message-ID: JavaFX currently doesn't support the :focus-visible CSS pseudoclass, which allows developers to create styles that differentiate between logical and visual focus. This severly limits developers from implementing the look&feel of many contemporary UI designs. For example, Microsoft's Fluent design uses modality-aware focus indicators in almost all implementations. I propose adding support for this pseudoclass with the following behavior: The :focus-visible pseudoclass in JavaFX would be set in addition to the :focused pseudoclass if a control gained focus as a consequence of keyboard input. In all other cases, the :focus-visible pseudoclass would not be set on a control. Additionally, a control loses its :focus-visible pseudoclass if it receives interaction with mouse or touch. https://github.com/openjdk/jfx/pull/475 https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible From github.com+2179736+matthiasblaesing at openjdk.java.net Wed Apr 21 18:26:35 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Wed, 21 Apr 2021 18:26:35 GMT Subject: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2] In-Reply-To: References: <97RUg0xMMll5kC0ZaVei09xPaV8iBcsuxRy0VxYTPSg=.a25d8b44-c131-4e72-be77-740bbcdc9739@github.com> <-69UnWnGCbsKhY0IrcJarv6sR-uH-zjsr5Usns40iV0=.4fc2fb96-966b-40eb-a897-79e35297c8a2@github.com> <9SHm6cYC3n7KZ_IWnB6_1CP76Ru4cjGuN2sMJfEULXA=.d1025f3c-4649-4be5-b589-e84d62aca613@github.com> Message-ID: On Thu, 15 Apr 2021 18:19:05 GMT, Johan Vos wrote: >>> The question is: Is there a second issue? >> >> If we don't have an example where a thread that isn't attached to the JVM already calls into these APIs, then it seems like the second issue is just hypothetical. >> >> In any case, it seems best to separate it out. >> >> @johanvos Do you have a case where it is actually failing as a result of a thread not being attached? > >> @johanvos Do you have a case where it is actually failing as a result of a thread not being attached? > > No, I don't have a usecase for that. Hence, as long as there is no trace that can lead to this, I agree this (calling the Attach/Detach) doesn't need to be added. @johanvos thanks for review and sponsoring! ------------- PR: https://git.openjdk.java.net/jfx/pull/458 From johan.vos at gluonhq.com Wed Apr 21 19:06:23 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 21 Apr 2021 21:06:23 +0200 Subject: Monocle, headless isolated from embedded Message-ID: Hi, Related to the issue at https://bugs.openjdk.java.net/browse/JDK-8265633, I want to add a general observation and trigger a discussion: I hear from more users who want to bundle Monocle with desktop distributions. However, I don't think Monocle is ready at this moment to be bundled with the desktop releases. We can add other bundles to the Gluon downloads, including desktop bundles that contain Monocle but those would mainly be unsupported. Most of the requests to bundle are because a headless platform is requested, which happens to be provided by Monocle. I think it might make sense to move the headless platform out of Monocle into its own -Dglass.platform component, so that it can easier be bundled, without adding to much requirements to the embedded platforms supported by Monocle. - Johan From kevin.rushforth at oracle.com Wed Apr 21 22:15:39 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Apr 2021 15:15:39 -0700 Subject: JavaFX 11 updates moving to GitHub on Wed, Apr 28 Message-ID: