From arapte at openjdk.java.net Mon May 2 11:35:49 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 11:35:49 GMT Subject: [jfx17u] Integrated: 8278759: PointerEvent: buttons property set to 0 when mouse down In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 17:06:02 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: dd592f13 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/dd592f13ca63abc1691b8eeff01bb03abf6ca6dc Stats: 302 lines in 8 files changed: 293 ins; 1 del; 8 mod 8278759: PointerEvent: buttons property set to 0 when mouse down Backport-of: 2e8a4a5e97bb88a5807ae5fe075b98e1d54a4ca0 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/44 From arapte at openjdk.java.net Mon May 2 11:38:54 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 11:38:54 GMT Subject: [jfx17u] Integrated: 8255940: localStorage is null after window.close() In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 17:07:27 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: ca7303ce Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/ca7303ce40e38848a7e606b940f376e979f6e187 Stats: 168 lines in 4 files changed: 167 ins; 0 del; 1 mod 8255940: localStorage is null after window.close() Backport-of: 5112be957be70dd6521e6fb6ee64e669c148729c ------------- PR: https://git.openjdk.java.net/jfx17u/pull/45 From arapte at openjdk.java.net Mon May 2 11:41:55 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 11:41:55 GMT Subject: [jfx17u] Integrated: 8269115: WebView paste event contains old data In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 17:08:56 GMT, Ambarish Rapte wrote: > Reviewed-by: arapte, kcr This pull request has now been integrated. Changeset: cc835ba1 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/cc835ba1fe0a135e82c6e6461f67e3ff56cf7b37 Stats: 120 lines in 3 files changed: 108 ins; 3 del; 9 mod 8269115: WebView paste event contains old data Backport-of: 2338821bdbb7db929a89aa89903271dcff333a5c ------------- PR: https://git.openjdk.java.net/jfx17u/pull/46 From arapte at openjdk.java.net Mon May 2 11:46:50 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 11:46:50 GMT Subject: [jfx17u] Integrated: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 17:10:09 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 8e52c7be Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/8e52c7bee8cd4e5aa83a6ea33572cd41026f9776 Stats: 192 lines in 2 files changed: 182 ins; 2 del; 8 mod 8280020: Underline and line-through not straight in WebView Backport-of: 263db3df5fdf9e0f6955be6ae58173aa589e55fe ------------- PR: https://git.openjdk.java.net/jfx17u/pull/47 From arapte at openjdk.java.net Mon May 2 11:46:54 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 11:46:54 GMT Subject: [jfx17u] Integrated: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: <0meS5B10zkuVCKFeibITX6n2K3WqC8HLPibHV2GHJz8=.df2cdfed-363d-44cc-ba9e-1da2e43994af@github.com> References: <0meS5B10zkuVCKFeibITX6n2K3WqC8HLPibHV2GHJz8=.df2cdfed-363d-44cc-ba9e-1da2e43994af@github.com> Message-ID: On Fri, 29 Apr 2022 17:14:21 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, jbhaskar This pull request has now been integrated. Changeset: 367f3d5a Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/367f3d5a8227aeb83af5fbc646329c860ca0fcdc Stats: 142 lines in 2 files changed: 1 ins; 141 del; 0 mod 8270867: Debug build of WebKit 613.1 fails on Linux Backport-of: eb7fa5dd1c0911bca15576060691d884d29895a1 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/48 From arapte at openjdk.java.net Mon May 2 11:57:18 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 11:57:18 GMT Subject: [jfx17u] Integrated: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Changes: https://git.openjdk.java.net/jfx17u/pull/51/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=51&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284184 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/51/head:pull/51 PR: https://git.openjdk.java.net/jfx17u/pull/51 From arapte at openjdk.java.net Mon May 2 11:57:18 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 11:57:18 GMT Subject: [jfx17u] Integrated: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ In-Reply-To: References: Message-ID: On Mon, 2 May 2022 11:48:02 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 13ca8ee8 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/13ca8ee891486b17551f55ef93532a703de37c3e Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Backport-of: 64da125f05f2a25038ce3370c8fe7c0baf0a354b ------------- PR: https://git.openjdk.java.net/jfx17u/pull/51 From arapte at openjdk.java.net Mon May 2 12:00:56 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 12:00:56 GMT Subject: [jfx11u] RFR: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 13:39:32 GMT, Kevin Rushforth wrote: > Simple backport to `jfx11u`. It isn't a clean backport since the mainline patch had an update to `gradle/verification-metadata.xml`, which doesn't exist in 11. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/95 From arapte at openjdk.java.net Mon May 2 12:05:59 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 May 2022 12:05:59 GMT Subject: [jfx11u] RFR: 8274274: Update JUnit to version 5.8.1 In-Reply-To: References: Message-ID: <8VRWkcBerhZ8iS8B0OSozyq7Irl7hZFb6HOQm50zRmw=.637685dd-5b31-4eae-9d23-f49e415075e4@github.com> On Sat, 30 Apr 2022 13:45:39 GMT, Kevin Rushforth wrote: > Nearly clean backport to `jfx11u`. It isn't a clean backport since the mainline patch updated `gradle/verification-metadata.xml`, which doesn't exist in 11. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/97 From jvos at openjdk.java.net Mon May 2 12:38:51 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 May 2022 12:38:51 GMT Subject: [jfx17u] Integrated: 8274137: TableView scrollbar/header misaligned when reloading data In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 18:44:09 GMT, Johan Vos wrote: > Reviewed-by: kcr, aghaisas This pull request has now been integrated. Changeset: ca0e5a47 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/ca0e5a4752e3a0ab2c9b6950c61678b4b07c4749 Stats: 34 lines in 3 files changed: 34 ins; 0 del; 0 mod 8274137: TableView scrollbar/header misaligned when reloading data Backport-of: b591912c749edef1e6c1b8509a8ea10e9fe9000f ------------- PR: https://git.openjdk.java.net/jfx17u/pull/49 From jvos at openjdk.java.net Mon May 2 12:40:55 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 May 2022 12:40:55 GMT Subject: [jfx17u] Integrated: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 18:48:06 GMT, Johan Vos wrote: > Reviewed-by: kcr, mstrauss This pull request has now been integrated. Changeset: 83534e2d Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/83534e2df8f4d20a661ae68c1c6f9925302953e3 Stats: 29 lines in 5 files changed: 19 ins; 2 del; 8 mod 8276553: ListView scrollTo() is broken after fix for JDK-8089589 Backport-of: d3fbb516c428876bd2389bbfd40f95a811ea6af8 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/50 From jvos at openjdk.java.net Mon May 2 13:23:22 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 May 2022 13:23:22 GMT Subject: [jfx17u] Integrated: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element Message-ID: Reviewed-by: aghaisas, jvos ------------- Commit messages: - 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element Changes: https://git.openjdk.java.net/jfx17u/pull/52/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=52&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276167 Stats: 42 lines in 4 files changed: 37 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx17u/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/52/head:pull/52 PR: https://git.openjdk.java.net/jfx17u/pull/52 From jvos at openjdk.java.net Mon May 2 13:23:22 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 May 2022 13:23:22 GMT Subject: [jfx17u] Integrated: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element In-Reply-To: References: Message-ID: <0k_nI6pcsynnM_icLqudTHHiO1908WpX4Mdnv_60IYQ=.1c707d09-5ac1-427a-b030-b1dc41d4bfbf@github.com> On Mon, 2 May 2022 13:14:05 GMT, Johan Vos wrote: > Reviewed-by: aghaisas, jvos This pull request has now been integrated. Changeset: 62ab00bd Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/62ab00bd5c8913fb8089b3d02404366db1d52c37 Stats: 42 lines in 4 files changed: 37 ins; 0 del; 5 mod 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element Backport-of: 115833923a644be8328b8f7a7a6845e5b42a57b3 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/52 From kcr at openjdk.java.net Mon May 2 13:25:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 May 2022 13:25:53 GMT Subject: [jfx11u] Integrated: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 13:39:32 GMT, Kevin Rushforth wrote: > Simple backport to `jfx11u`. It isn't a clean backport since the mainline patch had an update to `gradle/verification-metadata.xml`, which doesn't exist in 11. This pull request has now been integrated. Changeset: e877f305 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/e877f305edbb9c00cee091470049f7873c4f208e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8281564: Update cmake to 3.22.3 Reviewed-by: arapte Backport-of: d960d639dc6e37de0cdb69075a31a17090b83a3d ------------- PR: https://git.openjdk.java.net/jfx11u/pull/95 From kcr at openjdk.java.net Mon May 2 13:27:52 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 May 2022 13:27:52 GMT Subject: [jfx11u] Integrated: 8274274: Update JUnit to version 5.8.1 In-Reply-To: References: Message-ID: <5JADk0sfhXgIU1HTWMKuOVmZq71L3XNdi1mV1j1c8Mo=.776e20e8-cfdd-4653-88b1-5fe7c579f465@github.com> On Sat, 30 Apr 2022 13:45:39 GMT, Kevin Rushforth wrote: > Nearly clean backport to `jfx11u`. It isn't a clean backport since the mainline patch updated `gradle/verification-metadata.xml`, which doesn't exist in 11. This pull request has now been integrated. Changeset: 44e691e4 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/44e691e4811bac2202e2b8ee992f35937ec06f54 Stats: 63 lines in 4 files changed: 58 ins; 3 del; 2 mod 8274274: Update JUnit to version 5.8.1 Reviewed-by: arapte Backport-of: ff6e8d50badd57549811391b1380707bb94ac55b ------------- PR: https://git.openjdk.java.net/jfx11u/pull/97 From kcr at openjdk.java.net Mon May 2 13:40:52 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 May 2022 13:40:52 GMT Subject: [jfx11u] Integrated: 8283218: Update GStreamer to 1.20.1 In-Reply-To: <-uIlyw7rSlwjLvHKqEH5GcO323mjO82C3r9uWHztGRI=.35e628ce-ec14-42a3-88a1-ada480236dfd@github.com> References: <-uIlyw7rSlwjLvHKqEH5GcO323mjO82C3r9uWHztGRI=.35e628ce-ec14-42a3-88a1-ada480236dfd@github.com> Message-ID: On Sat, 30 Apr 2022 13:37:08 GMT, Kevin Rushforth wrote: > Backport to `jfx11u`. Tested in connection with libffi update in the `test-kcr-11.0.16` branch. > > This was not a clean backport, but the merge conflicts were trivial to resolve. Here is a summary of the changes. The jfx mainline patch applied cleanly to all other files. > > 1. The following file is not present in jfx11u, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c > > > 2. The following files had minor merge conflicts, the first was a diff in surrounding context and the rest were in copyright header blocks: > > > modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile > modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > modules/javafx.media/src/tools/native/def-glib.pl > modules/javafx.media/src/tools/native/def-gstlite.pl This pull request has now been integrated. Changeset: d0df8471 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/d0df8471c4e38e0b0dfae0e83848316694033002 Stats: 38984 lines in 412 files changed: 22060 ins; 5959 del; 10965 mod 8283218: Update GStreamer to 1.20.1 8283403: Update Glib to 2.72.0 Reviewed-by: jvos Backport-of: c4b1a72cc4d9253d1320d83281d50fb1f3bb6145 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/94 From kcr at openjdk.java.net Mon May 2 13:40:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 May 2022 13:40:53 GMT Subject: [jfx11u] Integrated: 8276174: JavaFX build fails on macOS aarch64 In-Reply-To: <8JuLLVSlPMkKqM35Vhwyj1CXbI0X2wCfmDysH2z_RYw=.c47aa197-04f0-428e-9dd6-55228935983a@github.com> References: <8JuLLVSlPMkKqM35Vhwyj1CXbI0X2wCfmDysH2z_RYw=.c47aa197-04f0-428e-9dd6-55228935983a@github.com> Message-ID: On Sat, 30 Apr 2022 13:51:23 GMT, Kevin Rushforth wrote: > Backport to `jfx11u` so we can build on macOS / aarch64 without needing to specify `-PCOMPILE_TARGET=arm64`. It isn't a clean backport, since I also had to include the definition of `IS_AARCH64` which is present in mainline, but not in `jfx11u` (it was added as part of another unrelated fix that isn't backported to `jfx11u`). This pull request has now been integrated. Changeset: ac52af6e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/ac52af6ed3535f687e2026d2afd398aac4111e84 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8276174: JavaFX build fails on macOS aarch64 Reviewed-by: jvos Backport-of: d289db94d15e49ed28f797b516ffccf023fce9c9 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/100 From kcr at openjdk.java.net Mon May 2 13:40:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 May 2022 13:40:53 GMT Subject: [jfx11u] Integrated: 8280840: Update libFFI to 3.4.2 In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 13:30:49 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. Tested in connection with gstreamer / glib update in the `test-kcr-11.0.16` branch. This pull request has now been integrated. Changeset: 1e4862f4 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/1e4862f436d17c409f0a33645a413acc771b731e Stats: 3475 lines in 34 files changed: 927 ins; 38 del; 2510 mod 8280840: Update libFFI to 3.4.2 Backport-of: 1beb3235223452929ec951ee18dd30a5345307cf ------------- PR: https://git.openjdk.java.net/jfx11u/pull/93 From kcr at openjdk.java.net Mon May 2 13:46:21 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 May 2022 13:46:21 GMT Subject: [jfx11u] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Message-ID: This PR is dependent on #97 so it is in Draft for now. Once #97 is integrated, I will rebase this and submit it, at which time it will be a clean backport, and the diffs will only show the updated test. ------------- Commit messages: - 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Changes: https://git.openjdk.java.net/jfx11u/pull/98/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=98&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280275 Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/98.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/98/head:pull/98 PR: https://git.openjdk.java.net/jfx11u/pull/98 From kcr at openjdk.java.net Mon May 2 13:50:45 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 May 2022 13:50:45 GMT Subject: [jfx11u] Integrated: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases In-Reply-To: References: Message-ID: <-E8fiRP9a5Kj6g3zgtGV1kzpkBt-sTafvp9AENJRNnA=.2ed50587-8d05-4ac9-aca8-7176b09cbf1f@github.com> On Sat, 30 Apr 2022 13:48:01 GMT, Kevin Rushforth wrote: > This PR is dependent on #97 so it is in Draft for now. Once #97 is integrated, I will rebase this and submit it, at which time it will be a clean backport, and the diffs will only show the updated test. This pull request has now been integrated. Changeset: f01fc732 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/f01fc732ac0972a79c1c5b397b23df38ba3a2004 Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Backport-of: 94807b6edfb9af55be353cab237e8e64007c61dc ------------- PR: https://git.openjdk.java.net/jfx11u/pull/98 From nlisker at openjdk.java.net Mon May 2 16:11:20 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 2 May 2022 16:11:20 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline Message-ID: Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. Since there are many small changes, I'm giving a full list here: **Java** * `NGShape3D.java` * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. * Normalized the direction here instead of in the native code. * Ambient light is now only set when it exists (and is not black). * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. **Native C++** * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). * `D3DLight` * Commented out unused methods. Were they supposed to be used at some point? * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. * `D3DPhongShader.h` * Renamed some of the register constants for more clarity. * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. * `D3DMeshView.cc` * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. * Removed the direction normalization as stated in the change for `NGShape3D.java`. * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. **Native shaders** * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). * Commented out many unused functions. I don't know what they are for, so I didn't remove them. * `vsConstants` * Removed the light color from here since it's unused, only the position is. * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. * `vs2ps` * Removed the ambient color interpolation, which frees a register (no change in performance). * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump?). * `Mtl1PS` and `psMath` * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. No changes in performance were measured and the behavior stayed the same. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/789/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=789&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8217853 Stats: 624 lines in 18 files changed: 232 ins; 202 del; 190 mod Patch: https://git.openjdk.java.net/jfx/pull/789.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/789/head:pull/789 PR: https://git.openjdk.java.net/jfx/pull/789 From nlisker at openjdk.java.net Mon May 2 19:55:28 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 2 May 2022 19:55:28 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: References: Message-ID: > Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. > > Since there are many small changes, I'm giving a full list here: > > **Java** > > * `NGShape3D.java` > * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. > * Normalized the direction here instead of in the native code. > * Ambient light is now only set when it exists (and is not black). > * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). > * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. > > **Native C++** > > * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). > * `D3DLight` > * Commented out unused methods. Were they supposed to be used at some point? > * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. > * `D3DPhongShader.h` > * Renamed some of the register constants for more clarity. > * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. > * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. > * `D3DMeshView.cc` > * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. > * Removed the direction normalization as stated in the change for `NGShape3D.java`. > * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. > > **Native shaders** > * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). > * Commented out many unused functions. I don't know what they are for, so I didn't remove them. > * `vsConstants` > * Removed the light color from here since it's unused, only the position is. > * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. > * `vs2ps` > * Removed the ambient color interpolation, which frees a register (no change in performance). > * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump?). > * `Mtl1PS` and `psMath` > * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. > * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. > > No changes in performance were measured and the behavior stayed the same. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Remove unused comments, clean constructor ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/789/files - new: https://git.openjdk.java.net/jfx/pull/789/files/8db9c8ba..05281ba3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=789&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=789&range=00-01 Stats: 21 lines in 2 files changed: 0 ins; 18 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/789.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/789/head:pull/789 PR: https://git.openjdk.java.net/jfx/pull/789 From kcr at openjdk.java.net Tue May 3 22:51:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 May 2022 22:51:47 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 18:26:06 GMT, Jose Pereda wrote: > This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. > > This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. Since this fix is in shared code, have you tested this using multiple screens on all platforms? Are there new tests that could be written for this? ------------- PR: https://git.openjdk.java.net/jfx/pull/778 From jvos at openjdk.java.net Wed May 4 09:42:20 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 May 2022 09:42:20 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v5] In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Don't recalculate estimated size while doing a layout cycle. There are a number of paths possible that first calculate an offset/position, and later do a layoutChildren pass. The offset/position calculations (e.g. in scrollTo calls) assume a specific estimatedSize. If that size is changed between the first call and the layoutChildren logic, the result will not look as intended. Hence, we should avoid updating the estimated size at the start of the layout phase. We can do it safely at the end. Thanks to Zeiss and Florian Kirmaier for providing additional tests. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/2b1b4bdc..aa08ba26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=03-04 Stats: 116 lines in 2 files changed: 115 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712 From jpereda at openjdk.java.net Wed May 4 16:03:20 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 4 May 2022 16:03:20 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v2] In-Reply-To: References: Message-ID: <9oZ8awiMoIjzNkMVXfWe4ClZGvGzVkvHTa5RjY8yhI8=.4532360a-4b84-45b2-90be-886537ee8055@github.com> > This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. > > This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Rollback change, move to new screen created via native if handler changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/778/files - new: https://git.openjdk.java.net/jfx/pull/778/files/233e29c6..6fcbd9be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=778&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=778&range=00-01 Stats: 40 lines in 4 files changed: 23 ins; 4 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/778.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/778/head:pull/778 PR: https://git.openjdk.java.net/jfx/pull/778 From jpereda at openjdk.java.net Wed May 4 16:16:27 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 4 May 2022 16:16:27 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v2] In-Reply-To: <9oZ8awiMoIjzNkMVXfWe4ClZGvGzVkvHTa5RjY8yhI8=.4532360a-4b84-45b2-90be-886537ee8055@github.com> References: <9oZ8awiMoIjzNkMVXfWe4ClZGvGzVkvHTa5RjY8yhI8=.4532360a-4b84-45b2-90be-886537ee8055@github.com> Message-ID: On Wed, 4 May 2022 16:03:20 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. >> >> This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Rollback change, move to new screen created via native if handler changes You are right, the proposed change was intended only for Android but was touching shared code for all platforms. Based on the comment "Note that if a window has moved to another screen...", and considering that this could apply to the Android case (the initial screen gets destroyed and a new screen is created when app resumes), I have now another solution that does the same but that is mostly on the Android side (`MonocleWindowManager::repaintFromNative` was only called from Android native anyway), with a small change in `MonocleWindow` though, as `Window::notifyMoveToAnotherScreen` has protected access. ------------- PR: https://git.openjdk.java.net/jfx/pull/778 From jpereda at openjdk.java.net Wed May 4 16:55:30 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 4 May 2022 16:55:30 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3] In-Reply-To: References: Message-ID: > This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. > > This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Scale screen dimensions ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/778/files - new: https://git.openjdk.java.net/jfx/pull/778/files/6fcbd9be..28129038 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=778&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=778&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/778.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/778/head:pull/778 PR: https://git.openjdk.java.net/jfx/pull/778 From arapte at openjdk.java.net Thu May 5 13:50:31 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 5 May 2022 13:50:31 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 This change fixes the exact issue that is reported in [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654). But I observed another issue that occurs with this change. Steps: 1. Run the sample attached to [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654). 2. Click button One and Two both once 3. Re-arrange both the windows such that they are visible. 4. Click the button "Click here" in Window Two: Error dialog will be displayed 5. Click anywhere in Window One 6. Close the Error dialog => Observe that Window One gets the focus and not Window Two. I think the expected behavior here should be: After closing a dialog the Focus should return to its parent window. ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From jpereda at openjdk.java.net Thu May 5 16:27:54 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 5 May 2022 16:27:54 GMT Subject: RFR: 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView Message-ID: This PR fixes an issue with selection of multiple items in TableView and TreeTableView controls that gets moved unexpectedly when new items are added even way below the selected items. A couple of tests have been added. They fail without this PR (first selected item gets deselected, and table anchor gets moved), and pass with this PR (first selected item keeps selected, and table anchor remains at the same place). ------------- Commit messages: - Only shift anchor if existing one is affected by the change event, and tests Changes: https://git.openjdk.java.net/jfx/pull/790/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=790&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284665 Stats: 100 lines in 4 files changed: 98 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/790.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/790/head:pull/790 PR: https://git.openjdk.java.net/jfx/pull/790 From jgneff at openjdk.java.net Fri May 6 05:11:05 2022 From: jgneff at openjdk.java.net (John Neffenger) Date: Fri, 6 May 2022 05:11:05 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v6] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 06:43:30 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Get build timestamp in UTC and set ZIP timestamps > > Create the build timestamp as a zoned date and time in UTC instead > of a local date and time. If SOURCE_DATE_EPOCH is defined, set the > last modification time of ZIP and JAR entries to the local date and > time in UTC of the instant defined by SOURCE_DATE_EPOCH. > > Add a comment as a reminder to make JMOD files deterministic when > the following enhancements are complete: > > * Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > https://github.com/openjdk/jdk/pull/6395 > > * Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > https://github.com/openjdk/jdk/pull/6481 > - Merge branch 'master' into allow-reproducible-builds > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > - Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll > - Enable reproducible builds with SOURCE_DATE_EPOCH > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Good news: starting today, the JDK can create reproducible builds of the JDK! Specifically, JDK 19+21 includes [pull request 8478][1], which was the last reproducibility bug remaining in my JDK builds on Linux. JDK 19 also includes [pull request 6481][2], which is the change we need in JavaFX for reproducible JMOD archives. Because the JMOD fix is in JDK 19 and JDK 17.0.3 but not JDK 18, we can either integrate this pull request now and add the one-line JMOD fix after we're building on JDK 19, or wait to integrate all of the changes after switching to JDK 19. Most of the changes in this pull request are behind a big feature flag called `SOURCE_DATE_EPOCH`, so I think it's safe either way. In either case, we will still need to fix the build path problem (item number 4 in the first comment), and the problem with the JavaFX WebKit library `libjfxwebkit`, but I prefer to address those issues separately. By the way, I'm hoping the WebKit problem might be [Bug 237506][3], "[GTK] generate-automation-atom.py breaks reproducible builds," but I really have no idea yet. I'll push the commits that include the JMOD fix (commented out for now) and the merged updates from the *master* branch. I'm also doing another round of testing and will post the results shortly. [1]: https://github.com/openjdk/jdk/pull/8478 [2]: https://github.com/openjdk/jdk/pull/6481 [3]: https://bugs.webkit.org/show_bug.cgi?id=237506 ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jpereda at openjdk.java.net Fri May 6 10:23:15 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 6 May 2022 10:23:15 GMT Subject: RFR: 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants Message-ID: This PR extends the check if a treeItem is expanded to all its ancestors, as in case one ancestor is collapsed, all its children will be hidden. 4 tests are included, two for TreeView and two for TreeTableView. ------------- Commit messages: - Check if treeItem and all its ancestors are expanded, including tests Changes: https://git.openjdk.java.net/jfx/pull/791/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=791&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286261 Stats: 179 lines in 5 files changed: 171 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/791.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/791/head:pull/791 PR: https://git.openjdk.java.net/jfx/pull/791 From tsayao at openjdk.java.net Fri May 6 13:40:58 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 6 May 2022 13:40:58 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: On Thu, 5 May 2022 13:46:56 GMT, Ambarish Rapte wrote: >> When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. >> >> The fix also works for: >> https://bugs.openjdk.java.net/browse/JDK-8269429 >> >> But this one might need another fix: >> https://bugs.openjdk.java.net/browse/JDK-8240640 > > This change fixes the exact issue that is reported in [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654). > and [JDK-8240640](https://bugs.openjdk.java.net/browse/JDK-8240640) does not reproduce with this change. > > > But I observed another issue that occurs with this change. > Steps: > 1. Run the sample attached to [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654). > 2. Click button One and Two both once > 3. Re-arrange both the windows such that they are visible. > 4. Click the button "Click here" in Window Two: Error dialog will be displayed > 5. Click anywhere in Window One > 6. Close the Error dialog > => Observe that Window One gets the focus and not Window Two. > > I think the expected behavior here should be: After closing a dialog the Focus should return to its parent window. @arapte I think it's another bug on Linux, as the window should not accept focus when disabled, so it should not reorder windows when you click it ("Window One" on step 5). Did you test it on Linux? ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From mstrauss at openjdk.java.net Fri May 6 14:30:06 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 May 2022 14:30:06 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: References: Message-ID: <7RdwRufm3wNe7zLMKxpH2WVWhF5wTvPJ9PO9snTQVrQ=.9564f03d-eb1f-4c81-8658-a0947ce17af6@github.com> On Mon, 2 May 2022 19:55:28 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some point? >> * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. >> * Removed the direction normalization as stated in the change for `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position is. >> * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused comments, clean constructor modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.h line 34: > 32: public: > 33: D3DLight() = default; > 34: virtual ~D3DLight() = default; It doesn't seem like this class is supposed to be subclassable. I would suggest removing the constructor and destructor declarations and marking the class `final`. modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 149: > 147: float spotLightsFactors[MAX_NUM_LIGHTS * 4]; // 2 angles + 1 falloff + 1 padding > 148: for (int i = 0, d = 0, p = 0, c = 0, a = 0, r = 0, s = 0; i < MAX_NUM_LIGHTS; i++) { > 149: D3DLight light = lights[i]; You're invoking the auto-generated copy constructor of `D3DLight` here, where the original code didn't do that. Just making sure that that's what you intended. modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.h line 61: > 59: bool lightsDirty = TRUE; > 60: int cullMode = D3DCULL_NONE; > 61: bool wireframe = FALSE; It seems like you're using `false` and `FALSE` interchangably (see `D3DPhongMaterial.h` L58). I would suggest using the `false` keyword with the builtin type `bool`, and the `FALSE` constant with the Win32 type `BOOL`. ------------- PR: https://git.openjdk.java.net/jfx/pull/789 From tsayao at openjdk.java.net Fri May 6 19:21:02 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 6 May 2022 19:21:02 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 Step 5 falls on: mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); which is correct, so might be a bug on java code. ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From nlisker at openjdk.java.net Fri May 6 19:28:01 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 May 2022 19:28:01 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: <7RdwRufm3wNe7zLMKxpH2WVWhF5wTvPJ9PO9snTQVrQ=.9564f03d-eb1f-4c81-8658-a0947ce17af6@github.com> References: <7RdwRufm3wNe7zLMKxpH2WVWhF5wTvPJ9PO9snTQVrQ=.9564f03d-eb1f-4c81-8658-a0947ce17af6@github.com> Message-ID: <7CF6sF9lEFSS7SCkQBol2ns5kptgld4u08okyyed_dg=.23e3510a-3eab-4f3f-8f6b-f1db1e5d81f6@github.com> On Fri, 6 May 2022 14:21:58 GMT, Michael Strau? wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused comments, clean constructor > > modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.h line 61: > >> 59: bool lightsDirty = TRUE; >> 60: int cullMode = D3DCULL_NONE; >> 61: bool wireframe = FALSE; > > It seems like you're using `false` and `FALSE` interchangably (see `D3DPhongMaterial.h` L58). I would suggest using the `false` keyword with the builtin type `bool`, and the `FALSE` constant with the Win32 type `BOOL`. The original code used the Win-only type. I thought it should be changed too. I should probably do that, ------------- PR: https://git.openjdk.java.net/jfx/pull/789 From nlisker at openjdk.java.net Fri May 6 19:31:58 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 May 2022 19:31:58 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: <7RdwRufm3wNe7zLMKxpH2WVWhF5wTvPJ9PO9snTQVrQ=.9564f03d-eb1f-4c81-8658-a0947ce17af6@github.com> References: <7RdwRufm3wNe7zLMKxpH2WVWhF5wTvPJ9PO9snTQVrQ=.9564f03d-eb1f-4c81-8658-a0947ce17af6@github.com> Message-ID: On Fri, 6 May 2022 14:09:13 GMT, Michael Strau? wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused comments, clean constructor > > modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.h line 34: > >> 32: public: >> 33: D3DLight() = default; >> 34: virtual ~D3DLight() = default; > > It doesn't seem like this class is supposed to be subclassable. I would suggest removing the constructor and destructor declarations and marking the class `final`. It might be subclassed in the future. One of the next changes will be a performance upgrade attempt, and we might need to separate the light types instead of bundling them into one that simulates the others. In theory, this class can be removed even, and instead the Java code could call the rendering pipeline directly with all the needed parameters. It's a more intrusive change though, and might as well wait for Panama with this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/789 From kcr at openjdk.java.net Fri May 6 20:52:58 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 May 2022 20:52:58 GMT Subject: RFR: 8283318: Videos with unusual sizes cannot be played on windows In-Reply-To: <2DA94ImMDRo3BGA4n_HefL32uNXihLRX71vf1aojk4Y=.c1800e7f-019a-4a09-8aa1-4f708c36bbac@github.com> References: <2DA94ImMDRo3BGA4n_HefL32uNXihLRX71vf1aojk4Y=.c1800e7f-019a-4a09-8aa1-4f708c36bbac@github.com> Message-ID: On Tue, 19 Apr 2022 22:38:13 GMT, Alexander Matveev wrote: > Fixed by removing check which enables dynamic format change, since it requires for portrait videos, not standard resolutions and anything that has width > 1920 or/and height > 1080. Looks good. I confirm that it fixes the problem. This is a simple enough change that a single reviewer is sufficient. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/775 From almatvee at openjdk.java.net Fri May 6 21:06:00 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 6 May 2022 21:06:00 GMT Subject: Integrated: 8283318: Videos with unusual sizes cannot be played on windows In-Reply-To: <2DA94ImMDRo3BGA4n_HefL32uNXihLRX71vf1aojk4Y=.c1800e7f-019a-4a09-8aa1-4f708c36bbac@github.com> References: <2DA94ImMDRo3BGA4n_HefL32uNXihLRX71vf1aojk4Y=.c1800e7f-019a-4a09-8aa1-4f708c36bbac@github.com> Message-ID: <7Q8zTcYSAdZIZG_rkDGOjicc3XuV1ZVdsGfL9e5LM5g=.0bfc8a68-e822-4a76-be23-4a08d7113391@github.com> On Tue, 19 Apr 2022 22:38:13 GMT, Alexander Matveev wrote: > Fixed by removing check which enables dynamic format change, since it requires for portrait videos, not standard resolutions and anything that has width > 1920 or/and height > 1080. This pull request has now been integrated. Changeset: ee7f23d5 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/ee7f23d562ebb46ddcfdeff42d1f1855d60f7a65 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8283318: Videos with unusual sizes cannot be played on windows Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/775 From kcr at openjdk.java.net Fri May 6 21:46:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 May 2022 21:46:47 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:55:30 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. >> >> This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Scale screen dimensions I like this approach better. Since it just touches Monocle, and most changes are in the android port, perhaps @johanvos can review it? ------------- PR: https://git.openjdk.java.net/jfx/pull/778 From kcr at openjdk.java.net Fri May 6 23:17:51 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 May 2022 23:17:51 GMT Subject: RFR: 8285534: Update the 3D lighting test sample [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:28:34 GMT, Nir Lisker wrote: >> Update the the test utility. Includes: >> * Refactoring since there is no more need the split pre- and post-attenuation and light types. >> * Added customizable material to the `Boxes` to test the interaction between lights and materials.. >> * Light colors can now be changed. >> * Added ambient lights, >> >> Note that GitHub decided to count the removal of the `AttenLightingSample` and addition of the `Controls` file as renaming. The sample is now run now only through `LightingSample`. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added ambient lights This looks like a nice improvement to the test app. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/787 From nlisker at openjdk.java.net Fri May 6 23:20:48 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 May 2022 23:20:48 GMT Subject: Integrated: 8285534: Update the 3D lighting test sample In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 11:47:45 GMT, Nir Lisker wrote: > Update the the test utility. Includes: > * Refactoring since there is no more need the split pre- and post-attenuation and light types. > * Added customizable material to the `Boxes` to test the interaction between lights and materials.. > * Light colors can now be changed. > * Added ambient lights, > > Note that GitHub decided to count the removal of the `AttenLightingSample` and addition of the `Controls` file as renaming. The sample is now run now only through `LightingSample`. This pull request has now been integrated. Changeset: e24eeceb Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/e24eeceb28741f4a044ea2cb0cb23a1174b27c66 Stats: 551 lines in 5 files changed: 316 ins; 198 del; 37 mod 8285534: Update the 3D lighting test sample Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/787 From nlisker at openjdk.java.net Fri May 6 23:32:56 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 May 2022 23:32:56 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: <7RdwRufm3wNe7zLMKxpH2WVWhF5wTvPJ9PO9snTQVrQ=.9564f03d-eb1f-4c81-8658-a0947ce17af6@github.com> References: <7RdwRufm3wNe7zLMKxpH2WVWhF5wTvPJ9PO9snTQVrQ=.9564f03d-eb1f-4c81-8658-a0947ce17af6@github.com> Message-ID: On Fri, 6 May 2022 14:13:55 GMT, Michael Strau? wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused comments, clean constructor > > modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 149: > >> 147: float spotLightsFactors[MAX_NUM_LIGHTS * 4]; // 2 angles + 1 falloff + 1 padding >> 148: for (int i = 0, d = 0, p = 0, c = 0, a = 0, r = 0, s = 0; i < MAX_NUM_LIGHTS; i++) { >> 149: D3DLight light = lights[i]; > > You're invoking the auto-generated copy constructor of `D3DLight` here, where the original code didn't do that. Just making sure that that's what you intended. I will change to `D3DLight& light = lights[i];`. ------------- PR: https://git.openjdk.java.net/jfx/pull/789 From jgneff at openjdk.java.net Sat May 7 04:17:13 2022 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 7 May 2022 04:17:13 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: > > > $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > $ bash gradlew sdk jmods javadoc > $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod > > > The three commands: > > 1. set the build timestamp to the date of the latest source code change, > 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and > 3. recreate the JMOD files with stable file modification times and ordering. > > The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. > > #### Fixes > > There are at least four sources of non-determinism in the JavaFX builds: > > 1. Build timestamp > > The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. > > 2. Modification times > > The JAR, JMOD, and ZIP archives store the modification time of each file. > > 3. File ordering > > The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. > > 4. Build path > > The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. > > This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Comment out 'jmod --date' until building on JDK 19 Support for the 'jmod --date' option was added to JDK 19 starting with the 19+2 early-access build, and it was backported to JDK 17 starting with release 17.0.3. It is not available in JDK 18. - Merge 'master' into allow-reproducible-builds - Make minimal changes for new '--date' option - Add new '--date' option to JMOD task - Add '--source-date' option to JMOD task - Get build timestamp in UTC and set ZIP timestamps Create the build timestamp as a zoned date and time in UTC instead of a local date and time. If SOURCE_DATE_EPOCH is defined, set the last modification time of ZIP and JAR entries to the local date and time in UTC of the instant defined by SOURCE_DATE_EPOCH. Add a comment as a reminder to make JMOD files deterministic when the following enhancements are complete: * Enable deterministic file content ordering for Jar and Jmod https://bugs.openjdk.java.net/browse/JDK-8276764 https://github.com/openjdk/jdk/pull/6395 * Enable jar and jmod to produce deterministic timestamped content https://bugs.openjdk.java.net/browse/JDK-8276766 https://github.com/openjdk/jdk/pull/6481 - Merge branch 'master' into allow-reproducible-builds - Make build of SDK ZIP bundle reproducible - Merge branch 'master' into allow-reproducible-builds - Merge branch 'master' into allow-reproducible-builds - ... and 4 more: https://git.openjdk.java.net/jfx/compare/d69a498c...3fd4449b ------------- Changes: https://git.openjdk.java.net/jfx/pull/446/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=06 Stats: 147 lines in 7 files changed: 117 ins; 13 del; 17 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 Sat May 7 22:33:50 2022 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 7 May 2022 22:33:50 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 15:15:10 GMT, Kevin Rushforth wrote: >> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Make build of SDK ZIP bundle reproducible >> - Merge branch 'master' into allow-reproducible-builds >> - Merge branch 'master' into allow-reproducible-builds >> - Include WebKit shared library for Windows >> >> Enable reproducible builds of the native WebKit shared library for >> Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. >> - Include media shared libraries for Windows >> >> Enable reproducible builds of the native media shared libraries for >> Windows when SOURCE_DATE_EPOCH is defined. The libraries are: >> >> fxplugins.dll >> glib-lite.dll >> gstreamer-lite.dll >> jfxmedia.dll >> - Enable reproducible builds with SOURCE_DATE_EPOCH >> - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH > > Here are couple more observations, and then I'll need to put this on the back burner for a bit: > > 1. I did a CI build yesterday and again today on all three platforms and compared the sdk between the two builds for each platform. On all three platforms the results are the same: All files were identical except the native jfxwebkit library. So there is something in the WebKit build that is affected by an external input (perhaps the system date or similar). > 2. On Mac, at least, there are several differences in the dylib files between a build on my local system and on our CI system. I was using the same devkit and boot JDK on both, and both were the same version of macOS (10.15.7). Likely some difference in the software installed on the two systems matters. @kevinrushforth Thank you, Kevin, for your review comments back in September. Your comment about the time zone was extremely helpful and indirectly helped with [openjdk/jdk#6481][1] as well. I think I have addressed all of your concerns now. My more recent commits simply add the following line in preparation for creating reproducible JMOD archives: `// args("--date", buildTimestamp)`. That line needs to be commented out until JavaFX starts building with JDK 19. I ran another round of 30 builds, 10 on each platform, with no surprises. The only non-reproducible artifacts are the JMOD archives and the native WebKit shared library, as before. See my GitHub repository [jgneff/jfxbuild][2] for the build environment and shell scripts that I use to build and test JavaFX on Linux, macOS, and Windows. [1]: https://github.com/openjdk/jdk/pull/6481 [2]: https://github.com/jgneff/jfxbuild ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From perini.davide at dpsoftware.org Sat May 7 23:26:21 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 8 May 2022 01:26:21 +0200 Subject: Jpopupmenu Bug/Glitch When Showing Submenu Message-ID: Hi all, I'm using a JPopupMenu to workaround the lack of a "real tray icon" in JavaFX. This is the simple code I'm using: https://github.com/Sylvain-Bugat/tray-icon-skeleton/blob/master/src/main/java/com/github/sbugat/trayiconskeleton/TrayIconMainClass.java It all works well until I add a submenu (JMenu) to my JPopupMenu. This is how the tray looks when no glitch appear: and this is the tray how looks like when the glitch of the submenu appers: to trigger the glitch I can simply move the mouse over the submenu and then move the mouse over the other jmenuitem. Any idea on why I have this error? Thanks Davide From duke at openjdk.java.net Sun May 8 06:31:49 2022 From: duke at openjdk.java.net (Paul) Date: Sun, 8 May 2022 06:31:49 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v3] In-Reply-To: References: Message-ID: > I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. > > Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. > > Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- > > > if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { > NSSize imgSize = {width / sx, height / sy}; > [image setSize: imgSize]; > } > > > The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. > > Before this fix:- > > Screenshot 2022-02-26 at 22 16 30 > > After this fix:- > > Screenshot 2022-02-26 at 22 18 17 Paul has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Updated variable names to be a bit more consistent - Merge branch 'master' into JDK-8181084 - Merge branch 'master' into JDK-8181084 - Removing trailing whitespace. - Correctly scales hi-res icons in MacOS system menu items ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/743/files - new: https://git.openjdk.java.net/jfx/pull/743/files/3057f683..bb6d34fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=743&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=743&range=01-02 Stats: 40324 lines in 468 files changed: 22990 ins; 6262 del; 11072 mod Patch: https://git.openjdk.java.net/jfx/pull/743.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743 PR: https://git.openjdk.java.net/jfx/pull/743 From duke at openjdk.java.net Sun May 8 06:31:52 2022 From: duke at openjdk.java.net (Paul) Date: Sun, 8 May 2022 06:31:52 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v2] In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 10:23:23 GMT, Paul wrote: >> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. >> >> Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. >> >> Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- >> >> >> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { >> NSSize imgSize = {width / sx, height / sy}; >> [image setSize: imgSize]; >> } >> >> >> The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. >> >> Before this fix:- >> >> Screenshot 2022-02-26 at 22 16 30 >> >> After this fix:- >> >> Screenshot 2022-02-26 at 22 18 17 > > Paul 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 branch 'master' into JDK-8181084 > - Removing trailing whitespace. > - Correctly scales hi-res icons in MacOS system menu items Made a minor change to some variable names to be more consistent with how those values are referenced elsewhere and pulled in the latest upstream changes. Can anyone help me out with pushing this little tweak over the finishing line? ------------- PR: https://git.openjdk.java.net/jfx/pull/743 From jvos at openjdk.java.net Sun May 8 18:59:54 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 8 May 2022 18:59:54 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Mon, 25 Apr 2022 09:00:54 GMT, Florian Kirmaier wrote: >> I agree with that observation. The mathematical perfect situation would be to pre-calculate the height of all items, so that the scrolbar position can be exact, and the content placing can be exact as well. That would be at the price of a major performance overhead for large lists. For small lists, this overhead is more acceptable. >> >> I agree that this is something that could be rather application-defined instead of having heuristics in the ListView. >> >> As a historical note, before https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed, all items were considered of equali height for the position of the scrollbar. In the current case, if that precondition holds, the estimated size will be the real size, so in that case there is no need to calculate the height of every item before getting the correct total size. >> This is again something the application knows best -- even with non-fixed cell heights, the expected variations might be small enough and if they are randomly spread, the estimate will soon be "good enough". > > @johanvos > As requested, we've made a unit test, which tests this bug. > It's based on your test and our original test class. It can be added to the ListViewTest. > You can find it, in the JDK ticket. > > Btw, adding the cells incrementally seems to make a difference - which is why the new test class tests both cases. > > It accepts various inputs of cell sizes - and should work with any inputs. > It should catch all the cases from the original test class. > Because it works with all possible inputs - one could even make a random test-cases generator to make sure it works in every case. > > It basically only works well, when the sizes are only 20s - in most other cases it fails. The later reported issues were due to the fact that the estimatedSize got updated during the layoutChildren call. That makes things much more complicated and leads to discrepancies. I disabled the updates to the estimated size during the layoutChildren call, so that all operations that are happening in that call are using a consistent value of the estimated size. We now pass all the tests added by @FlorianKirmaier on the JBS issue . Those tests are great regression tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From fkirmaier at openjdk.java.net Mon May 9 07:50:02 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 9 May 2022 07:50:02 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Sun, 8 May 2022 18:56:45 GMT, Johan Vos wrote: >> @johanvos >> As requested, we've made a unit test, which tests this bug. >> It's based on your test and our original test class. It can be added to the ListViewTest. >> You can find it, in the JDK ticket. >> >> Btw, adding the cells incrementally seems to make a difference - which is why the new test class tests both cases. >> >> It accepts various inputs of cell sizes - and should work with any inputs. >> It should catch all the cases from the original test class. >> Because it works with all possible inputs - one could even make a random test-cases generator to make sure it works in every case. >> >> It basically only works well, when the sizes are only 20s - in most other cases it fails. > > The later reported issues were due to the fact that the estimatedSize got updated during the layoutChildren call. That makes things much more complicated and leads to discrepancies. I disabled the updates to the estimated size during the layoutChildren call, so that all operations that are happening in that call are using a consistent value of the estimated size. We now pass all the tests added by @FlorianKirmaier on the JBS issue . Those tests are great regression tests. @johanvos Hi Johan, Great to see all these unit tests getting green so fast! Unfortunately, the provided Test Application still behaves very buggy - I would even say it still is equally buggy, which is quite a suprise. Nevertheless, this is a great step forward. So there must be something the tests are missing. I haven't found out yet what. Maybe they will behave different, if they are executed as a system test, with a real window? I will keep you posted, when we've updated the tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From arapte at openjdk.java.net Mon May 9 08:32:56 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 9 May 2022 08:32:56 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: On Fri, 6 May 2022 13:37:22 GMT, Thiago Milczarek Sayao wrote: > Did you test it on Linux? I tested it on MacOS Catalina 10.15.7 > the window should not accept focus when disabled, The window does not really gets the focus. The button cannot be clicked. but it does bring the window in foreground. Yes, It may be a different bug. The similarity is that the focus does not go back to parent stage after closing the dialog. ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From tsayao at openjdk.java.net Mon May 9 14:54:55 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 9 May 2022 14:54:55 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage [v2] In-Reply-To: References: Message-ID: <9oD_w8pQGG9qZQM9FXJQCgsx8ugiznC-zD_Pj8NmBa8=.da05ef3e-bda9-4cac-b36d-5b1ae22f78cd@github.com> > When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Set the focus on the latest window when re-enabling them ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/784/files - new: https://git.openjdk.java.net/jfx/pull/784/files/72317b21..b024de58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=784&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=784&range=00-01 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/784.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/784/head:pull/784 PR: https://git.openjdk.java.net/jfx/pull/784 From tsayao at openjdk.java.net Mon May 9 14:54:56 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 9 May 2022 14:54:56 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 The test does not set the Window owner. It's one APPLICATION_MODAL window. I have adjusted the PR to handle this case. It will set focus on the latest opened window when re-enabling, but will not change stacking order. ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From perini.davide at dpsoftware.org Mon May 9 16:04:16 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 9 May 2022 18:04:16 +0200 Subject: Jpopupmenu Bug/Glitch When Showing Submenu In-Reply-To: References: Message-ID: <235d1d21-a44c-5c60-ae68-4eb7f9bf43a3@dpsoftware.org> I can't load images unfortunantly but this is the minimum code to reproduce the issue. It seems that there is no way to add JMenu to JPopupMenu without having this glitch. Is this a problem in JavaFX? I see non obvious errors in my code. Thanks Davide package org.dpsoftware; import org.dpsoftware.config.Constants; import org.dpsoftware.utilities.CommonUtility; import javax.swing.*; import java.awt.*; import java.awt.event.*; import java.io.IOException; import java.io.PrintWriter; import java.io.Serial; import java.io.StringWriter; import java.net.URI; import java.net.URISyntaxException; public class TrayIconMainClass { private static final StringTRAY_ICON_SKELETON_PROJECT_URL ="https://github.com/Sylvain-Bugat/tray-icon-skeleton"; /** Load the tray icon image to display in the tray bar*/ private static ImageTRAY_ICON_IMAGE = Toolkit.getDefaultToolkit().getImage( TrayIconMainClass.class.getClassLoader().getResource("tray_play.png" ) ); //$NON-NLS-1$ static JMenuaspectRatioSubMenu; /** * Main program launched in the jar file * * @param args * @throws IOException */ private void initializeImages() { // load an image } public static void main(final String args[] )throws IOException { aspectRatioSubMenu =new JMenu("dadsdsa"); JMenuItem menuItam =new JMenuItem("dada"); aspectRatioSubMenu.add(menuItam); //Test if the system support the system tray if( SystemTray.isSupported() ) { //Try to use the system Look&Feel try { UIManager.setLookAndFeel( UIManager.getCrossPlatformLookAndFeelClassName() ); } catch(final ClassNotFoundException exception ) { //If System Look&Feel is not supported, stay with the default one } catch(final InstantiationException exception ) { //If System Look&Feel is not supported, stay with the default one } catch(final IllegalAccessException exception ) { //If System Look&Feel is not supported, stay with the default one } catch(final UnsupportedLookAndFeelException exception ) { //If System Look&Feel is not supported, stay with the default one } //Add the icon to the system tray final TrayIcon trayIcon =new TrayIcon(TRAY_ICON_IMAGE, "Tray icon skeleton" ); trayIcon.setImageAutoSize(true ); // Get the system default browser to open execution details final Desktop desktop = Desktop.getDesktop(); //Action listener to get click on top menu items final ActionListener menuListener =new ActionListener() { @SuppressWarnings("synthetic-access") public void actionPerformed(final ActionEvent e) { if( JMenuItem.class.isInstance( e.getSource() ) ){ JMenuItem jMenuItem = (JMenuItem) e.getSource(); JOptionPane.showMessageDialog(null, "It works, you clicked on:" + System.lineSeparator() + jMenuItem.getText(), "Your skill is great!!", JOptionPane.INFORMATION_MESSAGE ); //$NON-NLS-1$ } } }; //About menu listener final ActionListener aboutListener =new ActionListener() { @SuppressWarnings("synthetic-access") public void actionPerformed(final ActionEvent e) { //Open an URL using the system default browser try { final URI executionURI =new URI(TRAY_ICON_SKELETON_PROJECT_URL ); desktop.browse( executionURI ); } catch(final URISyntaxException exception ) { final StringWriter stringWriter =new StringWriter(); exception.printStackTrace(new PrintWriter( stringWriter ) ); JOptionPane.showMessageDialog(null, exception.getMessage() + System.lineSeparator() + stringWriter.toString(), "Tray icon skeleton redirection error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ } catch(final IOException exception ) { final StringWriter stringWriter =new StringWriter(); exception.printStackTrace(new PrintWriter( stringWriter ) ); JOptionPane.showMessageDialog(null, exception.getMessage() + System.lineSeparator() + stringWriter.toString(), "Tray icon skeleton redirection error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ } } }; //Get the system tray final SystemTray tray = SystemTray.getSystemTray(); //Tray icon skeleton exit listener final ActionListener exitListener =new ActionListener() { @SuppressWarnings("synthetic-access") public void actionPerformed(final ActionEvent e) { //Important: remove the icon from the tray to dispose it tray.remove(trayIcon ); System.exit(0 ); } }; //Popup menu JPopupMenu.setDefaultLightWeightPopupEnabled(false ); final JPopupMenu popupMenu =new JPopupMenu(); //Add 10 menu items for(int i =0 ; i <10 ; i++ ){ final JMenuItem jMenuItem =new JMenuItem("menu item " + i ); popupMenu.add( jMenuItem ); jMenuItem.addActionListener( menuListener ); System.out.println("DAD"); } //Adding some menu separator popupMenu.addSeparator(); final JMenuItem aboutItem =new JMenuItem("About Tray icon skeleton" ); //$NON-NLS-1$ popupMenu.add( aboutItem ); aboutItem.addActionListener( aboutListener ); //Adding some menu separator popupMenu.addSeparator(); //Quit menu to terminate the tray icon by disposing the tray icon final JMenuItem exitItem =new JMenuItem("Quit" ); //$NON-NLS-1$ popupMenu.add( exitItem ); exitItem.addActionListener( exitListener ); //Hidden dialog displayed behing the system tray to auto hide the popup menu when clicking somewhere else on the screen final JDialog hiddenDialog =new JDialog (); hiddenDialog.setSize(1000, 1000 ); //Listener based on the focus to auto hide the hidden dialog and the popup menu when the hidden dialog box lost focus hiddenDialog.addWindowFocusListener(new WindowFocusListener() { public void windowLostFocus (final WindowEvent e ) { hiddenDialog.setVisible(false ); } public void windowGainedFocus (final WindowEvent e ) { //Nothing to do } }); popupMenu.add(aspectRatioSubMenu); //Add a listener to display the popupmenu and the hidden dialog box when the tray icon is clicked trayIcon.addMouseListener(new MouseAdapter() { public void mouseReleased(final MouseEvent e) { if( e.isPopupTrigger() ) { //Display the menu at the position of the mouse //The dialog is also displayed at this position but it is behind the system tray popupMenu.setLocation( e.getX(), e.getY() ); hiddenDialog.setLocation( e.getX(), e.getY() ); //Important: set the hidden dialog as the invoker to hide the menu with this dialog lost focus popupMenu.setInvoker(hiddenDialog ); hiddenDialog.setVisible(true ); popupMenu.setVisible(true ); } } }); //Add the icon to the system tray try { tray.add( trayIcon ); } catch (final AWTException e ) { final StringWriter stringWriter =new StringWriter(); e.printStackTrace(new PrintWriter( stringWriter ) ); JOptionPane.showMessageDialog(null, "tray icon cannot be added to the system tray" + System.lineSeparator() + e.getMessage() + System.lineSeparator() + stringWriter.toString(), "Tray icon skeleton initialization error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ System.exit(2 ); } } else { //if the System is not compatible with SystemTray JOptionPane.showMessageDialog(null, "SystemTray cannot be initialized" + System.lineSeparator() +"this system is not compatible!", "Tray icon skeleton initialization error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ //$NON-NLS-2$ System.exit(1 ); } } } Il 08/05/2022 01:26, Davide Perini ha scritto: > Hi all, > I'm using a JPopupMenu to workaround the lack of a "real tray icon" in > JavaFX. > > This is the simple code I'm using: > https://github.com/Sylvain-Bugat/tray-icon-skeleton/blob/master/src/main/java/com/github/sbugat/trayiconskeleton/TrayIconMainClass.java > > > It all works well until I add a submenu (JMenu) to my JPopupMenu. > > This is how the tray looks when no glitch appear: > > > and this is the tray how looks like when the glitch of the submenu > appers: > > > > > to trigger the glitch I can simply move the mouse over the submenu and > then move the mouse over the other jmenuitem. > > Any idea on why I have this error? > > Thanks > Davide From perini.davide at dpsoftware.org Mon May 9 16:14:11 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 9 May 2022 18:14:11 +0200 Subject: Jpopupmenu Bug/Glitch When Showing Submenu In-Reply-To: <235d1d21-a44c-5c60-ae68-4eb7f9bf43a3@dpsoftware.org> References: <235d1d21-a44c-5c60-ae68-4eb7f9bf43a3@dpsoftware.org> Message-ID: <94ede0e3-29cd-3af9-66e4-d0299e9eb258@dpsoftware.org> I add a video that shows the issue. https://www.youtube.com/shorts/IYq_yHemsgA as you can see, there is no issue until I put the mouse pointer over the JMenu (submenu), once I put the mouse on the JMenu the entire JPopupMenu shows the glitch. Thanks Davide Il 09/05/2022 18:04, Davide Perini ha scritto: > I can't load images unfortunantly but this is the minimum code to > reproduce the issue. > It seems that there is no way to add JMenu to JPopupMenu without > having this glitch. > > Is this a problem in JavaFX? > I see non obvious errors in my code. > > Thanks > Davide > > package org.dpsoftware; import org.dpsoftware.config.Constants; import > org.dpsoftware.utilities.CommonUtility; import javax.swing.*; import > java.awt.*; import java.awt.event.*; import java.io.IOException; > import java.io.PrintWriter; import java.io.Serial; import > java.io.StringWriter; import java.net.URI; import > java.net.URISyntaxException; public class TrayIconMainClass { > > ?? private static final StringTRAY_ICON_SKELETON_PROJECT_URL > ="https://github.com/Sylvain-Bugat/tray-icon-skeleton"; /** Load the > tray icon image to display in the tray bar*/ private static > ImageTRAY_ICON_IMAGE = Toolkit.getDefaultToolkit().getImage( > TrayIconMainClass.class.getClassLoader().getResource("tray_play.png" ) > ); //$NON-NLS-1$ static JMenuaspectRatioSubMenu; /** * Main program > launched in the jar file * * @param args * @throws IOException */ > private void initializeImages() { > ????? // load an image } > > ?? public static void main(final String args[] )throws IOException { > ????? aspectRatioSubMenu =new JMenu("dadsdsa"); JMenuItem menuItam > =new JMenuItem("dada"); aspectRatioSubMenu.add(menuItam); //Test if > the system support the system tray if( SystemTray.isSupported() ) { > > ???????? //Try to use the system Look&Feel try { > ??????????? UIManager.setLookAndFeel( > UIManager.getCrossPlatformLookAndFeelClassName() ); } > ???????? catch(final ClassNotFoundException exception ) { > ??????????? //If System Look&Feel is not supported, stay with the > default one } > ???????? catch(final InstantiationException exception ) { > ??????????? //If System Look&Feel is not supported, stay with the > default one } > ???????? catch(final IllegalAccessException exception ) { > ??????????? //If System Look&Feel is not supported, stay with the > default one } > ???????? catch(final UnsupportedLookAndFeelException exception ) { > ??????????? //If System Look&Feel is not supported, stay with the > default one } > > ???????? //Add the icon to the system tray final TrayIcon trayIcon > =new TrayIcon(TRAY_ICON_IMAGE, "Tray icon skeleton" ); > trayIcon.setImageAutoSize(true ); // Get the system default browser to > open execution details final Desktop desktop = Desktop.getDesktop(); > //Action listener to get click on top menu items final ActionListener > menuListener =new ActionListener() { > ??????????? @SuppressWarnings("synthetic-access") > ??????????? public void actionPerformed(final ActionEvent e) { > > ?????????????? if( JMenuItem.class.isInstance( e.getSource() ) ){ > > ????????????????? JMenuItem jMenuItem = (JMenuItem) e.getSource(); > JOptionPane.showMessageDialog(null, "It works, you clicked on:" + > System.lineSeparator() + jMenuItem.getText(), "Your skill is great!!", > JOptionPane.INFORMATION_MESSAGE ); //$NON-NLS-1$ } > ??????????? } > ???????? }; //About menu listener final ActionListener aboutListener > =new ActionListener() { > ??????????? @SuppressWarnings("synthetic-access") > ??????????? public void actionPerformed(final ActionEvent e) { > > ?????????????? //Open an URL using the system default browser try { > ????????????????? final URI executionURI =new > URI(TRAY_ICON_SKELETON_PROJECT_URL ); desktop.browse( executionURI ); } > ?????????????? catch(final URISyntaxException exception ) { > > ????????????????? final StringWriter stringWriter =new StringWriter(); > exception.printStackTrace(new PrintWriter( stringWriter ) ); > JOptionPane.showMessageDialog(null, exception.getMessage() + > System.lineSeparator() + stringWriter.toString(), "Tray icon skeleton > redirection error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ } > ?????????????? catch(final IOException exception ) { > > ????????????????? final StringWriter stringWriter =new StringWriter(); > exception.printStackTrace(new PrintWriter( stringWriter ) ); > JOptionPane.showMessageDialog(null, exception.getMessage() + > System.lineSeparator() + stringWriter.toString(), "Tray icon skeleton > redirection error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ } > ??????????? } > ???????? }; //Get the system tray final SystemTray tray = > SystemTray.getSystemTray(); //Tray icon skeleton exit listener final > ActionListener exitListener =new ActionListener() { > ??????????? @SuppressWarnings("synthetic-access") > ??????????? public void actionPerformed(final ActionEvent e) { > ?????????????? //Important: remove the icon from the tray to dispose > it tray.remove(trayIcon ); System.exit(0 ); } > ???????? }; //Popup menu > JPopupMenu.setDefaultLightWeightPopupEnabled(false ); final JPopupMenu > popupMenu =new JPopupMenu(); //Add 10 menu items for(int i =0 ; i <10 > ; i++ ){ > > ??????????? final JMenuItem jMenuItem =new JMenuItem("menu item " + i > ); popupMenu.add( jMenuItem ); jMenuItem.addActionListener( > menuListener ); System.out.println("DAD"); } > > ???????? //Adding some menu separator popupMenu.addSeparator(); final > JMenuItem aboutItem =new JMenuItem("About Tray icon skeleton" ); > //$NON-NLS-1$ popupMenu.add( aboutItem ); aboutItem.addActionListener( > aboutListener ); //Adding some menu separator > popupMenu.addSeparator(); //Quit menu to terminate the tray icon by > disposing the tray icon final JMenuItem exitItem =new JMenuItem("Quit" > ); //$NON-NLS-1$ popupMenu.add( exitItem ); > exitItem.addActionListener( exitListener ); //Hidden dialog displayed > behing the system tray to auto hide the popup menu when clicking > somewhere else on the screen final JDialog hiddenDialog =new JDialog > (); hiddenDialog.setSize(1000, 1000 ); //Listener based on the focus > to auto hide the hidden dialog and the popup menu when the hidden > dialog box lost focus hiddenDialog.addWindowFocusListener(new > WindowFocusListener() { > > ??????????? public void windowLostFocus (final WindowEvent e ) { > ?????????????? hiddenDialog.setVisible(false ); } > > ??????????? public void windowGainedFocus (final WindowEvent e ) { > ?????????????? //Nothing to do } > ???????? }); popupMenu.add(aspectRatioSubMenu); //Add a listener to > display the popupmenu and the hidden dialog box when the tray icon is > clicked trayIcon.addMouseListener(new MouseAdapter() { > > ??????????? public void mouseReleased(final MouseEvent e) { > > ?????????????? if( e.isPopupTrigger() ) { > ????????????????? //Display the menu at the position of the mouse > //The dialog is also displayed at this position but it is behind the > system tray popupMenu.setLocation( e.getX(), e.getY() ); > hiddenDialog.setLocation( e.getX(), e.getY() ); //Important: set the > hidden dialog as the invoker to hide the menu with this dialog lost > focus popupMenu.setInvoker(hiddenDialog ); > hiddenDialog.setVisible(true ); popupMenu.setVisible(true ); } > ??????????? } > ???????? }); //Add the icon to the system tray try { > ??????????? tray.add( trayIcon ); } > ???????? catch (final AWTException e ) { > > ??????????? final StringWriter stringWriter =new StringWriter(); > e.printStackTrace(new PrintWriter( stringWriter ) ); > JOptionPane.showMessageDialog(null, "tray icon cannot be added to the > system tray" + System.lineSeparator() + e.getMessage() + > System.lineSeparator() + stringWriter.toString(), "Tray icon skeleton > initialization error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ > System.exit(2 ); } > ????? } > ????? else { > ???????? //if the System is not compatible with SystemTray > JOptionPane.showMessageDialog(null, "SystemTray cannot be initialized" > + System.lineSeparator() +"this system is not compatible!", "Tray icon > skeleton initialization error", JOptionPane.ERROR_MESSAGE ); > //$NON-NLS-1$ //$NON-NLS-2$ System.exit(1 ); } > > ?? } > } > > > > > > > > > > Il 08/05/2022 01:26, Davide Perini ha scritto: >> Hi all, >> I'm using a JPopupMenu to workaround the lack of a "real tray icon" >> in JavaFX. >> >> This is the simple code I'm using: >> https://github.com/Sylvain-Bugat/tray-icon-skeleton/blob/master/src/main/java/com/github/sbugat/trayiconskeleton/TrayIconMainClass.java >> >> >> It all works well until I add a submenu (JMenu) to my JPopupMenu. >> >> This is how the tray looks when no glitch appear: >> >> >> and this is the tray how looks like when the glitch of the submenu >> appers: >> >> >> >> >> to trigger the glitch I can simply move the mouse over the submenu >> and then move the mouse over the other jmenuitem. >> >> Any idea on why I have this error? >> >> Thanks >> Davide From kcr at openjdk.java.net Mon May 9 21:13:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:13:41 GMT Subject: [jfx17u] RFR: 8280840: Update libFFI to 3.4.2 Message-ID: Clean backport to `jfx17u`. Tested in connection with gstreamer / glib update in the `test-kcr-17.0.4` branch. ------------- Commit messages: - 8280840: Update libFFI to 3.4.2 Changes: https://git.openjdk.java.net/jfx17u/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280840 Stats: 3475 lines in 34 files changed: 927 ins; 38 del; 2510 mod Patch: https://git.openjdk.java.net/jfx17u/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/53/head:pull/53 PR: https://git.openjdk.java.net/jfx17u/pull/53 From kcr at openjdk.java.net Mon May 9 21:14:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:14:14 GMT Subject: [jfx17u] RFR: 8283218: Update GStreamer to 1.20.1 Message-ID: Almost clean backport to `jfx17u`. Tested in connection with libffi update in the `test-kcr-17.0.4` branch. The only difference from the mainline patch is that the following file is not present in `jfx17u`, so that part of the patch was skipped: modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c ------------- Commit messages: - 8283218: Update GStreamer to 1.20.1 Changes: https://git.openjdk.java.net/jfx17u/pull/54/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=54&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283218 Stats: 38921 lines in 412 files changed: 22007 ins; 5981 del; 10933 mod Patch: https://git.openjdk.java.net/jfx17u/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/54/head:pull/54 PR: https://git.openjdk.java.net/jfx17u/pull/54 From kcr at openjdk.java.net Mon May 9 21:20:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:20:37 GMT Subject: [jfx17u] RFR: 8281564: Update cmake to 3.22.3 Message-ID: Clean backport to `jfx17u`. Tested along with the rest of the fixes in the `test-kcr-17.0.4` branch. ------------- Commit messages: - 8281564: Update cmake to 3.22.3 Changes: https://git.openjdk.java.net/jfx17u/pull/55/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=55&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281564 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx17u/pull/55.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/55/head:pull/55 PR: https://git.openjdk.java.net/jfx17u/pull/55 From kcr at openjdk.java.net Mon May 9 21:20:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:20:37 GMT Subject: [jfx17u] RFR: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:13:07 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. Tested along with the rest of the fixes in the `test-kcr-17.0.4` branch. Reviewer: @arapte ------------- PR: https://git.openjdk.java.net/jfx17u/pull/55 From kcr at openjdk.java.net Mon May 9 21:20:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:20:37 GMT Subject: [jfx17u] RFR: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: <_BNeheeU4BKId9dC_E9JYwZ_l0KvIsuwt1obrmOnY_w=.849372b9-1c32-4e8e-a418-9de317fc8eef@github.com> On Mon, 9 May 2022 21:15:57 GMT, Kevin Rushforth wrote: > Reviewer: @arapte Since this is clean, a review is optional. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/55 From kcr at openjdk.java.net Mon May 9 21:21:32 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:21:32 GMT Subject: [jfx17u] RFR: 8276142: Update gradle to version 7.3 Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8276142: Update gradle to version 7.3 Changes: https://git.openjdk.java.net/jfx17u/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276142 Stats: 227 lines in 7 files changed: 102 ins; 49 del; 76 mod Patch: https://git.openjdk.java.net/jfx17u/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/56/head:pull/56 PR: https://git.openjdk.java.net/jfx17u/pull/56 From kcr at openjdk.java.net Mon May 9 21:22:21 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:22:21 GMT Subject: [jfx17u] RFR: 8273998: Clarify specification for Window properties controlled by the window manager Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8273998: Clarify specification for Window properties controlled by the window manager Changes: https://git.openjdk.java.net/jfx17u/pull/57/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=57&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273998 Stats: 84 lines in 2 files changed: 59 ins; 4 del; 21 mod Patch: https://git.openjdk.java.net/jfx17u/pull/57.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/57/head:pull/57 PR: https://git.openjdk.java.net/jfx17u/pull/57 From kcr at openjdk.java.net Mon May 9 21:25:22 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:25:22 GMT Subject: [jfx17u] RFR: 8274274: Update JUnit to version 5.8.1 Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8274274: Update JUnit to version 5.8.1 Changes: https://git.openjdk.java.net/jfx17u/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274274 Stats: 161 lines in 5 files changed: 151 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jfx17u/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/58/head:pull/58 PR: https://git.openjdk.java.net/jfx17u/pull/58 From kcr at openjdk.java.net Mon May 9 21:29:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:29:34 GMT Subject: [jfx17u] RFR: 8276174: JavaFX build fails on macOS aarch64 Message-ID: Clean backport to `jfx17u` so we can build on macOS / aarch64 without needing to specify `-PCOMPILE_TARGET=arm64`. ------------- Commit messages: - 8276174: JavaFX build fails on macOS aarch64 Changes: https://git.openjdk.java.net/jfx17u/pull/60/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=60&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276174 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/60/head:pull/60 PR: https://git.openjdk.java.net/jfx17u/pull/60 From kevin.rushforth at oracle.com Mon May 9 22:28:58 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 9 May 2022 15:28:58 -0700 Subject: Proposed schedule for JavaFX 19 Message-ID: Here is the proposed schedule for JavaFX 19. RDP1: Jul 14, 2022 (aka ?feature freeze?) RDP2: Aug 4, 2022 Freeze: Aug 25, 2022 GA: Sep 13, 2022 We plan to fork a jfx19 stabilization branch at RDP1. The GA date is one week ahead of JDK 19, matching what we did for 18. The start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin From jvos at openjdk.java.net Tue May 10 08:03:02 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 10 May 2022 08:03:02 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:55:30 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. >> >> This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Scale screen dimensions modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.c line 171: > 169: 0, 0, (jint) width, (jint) height, > 170: 0, 0, (jint) width, (jint) height, > 171: 100, 100, (jfloat) 1, (jfloat) 1, androidDensity, androidDensity); might be good to replace the `100` with e.g. `dpi` and assign a constant value (100) at the top of this file to it, in case we later want to retrieve that in a more dynamic way. ------------- PR: https://git.openjdk.java.net/jfx/pull/778 From jvos at openjdk.java.net Tue May 10 08:34:44 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 10 May 2022 08:34:44 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3] In-Reply-To: References: Message-ID: <-0-lym74ugtkrlRKvYx6pWfdVA3-MY9L45NF_rRE0wg=.ba360376-5b12-4a91-91d5-0bd966ee664c@github.com> On Wed, 4 May 2022 16:55:30 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. >> >> This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Scale screen dimensions This looks now more in line with what the other platforms are doing. We expect the native layer to deal with low-level window/screen handling, and they should notify the java layer in case of relevant events. ------------- PR: https://git.openjdk.java.net/jfx/pull/778 From arapte at openjdk.java.net Tue May 10 08:39:48 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 10 May 2022 08:39:48 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage [v2] In-Reply-To: <9oD_w8pQGG9qZQM9FXJQCgsx8ugiznC-zD_Pj8NmBa8=.da05ef3e-bda9-4cac-b36d-5b1ae22f78cd@github.com> References: <9oD_w8pQGG9qZQM9FXJQCgsx8ugiznC-zD_Pj8NmBa8=.da05ef3e-bda9-4cac-b36d-5b1ae22f78cd@github.com> Message-ID: On Mon, 9 May 2022 14:54:55 GMT, Thiago Milczarek Sayao wrote: >> When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. >> >> The fix also works for: >> https://bugs.openjdk.java.net/browse/JDK-8269429 >> >> But this one might need another fix: >> https://bugs.openjdk.java.net/browse/JDK-8240640 > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Set the focus on the latest window when re-enabling them The original fix gets affected by the new commit. Now, after closing dialog the focus always returns only to the stage that was created later. 1. Run the sample attached to [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654). 2. Click button One and Two both once in order 3. Re-arrange both the windows such that they are visible. 4. Click the button "Click here" in Window One: Error dialog will be displayed 5. Close the Error dialog => Window Two gets focused but Window One should gets focused. => This worked correctly before the latest commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From duke at openjdk.java.net Tue May 10 11:22:06 2022 From: duke at openjdk.java.net (=?UTF-8?B?UGF3ZcWC?= =?UTF-8?B?IA==?= =?UTF-8?B?S3J1c3pjennFhHNraQ==?=) Date: Tue, 10 May 2022 11:22:06 GMT Subject: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again [v3] In-Reply-To: References: Message-ID: > `Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on overlaying tooltip also kills the tooltip, so the infinite duration tooltip can be closed. Pawe? Kruszczy?ski 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 branch 'openjdk:master' into 8261221_tooltip_blinks - 8261221: Tooltip bigger than screen size blinks - applying reviewed fixes - 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/395/files - new: https://git.openjdk.java.net/jfx/pull/395/files/3fb62625..0a175dca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=395&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=395&range=01-02 Stats: 954937 lines in 11930 files changed: 523481 ins; 281758 del; 149698 mod Patch: https://git.openjdk.java.net/jfx/pull/395.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/395/head:pull/395 PR: https://git.openjdk.java.net/jfx/pull/395 From duke at openjdk.java.net Tue May 10 11:49:59 2022 From: duke at openjdk.java.net (=?UTF-8?B?UGF3ZcWC?= =?UTF-8?B?IA==?= =?UTF-8?B?S3J1c3pjennFhHNraQ==?=) Date: Tue, 10 May 2022 11:49:59 GMT Subject: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again In-Reply-To: References: <21FZi3uUrZuc2alNFDKRev6GWSZzS7ZGPHxx-BQOWr4=.04c2d319-9734-43e8-bba8-33f46f11192d@github.com> Message-ID: <05fcZIPTFONAgWS25r9fXuMULgCtLxIH4tSOODxjE80=.3abf37e3-75cb-41d2-a048-703019ca70a4@github.com> On Wed, 17 Feb 2021 18:50:54 GMT, Kevin Rushforth wrote: >> `Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on overlaying tooltip also kills the tooltip, so the infinite duration tooltip can be closed. > > One more request: Please follow the instructions [here](https://github.com/openjdk/jfx/pull/395/checks) to enable running pre-submit tests. @kevinrushforth sorry for "little" delay in answering, but I thing that previously failing tests have passed as successful now. ------------- PR: https://git.openjdk.java.net/jfx/pull/395 From kcr at openjdk.java.net Tue May 10 12:39:00 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 12:39:00 GMT Subject: [jfx17u] Integrated: 8274274: Update JUnit to version 5.8.1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:18:07 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: 2ab0e82e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/2ab0e82ee9cf2516b32914e2df4725becf8a2664 Stats: 161 lines in 5 files changed: 151 ins; 3 del; 7 mod 8274274: Update JUnit to version 5.8.1 Backport-of: ff6e8d50badd57549811391b1380707bb94ac55b ------------- PR: https://git.openjdk.java.net/jfx17u/pull/58 From kcr at openjdk.java.net Tue May 10 12:39:04 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 12:39:04 GMT Subject: [jfx17u] Integrated: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:13:07 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. Tested along with the rest of the fixes in the `test-kcr-17.0.4` branch. This pull request has now been integrated. Changeset: 684c80fc Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/684c80fc7c7149d77509936867e7a42dc88ed9ed Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod 8281564: Update cmake to 3.22.3 Backport-of: d960d639dc6e37de0cdb69075a31a17090b83a3d ------------- PR: https://git.openjdk.java.net/jfx17u/pull/55 From tsayao at openjdk.java.net Tue May 10 12:56:53 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 10 May 2022 12:56:53 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage [v3] In-Reply-To: References: Message-ID: > When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Revert "Set the focus on the latest window when re-enabling them" This reverts commit b024de586c187f9000f791dab99507a4979cc027. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/784/files - new: https://git.openjdk.java.net/jfx/pull/784/files/b024de58..a6cad45b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=784&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=784&range=01-02 Stats: 8 lines in 2 files changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/784.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/784/head:pull/784 PR: https://git.openjdk.java.net/jfx/pull/784 From kcr at openjdk.java.net Tue May 10 14:03:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 14:03:59 GMT Subject: [jfx17u] Integrated: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:15:34 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: bdb8d28e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/bdb8d28ecc7bb10278a9a8385da79b5f5652bb09 Stats: 84 lines in 2 files changed: 59 ins; 4 del; 21 mod 8273998: Clarify specification for Window properties controlled by the window manager Backport-of: 7a1a19c098e21572077c9c3d75cc2141fadc99f6 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/57 From kcr at openjdk.java.net Tue May 10 14:05:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 14:05:03 GMT Subject: [jfx17u] Integrated: 8276174: JavaFX build fails on macOS aarch64 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:22:04 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u` so we can build on macOS / aarch64 without needing to specify `-PCOMPILE_TARGET=arm64`. This pull request has now been integrated. Changeset: a5edae13 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/a5edae1392699e7380a0b528eb1118889377cc02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8276174: JavaFX build fails on macOS aarch64 Backport-of: d289db94d15e49ed28f797b516ffccf023fce9c9 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/60 From kcr at openjdk.java.net Tue May 10 14:05:05 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 14:05:05 GMT Subject: [jfx17u] Integrated: 8276142: Update gradle to version 7.3 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:14:23 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: be207ddb Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/be207ddb7249b369a028bc6fb6985adda7841648 Stats: 227 lines in 7 files changed: 102 ins; 49 del; 76 mod 8276142: Update gradle to version 7.3 Backport-of: 13c24d22463436bc953ec5159beec7a78017019f ------------- PR: https://git.openjdk.java.net/jfx17u/pull/56 From tsayao at openjdk.java.net Tue May 10 14:35:08 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 10 May 2022 14:35:08 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:56:53 GMT, Thiago Milczarek Sayao wrote: >> When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. >> >> The fix also works for: >> https://bugs.openjdk.java.net/browse/JDK-8269429 >> >> But this one might need another fix: >> https://bugs.openjdk.java.net/browse/JDK-8240640 > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Set the focus on the latest window when re-enabling them" > > This reverts commit b024de586c187f9000f791dab99507a4979cc027. I reverted the last change. After more analysis I think it's not a bug, but a side-effect of not using native window modality in favor of enabling/disabling windows. It works like this: On the original step 5 ("Click anywhere in Window One") the window would get the focus, but instead will send a FOCUS_DISABLED event, which will bring up the MODAL window. The problem is that the window will get the focus, to be lost in favor of the last window (which is the MODAL one). To prevent this, a disabled window should never be focused. But that prevents the whole FOCUS_DISABLED logic. Note that the APPLICATION_MODAL window on the example has no owner, so I think it's ok to consider a side effect and not a bug. ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From kcr at openjdk.java.net Tue May 10 15:10:23 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 15:10:23 GMT Subject: [jfx17u] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Message-ID: This PR is dependent on #58 so it is in Draft for now. Once #58 is integrated, I will rebase this and submit it, at which time it will be a clean backport, and the diffs will only show the updated test and build changes associated with just this fix. ------------- Commit messages: - 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Changes: https://git.openjdk.java.net/jfx17u/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280275 Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/59/head:pull/59 PR: https://git.openjdk.java.net/jfx17u/pull/59 From jpereda at openjdk.java.net Tue May 10 15:19:58 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 10 May 2022 15:19:58 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v4] In-Reply-To: References: Message-ID: <7rdy5t9nerXaZf2UsMVDPtARSWYSQuMEv6f_BCCIPrk=.8467ae20-5e5d-4338-849c-c86066c0c893@github.com> > This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. > > This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Use constant value for DPI ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/778/files - new: https://git.openjdk.java.net/jfx/pull/778/files/28129038..7e5958cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=778&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=778&range=02-03 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/778.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/778/head:pull/778 PR: https://git.openjdk.java.net/jfx/pull/778 From jvos at openjdk.java.net Tue May 10 15:34:03 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 10 May 2022 15:34:03 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v4] In-Reply-To: <7rdy5t9nerXaZf2UsMVDPtARSWYSQuMEv6f_BCCIPrk=.8467ae20-5e5d-4338-849c-c86066c0c893@github.com> References: <7rdy5t9nerXaZf2UsMVDPtARSWYSQuMEv6f_BCCIPrk=.8467ae20-5e5d-4338-849c-c86066c0c893@github.com> Message-ID: On Tue, 10 May 2022 15:19:58 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. >> >> This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use constant value for DPI Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/778 From kcr at openjdk.java.net Tue May 10 16:10:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 16:10:55 GMT Subject: [jfx17u] Integrated: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases In-Reply-To: References: Message-ID: <5j-hhglsNRNxe8e2Ju79MzNYsTgU41LOa5AchHR8K80=.33e6ef5c-1e19-4822-8ea0-c8a27b84e182@github.com> On Mon, 9 May 2022 21:20:29 GMT, Kevin Rushforth wrote: > This PR is dependent on #58 so it is in Draft for now. Once #58 is integrated, I will rebase this and submit it, at which time it will be a clean backport, and the diffs will only show the updated test and build changes associated with just this fix. This pull request has now been integrated. Changeset: c8eafd82 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/c8eafd827b5aff73e4fb14b2721bdf45c6f3dc0d Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Backport-of: 94807b6edfb9af55be353cab237e8e64007c61dc ------------- PR: https://git.openjdk.java.net/jfx17u/pull/59 From kcr at openjdk.java.net Tue May 10 16:14:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 16:14:55 GMT Subject: [jfx17u] RFR: 8283218: Update GStreamer to 1.20.1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c Reviewer: @johanvos ------------- PR: https://git.openjdk.java.net/jfx17u/pull/54 From kcr at openjdk.java.net Tue May 10 16:43:22 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 16:43:22 GMT Subject: RFR: 8283869: Update attribution in webkit.md file Message-ID: Doc-only change to update the license attribution in our `webkit.md` file. ------------- Commit messages: - 8283869: Update attribution in webkit.md file Changes: https://git.openjdk.java.net/jfx/pull/793/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=793&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283869 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/793.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/793/head:pull/793 PR: https://git.openjdk.java.net/jfx/pull/793 From arapte at openjdk.java.net Tue May 10 17:45:54 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 10 May 2022 17:45:54 GMT Subject: RFR: 8283869: Update attribution in webkit.md file In-Reply-To: References: Message-ID: <_sxr7yh75HtlpCN8TW-um30qii91PXf5abcyKDC8rSU=.06568c38-8038-44b7-bb45-7c7f751259fa@github.com> On Tue, 10 May 2022 16:37:57 GMT, Kevin Rushforth wrote: > Doc-only change to update the license attribution in our `webkit.md` file. LGTM ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/793 From kcr at openjdk.java.net Tue May 10 18:05:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 May 2022 18:05:47 GMT Subject: Integrated: 8283869: Update attribution in webkit.md file In-Reply-To: References: Message-ID: On Tue, 10 May 2022 16:37:57 GMT, Kevin Rushforth wrote: > Doc-only change to update the license attribution in our `webkit.md` file. This pull request has now been integrated. Changeset: 7bb48194 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/7bb4819409dd617ba2e3658ee66f23b94dc0bec1 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod 8283869: Update attribution in webkit.md file Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/793 From mhanl at openjdk.java.net Tue May 10 18:50:54 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 10 May 2022 18:50:54 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 08:38:20 GMT, Robert Lichtenberger wrote: > Separate test class added for TreeTableView case. > Fix is analogous to JDK-8251480. Looks good! Verified that the fix works. I can also confirm, that this fix is the same as previously done for `TableView` in PR: https://github.com/openjdk/jfx/pull/757 ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/779 From perini.davide at dpsoftware.org Tue May 10 20:02:53 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Tue, 10 May 2022 22:02:53 +0200 Subject: What can I do with the GStreamer bundled in JavaFX? Can I record the screen? Message-ID: <63d4720e-6284-9119-55bd-fa9deea44239@dpsoftware.org> Hi all, I haven't understood what part of GStreamer is included in JavaFX. Can I record the screen with it using d3d11screencapturesrc or ximagesrc? Thanks Davide From mhanl at openjdk.java.net Tue May 10 20:09:27 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 10 May 2022 20:09:27 GMT Subject: RFR: 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set Message-ID: A common reason for using the `TextFormatter` is the need for a `filter`. Therefore, the following constructor is typically used: `public TextFormatter(@NamedArg("filter") UnaryOperator filter) { ... }` With that, no `valueConverter` is set in the `TextFormatter`. When a `TextField` will commit his value, `TextFormatter.updateValue(...)` is called. Since `valueConverter` is null, an NPE is thrown and catched inside it and `TextFormatter.updateText()` is called (which will call `TextInputControl.updateText(...)`), which won't do anything either since `valueConverter` is still not set (=null). A minor improvement here is to just skip `TextFormatter.updateValue(...)` and therefore `TextFormatter.updateText()`, since this methods won't do anything without a `valueConverter`. With that change, no exception is thrown and catched, and therefore also exception breakpoints are not called. This will also slightly increase the performance, as throwing exceptions is a (minor) bottleneck. ------------- Commit messages: - 8286552: TextFormatter.updateValue(...) won't call updateText(), when no valueConverter is set Changes: https://git.openjdk.java.net/jfx/pull/794/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=794&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286552 Stats: 79 lines in 2 files changed: 75 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/794.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/794/head:pull/794 PR: https://git.openjdk.java.net/jfx/pull/794 From jpereda at openjdk.java.net Tue May 10 21:09:02 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 10 May 2022 21:09:02 GMT Subject: Integrated: 8285217: [Android] Window's screen is not updated after native screen was disposed In-Reply-To: References: Message-ID: <2_DqxQRuT8UErH8kdQ9uSBR0VoKv1RdsVBwH2vBrQEM=.e2963893-8e0b-46b2-9f88-1e7b22004b03@github.com> On Wed, 20 Apr 2022 18:26:06 GMT, Jose Pereda wrote: > This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. > > This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. This pull request has now been integrated. Changeset: 6c6545f7 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/6c6545f7b8b9917ef4aceb0a367864f240a2a9c5 Stats: 38 lines in 4 files changed: 25 ins; 3 del; 10 mod 8285217: [Android] Window's screen is not updated after native screen was disposed Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/778 From kevin.rushforth at oracle.com Wed May 11 11:27:42 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 May 2022 04:27:42 -0700 Subject: What can I do with the GStreamer bundled in JavaFX? Can I record the screen? In-Reply-To: <63d4720e-6284-9119-55bd-fa9deea44239@dpsoftware.org> References: <63d4720e-6284-9119-55bd-fa9deea44239@dpsoftware.org> Message-ID: <9f304ac9-7d56-ed6e-25f4-884fe4734778@oracle.com> GStreamer is used by the JavaFX media API. It is an implementation detail, and is not exposed. There are no media capture APIs, although that is something we have considered providing in the future. -- Kevin On 5/10/2022 1:02 PM, Davide Perini wrote: > Hi all, > I haven't understood what part of GStreamer is included in JavaFX. > > Can I record the screen with it using d3d11screencapturesrc or ximagesrc? > > Thanks > Davide From jvos at openjdk.java.net Wed May 11 16:20:04 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 11 May 2022 16:20:04 GMT Subject: [jfx17u] RFR: 8283218: Update GStreamer to 1.20.1 In-Reply-To: References: Message-ID: <8cyP7TOTflMUKMmO4ObRDIIP7842rjE_dEINV0UGSwc=.87e88397-9c80-4f93-92ad-c8d4b7938dea@github.com> On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/54 From thiago.sayao at gmail.com Wed May 11 17:44:43 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 11 May 2022 14:44:43 -0300 Subject: kenai closed Message-ID: Hi, http://duke.kenai.com/misc/DrinkingBeer.jpg This is on HelloImage.java A quick search for "kenai.com" shows some entries, mostly commented. -- Thiago. From perini.davide at dpsoftware.org Wed May 11 19:36:52 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 11 May 2022 21:36:52 +0200 Subject: What can I do with the GStreamer bundled in JavaFX? Can I record the screen? In-Reply-To: <9f304ac9-7d56-ed6e-25f4-884fe4734778@oracle.com> References: <63d4720e-6284-9119-55bd-fa9deea44239@dpsoftware.org> <9f304ac9-7d56-ed6e-25f4-884fe4734778@oracle.com> Message-ID: <74543cf1-bab4-b2a3-9635-c0f87c29d3e5@dpsoftware.org> Can't wait to see more GStreamer features inside JavaFX. Thank you for the answer! Davide Il 11/05/2022 13:27, Kevin Rushforth ha scritto: > GStreamer is used by the JavaFX media API. It is an implementation > detail, and is not exposed. There are no media capture APIs, although > that is something we have considered providing in the future. > > -- Kevin > > > On 5/10/2022 1:02 PM, Davide Perini wrote: >> Hi all, >> I haven't understood what part of GStreamer is included in JavaFX. >> >> Can I record the screen with it using d3d11screencapturesrc or >> ximagesrc? >> >> Thanks >> Davide > From aghaisas at openjdk.java.net Thu May 12 05:32:07 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 12 May 2022 05:32:07 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) In-Reply-To: References: Message-ID: <57Sp6VB8IX2Atvz3zKQP2Y6eEBpcmJIfbceQJHGr7qY=.695ed5ce-0ed7-4893-a79a-c2d0bff62c7e@github.com> On Thu, 21 Apr 2022 08:38:20 GMT, Robert Lichtenberger wrote: > Separate test class added for TreeTableView case. > Fix is analogous to JDK-8251480. The fix looks good. The newly introduced test file needs some cosmetic cleanups. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableColumnHeaderTest.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. Replace "2018, 2021" with just "2022" as this is newly introduced test file. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableColumnHeaderTest.java line 33: > 31: import javafx.event.Event; > 32: import javafx.scene.Node; > 33: import javafx.scene.control.*; Replace generic import statement with specific ones. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableColumnHeaderTest.java line 51: > 49: import java.util.List; > 50: > 51: import static org.junit.Assert.*; Replace generic import statement with specific ones. ------------- Changes requested by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/779 From aghaisas at openjdk.java.net Thu May 12 06:50:56 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 12 May 2022 06:50:56 GMT Subject: RFR: 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:21:45 GMT, Jose Pereda wrote: > This PR fixes an issue with selection of multiple items in TableView and TreeTableView controls that gets moved unexpectedly when new items are added even way below the selected items. > > A couple of tests have been added. They fail without this PR (first selected item gets deselected, and table anchor gets moved), and pass with this PR (first selected item keeps selected, and table anchor remains at the same place). The fix looks good. I verified that tests fail without this fix and pass with it. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/790 From S.Lewalder at tms-bonn.de Thu May 12 07:06:01 2022 From: S.Lewalder at tms-bonn.de (Lewalder, Sebastian) Date: Thu, 12 May 2022 07:06:01 +0000 Subject: AW: Fix for gestures and multitouch on linux In-Reply-To: <7a9ebf0803b649d889b4aa820402bc3d@tms-bonn.de> References: <7a9ebf0803b649d889b4aa820402bc3d@tms-bonn.de> Message-ID: Hello everybody, did anyone take a look at the implementation? Is that something that is of value and could be incorporated in openjfx? Can we improve it in any way? Kind Regards, Sebastian -----Urspr?ngliche Nachricht----- Von: openjfx-dev Im Auftrag von Anafinow, Andrej Gesendet: Mittwoch, 16. M?rz 2022 08:53 An: openjfx-dev at openjdk.java.net Betreff: Fix for gestures and multitouch on linux Hello, we have a problem with multitouch and gestures on Linux and JavaFx17. This is also described here: https://bugs.openjdk.java.net/browse/JDK-8090954 The sample project "GestureEventsExample" at https://docs.oracle.com/javafx/2/events/gestures.htm does not work either. We looked at the code and fixed the problem. See our commit at https://github.com/tms-bonn/jfx. With these changes, the above example works. The following touch and multi-touch functions were tested: Rotate, Zoom, Scroll and LongPress. Our current problem was actually about controlling the Openlayers map in a WebView with gestures on a touch monitor. All the above functions work without any problems. We would like to ask the community to take a look at our changes and maybe test them Regards, Andrej From kcr at openjdk.java.net Thu May 12 12:50:05 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 May 2022 12:50:05 GMT Subject: [jfx17u] Integrated: 8280840: Update libFFI to 3.4.2 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:05:17 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. Tested in connection with gstreamer / glib update in the `test-kcr-17.0.4` branch. This pull request has now been integrated. Changeset: 1c376ebd Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/1c376ebd51d59ae7b617cb84c5f1e04a80d87b0a Stats: 3475 lines in 34 files changed: 927 ins; 38 del; 2510 mod 8280840: Update libFFI to 3.4.2 Backport-of: 1beb3235223452929ec951ee18dd30a5345307cf ------------- PR: https://git.openjdk.java.net/jfx17u/pull/53 From kcr at openjdk.java.net Thu May 12 12:53:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 May 2022 12:53:06 GMT Subject: [jfx17u] Integrated: 8283218: Update GStreamer to 1.20.1 In-Reply-To: References: Message-ID: <31-RhJmcttOueGLeDg24fEkpIdgZeeUIuptC6LTgHUo=.1d022759-daae-4830-8f00-354335b4be4a@github.com> On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c This pull request has now been integrated. Changeset: 103cac04 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/103cac04472d3eddb1f28a6a0b4f8d60f5ce3d7f Stats: 38921 lines in 412 files changed: 22007 ins; 5981 del; 10933 mod 8283218: Update GStreamer to 1.20.1 8283403: Update Glib to 2.72.0 Reviewed-by: jvos Backport-of: c4b1a72cc4d9253d1320d83281d50fb1f3bb6145 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/54 From kcr at openjdk.java.net Thu May 12 22:26:39 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 May 2022 22:26:39 GMT Subject: RFR: 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set In-Reply-To: References: Message-ID: <0CmZ54l62WWu2N5fSlwhMjghfwvfxytpLaQwPblOEvU=.343d3c8b-2475-40b1-9464-2efd82d9b463@github.com> On Tue, 10 May 2022 20:03:08 GMT, Marius Hanl wrote: > A common reason for using the `TextFormatter` is the need for a `filter`. > Therefore, the following constructor is typically used: > `public TextFormatter(@NamedArg("filter") UnaryOperator filter) { ... }` > > With that, no `valueConverter` is set in the `TextFormatter`. > > When a `TextField` will commit his value, `TextFormatter.updateValue(...)` is called. > Since `valueConverter` is null, an NPE is thrown and catched inside it and `TextFormatter.updateText()` is called (which will call `TextInputControl.updateText(...)`), which won't do anything either since `valueConverter` is still not set (=null). > > A minor improvement here is to just skip `TextFormatter.updateValue(...)` and therefore `TextFormatter.updateText()` (-> `TextInputControl.updateText(...)`), since this methods won't do anything without a `valueConverter`. > With that change, no exception (NPE) is thrown and catched, and therefore also exception breakpoints are not called (can be annoying ;)). > This will also slightly increase the performance, as throwing exceptions is a (minor) bottleneck. > > Added tests for all `TextFormatter` functionalities, which pass before and after. The fix and tests look good, with a couple requested changes. modules/javafx.controls/src/main/java/javafx/scene/control/TextFormatter.java line 40: > 38: *
    > 39: *
  • A filter ({@link #getFilter()}) that can intercept and modify user input. This helps to keep the text > 40: * in the desired format. A default text supplier can be used to provide the initial text.
  • I know this is a simple typo, but it is unrelated to your bug fix, and is in public API docs, so I'd like to see it go in separately under a "Fix mistakes in docs" bug. I filed [JDK-8286678](https://bugs.openjdk.java.net/browse/JDK-8286678) to track this and any other such issues that arise (as we've done for most recent releases). modules/javafx.controls/src/main/java/javafx/scene/control/TextFormatter.java line 202: > 200: > 201: void updateValue(String text) { > 202: if (valueConverter != null &&!value.isBound()) { Minor: please add a space between the `&&` and `!` operators. ------------- PR: https://git.openjdk.java.net/jfx/pull/794 From kcr at openjdk.java.net Thu May 12 23:05:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 May 2022 23:05:56 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v3] In-Reply-To: References: Message-ID: On Sun, 8 May 2022 06:31:49 GMT, Paul wrote: >> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. >> >> Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. >> >> Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- >> >> >> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { >> NSSize imgSize = {width / sx, height / sy}; >> [image setSize: imgSize]; >> } >> >> >> The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. >> >> Before this fix:- >> >> Screenshot 2022-02-26 at 22 16 30 >> >> After this fix:- >> >> Screenshot 2022-02-26 at 22 18 17 > > Paul has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Updated variable names to be a bit more consistent > - Merge branch 'master' into JDK-8181084 > - Merge branch 'master' into JDK-8181084 > - Removing trailing whitespace. > - Correctly scales hi-res icons in MacOS system menu items I'll look at this in more detail later. You will likely need some error checking when calling the JNI methods (even though they should not ever return an error), and you might want to cache the class and field IDs it in `initIDs`. This will need a testing on all platforms, since the change to create a Pixel object using the scale is in shared code. Two things you could do to help with this. 1. Enable GitHub actions runs in your personal fork of the jfx repo. You will need to push some change (and empty commit is fine) to trigger it, once you do. This will run the headless tests on all platforms, so is really just a "smoke test". 2. Run the full set of tests on at least macOS by doing this: gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true test -x :web:test ------------- PR: https://git.openjdk.java.net/jfx/pull/743 From mhanl at openjdk.java.net Fri May 13 08:28:50 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 13 May 2022 08:28:50 GMT Subject: RFR: 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set [v2] In-Reply-To: References: Message-ID: > A common reason for using the `TextFormatter` is the need for a `filter`. > Therefore, the following constructor is typically used: > `public TextFormatter(@NamedArg("filter") UnaryOperator filter) { ... }` > > With that, no `valueConverter` is set in the `TextFormatter`. > > When a `TextField` will commit his value, `TextFormatter.updateValue(...)` is called. > Since `valueConverter` is null, an NPE is thrown and catched inside it and `TextFormatter.updateText()` is called (which will call `TextInputControl.updateText(...)`), which won't do anything either since `valueConverter` is still not set (=null). > > A minor improvement here is to just skip `TextFormatter.updateValue(...)` and therefore `TextFormatter.updateText()` (-> `TextInputControl.updateText(...)`), since this methods won't do anything without a `valueConverter`. > With that change, no exception (NPE) is thrown and catched, and therefore also exception breakpoints are not called (can be annoying ;)). > This will also slightly increase the performance, as throwing exceptions is a (minor) bottleneck. > > Added tests for all `TextFormatter` functionalities, which pass before and after. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8286552: Added space and revert typo fix ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/794/files - new: https://git.openjdk.java.net/jfx/pull/794/files/a171c370..bb157725 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=794&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=794&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/794.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/794/head:pull/794 PR: https://git.openjdk.java.net/jfx/pull/794 From mhanl at openjdk.java.net Fri May 13 08:28:53 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 13 May 2022 08:28:53 GMT Subject: RFR: 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set [v2] In-Reply-To: <0CmZ54l62WWu2N5fSlwhMjghfwvfxytpLaQwPblOEvU=.343d3c8b-2475-40b1-9464-2efd82d9b463@github.com> References: <0CmZ54l62WWu2N5fSlwhMjghfwvfxytpLaQwPblOEvU=.343d3c8b-2475-40b1-9464-2efd82d9b463@github.com> Message-ID: On Thu, 12 May 2022 22:13:38 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8286552: Added space and revert typo fix > > modules/javafx.controls/src/main/java/javafx/scene/control/TextFormatter.java line 40: > >> 38: *
      >> 39: *
    • A filter ({@link #getFilter()}) that can intercept and modify user input. This helps to keep the text >> 40: * in the desired format. A default text supplier can be used to provide the initial text.
    • > > I know this is a simple typo, but it is unrelated to your bug fix, and is in public API docs, so I'd like to see it go in separately under a "Fix mistakes in docs" bug. I filed [JDK-8286678](https://bugs.openjdk.java.net/browse/JDK-8286678) to track this and any other such issues that arise (as we've done for most recent releases). Ah okay, alright. I reverted it. > modules/javafx.controls/src/main/java/javafx/scene/control/TextFormatter.java line 202: > >> 200: >> 201: void updateValue(String text) { >> 202: if (valueConverter != null &&!value.isBound()) { > > Minor: please add a space between the `&&` and `!` operators. done. ------------- PR: https://git.openjdk.java.net/jfx/pull/794 From kcr at openjdk.java.net Fri May 13 12:29:08 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 May 2022 12:29:08 GMT Subject: RFR: 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set [v2] In-Reply-To: References: Message-ID: <5zNrBZgNCibsknhIULOabHVs0TN4tlYvHw3iQ112pUE=.b8b95bc2-b304-4b52-9e15-2485eaef24b5@github.com> On Fri, 13 May 2022 08:28:50 GMT, Marius Hanl wrote: >> A common reason for using the `TextFormatter` is the need for a `filter`. >> Therefore, the following constructor is typically used: >> `public TextFormatter(@NamedArg("filter") UnaryOperator filter) { ... }` >> >> With that, no `valueConverter` is set in the `TextFormatter`. >> >> When a `TextField` will commit his value, `TextFormatter.updateValue(...)` is called. >> Since `valueConverter` is null, an NPE is thrown and catched inside it and `TextFormatter.updateText()` is called (which will call `TextInputControl.updateText(...)`), which won't do anything either since `valueConverter` is still not set (=null). >> >> A minor improvement here is to just skip `TextFormatter.updateValue(...)` and therefore `TextFormatter.updateText()` (-> `TextInputControl.updateText(...)`), since this methods won't do anything without a `valueConverter`. >> With that change, no exception (NPE) is thrown and catched, and therefore also exception breakpoints are not called (can be annoying ;)). >> This will also slightly increase the performance, as throwing exceptions is a (minor) bottleneck. >> >> Added tests for all `TextFormatter` functionalities, which pass before and after. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8286552: Added space and revert typo fix LGTM ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/794 From mhanl at openjdk.java.net Fri May 13 12:49:05 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 13 May 2022 12:49:05 GMT Subject: Integrated: 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:03:08 GMT, Marius Hanl wrote: > A common reason for using the `TextFormatter` is the need for a `filter`. > Therefore, the following constructor is typically used: > `public TextFormatter(@NamedArg("filter") UnaryOperator filter) { ... }` > > With that, no `valueConverter` is set in the `TextFormatter`. > > When a `TextField` will commit his value, `TextFormatter.updateValue(...)` is called. > Since `valueConverter` is null, an NPE is thrown and catched inside it and `TextFormatter.updateText()` is called (which will call `TextInputControl.updateText(...)`), which won't do anything either since `valueConverter` is still not set (=null). > > A minor improvement here is to just skip `TextFormatter.updateValue(...)` and therefore `TextFormatter.updateText()` (-> `TextInputControl.updateText(...)`), since this methods won't do anything without a `valueConverter`. > With that change, no exception (NPE) is thrown and catched, and therefore also exception breakpoints are not called (can be annoying ;)). > This will also slightly increase the performance, as throwing exceptions is a (minor) bottleneck. > > Added tests for all `TextFormatter` functionalities, which pass before and after. This pull request has now been integrated. Changeset: 81e1cc3e Author: Marius Hanl Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/81e1cc3edcbfda34479ee876cbd9eb74099a7e57 Stats: 78 lines in 2 files changed: 75 ins; 0 del; 3 mod 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/794 From kcr at openjdk.java.net Sat May 14 12:42:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 14 May 2022 12:42:57 GMT Subject: RFR: 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:21:45 GMT, Jose Pereda wrote: > This PR fixes an issue with selection of multiple items in TableView and TreeTableView controls that gets moved unexpectedly when new items are added even way below the selected items. > > A couple of tests have been added. They fail without this PR (first selected item gets deselected, and table anchor gets moved), and pass with this PR (first selected item keeps selected, and table anchor remains at the same place). This looks simple enough that a single reviewer is sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/790 From fkirmaier at openjdk.java.net Mon May 16 11:08:04 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 16 May 2022 11:08:04 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Sun, 8 May 2022 18:56:45 GMT, Johan Vos wrote: >> @johanvos >> As requested, we've made a unit test, which tests this bug. >> It's based on your test and our original test class. It can be added to the ListViewTest. >> You can find it, in the JDK ticket. >> >> Btw, adding the cells incrementally seems to make a difference - which is why the new test class tests both cases. >> >> It accepts various inputs of cell sizes - and should work with any inputs. >> It should catch all the cases from the original test class. >> Because it works with all possible inputs - one could even make a random test-cases generator to make sure it works in every case. >> >> It basically only works well, when the sizes are only 20s - in most other cases it fails. > > The later reported issues were due to the fact that the estimatedSize got updated during the layoutChildren call. That makes things much more complicated and leads to discrepancies. I disabled the updates to the estimated size during the layoutChildren call, so that all operations that are happening in that call are using a consistent value of the estimated size. We now pass all the tests added by @FlorianKirmaier on the JBS issue . Those tests are great regression tests. Hi @johanvos, I've updated the TestClass once more. You can find it on the ticket. There are 2 cases that seem to not work properly yet. 1.) If the elements are very big, the tests seem to fail - but it only happens if the scene is layouted again. 2.) On Click, the element gets selected and the VirtualFlow "jumps around". I've adapted the tests to simulate the click with the selectionModel. I've also added another assert, to check whether our cell is visible - which seems to be not always the case. Both cases were also reproducible with the original test application. Btw, can I somehow become an official reviewer for this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From alexsch at openjdk.java.net Mon May 16 12:49:59 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 16 May 2022 12:49:59 GMT Subject: RFR: 8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: <8oTMbfK3zBEh2XzuANRIN1nc57486S85FFenwRDGyWk=.fb0b770b-a291-423c-993d-cd4287d8bf59@github.com> On Fri, 18 Feb 2022 17:04:08 GMT, Alexander Scherbatiy wrote: > Zoomed/Rotated with two fingers rectangle flickers (unexpectedly becomes pretty small or large and then returns back to previous size several times during zooming/rotating) on a Raspberry Pi with Touchscreen. > > The log with traced events shows that it is possible that only one ABS_MT_POSITION_X or ABS_MT_POSITION_Y can be sent for a given slot. In this case the corresponding omitted Y/X value is undefined and is assigned from ABS_Y/X value. This produces incorrect result for slots different from 0. > > Example of the trace events log, enabled by `-Dmonocle.input.traceEvents.verbose=true -Dmonocle.input.traceEvents=true` flags: > > traceEvent: Processing EV_ABS ABS_MT_SLOT 1 [index=48] > traceEvent: Processing EV_ABS ABS_MT_TRACKING_ID 302 [index=64] > traceEvent: Processing EV_ABS ABS_MT_POSITION_X 399 [index=80] > traceEvent: Processing EV_ABS ABS_MT_POSITION_Y 272 [index=96] > traceEvent: Processing EV_KEY BTN_TOUCH 1 [index=112] > traceEvent: Read EV_ABS ABS_MT_SLOT 0 [index=176] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 315 [index=192] > traceEvent: Read EV_ABS ABS_Y 315 [index=208] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=224] > > ... > > traceEvent: Read EV_ABS ABS_MT_SLOT 1 [index=320] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 271 [index=336] > traceEvent: Read EV_ABS ABS_X 552 [index=352] > traceEvent: Read EV_ABS ABS_Y 322 [index=368] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=384] > > First both ABS_MT_POSITION_X/Y events with values x: 399 and y: 272 are received for the slot 1. > Next only ABS_MT_POSITION_Y with y: 271 value is received (which implies that the x value has not been changed) for the slot 1. > The x value is undefined in the LinuxStatefulMultiTouchProcessor.processEvents() loop and is unexpectedly assigned to the ABS_X 552 value which belongs to the slot 0. > > The fix skips setting ABS_X/Y values for slots different from 0. The fix also fixes the first use case described in the JDK-8087370 1. Consider you're touching the screen with two fingers, for example coordinates of one point is ~100,100 and second point is ~200,200. While still touching around the same points some events are reported with one or another point to be either 100,200 or 200,100. ------------- PR: https://git.openjdk.java.net/jfx/pull/737 From duke at openjdk.java.net Tue May 17 07:28:39 2022 From: duke at openjdk.java.net (Paul) Date: Tue, 17 May 2022 07:28:39 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v4] In-Reply-To: References: Message-ID: <23U1-aWhn3GSdoqcr8up77Tb5kwisUYz9FgVG0zhU-c=.dcd06ccc-c608-422c-a211-3e5dd3a58032@github.com> > I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. > > Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. > > Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- > > > if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { > NSSize imgSize = {width / sx, height / sy}; > [image setSize: imgSize]; > } > > > The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. > > Before this fix:- > > Screenshot 2022-02-26 at 22 16 30 > > After this fix:- > > Screenshot 2022-02-26 at 22 18 17 Paul has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8181084 - Updated variable names to be a bit more consistent - Merge branch 'master' into JDK-8181084 - Merge branch 'master' into JDK-8181084 - Removing trailing whitespace. - Correctly scales hi-res icons in MacOS system menu items ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/743/files - new: https://git.openjdk.java.net/jfx/pull/743/files/bb6d34fe..e1d2885d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=743&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=743&range=02-03 Stats: 5600 lines in 7 files changed: 5583 ins; 3 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/743.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743 PR: https://git.openjdk.java.net/jfx/pull/743 From hmeda at openjdk.java.net Tue May 17 12:53:32 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Tue, 17 May 2022 12:53:32 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 Message-ID: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. Verified the build on all the platforms and sanity testing looks fine.No regressions observed. ------------- Commit messages: - Remove tab - Update version info for libxml and libxslt - Remove trailing whitespace - libxslt upgrade to 1.1.35 on linux - libxml update to v2.9.14 on linux - Update xsltconfig.h for libxslt - libxml update to 2.9.14 on windows - libxslt update for mac - Mac specific changes - libxml update to 2.9.14 on mac Changes: https://git.openjdk.java.net/jfx/pull/797/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=797&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286256 Stats: 21619 lines in 79 files changed: 4388 ins; 4294 del; 12937 mod Patch: https://git.openjdk.java.net/jfx/pull/797.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/797/head:pull/797 PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Tue May 17 12:53:32 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Tue, 17 May 2022 12:53:32 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 In-Reply-To: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: <3XR6K-1u5LiAacwpnAYP1m6UT5heTz0EU1wz74FmG1Y=.9cbb5afc-0560-4138-b159-b7c5d6ed8ec7@github.com> On Tue, 17 May 2022 12:32:17 GMT, Hima Bindu Meda wrote: > Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. > > Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. > > Verified the build on all the platforms and sanity testing looks fine.No regressions observed. Creating UPDATING.txt for libxslt. Will commit it once done. ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Tue May 17 17:06:51 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Tue, 17 May 2022 17:06:51 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v2] In-Reply-To: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: > Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. > > Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. > > Verified the build on all the platforms and sanity testing looks fine.No regressions observed. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Add UPDATING.txt for libxslt update ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/797/files - new: https://git.openjdk.java.net/jfx/pull/797/files/7af0e74b..b9091ece Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=797&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=797&range=00-01 Stats: 36 lines in 1 file changed: 36 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/797.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/797/head:pull/797 PR: https://git.openjdk.java.net/jfx/pull/797 From kcr at openjdk.java.net Tue May 17 18:07:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 May 2022 18:07:09 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v2] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Tue, 17 May 2022 17:06:51 GMT, Hima Bindu Meda wrote: >> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. >> >> Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. >> >> Verified the build on all the platforms and sanity testing looks fine.No regressions observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Add UPDATING.txt for libxslt update The code changes look good. I tested it on 3 platforms. All good. I left a few inline comments, including a couple questions about whitespace diffs. I notice that there are 27 files that only have whitespace changes and no other diffs, as well as one more where the whitespace diffs are the majority of the changes. Is this intentional? modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/valid.c line 30: > 28: > 29: static xmlElementPtr xmlGetDtdElementDesc2(xmlDtdPtr dtd, const xmlChar *name, > 30: int create); This file has many whitespace-only changes (more than 2,800 lines). There is only one actual diff for this file. Can you double check the tab conversion? modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/UPDATING.txt line 15: > 13: > cscript configure.js compiler=msvc xslt_debug=no iconv=no mem_debug=no modules=no zlib=no profiler=no trio=no > 14: - Above command generates a header file 'src/config.h' file (on all platforms) and libxslt\src\libxslt\xsltconfig.h. > 15: 4.1 Copy `libxslt\src\config.h` to `libxslt\win32\config.h'. config.h file defines several macros to control libxslt features. We do not require all of the features to be enabled. Minor: trailing whitespace (since this is a text file, jcheck won't complain, but since you will be editing this file anyway, maybe you can fix this). modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/UPDATING.txt line 36: > 34: 9.1 Copy `libxslt/src/config.h` to `libxslt/linux/config.h` and follow same guidelines as Windows to retain changes from our repo. > 35: > 36: 10. Remove tabs and trailing whitespaces from source files(.h and .c). Can you add a step to update the version in `modules/javafx.web/src/main/legal/libxslt.md`. Please also add a similar step to `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/UPDATING.txt` (which is otherwise unmodified). modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/linux/libexslt/exsltconfig.h line 21: > 19: * the version string like "1.2.3" > 20: */ > 21: #define LIBEXSLT_DOTTED_VERSION "0.8.20" Shouldn't this be `1.1.35`? modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/attributes.c line 67: > 65: ((c) == 0x0D)) > 66: > 67: #define IS_BLANK_NODE(n) \ This file has only whitespace changes and no other changes. other than whitespace changes. Is this intentional? ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From thiago.sayao at gmail.com Tue May 17 21:17:47 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 17 May 2022 18:17:47 -0300 Subject: Xlib backend In-Reply-To: References: <4hzgkqn7my.fsf@qfs.de> Message-ID: Hi, Did some improvements on my "pure x11" branch: - Bitmaps are now handled by cairo which will use Xrender if available (will be beneficial if there's an alpha channel). - Configuration using Xsettings (such as double click time) - Setting the app icon now works - Custom cursor works - Mouse button works - Able to launch Ensemble8 (with random crashes). Interesting thing is that there's no need to convert BGRA -> RGBA. Not sure if it's a big performance improvement. It seems the only thing that will be missing to completely ditch gtk are the "common dialogs" such as file open, etc. I'm also investigating Wayland. It's somewhat similar to Xorg when it comes to events and the use of XDG specs. Probably will replace cairo with egl. -- Thiago. Em dom., 24 de abr. de 2022 ?s 17:40, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > Xlib port at: > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib > > Is able to very poorly run Ensemble8: > java @build/run.args -jar apps/samples/Ensemble8/dist/Ensemble8.jar > > Keyboard events still do not work, mouse clicks are still buggy. > There will be crashes, but it's progress. > Window size & positioning is better now. > > I am painting directly like this: > > void WindowContextBase::paint(void* data, jint width, jint height) { > Pixmap pixmap = XCreatePixmapFromBitmapData(display, DefaultRootWindow(display), (char *) data, width, height, 0, 0, depth); > XCopyPlane(display, pixmap, xwindow, DefaultGC(display, DefaultScreen(display)), 0, 0, width, height, 0, 0, 1); > > XFlush(display); > XFreePixmap(display, pixmap); > } > > It does flicker a little, maybe it needs XSync extension to draw together > with WM, maybe some kind of buffering. > Using cairo is possible, but it's a final render, not sure if there will > be advantages. > > I am accepting opinions. > > > -- Thiago. > > Em ter., 12 de abr. de 2022 ?s 03:22, escreveu: > >> >> Hi Thiago, >> >> I wholly agree. >> >> If gtk can be taken out of the equation it will reduce dependencies >> significantly. Like we had with gtk2 vs. 3 in JavaFX/Swing >> cross-embedding. Moving to gtk3 would start this all over again >> whereas plain Xlib should remain fully compatible regardless of the >> gtk version used by Swing (or SWT or whatever). >> >> I'll gladly help with testing - just ping me when you've got a >> version that is reasonably stable. >> >> Best regards, >> Greg >> >> Thiago Milczarek Say?o writes: >> >> > Kevin, >> > >> > Sure, I was hoping for the question. >> > >> > "The focus of GTK has moved away from being a ?meta toolkit? that other >> > toolkits can use as a ?backend?." >> > >> > Quoted from >> > >> https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 >> > >> > The first attempt I have made is the logical one, gtk4: >> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground >> > >> > Then I have discovered it's not possible to use gtk4 without Xlib and >> that >> > many window management functions are gone (see the quotation link). >> > In addition to this: >> > - Gtk4 cannot draw directly on the window or set the background without >> > gtk4 css; >> > - It cannot even move the window, just tell the compositor it started a >> > move. >> > >> > I also have played plenty with gtk3, it breaks a lot of things thru the >> 3.x >> > release cycle, such as DND. >> > >> > So, I see no reason to use Gtk if Xlib fits better as a glass backend >> (has >> > all the needed functions) and Gtk would use Xlib anyway and hide much >> > needed functionality. >> > >> > Current glass Gtk backend already touches a lot of Xlib. >> > >> > Wayland is fully compatible with Xlib, so we can work on "both worlds" >> with >> > it. Someday on the future a pure Wayland backend would be nice. >> > >> > I'm happy to answer any further questions. >> > >> > -- Thiago. >> > >> > >> > >> > >> > Em seg., 11 de abr. de 2022 ?s 12:41, Kevin Rushforth < >> > kevin.rushforth at oracle.com> escreveu: >> > >> >> Can you say more about the motivation for doing this? Given the >> eventual >> >> direction for Wayland support, even in X11 compatibility mode, I would >> >> expect more use of gtk and less use of Xlib, not the other way around. >> >> >> >> -- Kevin >> >> >> >> On 4/10/2022 2:43 PM, Thiago Milczarek Say?o wrote: >> >> > Hi, >> >> > >> >> > I got simple samples running on the pure Xlib port of the Gtk >> backend. >> >> > >> >> > It still has gtk code, but mainly uses Xlib by now. Don't judge the >> code, >> >> > I'm porting it gradually. >> >> > >> >> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib >> >> > >> >> > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar >> >> hello.HelloCursors >> >> > >> >> > Window coordinates and sizes are still off a bit, so you might have >> to >> >> > resize the window to redraw. >> >> > >> >> > -- Thiago. >> >> >> >> >> >> -- >> Gregor Schmid >> >> E: gregor.schmid at qfs.de >> T: +49 8171 38648-11 >> F: +49 8171 38648-16 >> >> Quality First Software GmbH | www.qfs.de >> B?rgermeister-Graf-Ring 10 | 82538 Geretsried | Germany >> GF Gregor Schmid, Karlheinz Kellerer >> HRB M?nchen 140833 >> >> The data protection information in accordance with the EU General Data >> Protection Regulation applies to authorized representatives / >> authorized representatives of "legal persons" in accordance with Art. >> 12 ff. DS-GVO >> https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf >> > From hmeda at openjdk.java.net Wed May 18 06:00:12 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Wed, 18 May 2022 06:00:12 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v2] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: <9Qqw_Oa2ye-RFH8_jM_2KzXEwRv4c-NmvGCk_GvWTTg=.e00b3cfb-fd08-4d87-ac8f-dea50762dd2a@github.com> On Tue, 17 May 2022 17:39:27 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UPDATING.txt for libxslt update > > modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/attributes.c line 67: > >> 65: ((c) == 0x0D)) >> 66: >> 67: #define IS_BLANK_NODE(n) \ > > This file has only whitespace changes and no other changes. other than whitespace changes. Is this intentional? Yes, like in libxml, updated indentation here as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Wed May 18 06:24:04 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Wed, 18 May 2022 06:24:04 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v2] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Tue, 17 May 2022 17:23:15 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UPDATING.txt for libxslt update > > modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/UPDATING.txt line 36: > >> 34: 9.1 Copy `libxslt/src/config.h` to `libxslt/linux/config.h` and follow same guidelines as Windows to retain changes from our repo. >> 35: >> 36: 10. Remove tabs and trailing whitespaces from source files(.h and .c). > > Can you add a step to update the version in `modules/javafx.web/src/main/legal/libxslt.md`. Please also add a similar step to `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/UPDATING.txt` (which is otherwise unmodified). Done ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Wed May 18 07:19:11 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Wed, 18 May 2022 07:19:11 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v2] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: <6skFkUXvhTLNgizHOzpeSidV7ldPc-1A3YRCmorihYY=.c973cea3-7df8-46f6-92ce-0c417d106623@github.com> On Tue, 17 May 2022 17:19:00 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UPDATING.txt for libxslt update > > modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/valid.c line 30: > >> 28: >> 29: static xmlElementPtr xmlGetDtdElementDesc2(xmlDtdPtr dtd, const xmlChar *name, >> 30: int create); > > This file has many whitespace-only changes (more than 2,800 lines). There is only one actual diff for this file. Can you double check the tab conversion? These changes are due to the indentation corrections. Now, the formatting looks fine. Tab conversion looks fine for all the code blocks like if, switch and functions. ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Wed May 18 07:26:56 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Wed, 18 May 2022 07:26:56 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v3] In-Reply-To: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: > Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. > > Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. > > Verified the build on all the platforms and sanity testing looks fine.No regressions observed. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Update version inof related steps ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/797/files - new: https://git.openjdk.java.net/jfx/pull/797/files/b9091ece..df0207f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=797&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=797&range=01-02 Stats: 12 lines in 2 files changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/797.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/797/head:pull/797 PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Wed May 18 07:27:00 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Wed, 18 May 2022 07:27:00 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v2] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Tue, 17 May 2022 17:24:11 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UPDATING.txt for libxslt update > > modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/UPDATING.txt line 15: > >> 13: > cscript configure.js compiler=msvc xslt_debug=no iconv=no mem_debug=no modules=no zlib=no profiler=no trio=no >> 14: - Above command generates a header file 'src/config.h' file (on all platforms) and libxslt\src\libxslt\xsltconfig.h. >> 15: 4.1 Copy `libxslt\src\config.h` to `libxslt\win32\config.h'. config.h file defines several macros to control libxslt features. We do not require all of the features to be enabled. > > Minor: trailing whitespace (since this is a text file, jcheck won't complain, but since you will be editing this file anyway, maybe you can fix this). Done ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From perini.davide at dpsoftware.org Wed May 18 11:12:13 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 18 May 2022 13:12:13 +0200 Subject: Looked-up color fails for -fx-background-color in JavaFX CSS file Message-ID: <1e2583ae-c627-4d7c-7028-4ba713206ae2@dpsoftware.org> Hi all, someone else opened an issue in past on this problem. I have the exact same problem: https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030723.html Kevin closed the issue because it was not able to reproduce but I can reproduce it on JavaFX 18.0.1 Can you double check it please? Thanks Davide From john.hendrikx at gmail.com Wed May 18 11:53:47 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 18 May 2022 13:53:47 +0200 Subject: Looked-up color fails for -fx-background-color in JavaFX CSS file In-Reply-To: <1e2583ae-c627-4d7c-7028-4ba713206ae2@dpsoftware.org> References: <1e2583ae-c627-4d7c-7028-4ba713206ae2@dpsoftware.org> Message-ID: Could you share the program that reproduces this, as I didn't find an issue nor a sample program in the link you shared. You mentioned an issue was closed? Which issue? --John On 18/05/2022 13:12, Davide Perini wrote: > Hi all, > someone else opened an issue in past on this problem. > > I have the exact same problem: > https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030723.html > > Kevin closed the issue because it was not able to reproduce but I can > reproduce it on JavaFX 18.0.1 > > Can you double check it please? > > Thanks > Davide From kevin.rushforth at oracle.com Wed May 18 12:10:43 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 May 2022 05:10:43 -0700 Subject: Looked-up color fails for -fx-background-color in JavaFX CSS file In-Reply-To: <1e2583ae-c627-4d7c-7028-4ba713206ae2@dpsoftware.org> References: <1e2583ae-c627-4d7c-7028-4ba713206ae2@dpsoftware.org> Message-ID: <08690ab4-1bab-2c92-b1af-ec339f79c700@oracle.com> Hi Davide, Are you referring to https://bugs.openjdk.java.net/browse/JDK-8268657 ? I just tried it again, and it works fine for me. -- Kevin On 5/18/2022 4:12 AM, Davide Perini wrote: > Hi all, > someone else opened an issue in past on this problem. > > I have the exact same problem: > https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030723.html > > Kevin closed the issue because it was not able to reproduce but I can > reproduce it on JavaFX 18.0.1 > > Can you double check it please? > > Thanks > Davide From kcr at openjdk.java.net Wed May 18 12:40:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 12:40:10 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v3] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Wed, 18 May 2022 07:26:56 GMT, Hima Bindu Meda wrote: >> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. >> >> Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. >> >> Verified the build on all the platforms and sanity testing looks fine.No regressions observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Update version inof related steps The updated instructions look good with one minor issue (a missing space between a `.` and the start of the next sentence). modules/javafx.web/src/main/native/Source/ThirdParty/libxml/UPDATING.txt line 44: > 42: 9.2 Copy libxml\src\config.h to libxml\linux\config.h > 43: > 44: 10. Update version info in 'modules/javafx.web/src/main/legal/libxml.md'.Also, update copyright if any new files are added. Minor: missing space before `Also`. modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/UPDATING.txt line 37: > 35: 9.1 Copy `libxslt/src/config.h` to `libxslt/linux/config.h` and follow same guidelines as Windows to retain changes from our repo. > 36: > 37: 10. Update version info in 'modules/javafx.web/src/main/legal/libxslt.md'.Also, update copyright if any new files are added. Minor: missing space before `Also`. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/797 From kcr at openjdk.java.net Wed May 18 12:40:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 12:40:13 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v2] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: <81rJn8C3KfPuLNGLJbvi0dwymGp0j0RNI0b1MjYoLBI=.798c9bed-8a4d-4d16-a86d-a6c002a40361@github.com> On Tue, 17 May 2022 17:25:16 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UPDATING.txt for libxslt update > > modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/linux/libexslt/exsltconfig.h line 21: > >> 19: * the version string like "1.2.3" >> 20: */ >> 21: #define LIBEXSLT_DOTTED_VERSION "0.8.20" > > Shouldn't this be `1.1.35`? Actually, now that I see it, it looks correct as is, so you can ignore this question. ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From kcr at openjdk.java.net Wed May 18 13:13:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 13:13:49 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v3] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: <2nuqT8YPUjObtutYcPkQnLg5te6Ijb29n2MrC2RzvZs=.e8506a7d-7702-4881-8df9-4eb3682096b4@github.com> On Wed, 18 May 2022 07:26:56 GMT, Hima Bindu Meda wrote: >> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. >> >> Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. >> >> Verified the build on all the platforms and sanity testing looks fine.No regressions observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Update version inof related steps @johanvos or @tiainen Can one of you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Wed May 18 13:39:12 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Wed, 18 May 2022 13:39:12 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v4] In-Reply-To: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: > Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. > > Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. > > Verified the build on all the platforms and sanity testing looks fine.No regressions observed. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Space correction ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/797/files - new: https://git.openjdk.java.net/jfx/pull/797/files/df0207f3..e3ea6633 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=797&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=797&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/797.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/797/head:pull/797 PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Wed May 18 13:39:15 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Wed, 18 May 2022 13:39:15 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v3] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Wed, 18 May 2022 12:27:46 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update version inof related steps > > modules/javafx.web/src/main/native/Source/ThirdParty/libxml/UPDATING.txt line 44: > >> 42: 9.2 Copy libxml\src\config.h to libxml\linux\config.h >> 43: >> 44: 10. Update version info in 'modules/javafx.web/src/main/legal/libxml.md'.Also, update copyright if any new files are added. > > Minor: missing space before `Also`. done > modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/UPDATING.txt line 37: > >> 35: 9.1 Copy `libxslt/src/config.h` to `libxslt/linux/config.h` and follow same guidelines as Windows to retain changes from our repo. >> 36: >> 37: 10. Update version info in 'modules/javafx.web/src/main/legal/libxslt.md'.Also, update copyright if any new files are added. > > Minor: missing space before `Also`. done ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From kcr at openjdk.java.net Wed May 18 14:16:51 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 14:16:51 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v4] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Wed, 18 May 2022 13:39:12 GMT, Hima Bindu Meda wrote: >> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. >> >> Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. >> >> Verified the build on all the platforms and sanity testing looks fine.No regressions observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Space correction Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From perini.davide at dpsoftware.org Wed May 18 16:05:25 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 18 May 2022 18:05:25 +0200 Subject: Looked-up color fails for -fx-background-color in JavaFX CSS file In-Reply-To: <08690ab4-1bab-2c92-b1af-ec339f79c700@oracle.com> References: <1e2583ae-c627-4d7c-7028-4ba713206ae2@dpsoftware.org> <08690ab4-1bab-2c92-b1af-ec339f79c700@oracle.com> Message-ID: <98ca8b81-c270-3d69-af90-6aab571439ad@dpsoftware.org> Yes, I'm sorry, that was the issue. Thanks Davide Il 18/05/2022 14:10, Kevin Rushforth ha scritto: > Hi Davide, > > Are you referring to https://bugs.openjdk.java.net/browse/JDK-8268657 ? > > I just tried it again, and it works fine for me. > > -- Kevin > > On 5/18/2022 4:12 AM, Davide Perini wrote: >> Hi all, >> someone else opened an issue in past on this problem. >> >> I have the exact same problem: >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030723.html >> >> >> Kevin closed the issue because it was not able to reproduce but I can >> reproduce it on JavaFX 18.0.1 >> >> Can you double check it please? >> >> Thanks >> Davide > From duke at openjdk.java.net Wed May 18 21:16:09 2022 From: duke at openjdk.java.net (Tomator) Date: Wed, 18 May 2022 21:16:09 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number Message-ID: When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. The crash demo like this: `import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Menu; import javafx.scene.control.MenuBar; import javafx.scene.control.MenuItem; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class MenuExample extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) throws Exception { BorderPane root = new BorderPane(); Scene scene = new Scene(root,200,300); MenuBar menubar = new MenuBar(); Menu FileMenu = new Menu("??"); MenuItem filemenu1=new MenuItem("??"); MenuItem filemenu2=new MenuItem("Save"); MenuItem filemenu3=new MenuItem("Exit"); Menu EditMenu=new Menu("Edit"); MenuItem EditMenu1=new MenuItem("Cut"); MenuItem EditMenu2=new MenuItem("Copy"); MenuItem EditMenu3=new MenuItem("Paste"); EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); root.setTop(menubar); FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); menubar.getMenus().addAll(FileMenu,EditMenu); primaryStage.setScene(scene); primaryStage.setTitle("TEST"); primaryStage.show(); } } ` the error: `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) ` ------------- Commit messages: - Update GlyphCache.java - Update GlyphCache.java Changes: https://git.openjdk.java.net/jfx/pull/795/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286867 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/795.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/795/head:pull/795 PR: https://git.openjdk.java.net/jfx/pull/795 From duke at openjdk.java.net Wed May 18 21:16:09 2022 From: duke at openjdk.java.net (Tomator) Date: Wed, 18 May 2022 21:16:09 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: Message-ID: <0JkJZJ7btLHo5ialpyK1e__JZClsqF4YVo2N6ld1qpw=.2e6bd428-4ed9-4b21-9da8-022c9d275cc2@github.com> On Fri, 13 May 2022 05:34:08 GMT, Tomator wrote: > When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. > The crash demo like this: > `import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.control.MenuItem; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class MenuExample extends Application { > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > BorderPane root = new BorderPane(); > Scene scene = new Scene(root,200,300); > MenuBar menubar = new MenuBar(); > Menu FileMenu = new Menu("??"); > MenuItem filemenu1=new MenuItem("??"); > MenuItem filemenu2=new MenuItem("Save"); > MenuItem filemenu3=new MenuItem("Exit"); > Menu EditMenu=new Menu("Edit"); > MenuItem EditMenu1=new MenuItem("Cut"); > MenuItem EditMenu2=new MenuItem("Copy"); > MenuItem EditMenu3=new MenuItem("Paste"); > EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); > root.setTop(menubar); > FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); > menubar.getMenus().addAll(FileMenu,EditMenu); > primaryStage.setScene(scene); > primaryStage.setTitle("TEST"); > primaryStage.show(); > > } > } ` > > the error: > `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 > at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) > at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) > at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) > at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) > at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) > at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > ` The crash demo like this: `import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Menu; import javafx.scene.control.MenuBar; import javafx.scene.control.MenuItem; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class MenuExample extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) throws Exception { BorderPane root = new BorderPane(); Scene scene = new Scene(root,200,300); MenuBar menubar = new MenuBar(); Menu FileMenu = new Menu("??"); MenuItem filemenu1=new MenuItem("??"); MenuItem filemenu2=new MenuItem("Save"); MenuItem filemenu3=new MenuItem("Exit"); Menu EditMenu=new Menu("Edit"); MenuItem EditMenu1=new MenuItem("Cut"); MenuItem EditMenu2=new MenuItem("Copy"); MenuItem EditMenu3=new MenuItem("Paste"); EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); root.setTop(menubar); FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); menubar.getMenus().addAll(FileMenu,EditMenu); primaryStage.setScene(scene); primaryStage.setTitle("TEST"); primaryStage.show(); } } ` > > thanks,I'll wait for the bug ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From kcr at openjdk.java.net Wed May 18 21:16:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 21:16:10 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: <0JkJZJ7btLHo5ialpyK1e__JZClsqF4YVo2N6ld1qpw=.2e6bd428-4ed9-4b21-9da8-022c9d275cc2@github.com> References: <0JkJZJ7btLHo5ialpyK1e__JZClsqF4YVo2N6ld1qpw=.2e6bd428-4ed9-4b21-9da8-022c9d275cc2@github.com> Message-ID: On Fri, 13 May 2022 05:36:03 GMT, Tomator wrote: >> When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. >> The crash demo like this: >> `import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Menu; >> import javafx.scene.control.MenuBar; >> import javafx.scene.control.MenuItem; >> import javafx.scene.layout.BorderPane; >> import javafx.stage.Stage; >> >> public class MenuExample extends Application { >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> BorderPane root = new BorderPane(); >> Scene scene = new Scene(root,200,300); >> MenuBar menubar = new MenuBar(); >> Menu FileMenu = new Menu("??"); >> MenuItem filemenu1=new MenuItem("??"); >> MenuItem filemenu2=new MenuItem("Save"); >> MenuItem filemenu3=new MenuItem("Exit"); >> Menu EditMenu=new Menu("Edit"); >> MenuItem EditMenu1=new MenuItem("Cut"); >> MenuItem EditMenu2=new MenuItem("Copy"); >> MenuItem EditMenu3=new MenuItem("Paste"); >> EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); >> root.setTop(menubar); >> FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); >> menubar.getMenus().addAll(FileMenu,EditMenu); >> primaryStage.setScene(scene); >> primaryStage.setTitle("TEST"); >> primaryStage.show(); >> >> } >> } ` >> >> the error: >> `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 >> at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) >> at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) >> at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) >> at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) >> at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) >> at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) >> at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) >> at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) >> ` > > The crash demo like this: > `import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.control.MenuItem; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class MenuExample extends Application { > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > BorderPane root = new BorderPane(); > Scene scene = new Scene(root,200,300); > MenuBar menubar = new MenuBar(); > Menu FileMenu = new Menu("??"); > MenuItem filemenu1=new MenuItem("??"); > MenuItem filemenu2=new MenuItem("Save"); > MenuItem filemenu3=new MenuItem("Exit"); > Menu EditMenu=new Menu("Edit"); > MenuItem EditMenu1=new MenuItem("Cut"); > MenuItem EditMenu2=new MenuItem("Copy"); > MenuItem EditMenu3=new MenuItem("Paste"); > EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); > root.setTop(menubar); > FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); > menubar.getMenus().addAll(FileMenu,EditMenu); > primaryStage.setScene(scene); > primaryStage.setTitle("TEST"); > primaryStage.show(); > > } > } > ` @Tomator01 thank you for your interest in contributing to the OpenJFX project. In order for any comments that you add to this (or any other) PR to be retained, you will need to accept the OpenJDK Terms of Use as shown above. This is a one-time step. Please read the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) guidelines, in particular the [Before submitting a pull request](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#before-submitting-a-pull-request) section, for steps needed to advance this pull request, including: * Sign and submit the OCA, then indicate that you have done so with the `/signed` command * Submit a bug report with a test case at [bugreport.java.com](https://bugreport.java.com/) ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From kcr at openjdk.java.net Wed May 18 21:16:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 21:16:10 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: <0JkJZJ7btLHo5ialpyK1e__JZClsqF4YVo2N6ld1qpw=.2e6bd428-4ed9-4b21-9da8-022c9d275cc2@github.com> Message-ID: <5p4Pps82NpeUPmX2S_IUMuwVK6sSOhVl-hqGE1Y5Eac=.db44636b-299b-4394-8978-d94b12727d5a@github.com> On Fri, 13 May 2022 12:21:32 GMT, Kevin Rushforth wrote: > * Submit a bug report with a test case at [bugreport.java.com](https://bugreport.java.com/) I see that you already have submitted a bug report. You should get an email when it is made public. ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From duke at openjdk.java.net Wed May 18 21:16:12 2022 From: duke at openjdk.java.net (Tomator) Date: Wed, 18 May 2022 21:16:12 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: <0JkJZJ7btLHo5ialpyK1e__JZClsqF4YVo2N6ld1qpw=.2e6bd428-4ed9-4b21-9da8-022c9d275cc2@github.com> References: <0JkJZJ7btLHo5ialpyK1e__JZClsqF4YVo2N6ld1qpw=.2e6bd428-4ed9-4b21-9da8-022c9d275cc2@github.com> Message-ID: On Mon, 16 May 2022 08:12:54 GMT, Tomator wrote: >> When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. >> The crash demo like this: >> `import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Menu; >> import javafx.scene.control.MenuBar; >> import javafx.scene.control.MenuItem; >> import javafx.scene.layout.BorderPane; >> import javafx.stage.Stage; >> >> public class MenuExample extends Application { >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> BorderPane root = new BorderPane(); >> Scene scene = new Scene(root,200,300); >> MenuBar menubar = new MenuBar(); >> Menu FileMenu = new Menu("??"); >> MenuItem filemenu1=new MenuItem("??"); >> MenuItem filemenu2=new MenuItem("Save"); >> MenuItem filemenu3=new MenuItem("Exit"); >> Menu EditMenu=new Menu("Edit"); >> MenuItem EditMenu1=new MenuItem("Cut"); >> MenuItem EditMenu2=new MenuItem("Copy"); >> MenuItem EditMenu3=new MenuItem("Paste"); >> EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); >> root.setTop(menubar); >> FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); >> menubar.getMenus().addAll(FileMenu,EditMenu); >> primaryStage.setScene(scene); >> primaryStage.setTitle("TEST"); >> primaryStage.show(); >> >> } >> } ` >> >> the error: >> `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 >> at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) >> at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) >> at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) >> at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) >> at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) >> at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) >> at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) >> at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) >> ` > >> > > > >> > > thanks,I'll wait for the bug > @Tomator01 thank you for your interest in contributing to the OpenJFX project. > > In order for any comments that you add to this (or any other) PR to be retained, you will need to accept the OpenJDK Terms of Use as shown above. This is a one-time step. > > Please read the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) guidelines, in particular the [Before submitting a pull request](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#before-submitting-a-pull-request) section, for steps needed to advance this pull request, including: > > * Sign and submit the OCA, then indicate that you have done so with the `/signed` command > * Submit a bug report with a test case at [bugreport.java.com](https://bugreport.java.com/) Hello,i have signed oca ,and pull /signed command ,so I'm just wait for OCA to pass? ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From duke at openjdk.java.net Wed May 18 21:16:13 2022 From: duke at openjdk.java.net (yosbits) Date: Wed, 18 May 2022 21:16:13 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: Message-ID: On Fri, 13 May 2022 05:34:08 GMT, Tomator wrote: > When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. > The crash demo like this: > `import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.control.MenuItem; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class MenuExample extends Application { > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > BorderPane root = new BorderPane(); > Scene scene = new Scene(root,200,300); > MenuBar menubar = new MenuBar(); > Menu FileMenu = new Menu("??"); > MenuItem filemenu1=new MenuItem("??"); > MenuItem filemenu2=new MenuItem("Save"); > MenuItem filemenu3=new MenuItem("Exit"); > Menu EditMenu=new Menu("Edit"); > MenuItem EditMenu1=new MenuItem("Cut"); > MenuItem EditMenu2=new MenuItem("Copy"); > MenuItem EditMenu3=new MenuItem("Paste"); > EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); > root.setTop(menubar); > FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); > menubar.getMenus().addAll(FileMenu,EditMenu); > primaryStage.setScene(scene); > primaryStage.setTitle("TEST"); > primaryStage.show(); > > } > } ` > > the error: > `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 > at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) > at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) > at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) > at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) > at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) > at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > ` Reading the author's description of this PR, one wonders why the added condition is not "glyphCode < 0". ``` java if (glyphCode <= 0) {return null;} ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From duke at openjdk.java.net Wed May 18 21:16:13 2022 From: duke at openjdk.java.net (Tomator) Date: Wed, 18 May 2022 21:16:13 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: Message-ID: <7O2jFDYK5qO4AlG_7egCaKhlVMFrmXHLxfrbtC0VWd0=.c12cff2b-5cce-45fd-bfce-16c6d91e4372@github.com> On Tue, 17 May 2022 13:34:47 GMT, yosbits wrote: > Reading the author's description of this PR, one wonders why the added condition is not "glyphCode < 0". > > ```java > if (glyphCode <= 0) {return null;} > ``` Your suggestion is right ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From kcr at openjdk.java.net Wed May 18 21:16:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 21:16:14 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: <0JkJZJ7btLHo5ialpyK1e__JZClsqF4YVo2N6ld1qpw=.2e6bd428-4ed9-4b21-9da8-022c9d275cc2@github.com> Message-ID: On Tue, 17 May 2022 13:08:10 GMT, Tomator wrote: > Hello,i have signed oca ,and pull /signed command ,so I'm just wait for OCA to pass? Yes, at this point you wait for your OCA to be processed. ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From john.hendrikx at gmail.com Thu May 19 02:52:11 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 19 May 2022 04:52:11 +0200 Subject: Looked-up color fails for -fx-background-color in JavaFX CSS file In-Reply-To: <98ca8b81-c270-3d69-af90-6aab571439ad@dpsoftware.org> References: <1e2583ae-c627-4d7c-7028-4ba713206ae2@dpsoftware.org> <08690ab4-1bab-2c92-b1af-ec339f79c700@oracle.com> <98ca8b81-c270-3d69-af90-6aab571439ad@dpsoftware.org> Message-ID: I've tried the attached code as well, and I've been unable to reproduce it. I even modified the code a bit to clear and set the stylesheet every frame, and it runs fine. Also used the debugger a bit to see what's going on in CssStyleHelper#calculateValue but didn't see any obvious flaws. If you want, you could put a breakpoint on line 1634 in that class (just after #calculateValue's "catch(ClassCastException)") and see if you can see something odd going on. The stack trace might be useful to have, and perhaps why it occured if you could dig a bit deeper. The only way I could get it to fail is to put an actual bad value in "-theme-button". Are you doing anything else special while running the code? Or do you have a different example case that shows the problem? --John On 18/05/2022 18:05, Davide Perini wrote: > Yes, I'm sorry, that was the issue. > > Thanks > Davide > > > Il 18/05/2022 14:10, Kevin Rushforth ha scritto: >> Hi Davide, >> >> Are you referring to https://bugs.openjdk.java.net/browse/JDK-8268657 ? >> >> I just tried it again, and it works fine for me. >> >> -- Kevin >> >> On 5/18/2022 4:12 AM, Davide Perini wrote: >>> Hi all, >>> someone else opened an issue in past on this problem. >>> >>> I have the exact same problem: >>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-June/030723.html >>> >>> >>> Kevin closed the issue because it was not able to reproduce but I >>> can reproduce it on JavaFX 18.0.1 >>> >>> Can you double check it please? >>> >>> Thanks >>> Davide >> > From jhendrikx at openjdk.java.net Thu May 19 03:03:57 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 19 May 2022 03:03:57 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: <4UjI5xTzVnSpZbB-HCn588NWS5ClDqQfYj-VqmAAvXE=.d3880064-7d36-4af4-bc40-a535b67cc0fe@github.com> On Tue, 22 Mar 2022 20:17:36 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wording > > Yes, I definitely want to be one of the reviewers. I'll need to review the CSR in any case. @kevinrushforth have you had a chance to look at this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From mstrauss at openjdk.java.net Thu May 19 04:03:46 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 19 May 2022 04:03:46 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v9] In-Reply-To: References: Message-ID: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request 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 23 additional commits since the last revision: - Merge branch 'master' into feature/focusvisible - Updated since tag - Update copyright headers - Merge branch 'master' into feature/focusvisible - fixed undeterministic test failures - minor wording change - restart github actions - Merge branch 'master' of https://github.com/mstr2/jfx into feature/focusvisible - changes per discussion, added test - wording - ... and 13 more: https://git.openjdk.java.net/jfx/compare/a6d4f5e5...0c7d6e72 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/bd57bbac..0c7d6e72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=07-08 Stats: 101583 lines in 580 files changed: 34334 ins; 31264 del; 35985 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From duke at openjdk.java.net Thu May 19 12:27:49 2022 From: duke at openjdk.java.net (=?UTF-8?B?UGF3ZcWC?= =?UTF-8?B?IA==?= =?UTF-8?B?S3J1c3pjennFhHNraQ==?=) Date: Thu, 19 May 2022 12:27:49 GMT Subject: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again [v4] In-Reply-To: References: Message-ID: > `Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on overlaying tooltip also kills the tooltip, so the infinite duration tooltip can be closed. Pawe? Kruszczy?ski 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: - Merge branch 'openjdk:master' into 8261221_tooltip_blinks - Merge branch 'openjdk:master' into 8261221_tooltip_blinks - 8261221: Tooltip bigger than screen size blinks - applying reviewed fixes - 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/395/files - new: https://git.openjdk.java.net/jfx/pull/395/files/0a175dca..7dc2ff37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=395&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=395&range=02-03 Stats: 5600 lines in 7 files changed: 5583 ins; 3 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/395.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/395/head:pull/395 PR: https://git.openjdk.java.net/jfx/pull/395 From duke at openjdk.java.net Thu May 19 12:50:29 2022 From: duke at openjdk.java.net (=?UTF-8?B?UGF3ZcWC?= =?UTF-8?B?IA==?= =?UTF-8?B?S3J1c3pjennFhHNraQ==?=) Date: Thu, 19 May 2022 12:50:29 GMT Subject: RFR: 8090522: Allow support for disabling stage iconification (minimization) Message-ID: <27gFx9-A428ulQkJAVBshlERDqh1RX8wJZLIafdl4B4=.98b3983d-7c98-4a26-b491-5797dbfb5ca6@github.com> `Stage` minimalizing (iconified state) cannot be disabled for the user. The same for `Stage` closable state. PR adds these features without breaking backward compatibility. ------------- Commit messages: - 8090522: Allow support for disabling stage iconification (minimization) Changes: https://git.openjdk.java.net/jfx/pull/798/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=798&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8090522 Stats: 199 lines in 5 files changed: 198 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/798.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/798/head:pull/798 PR: https://git.openjdk.java.net/jfx/pull/798 From kcr at openjdk.java.net Thu May 19 13:05:02 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 May 2022 13:05:02 GMT Subject: RFR: 8090522: Allow support for disabling stage iconification (minimization) In-Reply-To: <27gFx9-A428ulQkJAVBshlERDqh1RX8wJZLIafdl4B4=.98b3983d-7c98-4a26-b491-5797dbfb5ca6@github.com> References: <27gFx9-A428ulQkJAVBshlERDqh1RX8wJZLIafdl4B4=.98b3983d-7c98-4a26-b491-5797dbfb5ca6@github.com> Message-ID: On Thu, 19 May 2022 12:44:44 GMT, Pawe? Kruszczy?ski wrote: > `Stage` minimalizing (iconified state) cannot be disabled for the user. The same for `Stage` closable state. > PR adds these features without breaking backward compatibility. @xardif It is premature to review this PR. Please read the section on [New features / API additions](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#new-features--api-additions) in the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) guide for necessary steps, which involves discussing any new feature on the openjfx-dev mailing list to see if there is general support for the idea. ------------- PR: https://git.openjdk.java.net/jfx/pull/798 From kcr at openjdk.java.net Thu May 19 13:08:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 May 2022 13:08:03 GMT Subject: RFR: 8090522: Allow support for disabling stage iconification (minimization) In-Reply-To: <27gFx9-A428ulQkJAVBshlERDqh1RX8wJZLIafdl4B4=.98b3983d-7c98-4a26-b491-5797dbfb5ca6@github.com> References: <27gFx9-A428ulQkJAVBshlERDqh1RX8wJZLIafdl4B4=.98b3983d-7c98-4a26-b491-5797dbfb5ca6@github.com> Message-ID: On Thu, 19 May 2022 12:44:44 GMT, Pawe? Kruszczy?ski wrote: > `Stage` minimalizing (iconified state) cannot be disabled for the user. The same for `Stage` closable state. > PR adds these features without breaking backward compatibility. Marking this as "Draft" since it is not ready for review. ------------- PR: https://git.openjdk.java.net/jfx/pull/798 From jbhaskar at openjdk.java.net Thu May 19 13:19:30 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 19 May 2022 13:19:30 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener Message-ID: This PR is new implementation of JavaEvent listener memory management. Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) 1. Calling remove event listener does not free jni global references. 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. Solution: 1. Detached the jni global reference from JavaEventListener. 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. ------------- Commit messages: - 8088420: JavaFX WebView memory leak via EventListener, code clean up - 8088420: JavaFX WebView memory leak via EventListener Changes: https://git.openjdk.java.net/jfx/pull/799/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8088420 Stats: 1148 lines in 11 files changed: 1142 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From rlichten at openjdk.java.net Thu May 19 14:23:55 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 19 May 2022 14:23:55 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) [v2] In-Reply-To: References: Message-ID: > Separate test class added for TreeTableView case. > Fix is analogous to JDK-8251480. Robert Lichtenberger has updated the pull request incrementally with two additional commits since the last revision: - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) Test class cosmetic cleanups #2. - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) Test class cosmetic cleanups. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/779/files - new: https://git.openjdk.java.net/jfx/pull/779/files/38d930a8..68f7c806 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=779&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=779&range=00-01 Stats: 13 lines in 1 file changed: 3 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/779.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/779/head:pull/779 PR: https://git.openjdk.java.net/jfx/pull/779 From rlichten at openjdk.java.net Thu May 19 14:23:56 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 19 May 2022 14:23:56 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 08:38:20 GMT, Robert Lichtenberger wrote: > Separate test class added for TreeTableView case. > Fix is analogous to JDK-8251480. Finally found the time to cleanup the test class... ------------- PR: https://git.openjdk.java.net/jfx/pull/779 From rlichten at openjdk.java.net Thu May 19 14:24:00 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 19 May 2022 14:24:00 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) [v2] In-Reply-To: <57Sp6VB8IX2Atvz3zKQP2Y6eEBpcmJIfbceQJHGr7qY=.695ed5ce-0ed7-4893-a79a-c2d0bff62c7e@github.com> References: <57Sp6VB8IX2Atvz3zKQP2Y6eEBpcmJIfbceQJHGr7qY=.695ed5ce-0ed7-4893-a79a-c2d0bff62c7e@github.com> Message-ID: On Thu, 12 May 2022 05:22:38 GMT, Ajit Ghaisas wrote: >> Robert Lichtenberger has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) >> >> Test class cosmetic cleanups #2. >> - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) >> >> Test class cosmetic cleanups. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableColumnHeaderTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. > > Replace "2018, 2021" with just "2022" as this is newly introduced test file. done > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableColumnHeaderTest.java line 51: > >> 49: import java.util.List; >> 50: >> 51: import static org.junit.Assert.*; > > Replace generic import statement with specific ones. done ------------- PR: https://git.openjdk.java.net/jfx/pull/779 From mhanl at openjdk.java.net Thu May 19 14:30:09 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 19 May 2022 14:30:09 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) [v2] In-Reply-To: References: Message-ID: <58Lv3vGShX3HEbgSJwX64A6y0fmig1Uda4FH2PNkHUw=.c3b9dd43-4609-4dfa-9b76-ea8ea88c54b3@github.com> On Thu, 19 May 2022 14:23:55 GMT, Robert Lichtenberger wrote: >> Separate test class added for TreeTableView case. >> Fix is analogous to JDK-8251480. > > Robert Lichtenberger has updated the pull request incrementally with two additional commits since the last revision: > > - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) > > Test class cosmetic cleanups #2. > - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) > > Test class cosmetic cleanups. Marked as reviewed by mhanl (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/779 From aghaisas at openjdk.java.net Thu May 19 15:15:08 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 19 May 2022 15:15:08 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) [v2] In-Reply-To: References: Message-ID: <28c79n0JeddNd5vuI918vsyemQG_pVNSh6XZGkkyI9w=.4a8d6aeb-6fa8-4b90-963e-32f76c51b519@github.com> On Thu, 19 May 2022 14:23:55 GMT, Robert Lichtenberger wrote: >> Separate test class added for TreeTableView case. >> Fix is analogous to JDK-8251480. > > Robert Lichtenberger has updated the pull request incrementally with two additional commits since the last revision: > > - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) > > Test class cosmetic cleanups #2. > - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) > > Test class cosmetic cleanups. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/779 From kcr at openjdk.java.net Thu May 19 15:27:01 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 May 2022 15:27:01 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener In-Reply-To: References: Message-ID: On Thu, 19 May 2022 13:13:01 GMT, Jay Bhaskar wrote: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. While testing, I noticed one problem in that the new unit tests calls `Platform.exit()` (this was my fault for adding it when sending you the test case), causing any subsequent web test to fail. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 113: > 111: public static void cleanupOnce() { > 112: Platform.exit(); > 113: } I just noticed that this will cause subsequent tests to fail. Unit tests should not call `Platform.exit()` (as opposed to system tests, which should). You can remove the entire method. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Thu May 19 15:57:46 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 19 May 2022 15:57:46 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v2] In-Reply-To: References: Message-ID: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Platform.exit() , removing code block, as it is causing other test fail ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/a62558ea..2d5604bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Thu May 19 15:57:47 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 19 May 2022 15:57:47 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v2] In-Reply-To: References: Message-ID: <6orLnBQwWzzkytJuTE40skxhbUu6t6YaSqeV9p0laGE=.3dd6a54a-0519-4fb9-9dd4-b7d139561ef9@github.com> On Thu, 19 May 2022 15:22:08 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Platform.exit() , removing code block, as it is causing other test fail > > modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 113: > >> 111: public static void cleanupOnce() { >> 112: Platform.exit(); >> 113: } > > I just noticed that this will cause subsequent tests to fail. Unit tests should not call `Platform.exit()` (as opposed to system tests, which should). You can remove the entire method. applied ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From kcr at openjdk.java.net Fri May 20 01:29:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 20 May 2022 01:29:56 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 15:57:46 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Platform.exit() , removing code block, as it is causing other test fail The fix looks good with a couple questions about removing entries from the map when they are done and some cleanup comments. In addition to the inline comments I left about the test, I think the following scenarios should be added to the automated test: 1. Multiple listeners single webiew implicit release (i.e., WebView goes out of scope) 2. Multiple listeners multiple webiew with explicit release of one webview and implicit release of the other (this one is basically a combination of the others) 3. Ref count test (single webview is fine) with adding and removing listeners. It should handle the cases of both increasing and decreasing the ref count, and adding the listener to another DOM node after its ref count has gone to zero to make sure that case works. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 57: > 55: if (it->second && it->second->use_count() == 1) { > 56: delete it->second; > 57: it->second = nullptr; Do you need to remove the item from the list in this case? modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 91: > 89: for (win_it = windowHasEvent.begin(); win_it != windowHasEvent.end(); win_it++) { > 90: // de register associated event listeners with window > 91: if(window == win_it->second) { Minor: add space after the `if`. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 92: > 90: // de register associated event listeners with window > 91: if(window == win_it->second) { > 92: unregisterListener(win_it->first); Same question as earlier: do you need to also remove the entries matching the `window` from the list here? modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 48: > 46: > 47: class JavaObjectWrapperHandler { > 48: jobject handler_; Have you considered using `JGObject` here instead of raw `jobject`? modules/javafx.web/src/main/native/Source/WebCore/bindings/java/JavaEventListener.cpp line 50: > 48: ? static_cast(&other) > 49: : nullptr; > 50: return jother && ( this == jother); Minor: you can remove the space after `(` modules/javafx.web/src/main/native/Source/WebCore/bindings/java/JavaEventListener.h line 32: > 30: #include "Node.h" > 31: > 32: #if PLATFORM(JAVA) This is a java platform-specific class, so you don't need the `#if PLATFORM(JAVA)` in this file. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 43: > 41: import javafx.scene.web.WebEngine; > 42: import javafx.scene.web.WebView; > 43: import org.junit.AfterClass; This import is no longer used. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 53: > 51: import org.junit.Before; > 52: import org.w3c.dom.Document; > 53: import org.w3c.dom.NodeList; Minor: maybe move these up to the previous block (with the ordinary imports? modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 631: > 629: > 630: // Verify that all listeners have not been released > 631: Thread.sleep(100); The sleep should be right before the call to `getClickCount` (as in other cases in the test). modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 637: > 635: }); > 636: > 637: assertEquals("Click count", 1, listeners1.get(0).getClickCount()); You should add a comment that this check is testing that the immediately previous click does _not_ get delivered since the associated DOM node is not part of the page any more. This is why the count remains at 1 (from the first click on the original page). Also, I think it would be useful here to clear the references to the listeners and WebView and make sure that the listener attached to the previously loaded page for this WebView gets released. Something like this as the final statements of the method: // Clear strong reference to listener and WebView listeners1.clear(); webView1 = null; // Verify that there is no strong reference to the WebView assertNumActive("WebView", webViewRefs, 0); // Verify that no listeners are strongly held assertNumActive("MyListener", listenerRefs, 0); tests/manual/web/EventListenerLeak.java line 1: > 1: import javafx.application.Application; You need to add a copyright header block. tests/manual/web/EventListenerLeak.java line 265: > 263: public static void main(String[] args) { > 264: > 265: // NOTE: this timer is probably not needed It turns out that this is needed to ensure GC, so you can remove the comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From arapte at openjdk.java.net Fri May 20 07:39:47 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 20 May 2022 07:39:47 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:56:53 GMT, Thiago Milczarek Sayao wrote: >> When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. >> >> The fix also works for: >> https://bugs.openjdk.java.net/browse/JDK-8269429 >> >> But this one might need another fix: >> https://bugs.openjdk.java.net/browse/JDK-8240640 > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Set the focus on the latest window when re-enabling them" > > This reverts commit b024de586c187f9000f791dab99507a4979cc027. Marked as reviewed by arapte (Reviewer). The fix look good to me. The other behavior is observed on mac but not on windows. The platform behavior itself looks different. Not sure if should be captured in a JBS (at least for documentation purpose) ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From rlichten at openjdk.java.net Fri May 20 09:16:14 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 20 May 2022 09:16:14 GMT Subject: Integrated: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 08:38:20 GMT, Robert Lichtenberger wrote: > Separate test class added for TreeTableView case. > Fix is analogous to JDK-8251480. This pull request has now been integrated. Changeset: 18b2366f Author: Robert Lichtenberger Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/18b2366f3d0520479f0d9c4af48acf9495d15a72 Stats: 180 lines in 2 files changed: 176 ins; 1 del; 3 mod 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) Reviewed-by: mhanl, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/779 From kcr at openjdk.java.net Fri May 20 12:24:54 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 20 May 2022 12:24:54 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 22:01:31 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Platform.exit() , removing code block, as it is causing other test fail > > modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 637: > >> 635: }); >> 636: >> 637: assertEquals("Click count", 1, listeners1.get(0).getClickCount()); > > You should add a comment that this check is testing that the immediately previous click does _not_ get delivered since the associated DOM node is not part of the page any more. This is why the count remains at 1 (from the first click on the original page). > > > Also, I think it would be useful here to clear the references to the listeners and WebView and make sure that the listener attached to the previously loaded page for this WebView gets released. Something like this as the final statements of the method: > > > // Clear strong reference to listener and WebView > listeners1.clear(); > webView1 = null; > > // Verify that there is no strong reference to the WebView > assertNumActive("WebView", webViewRefs, 0); > > // Verify that no listeners are strongly held > assertNumActive("MyListener", listenerRefs, 0); You will also need to clear the references to the DOM nodes, and set `webView2 = null;` for this to work. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From aghaisas at openjdk.java.net Fri May 20 15:08:07 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 20 May 2022 15:08:07 GMT Subject: RFR: 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants In-Reply-To: References: Message-ID: On Fri, 6 May 2022 10:16:41 GMT, Jose Pereda wrote: > This PR extends the check if a treeItem is expanded to all its ancestors, as in case one ancestor is collapsed, all its children will be hidden. > > 4 tests are included, two for TreeView and two for TreeTableView. This looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/791 From thiago.sayao at gmail.com Fri May 20 21:06:57 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 20 May 2022 18:06:57 -0300 Subject: @font-face question Message-ID: Hi, I want to have one font that is "regular" and a variation of the same font as "bold", used when specified "-fx-font-weight: bold". @font-face { font-family: 'Gotham Condensed'; src: url('../fonts/GothamCondensed-Book.otf'); } @font-face { font-family: 'Gotham Condensed Bold'; src: url('../fonts/GothamCondensed-Bold.otf'); } .text { -fx-font-family: 'Gotham Condensed'; } I have searched online and there are many variations such as: - @font-face "font-family" is ignored and you have to use the real font name; - If you use 'Bold' as a suffix, javafx will use it as bold; - you have to specify "font-weight: bold" on the @font-face The last one is what seems that the CSS specs says, but does not seem to work. Is it possible? Thanks. From jbhaskar at openjdk.java.net Sun May 22 11:44:50 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Sun, 22 May 2022 11:44:50 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v3] In-Reply-To: References: Message-ID: <9IQJHOw4xSn_pHpawabkJMrB5DjGmsGYy92ZwutnjVU=.5ec78a0a-db86-4917-a7bc-f9bdb57176b7@github.com> > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: remove data from map and extend unit test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/2d5604bf..5dc52378 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=01-02 Stats: 419 lines in 6 files changed: 407 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Sun May 22 11:44:52 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Sun, 22 May 2022 11:44:52 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 21:34:54 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Platform.exit() , removing code block, as it is causing other test fail > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 57: > >> 55: if (it->second && it->second->use_count() == 1) { >> 56: delete it->second; >> 57: it->second = nullptr; > > Do you need to remove the item from the list in this case? applied new change , for removal of unused pairs > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 91: > >> 89: for (win_it = windowHasEvent.begin(); win_it != windowHasEvent.end(); win_it++) { >> 90: // de register associated event listeners with window >> 91: if(window == win_it->second) { > > Minor: add space after the `if`. done > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 92: > >> 90: // de register associated event listeners with window >> 91: if(window == win_it->second) { >> 92: unregisterListener(win_it->first); > > Same question as earlier: do you need to also remove the entries matching the `window` from the list here? applied > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 48: > >> 46: >> 47: class JavaObjectWrapperHandler { >> 48: jobject handler_; > > Have you considered using `JGObject` here instead of raw `jobject`? No ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Sun May 22 14:06:41 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Sun, 22 May 2022 14:06:41 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v4] In-Reply-To: References: Message-ID: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Adding JGObject in plave of raw jni object ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/5dc52378..43f8e549 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=02-03 Stats: 32 lines in 3 files changed: 25 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Sun May 22 14:06:42 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Sun, 22 May 2022 14:06:42 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 21:45:00 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Platform.exit() , removing code block, as it is causing other test fail > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 48: > >> 46: >> 47: class JavaObjectWrapperHandler { >> 48: jobject handler_; > > Have you considered using `JGObject` here instead of raw `jobject`? Applied ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jpereda at openjdk.java.net Sun May 22 18:39:44 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 22 May 2022 18:39:44 GMT Subject: Integrated: 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants In-Reply-To: References: Message-ID: <_ezJ92eUDKyGh_zKN4egdiUgoM4A6ecb5_caC2KINOA=.71dee628-b18f-4519-ac57-2cc41a8660da@github.com> On Fri, 6 May 2022 10:16:41 GMT, Jose Pereda wrote: > This PR extends the check if a treeItem is expanded to all its ancestors, as in case one ancestor is collapsed, all its children will be hidden. > > 4 tests are included, two for TreeView and two for TreeTableView. This pull request has now been integrated. Changeset: 19a855e8 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/19a855e8ec3972377359ecbc0f71808f34c1b288 Stats: 179 lines in 5 files changed: 171 ins; 0 del; 8 mod 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/791 From thiago.sayao at gmail.com Mon May 23 12:32:40 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 23 May 2022 09:32:40 -0300 Subject: @font-face question In-Reply-To: References: Message-ID: Hi, After further investigation, I think there's a bug that font-family is not working (defining a font family name). Because regardless of the font-family I use, the font name within the font is used. It's openjfx 17.0.2 -- Thiago. Em sex., 20 de mai. de 2022 ?s 18:06, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > I want to have one font that is "regular" and a variation of the same font > as "bold", used when specified "-fx-font-weight: bold". > > @font-face { > font-family: 'Gotham Condensed'; > src: url('../fonts/GothamCondensed-Book.otf'); > } > > @font-face { > font-family: 'Gotham Condensed Bold'; > src: url('../fonts/GothamCondensed-Bold.otf'); > } > > > .text { > -fx-font-family: 'Gotham Condensed'; > } > > I have searched online and there are many variations such as: > > - @font-face "font-family" is ignored and you have to use the real font > name; > - If you use 'Bold' as a suffix, javafx will use it as bold; > - you have to specify "font-weight: bold" on the @font-face > > The last one is what seems that the CSS specs says, but does not seem to > work. > > Is it possible? > > Thanks. > > From jvos at openjdk.java.net Mon May 23 14:45:04 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 23 May 2022 14:45:04 GMT Subject: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v4] In-Reply-To: References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Wed, 18 May 2022 13:39:12 GMT, Hima Bindu Meda wrote: >> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. >> >> Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. >> >> Verified the build on all the platforms and sanity testing looks fine.No regressions observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Space correction works with our new build approach. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/797 From hmeda at openjdk.java.net Mon May 23 15:52:58 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Mon, 23 May 2022 15:52:58 GMT Subject: Integrated: JDK-8286256 : Update libxml2 to 2.9.14 In-Reply-To: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> References: <_0Xt7vraer_-HT_5Da3d8bDR0uvzO5BTwzY649sbhPk=.7c6440df-bad2-4e97-ba7f-0c0aefc40144@github.com> Message-ID: On Tue, 17 May 2022 12:32:17 GMT, Hima Bindu Meda wrote: > Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for windows , linux and Mac platforms and updated the files accordingly. > > Updated libxslt to version 1.1.35. Generated the config.h files for windows , Mac and linux platforms and updated accordingly. > > Verified the build on all the platforms and sanity testing looks fine.No regressions observed. This pull request has now been integrated. Changeset: d6770034 Author: Hima Bindu Meda Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d6770034a66a294b8740875c28871f2b4677aef2 Stats: 21664 lines in 81 files changed: 4429 ins; 4294 del; 12941 mod 8286256: Update libxml2 to 2.9.14 8286257: Update libxslt to 1.1.35 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/797 From jvos at openjdk.java.net Mon May 23 20:44:47 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 23 May 2022 20:44:47 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v6] In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Try to keep visible cells at their original position when improving the estimate. This reduces annoying effects when re-layouting cells without relevant changes. This should not be done when we don't have a valid estimate yet/anymore, or when the absoluteOffset is set to infinity (which may happen if the position is set to infinity, which is the case in some calls in Skin classes). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/aa08ba26..c7d722d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=04-05 Stats: 121 lines in 2 files changed: 75 ins; 29 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712 From jvos at openjdk.java.net Mon May 23 20:52:56 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 23 May 2022 20:52:56 GMT Subject: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v6] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Mon, 23 May 2022 20:44:47 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Try to keep visible cells at their original position when improving the estimate. > This reduces annoying effects when re-layouting cells without relevant changes. > > This should not be done when we don't have a valid estimate yet/anymore, > or when the absoluteOffset is set to infinity (which may happen if the > position is set to infinity, which is the case in some calls in Skin classes). To give some background: the reason for this PR is to fix (real or perceived) regression after https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed. The original problem was this: in case a ListView contains items with different heights, the scrollbar can show weird jumps as it considers all cells to have the same height. The "easy" solution to this would be to pre-calculate the height of all cells, but that would be a potential performance issue. The approach taken in JDK-8089589 is to gradually improve the information about the different sizes of the cells, and it fixes the weird jumps (at the very least, it avoids jumping upwards when scrolling down and vice versa). However, this gradual improvements can cause other visual disturbances. Initially, we improved the parameters whenever a layoutChildren was invoked. However, this leads to undesired effects in case layoutChildren is invoked again after a specific goal is asked (e.g. scroll to a cell with a specific index). A consequence of the gradual improvement is that the algorithm realizes the first cell need to move upwards or downwards a bit, but that will destroy the state where a cell should be positioned exactly at a given position. The latest commit fixes this, by modifying the parameters (absoluteOffset and position) in such a way that they lead to improvements, yet keep the visible cells intact. This broke a number of tests, as there are cases where keeping these cells intact is not what we want. When there is no cached estimate, or when the absoluteOffset has a bogus value, we do not want to maintain the previous situation. I'm moving this PR to draft until I have more confirmation about the (perceived) stability. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From jpereda at openjdk.java.net Tue May 24 09:51:29 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 24 May 2022 09:51:29 GMT Subject: RFR: 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView [v2] In-Reply-To: References: Message-ID: <6v0aSa7XHHj7oDd-mTsY56oPIHtADUqco15zLPZhk-k=.5167c77f-3459-4ca9-a9d5-6677ba89f407@github.com> > This PR fixes an issue with selection of multiple items in TableView and TreeTableView controls that gets moved unexpectedly when new items are added even way below the selected items. > > A couple of tests have been added. They fail without this PR (first selected item gets deselected, and table anchor gets moved), and pass with this PR (first selected item keeps selected, and table anchor remains at the same place). Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8284665-tableviewanchor - Only shift anchor if existing one is affected by the change event, and tests ------------- Changes: https://git.openjdk.java.net/jfx/pull/790/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=790&range=01 Stats: 101 lines in 4 files changed: 99 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/790.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/790/head:pull/790 PR: https://git.openjdk.java.net/jfx/pull/790 From jpereda at openjdk.java.net Tue May 24 09:51:30 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 24 May 2022 09:51:30 GMT Subject: RFR: 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView In-Reply-To: References: Message-ID: <2PY4XNtjcKT6hevUj5IK-eSwutS0etI-mr2PA_lN-H4=.a60ad1ad-2695-4263-82e2-2bfbb6866f69@github.com> On Thu, 5 May 2022 16:21:45 GMT, Jose Pereda wrote: > This PR fixes an issue with selection of multiple items in TableView and TreeTableView controls that gets moved unexpectedly when new items are added even way below the selected items. > > A couple of tests have been added. They fail without this PR (first selected item gets deselected, and table anchor gets moved), and pass with this PR (first selected item keeps selected, and table anchor remains at the same place). I've merged from head to fix conflicts, I guess it needs to be reviewed again? ------------- PR: https://git.openjdk.java.net/jfx/pull/790 From fkirmaier at openjdk.java.net Tue May 24 13:08:01 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 24 May 2022 13:08:01 GMT Subject: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v6] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Mon, 23 May 2022 20:44:47 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Try to keep visible cells at their original position when improving the estimate. > This reduces annoying effects when re-layouting cells without relevant changes. > > This should not be done when we don't have a valid estimate yet/anymore, > or when the absoluteOffset is set to infinity (which may happen if the > position is set to infinity, which is the case in some calls in Skin classes). Thank you for the update! We've tested it, and we made good progress. In our Application, we often resize the Cells, after the content is loaded. We've polished the unit test for the following 3 cases. (the changes are in this comment) **1.) Not jumping to the last cell.** Sometimes, when the last cell is very big, the ListView jumps to one cell above it. This was supposed to be caught by the previous tests, but due to a bug in the tests, it was missed. With this new definition of "shouldScrollToBottom" the bug is caught by the unit test: boolean isLastIndex = scrollToIndex == heights.length - 1; boolean shouldScrollToBottom = (sizeBelow < viewportLength) || (isLastIndex && lastCellSize >= viewportLength); **2.) Jumps on height changes** When the heights of the cells changes, "everything jumps around". Would it be possible to have the invariant, that the topmost visible element shouldn't move? Or alternatively: The selected element should be stable if it is visible. If this would be implementable, this would make the VirtualFlow behave much more "calm". **3.) Jumps on click after height changes** When the heights have changed, and an element is selected, then the position jumps around again. This is clearly a bug, because selecting a visible element shouldn't have the effect that cells "fly around". If they should move due to the height changes, this should happen when the height is changed, not when a cell is selected. For 2 and 3, I have some test-code, which can be added to the end of the method "verifyListViewScrollTo": // Additional Tests: double previousLayoutY = scrollToCell.getLayoutY(); System.out.println("previousLayoutY: " + previousLayoutY); if(previousLayoutY == 0) { System.out.println("ADDITIONAL CHECKS"); // Upper cell shouldn't move after heights are changed List alternateHeights = Arrays.stream(heights).map(x -> x + 250).collect(Collectors.toList()); listView.getItems().setAll(alternateHeights); listView.requestLayout(); Toolkit.getToolkit().firePulse(); assertEquals("Upper cell shouldn't move after changing heights", previousLayoutY, scrollToCell.getLayoutY(), 1.); // After clicking, the cells shouldn't move listView.getSelectionModel().select(scrollToIndex); listView.requestLayout(); Toolkit.getToolkit().firePulse(); assertEquals("Upper cell shouldn't move after changing heights and clicking", previousLayoutY, scrollToCell.getLayoutY(), 1.); } ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From kcr at openjdk.java.net Tue May 24 15:46:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 15:46:10 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v4] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 14:06:41 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Adding JGObject in plave of raw jni object I left a couple comments and one question on the changes to the fix. The new tests look good. I left a few comments and suggestions on the test, but overall they are good additions to verify the fix. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 29: > 27: #include "JavaEventListener.h" > 28: #include "DOMWindow.h" > 29: #include You probably don't need to include `stdio.h` modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 99: > 97: } > 98: > 99: void EventListenerManager::resetDOMWindow(DOMWindow* window) Have you validated this logic? If I understand correctly, the `isReferringToOtherListener` var will be true if any listener in the list of listeners for this DOM window has a ref count > 1. Is my understanding correct? This doesn't seem quite right to me, but I may be missing something. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 53: > 51: JavaObjectWrapperHandler(const JLObject& handler) { > 52: JNIEnv *env = nullptr; > 53: env = JavaScriptCore_GetJavaEnv(); You can remove these two lines, since `env` is now unused here. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 60: > 58: JNIEnv *env = nullptr; > 59: env = JavaScriptCore_GetJavaEnv(); > 60: env->DeleteGlobalRef(handler_); I think you can replace these three lines with: `handler_.clear();` modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 96: > 94: } > 95: > 96: static class MyListener1 implements EventListener { There is no need for another subclass of `EventListener`. It is unused and can be removed. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 630: > 628: */ > 629: @Test > 630: public void TestStrongRefNewContentLoad() throws Exception { You should set `webView2 = null` here modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 657: > 655: }); > 656: > 657: // Verify that all listeners have not been released This comment is not right. It should be something like: // Verify that the click event is not delivered to the event handler. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 664: > 662: listeners1.clear(); > 663: domNodes1.clear(); > 664: webViewRefs.clear(); This makes the subsequent call to `assertNumActive` ineffective. There should never be a need for any test method to explicitly modify the global refs lists. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 672: > 670: // Verify that no listeners are strongly held > 671: assertNumActive("MyListener", listenerRefs, 0); > 672: listenerRefs.clear(); It is not necessary to clear the `listenerRefs` list. There is never a need for a test to explicitly modify this list. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 676: > 674: > 675: /** > 676: * Test that the listener ref cont increase on addevent and decrease on remove event Typo: cont -> count modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 706: > 704: }); > 705: > 706: // Verify that the events are delivered to the listeners (0 and 2 are same) Actually all three refer to the same listener. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 713: > 711: MyListener tmpListener = listeners.get(0).get(); > 712: > 713: // remove previously registered listeners fro dom nodes Typo: fro -> from modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 716: > 714: submit(() -> { > 715: domNodes1 = getDomNodes(webView1); > 716: assertEquals(NUM_DOM_NODES, domNodes1.size()); I don't think you need to repeat these two calls. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 731: > 729: }); > 730: > 731: // Verify that the events are delivered to the listeners (0 and 2 are same) This comment is wrong. What you are verifying is that the events are _not_ delivered, which is why the count remains at 3. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 765: > 763: assertEquals("Click count", 6, listeners.get(1).get().getClickCount() + listeners.get(0).get().getClickCount()); > 764: > 765: // add events listeners again that should be "remove" modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 797: > 795: // Verify that no listeners are strongly held > 796: assertNumActive("MyListener", listenerRefs, 0); > 797: listenerRefs.clear(); No need to clear. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 855: > 853: // Verify that active listener > 854: assertNumActive("MyListener", listenerRefs, 0); > 855: listenerRefs.clear(); No need to clear this list. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 921: > 919: // Verify that the events are delivered to both webviews > 920: Thread.sleep(100); > 921: assertEquals("Click count", 3, listeners.get(0).get().getClickCount()); You might want to assert the counts for the other listeners, too. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 959: > 957: domNodes2.clear(); > 958: webView2 = null; > 959: Thread.sleep(100); This isn't harmful, but isn't needed. The sleep(100) is only used in the tests prior to checking click count. The `assertNumActive` method already does sleep between checks. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 962: > 960: // Verify that active listener > 961: assertNumActive("MyListener", listenerRefs, 0); > 962: listenerRefs.clear(); Same comment as previously about not clearing this list. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 991: > 989: click(webView1, 0); > 990: }); > 991: It would be useful to call `assertNumActive' and verify that there are two active refs. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 1003: > 1001: click(webView1, 0); > 1002: }); > 1003: It would be useful to call `assertNumActive' and verify that there is one active ref. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 1005: > 1003: > 1004: // Verify that listener has been released > 1005: assertEquals("Click count", 1, listeners.get(0).getClickCount()); sleep(100) before this check. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 1008: > 1006: assertEquals("Click count", 2, listeners.get(1).getClickCount()); > 1007: > 1008: // make web view , goes out of scope Suggestion: "// make WebView go out of scope" modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 1016: > 1014: // Verify that active listener > 1015: assertNumActive("MyListener", listenerRefs, 0); > 1016: listenerRefs.clear(); Same comment about not needing to clear this. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Tue May 24 16:54:51 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Tue, 24 May 2022 16:54:51 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v4] In-Reply-To: References: Message-ID: <6eLMkOYcNrC1ZqCQdgiKyUNh8RXz8jxb2pqcbhGDbd0=.2b849693-c437-4102-a042-fb2080b593ff@github.com> On Tue, 24 May 2022 14:54:19 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding JGObject in plave of raw jni object > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 99: > >> 97: } >> 98: >> 99: void EventListenerManager::resetDOMWindow(DOMWindow* window) > > Have you validated this logic? If I understand correctly, the `isReferringToOtherListener` var will be true if any listener in the list of listeners for this DOM window has a ref count > 1. Is my understanding correct? This doesn't seem quite right to me, but I may be missing something. yes , this is the case where we would remove pairs from map. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From kcr at openjdk.java.net Tue May 24 17:41:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:41:56 GMT Subject: [jfx17u] RFR: 8286256: Update libxml2 to 2.9.14 Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8286256: Update libxml2 to 2.9.14 Changes: https://git.openjdk.java.net/jfx17u/pull/61/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=61&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286256 Stats: 21664 lines in 81 files changed: 4429 ins; 4294 del; 12941 mod Patch: https://git.openjdk.java.net/jfx17u/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/61/head:pull/61 PR: https://git.openjdk.java.net/jfx17u/pull/61 From kcr at openjdk.java.net Tue May 24 17:42:31 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:42:31 GMT Subject: [jfx17u] RFR: 8283869: Update attribution in webkit.md file Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8283869: Update attribution in webkit.md file Changes: https://git.openjdk.java.net/jfx17u/pull/62/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=62&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283869 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/62/head:pull/62 PR: https://git.openjdk.java.net/jfx17u/pull/62 From kcr at openjdk.java.net Tue May 24 17:43:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:43:55 GMT Subject: [jfx11u] Integrated: 8286256: Update libxml2 to 2.9.14 Message-ID: Clean backport to `jfx11u`. ------------- Commit messages: - 8286256: Update libxml2 to 2.9.14 Changes: https://git.openjdk.java.net/jfx11u/pull/101/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=101&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286256 Stats: 21664 lines in 81 files changed: 4429 ins; 4294 del; 12941 mod Patch: https://git.openjdk.java.net/jfx11u/pull/101.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/101/head:pull/101 PR: https://git.openjdk.java.net/jfx11u/pull/101 From kcr at openjdk.java.net Tue May 24 17:43:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:43:56 GMT Subject: [jfx11u] Integrated: 8286256: Update libxml2 to 2.9.14 In-Reply-To: References: Message-ID: On Tue, 24 May 2022 17:31:27 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: 8504dad2 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/8504dad26ac0f0dcbf7cb62ac58642dc8a91f02e Stats: 21664 lines in 81 files changed: 4429 ins; 4294 del; 12941 mod 8286256: Update libxml2 to 2.9.14 8286257: Update libxslt to 1.1.35 Backport-of: d6770034a66a294b8740875c28871f2b4677aef2 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/101 From kcr at openjdk.java.net Tue May 24 17:44:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:44:48 GMT Subject: [jfx11u] Integrated: 8283869: Update attribution in webkit.md file Message-ID: <8s3AGtRGa4uhbjjekV69p-01scviEhjTFgu7FnoeOrc=.08dc2dc5-4007-41d3-837a-0dd09c5e3502@github.com> Clean backport to `jfx11u`. ------------- Commit messages: - 8283869: Update attribution in webkit.md file Changes: https://git.openjdk.java.net/jfx11u/pull/102/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283869 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/102/head:pull/102 PR: https://git.openjdk.java.net/jfx11u/pull/102 From kcr at openjdk.java.net Tue May 24 17:44:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:44:49 GMT Subject: [jfx11u] Integrated: 8283869: Update attribution in webkit.md file In-Reply-To: <8s3AGtRGa4uhbjjekV69p-01scviEhjTFgu7FnoeOrc=.08dc2dc5-4007-41d3-837a-0dd09c5e3502@github.com> References: <8s3AGtRGa4uhbjjekV69p-01scviEhjTFgu7FnoeOrc=.08dc2dc5-4007-41d3-837a-0dd09c5e3502@github.com> Message-ID: On Tue, 24 May 2022 17:31:58 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: f89a5139 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/f89a513980c2c2637c4f3d2b80f0708fd6f9e252 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod 8283869: Update attribution in webkit.md file Backport-of: 7bb4819409dd617ba2e3658ee66f23b94dc0bec1 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/102 From kcr at openjdk.java.net Tue May 24 17:45:01 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:45:01 GMT Subject: [jfx17u] Integrated: 8286256: Update libxml2 to 2.9.14 In-Reply-To: References: Message-ID: On Tue, 24 May 2022 17:33:57 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: 7b1637f8 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/7b1637f8f617639ddc0c93e15589824c6a0d71b1 Stats: 21664 lines in 81 files changed: 4429 ins; 4294 del; 12941 mod 8286256: Update libxml2 to 2.9.14 8286257: Update libxslt to 1.1.35 Backport-of: d6770034a66a294b8740875c28871f2b4677aef2 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/61 From kcr at openjdk.java.net Tue May 24 17:45:25 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 17:45:25 GMT Subject: [jfx17u] Integrated: 8283869: Update attribution in webkit.md file In-Reply-To: References: Message-ID: On Tue, 24 May 2022 17:34:25 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: 1835d1f5 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/1835d1f59104136d6cb34090bd69091433ddac00 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod 8283869: Update attribution in webkit.md file Backport-of: 7bb4819409dd617ba2e3658ee66f23b94dc0bec1 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/62 From kcr at openjdk.java.net Tue May 24 20:45:20 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 May 2022 20:45:20 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wording Not yet, but it's on my list to look at this week. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From mhanl at openjdk.java.net Tue May 24 21:31:48 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 24 May 2022 21:31:48 GMT Subject: RFR: 8218826: TableRowSkinBase: horizontal layout broken if row has padding Message-ID: This PR fixes a problem, where the layout is broken when a `(Tree)TableRow` has padding. As also mentioned in the ticket, the `layoutChildren` method in `TableRowSkinBase` is implemented wrong. The `layoutChildren` method is responsible for layouting all the `(Tree)TableCells`. When the row has padding, it is subtracted on every `(Tree)TableCell` - which is wrong. Instead the `x` and `y` from `layoutChildren` should be used. (E.g. if `x` is 10, then only the first cell should start at 10 and the other cells follow as usual) Also the `compute...` methods needs to add the padding as well. **Example:** _Row padding left right 0:_ [Cell1][Cell2][Cell3] _Row padding left right 10:_ [ 10 ][Cell1][Cell2][Cell3][ 10 ] _Same for top bottom._ When a `fixedCellSize` is set, the padding is currently ignored (also after this PR). Therefore, `y` in the `layoutChildren` method is set to 0 for `fixedCellSize`. This may can be discussed in the mailing list (Could be a follow up). To support padding also when a `fixedCellSize` is set, the `compute...` methods needs to also add the padding when a `fixedCellSize` is set (in the `if` clauses) and the `VirtualFlow` needs to add the padding to every row instead of using the `fixedCellSize` directly. ------------- Commit messages: - 8218826: fixed horizontal layout broken if row has padding Changes: https://git.openjdk.java.net/jfx/pull/800/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=800&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8218826 Stats: 439 lines in 3 files changed: 417 ins; 10 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/800.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/800/head:pull/800 PR: https://git.openjdk.java.net/jfx/pull/800 From mhanl at openjdk.java.net Tue May 24 21:31:48 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 24 May 2022 21:31:48 GMT Subject: RFR: 8218826: TableRowSkinBase: horizontal layout broken if row has padding In-Reply-To: References: Message-ID: On Tue, 24 May 2022 21:25:23 GMT, Marius Hanl wrote: > This PR fixes a problem, where the layout is broken when a `(Tree)TableRow` has padding. > As also mentioned in the ticket, the `layoutChildren` method in `TableRowSkinBase` is implemented wrong. > > The `layoutChildren` method is responsible for layouting all the `(Tree)TableCells`. > When the row has padding, it is subtracted on every `(Tree)TableCell` - which is wrong. > > Instead the `x` and `y` from `layoutChildren` should be used. (E.g. if `x` is 10, then only the first cell should start at 10 and the other cells follow as usual) > Also the `compute...` methods needs to add the padding as well. > > **Example:** > _Row padding left right 0:_ > [Cell1][Cell2][Cell3] > _Row padding left right 10:_ > [ 10 ][Cell1][Cell2][Cell3][ 10 ] > _Same for top bottom._ > > When a `fixedCellSize` is set, the padding is currently ignored (also after this PR). > Therefore, `y` in the `layoutChildren` method is set to 0 for `fixedCellSize`. > > This may can be discussed in the mailing list (Could be a follow up). To support padding also when a `fixedCellSize` is set, the `compute...` methods needs to also add the padding when a `fixedCellSize` is set (in the `if` clauses) and the `VirtualFlow` needs to add the padding to every row instead of using the `fixedCellSize` directly. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 255: > 253: private void removedColumnsShouldRemoveCorrespondingCellsInRowImpl() { > 254: // Remove the last 2 columns. > 255: tableView.getColumns().remove(tableView.getColumns().size() - 2, tableView.getColumns().size()); Note: I added this test in PR: https://github.com/openjdk/jfx/pull/444. While testing this PR I found out that this removes just one column, therefore I fixed it right away. ------------- PR: https://git.openjdk.java.net/jfx/pull/800 From mhanl at openjdk.java.net Tue May 24 21:42:47 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 24 May 2022 21:42:47 GMT Subject: RFR: 8277756: DatePicker listener might not be added when using second constructor Message-ID: The `valueProperty()` and `chronologyProperty()` listener are now added in the second constructor of `DatePicker` (`public DatePicker(LocalDate localDate)`) instead of the first one (`public DatePicker()`). Therefore, both listener are now added no matter which constructor is used. ------------- Commit messages: - 8277756: DatePicker listener are now always added regardless of which constructor was used Changes: https://git.openjdk.java.net/jfx/pull/801/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=801&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277756 Stats: 116 lines in 2 files changed: 94 ins; 19 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/801.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/801/head:pull/801 PR: https://git.openjdk.java.net/jfx/pull/801 From lbourges at openjdk.java.net Wed May 25 07:41:07 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 25 May 2022 07:41:07 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords Hi, Time is going short before openjfx 19... 2 options: - keep dpqs for corner cases and keep my coding life simple - disable or remove dpqs code in marlinFX for openjfx, so my branches will diverge... Any advice, @kevinrushforth ? ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From jbhaskar at openjdk.java.net Wed May 25 10:10:08 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Wed, 25 May 2022 10:10:08 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v5] In-Reply-To: References: Message-ID: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Review comments applied ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/43f8e549..2a09a847 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=03-04 Stats: 80 lines in 3 files changed: 6 ins; 59 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From arapte at openjdk.java.net Wed May 25 15:07:23 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 25 May 2022 15:07:23 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v5] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 10:10:08 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Review comments applied My review is not complete. I shall continue later. Providing few comments for now. Please take a look. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 34: > 32: EventListenerManager& EventListenerManager::get_instance() > 33: { > 34: static NeverDestroyed sharedManager; This does behave well as a singleton class. But I think the instance should be class member variable or a pointer. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 38: > 36: } > 37: > 38: EventListenerManager::EventListenerManager() { } Empty constructor. Can be moved to .h file. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 52: > 50: it = listener_lists.find(ptr); > 51: JNIEnv *env = nullptr; > 52: env = JavaScriptCore_GetJavaEnv(); env seems unused. should be removed. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 109: > 107: isReferringToOtherListener = false; > 108: else > 109: isReferringToOtherListener = true; I have not looked very clearly, but here is a question: Should the loop break when `if` condition passes ? modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 115: > 113: if (window == win_it->second) > 114: windowHasEvent.erase(win_it->first); > 115: } I would change the code to be something like: if (!isReferringToOtherListener) { for (win_it = windowHasEvent.begin(); win_it != windowHasEvent.end(); win_it++) { if (window == win_it->second) windowHasEvent.erase(win_it->first); } } modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 36: > 34: #include > 35: #include > 36: #include minor: Add space after `#include`, on line 34, 36. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 79: > 77: > 78: private: > 79: EventListenerManager(); I would recommend to move it in previous private block. (line 65, 66) modules/javafx.web/src/main/native/Source/WebCore/bindings/java/JavaEventListener.cpp line 50: > 48: ? static_cast(&other) > 49: : nullptr; > 50: return jother && (this == jother); `this` will never be null so the statement can be changed to: `return this == jother;` modules/javafx.web/src/main/native/Source/WebCore/dom/Node.cpp line 2151: > 2149: #if PLATFORM(JAVA) > 2150: EventListenerManager::get_instance().registerDOMWindow(targetNode->document().domWindow(), > 2151: static_cast (&listener.copyRef().get())); minor: Alignment correction, should move few spaces to left. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/799 From perini.davide at dpsoftware.org Wed May 25 16:28:13 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 25 May 2022 18:28:13 +0200 Subject: Jpopupmenu Bug/Glitch When Showing Submenu In-Reply-To: <94ede0e3-29cd-3af9-66e4-d0299e9eb258@dpsoftware.org> References: <235d1d21-a44c-5c60-ae68-4eb7f9bf43a3@dpsoftware.org> <94ede0e3-29cd-3af9-66e4-d0299e9eb258@dpsoftware.org> Message-ID: <184ae777-51a9-c6a7-579b-caf9eda6cc13@dpsoftware.org> I opened a bug report but they closed it by saying that they can't reproduce. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8286713 They test on Windows 10, can this be the cause why they are not able to reproduce? Here a gist where the code is better formatted. https://gist.github.com/sblantipodi/4ed1d3acc04fd6d4f87c00c7e91eb343 This is the glitch I have, better described on a video: https://www.youtube.com/shorts/IYq_yHemsgA Using Adopt Open JDK 17, JavaFX 18.0.1 and Windows 11. If I remove the submenu, problem is solved but I need the submenu. Any idea? Thanks Davide Il 09/05/2022 18:14, Davide Perini ha scritto: > I add a video that shows the issue. > https://www.youtube.com/shorts/IYq_yHemsgA > > as you can see, there is no issue until I put the mouse pointer over > the JMenu (submenu), > once I put the mouse on the JMenu the entire JPopupMenu shows the glitch. > > Thanks > Davide > > Il 09/05/2022 18:04, Davide Perini ha scritto: >> I can't load images unfortunantly but this is the minimum code to >> reproduce the issue. >> It seems that there is no way to add JMenu to JPopupMenu without >> having this glitch. >> >> Is this a problem in JavaFX? >> I see non obvious errors in my code. >> >> Thanks >> Davide >> >> package org.dpsoftware; import org.dpsoftware.config.Constants; >> import org.dpsoftware.utilities.CommonUtility; import javax.swing.*; >> import java.awt.*; import java.awt.event.*; import >> java.io.IOException; import java.io.PrintWriter; import >> java.io.Serial; import java.io.StringWriter; import java.net.URI; >> import java.net.URISyntaxException; public class TrayIconMainClass { >> >> ?? private static final StringTRAY_ICON_SKELETON_PROJECT_URL >> ="https://github.com/Sylvain-Bugat/tray-icon-skeleton"; /** Load the >> tray icon image to display in the tray bar*/ private static >> ImageTRAY_ICON_IMAGE = Toolkit.getDefaultToolkit().getImage( >> TrayIconMainClass.class.getClassLoader().getResource("tray_play.png" >> ) ); //$NON-NLS-1$ static JMenuaspectRatioSubMenu; /** * Main program >> launched in the jar file * * @param args * @throws IOException */ >> private void initializeImages() { >> ????? // load an image } >> >> ?? public static void main(final String args[] )throws IOException { >> ????? aspectRatioSubMenu =new JMenu("dadsdsa"); JMenuItem menuItam >> =new JMenuItem("dada"); aspectRatioSubMenu.add(menuItam); //Test if >> the system support the system tray if( SystemTray.isSupported() ) { >> >> ???????? //Try to use the system Look&Feel try { >> ??????????? UIManager.setLookAndFeel( >> UIManager.getCrossPlatformLookAndFeelClassName() ); } >> ???????? catch(final ClassNotFoundException exception ) { >> ??????????? //If System Look&Feel is not supported, stay with the >> default one } >> ???????? catch(final InstantiationException exception ) { >> ??????????? //If System Look&Feel is not supported, stay with the >> default one } >> ???????? catch(final IllegalAccessException exception ) { >> ??????????? //If System Look&Feel is not supported, stay with the >> default one } >> ???????? catch(final UnsupportedLookAndFeelException exception ) { >> ??????????? //If System Look&Feel is not supported, stay with the >> default one } >> >> ???????? //Add the icon to the system tray final TrayIcon trayIcon >> =new TrayIcon(TRAY_ICON_IMAGE, "Tray icon skeleton" ); >> trayIcon.setImageAutoSize(true ); // Get the system default browser >> to open execution details final Desktop desktop = >> Desktop.getDesktop(); //Action listener to get click on top menu >> items final ActionListener menuListener =new ActionListener() { >> ??????????? @SuppressWarnings("synthetic-access") >> ??????????? public void actionPerformed(final ActionEvent e) { >> >> ?????????????? if( JMenuItem.class.isInstance( e.getSource() ) ){ >> >> ????????????????? JMenuItem jMenuItem = (JMenuItem) e.getSource(); >> JOptionPane.showMessageDialog(null, "It works, you clicked on:" + >> System.lineSeparator() + jMenuItem.getText(), "Your skill is >> great!!", JOptionPane.INFORMATION_MESSAGE ); //$NON-NLS-1$ } >> ??????????? } >> ???????? }; //About menu listener final ActionListener aboutListener >> =new ActionListener() { >> ??????????? @SuppressWarnings("synthetic-access") >> ??????????? public void actionPerformed(final ActionEvent e) { >> >> ?????????????? //Open an URL using the system default browser try { >> ????????????????? final URI executionURI =new >> URI(TRAY_ICON_SKELETON_PROJECT_URL ); desktop.browse( executionURI ); } >> ?????????????? catch(final URISyntaxException exception ) { >> >> ????????????????? final StringWriter stringWriter =new >> StringWriter(); exception.printStackTrace(new PrintWriter( >> stringWriter ) ); JOptionPane.showMessageDialog(null, >> exception.getMessage() + System.lineSeparator() + >> stringWriter.toString(), "Tray icon skeleton redirection error", >> JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ } >> ?????????????? catch(final IOException exception ) { >> >> ????????????????? final StringWriter stringWriter =new >> StringWriter(); exception.printStackTrace(new PrintWriter( >> stringWriter ) ); JOptionPane.showMessageDialog(null, >> exception.getMessage() + System.lineSeparator() + >> stringWriter.toString(), "Tray icon skeleton redirection error", >> JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ } >> ??????????? } >> ???????? }; //Get the system tray final SystemTray tray = >> SystemTray.getSystemTray(); //Tray icon skeleton exit listener final >> ActionListener exitListener =new ActionListener() { >> ??????????? @SuppressWarnings("synthetic-access") >> ??????????? public void actionPerformed(final ActionEvent e) { >> ?????????????? //Important: remove the icon from the tray to dispose >> it tray.remove(trayIcon ); System.exit(0 ); } >> ???????? }; //Popup menu >> JPopupMenu.setDefaultLightWeightPopupEnabled(false ); final >> JPopupMenu popupMenu =new JPopupMenu(); //Add 10 menu items for(int i >> =0 ; i <10 ; i++ ){ >> >> ??????????? final JMenuItem jMenuItem =new JMenuItem("menu item " + i >> ); popupMenu.add( jMenuItem ); jMenuItem.addActionListener( >> menuListener ); System.out.println("DAD"); } >> >> ???????? //Adding some menu separator popupMenu.addSeparator(); final >> JMenuItem aboutItem =new JMenuItem("About Tray icon skeleton" ); >> //$NON-NLS-1$ popupMenu.add( aboutItem ); >> aboutItem.addActionListener( aboutListener ); //Adding some menu >> separator popupMenu.addSeparator(); //Quit menu to terminate the tray >> icon by disposing the tray icon final JMenuItem exitItem =new >> JMenuItem("Quit" ); //$NON-NLS-1$ popupMenu.add( exitItem ); >> exitItem.addActionListener( exitListener ); //Hidden dialog displayed >> behing the system tray to auto hide the popup menu when clicking >> somewhere else on the screen final JDialog hiddenDialog =new JDialog >> (); hiddenDialog.setSize(1000, 1000 ); //Listener based on the focus >> to auto hide the hidden dialog and the popup menu when the hidden >> dialog box lost focus hiddenDialog.addWindowFocusListener(new >> WindowFocusListener() { >> >> ??????????? public void windowLostFocus (final WindowEvent e ) { >> ?????????????? hiddenDialog.setVisible(false ); } >> >> ??????????? public void windowGainedFocus (final WindowEvent e ) { >> ?????????????? //Nothing to do } >> ???????? }); popupMenu.add(aspectRatioSubMenu); //Add a listener to >> display the popupmenu and the hidden dialog box when the tray icon is >> clicked trayIcon.addMouseListener(new MouseAdapter() { >> >> ??????????? public void mouseReleased(final MouseEvent e) { >> >> ?????????????? if( e.isPopupTrigger() ) { >> ????????????????? //Display the menu at the position of the mouse >> //The dialog is also displayed at this position but it is behind the >> system tray popupMenu.setLocation( e.getX(), e.getY() ); >> hiddenDialog.setLocation( e.getX(), e.getY() ); //Important: set the >> hidden dialog as the invoker to hide the menu with this dialog lost >> focus popupMenu.setInvoker(hiddenDialog ); >> hiddenDialog.setVisible(true ); popupMenu.setVisible(true ); } >> ??????????? } >> ???????? }); //Add the icon to the system tray try { >> ??????????? tray.add( trayIcon ); } >> ???????? catch (final AWTException e ) { >> >> ??????????? final StringWriter stringWriter =new StringWriter(); >> e.printStackTrace(new PrintWriter( stringWriter ) ); >> JOptionPane.showMessageDialog(null, "tray icon cannot be added to the >> system tray" + System.lineSeparator() + e.getMessage() + >> System.lineSeparator() + stringWriter.toString(), "Tray icon skeleton >> initialization error", JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ >> System.exit(2 ); } >> ????? } >> ????? else { >> ???????? //if the System is not compatible with SystemTray >> JOptionPane.showMessageDialog(null, "SystemTray cannot be >> initialized" + System.lineSeparator() +"this system is not >> compatible!", "Tray icon skeleton initialization error", >> JOptionPane.ERROR_MESSAGE ); //$NON-NLS-1$ //$NON-NLS-2$ >> System.exit(1 ); } >> >> ?? } >> } >> >> >> >> >> >> >> >> >> >> Il 08/05/2022 01:26, Davide Perini ha scritto: >>> Hi all, >>> I'm using a JPopupMenu to workaround the lack of a "real tray icon" >>> in JavaFX. >>> >>> This is the simple code I'm using: >>> https://github.com/Sylvain-Bugat/tray-icon-skeleton/blob/master/src/main/java/com/github/sbugat/trayiconskeleton/TrayIconMainClass.java >>> >>> >>> It all works well until I add a submenu (JMenu) to my JPopupMenu. >>> >>> This is how the tray looks when no glitch appear: >>> >>> >>> and this is the tray how looks like when the glitch of the submenu >>> appers: >>> >>> >>> >>> >>> to trigger the glitch I can simply move the mouse over the submenu >>> and then move the mouse over the other jmenuitem. >>> >>> Any idea on why I have this error? >>> >>> Thanks >>> Davide > From kcr at openjdk.java.net Thu May 26 00:22:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 00:22:53 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v5] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 10:10:08 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Review comments applied I left a couple comments on one of your test changes. I think the only remaining question (aside from the few minor comments that Ambarish left) is around the logic in `EventListenerManager::resetDOMWindow`. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From kcr at openjdk.java.net Thu May 26 00:22:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 00:22:56 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v4] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 14:06:41 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Adding JGObject in plave of raw jni object modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 764: > 762: Thread.sleep(100); > 763: assertEquals("Click count", 6, listeners.get(1).get().getClickCount() + listeners.get(0).get().getClickCount()); > 764: The above code should be restored. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 789: > 787: Thread.sleep(100); > 788: assertEquals("Click count", 6, listeners.get(1).get().getClickCount() + listeners.get(0).get().getClickCount()); > 789: I think the above code should be restored. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From kcr at openjdk.java.net Thu May 26 00:22:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 00:22:59 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v4] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 15:20:01 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding JGObject in plave of raw jni object > > modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 765: > >> 763: assertEquals("Click count", 6, listeners.get(1).get().getClickCount() + listeners.get(0).get().getClickCount()); >> 764: >> 765: // add events listeners again > > that should be "remove" I think you may have misunderstood my comment. I didn't mean to suggest that you should remove the blocks of code that you removed in the most recent update -- it was performing a quite useful check. Rather I meant that since you were removing the listeners, the comment `add listeners again` was wrong and should say `remove listeners again`. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From duke at openjdk.java.net Thu May 26 06:07:51 2022 From: duke at openjdk.java.net (Tomator) Date: Thu, 26 May 2022 06:07:51 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: Message-ID: <2kmr2iSiKyGxtcyFn5NDJrONETCg_8SNxop_uFvFVTQ=.76b061f0-68f0-40ca-9913-4283f8100b02@github.com> On Fri, 13 May 2022 05:34:08 GMT, Tomator wrote: > When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. > The crash demo like this: > `import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.control.MenuItem; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class MenuExample extends Application { > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > BorderPane root = new BorderPane(); > Scene scene = new Scene(root,200,300); > MenuBar menubar = new MenuBar(); > Menu FileMenu = new Menu("??"); > MenuItem filemenu1=new MenuItem("??"); > MenuItem filemenu2=new MenuItem("Save"); > MenuItem filemenu3=new MenuItem("Exit"); > Menu EditMenu=new Menu("Edit"); > MenuItem EditMenu1=new MenuItem("Cut"); > MenuItem EditMenu2=new MenuItem("Copy"); > MenuItem EditMenu3=new MenuItem("Paste"); > EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); > root.setTop(menubar); > FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); > menubar.getMenus().addAll(FileMenu,EditMenu); > primaryStage.setScene(scene); > primaryStage.setTitle("TEST"); > primaryStage.show(); > > } > } ` > > the error: > `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 > at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) > at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) > at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) > at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) > at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) > at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > ` I can repeated this issue on uos when the linux doesn't have /usr/share/fonts/wps-office/FZSongS_20100603.TTF file ,openjfx version 11,method getGlyphCode will return a negative number ------------- PR: https://git.openjdk.java.net/jfx/pull/795 From jbhaskar at openjdk.java.net Thu May 26 06:37:53 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 26 May 2022 06:37:53 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v5] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 12:45:59 GMT, Ambarish Rapte wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments applied > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 34: > >> 32: EventListenerManager& EventListenerManager::get_instance() >> 33: { >> 34: static NeverDestroyed sharedManager; > > This does behave well as a singleton class. But I think the instance should be class member variable or a pointer. Most of the singleton class implementation is as above in Webkit. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Thu May 26 06:58:04 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 26 May 2022 06:58:04 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v5] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 14:57:13 GMT, Ambarish Rapte wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments applied > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 109: > >> 107: isReferringToOtherListener = false; >> 108: else >> 109: isReferringToOtherListener = true; > > I have not looked very clearly, but here is a question: Should the loop break when `if` condition passes ? No, it should not , if condition pass means there is ref count of 1 for the particular ref object. but we have to look for all other objects too , to check whether a ref counted object might be referred by other Dom Window. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Thu May 26 07:08:59 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 26 May 2022 07:08:59 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v6] In-Reply-To: References: Message-ID: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Adding new review change ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/2a09a847..4c8e4a5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=04-05 Stats: 34 lines in 5 files changed: 18 ins; 9 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From duke at openjdk.java.net Thu May 26 07:17:50 2022 From: duke at openjdk.java.net (danielpeintner) Date: Thu, 26 May 2022 07:17:50 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v6] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 07:08:59 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Adding new review change modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.h line 34: > 32: #include "config.h" > 33: > 34: #include nit: space ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Thu May 26 07:26:38 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 26 May 2022 07:26:38 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v7] In-Reply-To: References: Message-ID: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Adding space for map include ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/4c8e4a5b..d6fd438b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From ooo_saturn7 at mail.ru Thu May 26 17:20:25 2022 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBPcmxvdg==?=) Date: Thu, 26 May 2022 20:20:25 +0300 Subject: =?UTF-8?B?SG93IHRvIHNldCBXTV9DTEFTUyBmb3IgR05PTUU/?= Message-ID: <1653585625.198711531@f498.i.mail.ru> Hello, ? I develop a JavaFX application for Linux. And on my Ubuntu 20 I have a problem. I do `stage.setTitle("Foo");` and I have a window with title `Foo`, but in Ubuntu top bar I see the name of the class `com.foo.bar.FooApplication`. ? As I understand I should set correctly WM_CLASS. The only solution I found is this one https://stackoverflow.com/a/54467323/5057736? ? However, I work in JPMS and I can?t access com.sun.glass.ui.Application. Could anyone say how I can make my JavaFx application show "Foo" instead of class name in Ubuntu top bar? ? -- Best regards, Alex Orlov From kcr at openjdk.java.net Thu May 26 17:36:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 17:36:49 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v7] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 07:26:38 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Adding space for map include Comments inline. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 106: > 104: else > 105: isReferringToOtherListener = true; > 106: } I think I now understand what this is trying to do, but it doesn't looks like it's implemented correctly nor is it optimal. It seems that the `isReferringToOtherListener` flag is intended to be true iff there is any `JavaEventListener` with a ref count > 1 associated with the Window being unregistered. Ignoring any possible bugs in how it is implemented, there are two problems with this approach. First, you want to remove entries associated with a particular listener if _that_ listener isn't used by another window. So a global "is any listener referring to another window" isn't what you want. Second, since this is multimap, it would seem better to remove individual `(key,value)` pairs associated with the specific window being removed rather than calling erase only for those listeners that aren't being shared at all. If this is feasible, then you wouldn't have to even care if that listener is used by a node in another window. I'm not familiar enough with C++ multimap calls to know how easy this would be, but presumably, it shouldn't be too hard. Not directly related to this, it might be cleaner to move this logic to `unregisterDOMWindow` instead of having a separate `resetDOMWindow` method, since this is really part of the same conceptual operation. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 607: > 605: */ > 606: @Test > 607: public void TestStrongRefNewContentLoad() throws Exception { Minor: method names should start with a lower-case letter. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 730: > 728: }); > 729: > 730: // Verify that the events are delivered to the listeners (0 and 2 are same) Minor: all three listeners are the same, not just 0 and 2. modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java line 959: > 957: // Verify that the event is delivered to the listener > 958: assertEquals("Click count", 1, listeners.get(0).getClickCount()); > 959: assertEquals("Click count", 1, listeners.get(0).getClickCount()); The second check should be `listeners.get(1)` ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Fri May 27 12:13:43 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 27 May 2022 12:13:43 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v8] In-Reply-To: References: Message-ID: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Change for unregisterDomWindow function and code cleanup ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/d6fd438b..79f30067 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=06-07 Stats: 74 lines in 5 files changed: 11 ins; 23 del; 40 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Fri May 27 12:13:46 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 27 May 2022 12:13:46 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v7] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 17:00:46 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding space for map include > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 106: > >> 104: else >> 105: isReferringToOtherListener = true; >> 106: } > > I think I now understand what this is trying to do, but it doesn't looks like it's implemented correctly nor is it optimal. > > It seems that the `isReferringToOtherListener` flag is intended to be true iff there is any `JavaEventListener` with a ref count > 1 associated with the Window being unregistered. Ignoring any possible bugs in how it is implemented, there are two problems with this approach. First, you want to remove entries associated with a particular listener if _that_ listener isn't used by another window. So a global "is any listener referring to another window" isn't what you want. Second, since this is multimap, it would seem better to remove individual `(key,value)` pairs associated with the specific window being removed rather than calling erase only for those listeners that aren't being shared at all. If this is feasible, then you wouldn't have to even care if that listener is used by a node in another window. I'm not familiar enough with C++ multimap calls to know how easy this would be, but presumably, it shouldn't be too hard. > > Not directly related to this, it might be cleaner to move this logic to `unregisterDOMWindow` instead of having a separate `resetDOMWindow` method, since this is really part of the same conceptual operation. I have used the suggested method , and tested it works expected. Thanks ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From kcr at openjdk.java.net Fri May 27 15:55:07 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 May 2022 15:55:07 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v8] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 12:13:43 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Change for unregisterDomWindow function and code cleanup The changes look good. While doing my final review I noticed one more thing that I think should be changed. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 57: > 55: } > 56: > 57: if (it->second && it->second->use_count() > 1) Shouldn't this be `else if`? The previous block calls `erase(it)`, so it isn't valid to dereference `it` after that call. ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Fri May 27 16:47:04 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 27 May 2022 16:47:04 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v9] In-Reply-To: References: Message-ID: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Adingef else block to unregisterListener ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/799/files - new: https://git.openjdk.java.net/jfx/pull/799/files/79f30067..c609ad9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=799&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/799.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/799/head:pull/799 PR: https://git.openjdk.java.net/jfx/pull/799 From jbhaskar at openjdk.java.net Fri May 27 16:47:07 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Fri, 27 May 2022 16:47:07 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v8] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 15:42:09 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Change for unregisterDomWindow function and code cleanup > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/EventListenerManager.cpp line 57: > >> 55: } >> 56: >> 57: if (it->second && it->second->use_count() > 1) > > Shouldn't this be `else if`? The previous block calls `erase(it)`, so it isn't valid to dereference `it` after that call. Applied and tested ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From kcr at openjdk.java.net Fri May 27 17:03:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 May 2022 17:03:41 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v9] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 16:47:04 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Adingef else block to unregisterListener Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/799 From kcr at openjdk.java.net Fri May 27 23:37:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 May 2022 23:37:53 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wording I reviewed the public API changes, and this looks like a great addition to JavaFX bindings. I think there might be time to get this into JavaFX 19, presuming that there are no issues with the testing or implementation, so let's proceed down that path. I left one comment on the API docs as well as pointed out the public methods that will need an `@since 19` javadoc tag. Once that is updated you can propagate the javadoc changes to the CSR (including the `@since` tags) and move it to "Proposed". I'll formally review it later, once the code review is closer to being done. modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 198: > 196: * @return {@code true} if this binding currently has one or more > 197: * listeners registered on it, otherwise {@code false} > 198: */ This needs an `@since` tag. Presuming that this makes JavaFX 19, that would be: * @since 19 modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 213: > 211: * > 212: * @return {@code true} if this binding is allowed to become valid, otherwise > 213: * {@code false} Needs an `@since` tag. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 166: > 164: * mapping function on this value, or {@code null} when it > 165: * is {@code null}; never returns {@code null} > 166: * @throws NullPointerException if the mapping function is {@code null} Needs an `@since` tag. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 192: > 190: * holds {@code null}; can be {@code null} > 191: * @return an {@code ObservableValue} that holds this value, or the given constant if > 192: * it is {@code null}; never returns {@code null} Needs an `@since` tag. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 205: > 203: * resulting value is {@code null}. If the mapping resulted in {@code null}, then the > 204: * resulting value is also {@code null}. > 205: *

      It might be worth borrowing some language from `Optional::flatMap`. Maybe something like this? This method is similar to {@link #map(Function)}, but the mapping function is one whose result is already an ObservableValue, and if invoked, flatMap does not wrap it within an additional ObservableValue. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 239: > 237: * {@code null} when the value is {@code null}; never returns {@code null} > 238: * @throws NullPointerException if the mapping function is {@code null} > 239: */ This also needs an `@since` tag. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Sat May 28 07:07:01 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 28 May 2022 07:07:01 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Standard JavaFX + Optional: > label.textProperty().bind(Bindings.createStringBinding( > () -> Optinal.ofNullable(employee.get()) > .map(Employee::getCompany) > .map(Company::getName) > .orElse(""), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Expand flatMap javadoc with additional wording from Optional#flatMap - Add since tags to all new API ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/e2703e6b..c3523903 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=13-14 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Sat May 28 07:26:49 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 28 May 2022 07:26:49 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v14] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <3IThEpMqjcknY6Bf9R-bmIWaHOwbJqrN8yGYqdA9elk=.83613f2e-257e-467b-a264-27efba1547ce@github.com> Message-ID: On Fri, 27 May 2022 23:31:42 GMT, Kevin Rushforth wrote: > I reviewed the public API changes, and this looks like a great addition to JavaFX bindings. I think there might be time to get this into JavaFX 19, presuming that there are no issues with the testing or implementation, so let's proceed down that path. > > I left one comment on the API docs as well as pointed out the public methods that will need an `@since 19` javadoc tag. > > Once that is updated you can propagate the javadoc changes to the CSR (including the `@since` tags) and move it to "Proposed". I'll formally review it later, once the code review is closer to being done. Thanks, I've made the changes and updated the CSR with the latest docs. It's now proposed. > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 205: > >> 203: * resulting value is {@code null}. If the mapping resulted in {@code null}, then the >> 204: * resulting value is also {@code null}. >> 205: *

      > > It might be worth borrowing some language from `Optional::flatMap`. Maybe something like this? > > > This method is similar to {@link #map(Function)}, but the mapping function is > one whose result is already an ObservableValue, and if invoked, flatMap does > not wrap it within an additional ObservableValue. Added this and put code tags where necessary. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From arapte at openjdk.java.net Sat May 28 15:30:41 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 28 May 2022 15:30:41 GMT Subject: RFR: 8088420: JavaFX WebView memory leak via EventListener [v9] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 16:47:04 GMT, Jay Bhaskar wrote: >> This PR is new implementation of JavaEvent listener memory management. >> Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) >> >> 1. Calling remove event listener does not free jni global references. >> 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. >> >> Solution: >> 1. Detached the jni global reference from JavaEventListener. >> 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. >> 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. >> 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. >> 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. >> 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. >> 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Adingef else block to unregisterListener LGTM ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/799 From nlisker at gmail.com Mon May 30 01:22:10 2022 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 30 May 2022 04:22:10 +0300 Subject: JDK-8091393: Observable collections for ObservableMap views Message-ID: Hi, Picking up an old issue, JDK-8091393 [1], I went ahead and looked at the work needed to implement it. keySet() and entrySet() can both be made to return ObservableSet rather easily. values() will probably require an ObservableCollection type. Before discussing these details, my question is: is it backwards compatible to require that these methods now return a more refined type? I think that it will break implementations of ObservableMap out in the wild if it overrides these methods in Map. What is the assessment here? https://bugs.openjdk.java.net/browse/JDK-8091393 From john.hendrikx at gmail.com Mon May 30 06:58:48 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 30 May 2022 08:58:48 +0200 Subject: JDK-8091393: Observable collections for ObservableMap views In-Reply-To: References: Message-ID: It's not binary compatible, as changing the return type results in a new method that compiled code won't be able to find. See also "change result type (including void)" here: https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods --John On 30/05/2022 03:22, Nir Lisker wrote: > Hi, > > Picking up an old issue, JDK-8091393 [1], I went ahead and looked at the > work needed to implement it. > > keySet() and entrySet() can both be made to return ObservableSet rather > easily. values() will probably require an ObservableCollection type. > > Before discussing these details, my question is: is it backwards compatible > to require that these methods now return a more refined type? I think that > it will break implementations of ObservableMap out in the wild if it > overrides these methods in Map. What is the assessment here? > > https://bugs.openjdk.java.net/browse/JDK-8091393 From tom.schindl at bestsolution.at Mon May 30 07:39:59 2022 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 30 May 2022 09:39:59 +0200 Subject: JDK-8091393: Observable collections for ObservableMap views In-Reply-To: References: Message-ID: <732c2991-b2e2-0048-e86d-b894fd95640c@bestsolution.at> Hi, Well the binary compat IMHO is not a problem. If your subtype overwrites the return type of a method the compiler will inserts a bridge method: Take this example package bla; import java.util.ArrayList; import java.util.Collection; import java.util.List; public class Test { public interface IB { public Collection get(); } public interface I extends IB { public List get(); } public class C implements I { public ArrayList get() { return new ArrayList(); } } } if you look at C with javap you'll notice Compiled from "Test.java" public class bla.Test$C implements bla.Test$I { final bla.Test this$0; public bla.Test$C(bla.Test); public java.util.ArrayList get(); public java.util.Collection get(); public java.util.List get(); } The problem is more that if someone directly implemented ObservableMap him/her self that it won't compile anymore. So it is a source incompatible change. Tom Am 30.05.22 um 08:58 schrieb John Hendrikx: > It's not binary compatible, as changing the return type results in a new > method that compiled code won't be able to find. > > See also "change result type (including void)" here: > https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods > > > --John > > On 30/05/2022 03:22, Nir Lisker wrote: >> Hi, >> >> Picking up an old issue, JDK-8091393 [1], I went ahead and looked at the >> work needed to implement it. >> >> keySet() and entrySet() can both be made to return ObservableSet rather >> easily. values() will probably require an ObservableCollection type. >> >> Before discussing these details, my question is: is it backwards >> compatible >> to require that these? methods now return a more refined type? I think >> that >> it will break implementations of ObservableMap out in the wild if it >> overrides these methods in Map. What is the assessment here? >> >> https://bugs.openjdk.java.net/browse/JDK-8091393 From jvos at openjdk.java.net Mon May 30 08:10:36 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 30 May 2022 08:10:36 GMT Subject: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v7] In-Reply-To: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: > When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Precalculate size of cells that are likely going to be used in rendering. This avoid resizing cells after their position has been laid out, leading to misalignments. Relaxed some tests that check on the number of invocations on updateItem. We heavily use the accumcell for calculating sizes, and that cell is released every time, leading to a call to updateItem as well (but this call should not do any CPU intensive work) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/c7d722d3..67b351ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=05-06 Stats: 95 lines in 4 files changed: 65 ins; 18 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712 From john.hendrikx at gmail.com Mon May 30 08:49:30 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 30 May 2022 10:49:30 +0200 Subject: JDK-8091393: Observable collections for ObservableMap views In-Reply-To: <732c2991-b2e2-0048-e86d-b894fd95640c@bestsolution.at> References: <732c2991-b2e2-0048-e86d-b894fd95640c@bestsolution.at> Message-ID: <2cc3e30a-2b92-a78d-8b9d-f7f1a2aba155@gmail.com> Sorry, I misunderstood, I missed that the methods weren't already defined in ObservableMap, so no existing signature is changed. --John On 30/05/2022 09:39, Tom Schindl wrote: > Hi, > > Well the binary compat IMHO is not a problem. If your subtype > overwrites the return type of a method the compiler will inserts a > bridge method: > > Take this example > > package bla; > > import java.util.ArrayList; > import java.util.Collection; > import java.util.List; > > public class Test { > ????public interface IB { > ??????? public Collection get(); > ????} > > ????public interface I extends IB { > ??????? public List get(); > ????} > > ????public class C implements I { > ??????? public ArrayList get() { > ??????????? return new ArrayList(); > ??????? } > ????} > } > > if you look at C with javap you'll notice > > Compiled from "Test.java" > public class bla.Test$C implements bla.Test$I { > ? final bla.Test this$0; > ? public bla.Test$C(bla.Test); > ? public java.util.ArrayList get(); > ? public java.util.Collection get(); > ? public java.util.List get(); > } > > > The problem is more that if someone directly implemented ObservableMap > him/her self that it won't compile anymore. So it is a source > incompatible change. > > Tom > > Am 30.05.22 um 08:58 schrieb John Hendrikx: >> It's not binary compatible, as changing the return type results in a >> new method that compiled code won't be able to find. >> >> See also "change result type (including void)" here: >> https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods >> >> >> --John >> >> On 30/05/2022 03:22, Nir Lisker wrote: >>> Hi, >>> >>> Picking up an old issue, JDK-8091393 [1], I went ahead and looked at >>> the >>> work needed to implement it. >>> >>> keySet() and entrySet() can both be made to return ObservableSet rather >>> easily. values() will probably require an ObservableCollection type. >>> >>> Before discussing these details, my question is: is it backwards >>> compatible >>> to require that these? methods now return a more refined type? I >>> think that >>> it will break implementations of ObservableMap out in the wild if it >>> overrides these methods in Map. What is the assessment here? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8091393 From jbhaskar at openjdk.java.net Mon May 30 12:37:07 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Mon, 30 May 2022 12:37:07 GMT Subject: Integrated: 8088420: JavaFX WebView memory leak via EventListener In-Reply-To: References: Message-ID: On Thu, 19 May 2022 13:13:01 GMT, Jay Bhaskar wrote: > This PR is new implementation of JavaEvent listener memory management. > Issue [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1) > > 1. Calling remove event listener does not free jni global references. > 2. When WebView goes out of scope (disposed from app) , its Event Listeners are not being garbage collected. > > Solution: > 1. Detached the jni global reference from JavaEventListener. > 2. Create scoped ref counted wrapper class JavaObjectWrapperHandler for jni global reference. > 3. Create unique JavaObjectWrapperHandler object for each JavaEventListener. > 4. EventListenerManager is a singleton class , which stores the JavaObjectWrapperHandler mapped with JavaEventListener. > 5. EventListenerManager also stores the JavaEventListener mapped with DOMWindow. > 6. When Event listener explicitly removed , JavaEventListener is being forwarded to EventListenerManager to clear the listener. > 7. When WebView goes out of scope, EventListenerManager will de-registered all the event listeners based on the ref counts attached with WebView DOMWindow. This pull request has now been integrated. Changeset: f5348503 Author: Jay Bhaskar Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f5348503143e8d08f09b4cd48b6a3864bd09c336 Stats: 1509 lines in 11 files changed: 1503 ins; 3 del; 3 mod 8088420: JavaFX WebView memory leak via EventListener Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/799 From nlisker at gmail.com Mon May 30 21:02:17 2022 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 31 May 2022 00:02:17 +0300 Subject: JDK-8091393: Observable collections for ObservableMap views In-Reply-To: <2cc3e30a-2b92-a78d-8b9d-f7f1a2aba155@gmail.com> References: <732c2991-b2e2-0048-e86d-b894fd95640c@bestsolution.at> <2cc3e30a-2b92-a78d-8b9d-f7f1a2aba155@gmail.com> Message-ID: Then maybe a solution would be around adding new methods like observableKeySet(). These will need to be default methods, and the implementation could test if keySet() already returns an ObservableSet, in which case it returns it, and if not it wraps the Set in an ObservableSetWrapper or something like that. On Mon, May 30, 2022 at 11:50 AM John Hendrikx wrote: > Sorry, I misunderstood, I missed that the methods weren't already > defined in ObservableMap, so no existing signature is changed. > > --John > > On 30/05/2022 09:39, Tom Schindl wrote: > > Hi, > > > > Well the binary compat IMHO is not a problem. If your subtype > > overwrites the return type of a method the compiler will inserts a > > bridge method: > > > > Take this example > > > > package bla; > > > > import java.util.ArrayList; > > import java.util.Collection; > > import java.util.List; > > > > public class Test { > > public interface IB { > > public Collection get(); > > } > > > > public interface I extends IB { > > public List get(); > > } > > > > public class C implements I { > > public ArrayList get() { > > return new ArrayList(); > > } > > } > > } > > > > if you look at C with javap you'll notice > > > > Compiled from "Test.java" > > public class bla.Test$C implements bla.Test$I { > > final bla.Test this$0; > > public bla.Test$C(bla.Test); > > public java.util.ArrayList get(); > > public java.util.Collection get(); > > public java.util.List get(); > > } > > > > > > The problem is more that if someone directly implemented ObservableMap > > him/her self that it won't compile anymore. So it is a source > > incompatible change. > > > > Tom > > > > Am 30.05.22 um 08:58 schrieb John Hendrikx: > >> It's not binary compatible, as changing the return type results in a > >> new method that compiled code won't be able to find. > >> > >> See also "change result type (including void)" here: > >> > https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods > >> > >> > >> --John > >> > >> On 30/05/2022 03:22, Nir Lisker wrote: > >>> Hi, > >>> > >>> Picking up an old issue, JDK-8091393 [1], I went ahead and looked at > >>> the > >>> work needed to implement it. > >>> > >>> keySet() and entrySet() can both be made to return ObservableSet rather > >>> easily. values() will probably require an ObservableCollection type. > >>> > >>> Before discussing these details, my question is: is it backwards > >>> compatible > >>> to require that these methods now return a more refined type? I > >>> think that > >>> it will break implementations of ObservableMap out in the wild if it > >>> overrides these methods in Map. What is the assessment here? > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8091393 > From aghaisas at openjdk.java.net Tue May 31 09:35:01 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 31 May 2022 09:35:01 GMT Subject: RFR: 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView [v2] In-Reply-To: <6v0aSa7XHHj7oDd-mTsY56oPIHtADUqco15zLPZhk-k=.5167c77f-3459-4ca9-a9d5-6677ba89f407@github.com> References: <6v0aSa7XHHj7oDd-mTsY56oPIHtADUqco15zLPZhk-k=.5167c77f-3459-4ca9-a9d5-6677ba89f407@github.com> Message-ID: <4Ap5VkmBcDcHy-K6cd-9s8g2dZ-27XU8CZouN6Js_zE=.168c3511-81cb-4fea-abdc-467bd2dfcd45@github.com> On Tue, 24 May 2022 09:51:29 GMT, Jose Pereda wrote: >> This PR fixes an issue with selection of multiple items in TableView and TreeTableView controls that gets moved unexpectedly when new items are added even way below the selected items. >> >> A couple of tests have been added. They fail without this PR (first selected item gets deselected, and table anchor gets moved), and pass with this PR (first selected item keeps selected, and table anchor remains at the same place). > > Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into 8284665-tableviewanchor > - Only shift anchor if existing one is affected by the change event, and tests Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/790 From jpereda at openjdk.java.net Tue May 31 10:10:48 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 31 May 2022 10:10:48 GMT Subject: Integrated: 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:21:45 GMT, Jose Pereda wrote: > This PR fixes an issue with selection of multiple items in TableView and TreeTableView controls that gets moved unexpectedly when new items are added even way below the selected items. > > A couple of tests have been added. They fail without this PR (first selected item gets deselected, and table anchor gets moved), and pass with this PR (first selected item keeps selected, and table anchor remains at the same place). This pull request has now been integrated. Changeset: 83a46e0c Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/83a46e0cef3f041b349c59cd9108d9a5895e79c9 Stats: 101 lines in 4 files changed: 99 ins; 0 del; 2 mod 8284665: First selected item of a TreeItem multiple selection gets removed if new items are constantly added to the TreeTableView Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/790 From kcr at openjdk.java.net Tue May 31 22:28:46 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 31 May 2022 22:28:46 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Wed, 25 May 2022 07:37:38 GMT, Laurent Bourg?s wrote: > keep dpqs for corner cases and keep my coding life simple I think this approach is fine. Diverging the code would likely make it less stable, and you answered the question about the provenance of the code, so there's no issue there. We should try to get this in before RDP1 of JavaFX 19 if possible. One more thing, as I wrote in my above comment: > We should file a new JBS Enhancement issue -- similar to what was done for Marlin 0.9.2 via [JDK-8204621](https://bugs.openjdk.java.net/browse/JDK-8204621) rather than using a narrow bug, since that bug is only part of what's being done. The current bug can either be added to the PR, or else that JBS bug (JDK-8274066) can be closed as a duplicate of the new Enhancement. I took the liberty of filing [JDK-8287604](https://bugs.openjdk.java.net/browse/JDK-8287604) for this enhancement. Can you change the title to: 8287604: Update MarlinFX to 0.9.4.5 ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From kcr at openjdk.java.net Tue May 31 23:23:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 31 May 2022 23:23:38 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:56:53 GMT, Thiago Milczarek Sayao wrote: >> When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. >> >> The fix also works for: >> https://bugs.openjdk.java.net/browse/JDK-8269429 >> >> But this one might need another fix: >> https://bugs.openjdk.java.net/browse/JDK-8240640 > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Set the focus on the latest window when re-enabling them" > > This reverts commit b024de586c187f9000f791dab99507a4979cc027. Looks good now. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/784