From arapte at openjdk.org Thu Aug 1 07:40:38 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Aug 2024 07:40:38 GMT Subject: RFR: 8337281: build.gradle assumes all modules are named "javafx.$project" [v2] In-Reply-To: References: Message-ID: <_P_IUaD4-_qQWpkheLy7oQuq0nYvdVnFVvZ2ockqa3c=.4fefc17b-c9b0-4bcc-b4be-1d9a7bd7508f@github.com> On Fri, 26 Jul 2024 23:00:33 GMT, Kevin Rushforth wrote: >> This PR fixes a bad assumption in a few places in `build.gradle`, which assumes that the module name can be derived from the name of the gradle project name by prepending `"javafx."` to the name rather than using the `moduleName` property of the project. In many of these places, the logic replaces dots with dashes in the name, but it does so by prefixing the project name with `"javafx-"` rather than doing a string replacement. This means that a module with more than one dot will only have the first one replaced. >> >> I discovered this while working on the following two RFEs, both of which hit this bug: >> >> [JDK-8309381](https://bugs.openjdk.org/browse/JDK-8309381): Support JavaFX incubator modules >> [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280): Include jdk.jsobject module with JavaFX >> >> Both of them need this bug to be fixed, so I am separating it out into its own issue. >> >> ### Notes to reviewers >> >> Most of the problematic logic is in the maven publication method, which is only enabled via `gradle -PMAVEN_PUBLISH=true` (in the absence of any other params, that won't actually try to publish anything, so is safe to use for testing). I left in some print statements for the purpose of testing, that I will remove with the next commit. >> >> I tested this with the following branch, which is a preliminary prototype of adding jdk.jsobject to the build with the fix from _this_ PR applied: [test-module-name-jsobject](https://github.com/kevinrushforth/jfx/tree/test-module-name-jsobject). > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug where String was being used as if it were a Project Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1518#pullrequestreview-2211882793 From jvos at openjdk.org Thu Aug 1 08:46:05 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 08:46:05 GMT Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener never being removed Message-ID: Backport of 8323787: Mac System MenuBar throws IOB exception Required manual changes as the location of the test has changed. ------------- Commit messages: - 8319779: SystemMenu: memory leak due to listener never being removed Changes: https://git.openjdk.org/jfx21u/pull/63/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=63&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319779 Stats: 603 lines in 5 files changed: 462 ins; 132 del; 9 mod Patch: https://git.openjdk.org/jfx21u/pull/63.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/63/head:pull/63 PR: https://git.openjdk.org/jfx21u/pull/63 From jvos at openjdk.org Thu Aug 1 08:53:11 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 08:53:11 GMT Subject: [jfx21u] RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs Message-ID: Almost clean backport of JDK-8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs The only change was the (c) date that had changed. ------------- Commit messages: - 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs Changes: https://git.openjdk.org/jfx21u/pull/64/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=64&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334874 Stats: 111 lines in 2 files changed: 107 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx21u/pull/64.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/64/head:pull/64 PR: https://git.openjdk.org/jfx21u/pull/64 From jvos at openjdk.org Thu Aug 1 09:32:06 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 09:32:06 GMT Subject: [jfx21u] RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used Message-ID: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used ------------- Commit messages: - Backport 8dd3c37cae3dd52dc3a258033d0e8f168ceaf307 Changes: https://git.openjdk.org/jfx21u/pull/65/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=65&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318841 Stats: 80 lines in 4 files changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/65.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/65/head:pull/65 PR: https://git.openjdk.org/jfx21u/pull/65 From jvos at openjdk.org Thu Aug 1 09:53:37 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 09:53:37 GMT Subject: [jfx21u] Integrated: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 09:23:42 GMT, Johan Vos wrote: > 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used This pull request has now been integrated. Changeset: e6f725f5 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/e6f725f59a801805bab090387685907fe30e1fff Stats: 80 lines in 4 files changed: 80 ins; 0 del; 0 mod 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used Backport-of: 8dd3c37cae3dd52dc3a258033d0e8f168ceaf307 ------------- PR: https://git.openjdk.org/jfx21u/pull/65 From jvos at openjdk.org Thu Aug 1 10:09:40 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 10:09:40 GMT Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener never being removed In-Reply-To: References: Message-ID: <-KaT5Zrp47Ap-7ymnGYwaXGBdBDAl2p8nP9CzLzXvFc=.590270ef-d033-4ce1-8588-1771c3d44af4@github.com> On Thu, 1 Aug 2024 08:41:59 GMT, Johan Vos wrote: > Backport of 8323787: Mac System MenuBar throws IOB exception > > Required manual changes as the location of the test has changed. closed in favor of #66 ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/63#issuecomment-2262658260 From jvos at openjdk.org Thu Aug 1 10:09:41 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 10:09:41 GMT Subject: [jfx21u] Withdrawn: 8319779: SystemMenu: memory leak due to listener never being removed In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 08:41:59 GMT, Johan Vos wrote: > Backport of 8323787: Mac System MenuBar throws IOB exception > > Required manual changes as the location of the test has changed. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx21u/pull/63 From jvos at openjdk.org Thu Aug 1 10:09:52 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 10:09:52 GMT Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener never being removed Message-ID: almost clean backport of 8319779: SystemMenu: memory leak due to listener never being removed Didn't apply clean because the imports where shuffled. ------------- Commit messages: - Backport 25ac6fed22d0f49d01c831aaa48049c34899fe96 Changes: https://git.openjdk.org/jfx21u/pull/66/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=66&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319779 Stats: 667 lines in 5 files changed: 462 ins; 196 del; 9 mod Patch: https://git.openjdk.org/jfx21u/pull/66.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/66/head:pull/66 PR: https://git.openjdk.org/jfx21u/pull/66 From jvos at openjdk.org Thu Aug 1 10:25:36 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 10:25:36 GMT Subject: [jfx21u] Integrated: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 08:47:38 GMT, Johan Vos wrote: > Almost clean backport of JDK-8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs > The only change was the (c) date that had changed. This pull request has now been integrated. Changeset: 29aa85ab Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/29aa85ab2a2c624db9f84e05eaff51ee3b9e248a Stats: 111 lines in 2 files changed: 107 ins; 0 del; 4 mod 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs Backport-of: 1bdb93c792cf7c218c74ec5cacda8bac1242f73b ------------- PR: https://git.openjdk.org/jfx21u/pull/64 From jpereda at openjdk.org Thu Aug 1 10:26:34 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 1 Aug 2024 10:26:34 GMT Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener never being removed In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 10:04:12 GMT, Johan Vos wrote: > almost clean backport of 8319779: SystemMenu: memory leak due to listener never being removed > Didn't apply clean because the imports where shuffled. Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/66#pullrequestreview-2212342712 From jvos at openjdk.org Thu Aug 1 10:36:39 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 1 Aug 2024 10:36:39 GMT Subject: [jfx21u] Integrated: 8319779: SystemMenu: memory leak due to listener never being removed In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 10:04:12 GMT, Johan Vos wrote: > almost clean backport of 8319779: SystemMenu: memory leak due to listener never being removed > Didn't apply clean because the imports where shuffled. This pull request has now been integrated. Changeset: ef8397aa Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/ef8397aa4886c2d1ac38b44a45c6adee3269827a Stats: 667 lines in 5 files changed: 462 ins; 196 del; 9 mod 8319779: SystemMenu: memory leak due to listener never being removed 8323787: Mac System MenuBar throws IOB exception Reviewed-by: jpereda Backport-of: 25ac6fed22d0f49d01c831aaa48049c34899fe96 ------------- PR: https://git.openjdk.org/jfx21u/pull/66 From fkirmaier at openjdk.org Thu Aug 1 11:45:05 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 1 Aug 2024 11:45:05 GMT Subject: RFR: 8337656 iOS WebView Position Message-ID: Fixing WebView on iOS (I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.) @johanvos If this looks reasonable to you, can you provide a test build for @dlemmermann ? Then he can test it with his JFX-Central iOS version. ------------- Commit messages: - JDK-8337656-ios-webview-position - JDK-8337656-ios-webview-position Changes: https://git.openjdk.org/jfx/pull/1526/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337656 Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1526.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1526/head:pull/1526 PR: https://git.openjdk.org/jfx/pull/1526 From angorya at openjdk.org Thu Aug 1 15:14:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 15:14:41 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Added debug trace for formats. Disabled by default. This might sound silly, but these formats seem to differ by the way color bits are laid out in memory - would it be possible to write a utility that does the direct conversion instead of calling two conversion methods? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2263322069 From duke at openjdk.org Thu Aug 1 17:03:47 2024 From: duke at openjdk.org (8Mi_Yile) Date: Thu, 1 Aug 2024 17:03:47 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec pls test and accept this pr can use this [app](https://github.com/HMCL-dev/HMCL/releases) test this fix ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2263531801 From angorya at openjdk.org Thu Aug 1 17:19:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 17:19:43 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: <6AxPpiiKIhuGEc3s0obVTv5klMcEiQiVOXgtgQRpNoo=.ad27a3e3-f7fd-4afe-8446-ed6eb5e4e736@github.com> On Thu, 1 Aug 2024 16:57:40 GMT, 8Mi_Yile wrote: > pls test and accept this pr can use this [app](https://github.com/HMCL-dev/HMCL/releases) test this fix @8MiYile : are you saying that the proposed fix works with this app? Would you provide more information on which platform(s) you've tested, how, and whether there were any issues? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2263569079 From angorya at openjdk.org Thu Aug 1 18:18:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 18:18:36 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v4] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 23:34:13 GMT, Martin Fox wrote: >> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). >> >> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. >> >> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. >> >> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. >> >> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments concerning the AWT Robot The reproducer in the ticket fails without the fix and works as described on 2021 macOS 14.5 M1, using built-in retina and an external Samsung LS27A600U display (which seems to have a different color profile). I would like to request a change for SRGBTest.COMPONENT_TOLERANCE value (or comment), please see inline comments. modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m line 423: > 421: components[1] = (CGFloat)((color & 0x0000FF00) >> 8) / 255.0; > 422: components[2] = (CGFloat)((color & 0x000000FF)) / 255.0; > 423: components[3] = (CGFloat)((color & 0xFF000000) >> 24) / 255.0; is this line guaranteed not to produce negative values? e.g. when `color = 0xffffffff` tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 100: > 98: // An AWT Robot is color space aware and will correctly convert from the > 99: // screeen's color space to sRGB. We use one to verify that the JavaFX > 100: // Robot is performing the same conversions. this comment is much clearer, thank you! ------------- PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2213465658 PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700569990 PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700605558 From angorya at openjdk.org Thu Aug 1 18:18:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 18:18:38 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 23:31:38 GMT, Martin Fox wrote: >> tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 52: >> >>> 50: >>> 51: import org.junit.Test; >>> 52: import static org.junit.Assume.assumeTrue; >> >> should we use junit5 for the new tests? > > This test is based on the VisualTestBase test harness class which is written using junit4. I use that test harness since it contains waitFirstFrame and waitNextFrame as well as existing utility routines for reporting on color mismatches. you are right, please disregard. >> tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 68: >> >>> 66: // The component tolerance allows one bit of rounding when writing a color >>> 67: // out and another bit when reading it back in. >>> 68: static final double COMPONENT_TOLERANCE = 2.0 / 255.0; >> >> suggestion: 2.0001 / 255.0 to account for floating point errors > > I'm not sure this test needs to be that precise. And I'm fine with the threshold falling below 2.0/255.0 since it should be as small as possible (I even experimented briefly with lower numbers). I haven't run into an issue on the three platforms I've run this test on. Then the comment might not be technically correct, because it is possible to have "two bit difference" in the integer color values, yet fail due to small error intrinsic in floating point operations. Example: a=253 b=251 delta=0.007843137254902044 tol=0.00784313725490196 delta=0.007843137254902044 tol=0.00784313725490196 (2.0 / 255.0) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700570982 PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700598001 From mfox at openjdk.org Thu Aug 1 19:51:09 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 1 Aug 2024 19:51:09 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: > When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). > > In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. > > Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. > > I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. > > I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Review feedback: floating point precision in test, ensure unsigned int handling in Robot ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1473/files - new: https://git.openjdk.org/jfx/pull/1473/files/20c23759..2dad883c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=03-04 Stats: 9 lines in 2 files changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1473.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1473/head:pull/1473 PR: https://git.openjdk.org/jfx/pull/1473 From mfox at openjdk.org Thu Aug 1 19:51:09 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 1 Aug 2024 19:51:09 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v4] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 17:42:16 GMT, Andy Goryachev wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated comments concerning the AWT Robot > > modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m line 423: > >> 421: components[1] = (CGFloat)((color & 0x0000FF00) >> 8) / 255.0; >> 422: components[2] = (CGFloat)((color & 0x000000FF)) / 255.0; >> 423: components[3] = (CGFloat)((color & 0xFF000000) >> 24) / 255.0; > > is this line guaranteed not to produce negative values? e.g. when `color = 0xffffffff` Good catch. I've updated the code to read the pixel value into an unsigned integer. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700742971 From mfox at openjdk.org Thu Aug 1 19:51:09 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 1 Aug 2024 19:51:09 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v3] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 18:02:05 GMT, Andy Goryachev wrote: >> I'm not sure this test needs to be that precise. And I'm fine with the threshold falling below 2.0/255.0 since it should be as small as possible (I even experimented briefly with lower numbers). I haven't run into an issue on the three platforms I've run this test on. > > Then the comment might not be technically correct, because it is possible to have "two bit difference" in the integer color values, yet fail due to small error intrinsic in floating point operations. > > Example: > > a=253 b=251 delta=0.007843137254902044 tol=0.00784313725490196 > > delta=0.007843137254902044 > tol=0.00784313725490196 (2.0 / 255.0) I've updated the constant as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700739626 From angorya at openjdk.org Thu Aug 1 19:55:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 19:55:35 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 19:51:09 GMT, Martin Fox wrote: >> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). >> >> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. >> >> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. >> >> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. >> >> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback: floating point precision in test, ensure unsigned int handling in Robot retested, looks good. thank you for the meticulously commented unit tests! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2213781126 From almatvee at openjdk.org Thu Aug 1 20:52:36 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 1 Aug 2024 20:52:36 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Thu, 1 Aug 2024 15:12:15 GMT, Andy Goryachev wrote: > This might sound silly, but these formats seem to differ by the way color bits are laid out in memory - would it be possible to write a utility that does the direct conversion instead of calling two conversion methods? NV12 and IYUV are different in memory layout only, but P010 is 10-bit per pixel and NV12 is 8-bit per pixel. I filed enhancement request https://bugs.openjdk.org/browse/JDK-8337686 to support P010 and NV12 directly by Graphics. I think it is better approach, then doing conversion in Media. For now this approach is good enough until JDK-8337686 is implemented. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2263960073 From angorya at openjdk.org Thu Aug 1 21:24:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 21:24:35 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com> On Thu, 1 Aug 2024 20:49:35 GMT, Alexander Matveev wrote: > JDK-8337686 thank you for filing the RFE. Should JDK-8337686 explicitly specify that the double conversion introduced in this PR be replaced? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2264025287 From kcr at openjdk.org Thu Aug 1 22:13:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Aug 2024 22:13:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 19:34:12 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed a bug I note that PR #1471 was originally proposed to address this. Can you highlight the differences? Are any of the comments added to that PR still relevant? I also note that [JDK-8226911](https://bugs.openjdk.org/browse/JDK-8226911) was added as an issue to the original PR? Should it also be added here? I'd like a review by at least two with a "Reviewer" role in addition to the CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2264099474 From angorya at openjdk.org Thu Aug 1 22:25:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 22:25:36 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev wrote: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 how do I set 3 reviewers and at least 2 "R"eviewers? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2264115220 From kizune at openjdk.org Thu Aug 1 22:41:05 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 1 Aug 2024 22:41:05 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v3] In-Reply-To: References: Message-ID: > Initial implementation of the protocol. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1507/files - new: https://git.openjdk.org/jfx/pull/1507/files/ce4cc10b..aeedf36f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1507&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1507&range=01-02 Stats: 19 lines in 2 files changed: 0 ins; 19 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1507.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1507/head:pull/1507 PR: https://git.openjdk.org/jfx/pull/1507 From kcr at openjdk.org Thu Aug 1 22:43:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Aug 2024 22:43:38 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: <4RRw8Xsqq0p_P7DOIU3BTpVfKym2v6crTMC7ra7NlDc=.e11ad5df-e709-495a-ab83-74e4d8875b71@github.com> On Thu, 1 Aug 2024 22:22:41 GMT, Andy Goryachev wrote: > how do I set 3 reviewers and at least 2 "R"eviewers? You can't. You can set it to `/reviewers 2 reviewers` and ask others to also review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2264139892 From kizune at openjdk.org Thu Aug 1 22:44:37 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 1 Aug 2024 22:44:37 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v3] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 22:41:05 GMT, Alexander Zuev wrote: >> Initial implementation of the protocol. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested. Fixed the crash by eliminating request to unsupported type of metadata. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2264140752 From kcr at openjdk.org Thu Aug 1 22:45:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Aug 2024 22:45:35 GMT Subject: RFR: 8320232: Cells duplicated when table collapsed and expanded In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 18:45:23 GMT, Marius Hanl wrote: > This PR fixes a bug where a `TableView` inside a `TitledPane` may 'duplicate' the cells. This actually has nothing to do with the `TitledPane`, but it triggered the bug easily due to its nature to change the size of his content when collapsing. > > The expansion change of a `TitledPane` triggered an event where the underlying `VirtualFlow` was adding cells to the pile (for reuse) and later cleaning them all up without resetting the index to -1. > This led to a bug where two cells had the same index and therefore received an edit event, although just one should (and is visible, the other cell has no parent -> orphan node). > > The fix is to always reset the index to -1. This was already done before, just not everywhere, for all cells. > So before we clear the pile (or cells), we always reset the index to -1. > Added a bunch of tests, some pass before and after. Looks good. I confirm that 3 of the newly-added test methods fail without the fix and pass with the fix. I agree with Andy about the unrelated change. I'll reapprove if you fix it. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1521#pullrequestreview-2214160824 From kcr at openjdk.org Thu Aug 1 22:48:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Aug 2024 22:48:37 GMT Subject: RFR: 8337400: [Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao wrote: > On Ubuntu 24.04 with Xorg windows are not shown centered. > > This is due a configure event being received with position 0,0 which is wrong. > > The fix ignores the configure events until the window is mapped. I've noticed a few Ubuntu 24.04 failures both on Xorg and on Wayland. I'll test them with this patch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1520#issuecomment-2264145178 From kcr at openjdk.org Thu Aug 1 22:49:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Aug 2024 22:49:36 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 22 Jul 2024 20:30:51 GMT, John Hendrikx wrote: >>> You might want to merge in the latest upstream master to pick up the JUnit 5 change (also, Skara doesn't report a conflict, but GitHub does). >> >> Skara woke up and reported the merge conflict, so you will need to merge master anyway. > > @kevinrushforth > >> I'll approve it as-is and reapprove if you are able to add a check for `CssParser::errorsProperty`. > > So, I added a check there, but must say the error system seems a bit unfinished/unpolished... this took way longer than it should have for the following reasons: > > - The `errorsProperty` will simply **not** be filled at all if you didn't access it first at least once. This is undocumented. > - The strings produced use a mix of line-endings on Windows (sometimes `\r\n`, sometimes `\n`), which isn't at all apparent when logging them to the console and trying to match them > - The produced strings are hard to read; it's some kind of text/xml/json hybrid > - Value is sometimes `value` sometimes `Value` > - The word `value` seems a bit overused, a part of the output: > > > > > > 50.0% > > > - Sometimes the produced string contains "indents" that are not preceded by a newline... > > > > > - Indents use a mix of tabs and spaces > - Quotes are sometimes unmatched: `'-fx-base''` > > In the PR you can see the strings it produces... @hjohn This is pending resolution of the merge conflict (then we can re-review) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2264146155 From kcr at openjdk.org Thu Aug 1 23:05:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Aug 2024 23:05:41 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: <94OGUzkD2amykoduDwP4194OKF8Lq3G-0-j39t7MJRY=.958e69f3-3169-432d-aaf8-35a1b7676db6@github.com> On Thu, 1 Aug 2024 19:51:09 GMT, Martin Fox wrote: >> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). >> >> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. >> >> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. >> >> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. >> >> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback: floating point precision in test, ensure unsigned int handling in Robot I'll test the updated version. From my earlier testing, I think the following two things need to be addressed, but I'll let you know for sure: 1. The new system test that uses both AWT and FX robot will need a timeout value, so it won't hang due to [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). We might separately consider skipping the test on Linux until that bug is fixed, but since that is an AWT bug, we need the timeout regardless so it doesn't hang the test run when run on a JDK without that fix. 2. I want to test this with the [metal branch](https://github.com/openjdk/jfx-sandbox/tree/metal) of the jfx-sandbox repo, which will require fixing a merge conflict. When I did this last time I ran into a few unexpected test failures. It's possible I made a mistake in resolving the merge conflicts, but that will need to be checked. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1473#issuecomment-2264164399 From almatvee at openjdk.org Thu Aug 1 23:27:38 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 1 Aug 2024 23:27:38 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com> Message-ID: On Thu, 1 Aug 2024 21:21:45 GMT, Andy Goryachev wrote: > > JDK-8337686 > > thank you for filing the RFE. Should JDK-8337686 explicitly specify that the double conversion introduced in this PR be replaced? I think this issue/PR should specify it. I just updated description for this PR that color conversion is temporary solution. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2264196640 From angorya at openjdk.org Thu Aug 1 23:57:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 23:57:46 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: Message-ID: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> On Wed, 31 Jul 2024 19:34:12 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed a bug Not a complete review, but the first batch of comments (I stopped at Stop, will continue). I think it's better to send smaller batches than one giant one (and I am afraid losing the comments due to some GH glitch). modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 37: > 35: * Interpolation types > 36: * > 37: * default very minor: is it possible to top-align the first column content instead of center? something like `` modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57: > 55: * > 56: * > 57: * (see prose) "see prose" - could you be more specific? maybe give an example? modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java line 157: > 155: @Override > 156: public boolean updateReversingAdjustedStartValue(TransitionMediator existingMediator) { > 157: var mediator = (TransitionMediatorImpl)existingMediator; minor: should we use an instanceof pattern here, or do we want to throw ClassCastException? (here and elsewhere) example: if(existingMediator instanceof TransitionMediatorImpl mediator) { ... } modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 136: > 134: @Override > 135: public void onUpdate(double progress) { > 136: set(progress < 1 ? startValue + (long)((endValue - startValue) * progress) : endValue); minor: should it use (long)Math.round() ? modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 124: > 122: // value of the existing transition. This scenario can sometimes happen when a CSS value > 123: // is redundantly applied, which would cause unexpected animations if we allowed the new > 124: // transition to interrupt the existing transition. TODO is there a unit test for this scenario? modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 210: > 208: // the running transition by adding its mediator to the newly created transition controller > 209: // that manages the hover->base transition. In this way, the new transition controller will > 210: // continue to aggregate the effects of the pre-existing transition. TODO add a unit test? modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 273: > 271: > 272: private StyleOrigin origin = null; > 273: private TransitionController controller = null; minor: `= null` is unnecessary modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 312: > 310: // refers to the reversing controller, and not to this controller. We need to be careful to only > 311: // clear references to this controller. > 312: if (controller == this) { is it guaranteed that the reference will be cleared eventually? TODO is there a unit test? modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 465: > 463: if (mediators.get(i) == mediator) { > 464: mediators.remove(i); > 465: break; how do we ensure there are no duplicates in the `mediators` list? modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 538: > 536: } else if (startValue instanceof Interpolatable && endValue instanceof Interpolatable) { > 537: value = ((Interpolatable)startValue).interpolate(endValue, progress); > 538: } else { minor: does this if-else block ordered by the expected frequency? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9010: > 9008: * > 9009: * @param property the {@code StyleableProperty} > 9010: * @param result the map into which results are stored, should be {@code null} should be or could be? see L9032 modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9184: > 9182: * > 9183: * @param metadata the CSS metadata of the property > 9184: * @param result the map into which results are stored, should be {@code null} same comment, `could be null`? modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 301: > 299: boolean opaqueFill = false; > 300: > 301: // We need to iterate over all of the supplied elements in the fills list. TODO check if there is a unit test for this modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundFill.java line 157: > 155: return this.fill == fill > 156: && this.radii == radii > 157: && this.insets == insets; are you sure these don't need equals()? modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundImage.java line 212: > 210: && this.repeatY == repeatY > 211: && this.position == position > 212: && this.size == size; same comment on equals(). 'size' comes from interpolate() on L178, so there is no guarantee as of its identity modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundPosition.java line 266: > 264: Side verticalSide, double verticalPosition, boolean verticalAsPercentage) { > 265: return this.horizontalSide == horizontalSide > 266: && this.horizontalPosition == horizontalPosition so here `==` seems to be ok since we are comparing enums and primitive values, but... should we account for floating point errors that might appear during interpolation? i.e. isClose(this.horizontalPosition, horizontalPosition) && where private static boolean isClose(double a, double b) { return Math.abs(a - b) < EPSILON; // 0.00001 or something like that should be ok for screen coordinates } modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundSize.java line 258: > 256: return this.width == width > 257: && this.height == height > 258: && this.widthAsPercentage == widthAsPercentage same comment - use isClose() for doubles? modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 331: > 329: > 330: for (int i = 0, max = strokes.size(); i < max; i++) { > 331: final BorderStroke stroke = strokes.get(i); just curious: do we really need `final` keyword for local variables after java8? modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 270: > 268: case ROUND -> BackgroundRepeat.ROUND; > 269: case SPACE -> BackgroundRepeat.SPACE; > 270: case STRETCH -> BackgroundRepeat.NO_REPEAT; what do you think of adding default: case? this code will not compile if BorderRepeat ever acquires a new value. modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 279: > 277: case ROUND -> BorderRepeat.ROUND; > 278: case SPACE -> BorderRepeat.SPACE; > 279: case NO_REPEAT -> BorderRepeat.STRETCH; same here // "non-comprehensive switch expression over evolved enum problem" modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 1956: > 1954: > 1955: // If both instances are equal, return this instance to prevent the creation of numerous small objects. > 1956: if (t <= 0.0 || equals(endValue)) return this; This question might be outside of the current PR, but I think the naive color interpolation algorithm is a bad choice here (L1960). See for example https://www.alanzucconi.com/2016/01/06/colour-interpolation/ The question that is relevant to this PR is whether we should enable the user to specify the interpolation algorithm. ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2213806821 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700900660 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700902994 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700911902 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700915376 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700918183 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700925072 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700933990 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700936434 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700942231 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700956059 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700960388 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700962134 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700967627 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700988085 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700990366 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700995142 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700997569 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700999656 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701010560 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701011685 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701018016 From angorya at openjdk.org Thu Aug 1 23:59:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Aug 2024 23:59:35 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com> Message-ID: On Thu, 1 Aug 2024 23:25:10 GMT, Alexander Matveev wrote: > I think this issue/PR should specify it. The main reason to mention what needs to be corrected is to help the person who will be working on JDK-8337686 many years from now ;-) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2264237284 From mstrauss at openjdk.org Fri Aug 2 00:40:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 00:40:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 22:10:31 GMT, Kevin Rushforth wrote: > I note that PR #1471 was originally proposed to address this. Can you highlight the differences? Are any of the comments added to that PR still relevant? The CSS specification allows specifying separate transitions for sub-properties (see "Independent transitions of sub-properties" in this PR). The previous implementation didn't account for that, while this implementation does. The comments are still applicable where they concern the `Interpolatable` implementations. > I also note that [JDK-8226911](https://bugs.openjdk.org/browse/JDK-8226911) was added as an issue to the original PR? Should it also be added here? Yes, I will add it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2264278865 From mstrauss at openjdk.org Fri Aug 2 01:28:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 01:28:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Thu, 1 Aug 2024 21:40:54 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 37: > >> 35: * Interpolation types >> 36: * >> 37: * default > > very minor: is it possible to top-align the first column content instead of center? > > something like > `` Sure. > modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57: > >> 55: * >> 56: * >> 57: * (see prose) > > "see prose" - could you be more specific? maybe give an example? An example would be `LinearGradient.stops`, but this is rather arbitrary. This table is not exhaustive, and the last line is meant to mention that it's not exhaustive. I'm not sure how an example helps, as every example will probably be different. > modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java line 157: > >> 155: @Override >> 156: public boolean updateReversingAdjustedStartValue(TransitionMediator existingMediator) { >> 157: var mediator = (TransitionMediatorImpl)existingMediator; > > minor: should we use an instanceof pattern here, or do we want to throw ClassCastException? > (here and elsewhere) > > example: > > if(existingMediator instanceof TransitionMediatorImpl mediator) { > ... > } A reversing mediator must be the same type, otherwise something is seriously broken. I prefer a `ClassCastException` to highlight that this is very unexpected. > modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 124: > >> 122: // value of the existing transition. This scenario can sometimes happen when a CSS value >> 123: // is redundantly applied, which would cause unexpected animations if we allowed the new >> 124: // transition to interrupt the existing transition. > > TODO > is there a unit test for this scenario? `StyleableProperty_transition_Test.testRedundantTransitionIsDiscarded` > modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 273: > >> 271: >> 272: private StyleOrigin origin = null; >> 273: private TransitionController controller = null; > > minor: `= null` is unnecessary I agree. Not sure if I should remove it from all of the StyleableProperty implementations, as the `origin = null` is already there. > modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 465: > >> 463: if (mediators.get(i) == mediator) { >> 464: mediators.remove(i); >> 465: break; > > how do we ensure there are no duplicates in the `mediators` list? The only mediators that are added are new ones (L418) or ones that don't come from this controller (L430). This applies to all controllers, so there can never be a duplicate. > modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 538: > >> 536: } else if (startValue instanceof Interpolatable && endValue instanceof Interpolatable) { >> 537: value = ((Interpolatable)startValue).interpolate(endValue, progress); >> 538: } else { > > minor: does this if-else block ordered by the expected frequency? Most of the time, we get an array series from CSS, so the common case is at the top. > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9010: > >> 9008: * >> 9009: * @param property the {@code StyleableProperty} >> 9010: * @param result the map into which results are stored, should be {@code null} > > should be or could be? > see L9032 _Should_ be `null` to get the non-allocating behavior if nothing is found, but _could_ also be non-null if we want to provide our own output map. > modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundFill.java line 157: > >> 155: return this.fill == fill >> 156: && this.radii == radii >> 157: && this.insets == insets; > > are you sure these don't need equals()? This is an internal optimization, see the comment at L135. Since we control the implementation of all types here, we _know_ that these types will return the existing instance if the intermediate value is equal to either the start value or the end value. Using `equals()` here is not necessary, and is not required for correctness. > modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundImage.java line 212: > >> 210: && this.repeatY == repeatY >> 211: && this.position == position >> 212: && this.size == size; > > same comment on equals(). > > 'size' comes from interpolate() on L178, so there is no guarantee as of its identity See my other comment. We _know_ that `BackgroundSize` returns existing instances if the intermediate value would be equal. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068408 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068436 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068449 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068468 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068503 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068540 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068594 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068658 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068704 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068718 From mstrauss at openjdk.org Fri Aug 2 01:34:37 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 01:34:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: <_VXULhjdYS0V_KY3m0CHZrfVAevz1mkKmpniLOSxUfA=.a9670e8c-1297-4e43-a0c3-bcb12ae077b7@github.com> On Thu, 1 Aug 2024 23:21:12 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundPosition.java line 266: > >> 264: Side verticalSide, double verticalPosition, boolean verticalAsPercentage) { >> 265: return this.horizontalSide == horizontalSide >> 266: && this.horizontalPosition == horizontalPosition > > so here `==` seems to be ok since we are comparing enums and primitive values, but... > should we account for floating point errors that might appear during interpolation? > i.e. > > isClose(this.horizontalPosition, horizontalPosition) && > > > where > > private static boolean isClose(double a, double b) { > return Math.abs(a - b) < EPSILON; // 0.00001 or something like that should be ok for screen coordinates > } I don't think that this is necessary. It would only save an allocation in a exceedingly rare case where the interpolation factor was microscopically different from either 0 or 1. This shouldn't happen in practice. > modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 331: > >> 329: >> 330: for (int i = 0, max = strokes.size(); i < max; i++) { >> 331: final BorderStroke stroke = strokes.get(i); > > just curious: do we really need `final` keyword for local variables after java8? I don't use it, but I didn't change the existing code here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701071650 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701072138 From mstrauss at openjdk.org Fri Aug 2 01:39:11 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 01:39:11 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - fix since tag - adjust table styling ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/675bc7f4..7a92bbf6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Fri Aug 2 01:39:12 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 01:39:12 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Thu, 1 Aug 2024 23:36:41 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 270: > >> 268: case ROUND -> BackgroundRepeat.ROUND; >> 269: case SPACE -> BackgroundRepeat.SPACE; >> 270: case STRETCH -> BackgroundRepeat.NO_REPEAT; > > what do you think of adding default: case? > this code will not compile if BorderRepeat ever acquires a new value. Yes, I think that's good, as it will alert us to the impact of adding a new enum value. We would probably need to account for the new value here (there's no good default we can choose). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701073308 From mstrauss at openjdk.org Fri Aug 2 02:15:35 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 02:15:35 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Thu, 1 Aug 2024 23:49:08 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 1956: > >> 1954: >> 1955: // If both instances are equal, return this instance to prevent the creation of numerous small objects. >> 1956: if (t <= 0.0 || equals(endValue)) return this; > > This question might be outside of the current PR, but I think the naive color interpolation algorithm is a bad choice here (L1960). > > See for example > https://www.alanzucconi.com/2016/01/06/colour-interpolation/ > > The question that is relevant to this PR is whether we should enable the user to specify the interpolation algorithm. CSS Transitions 1 is a feature-complete spec, and it doesn't include an option to specify the transition color space. That might come with CSS Transitions 2, but it's not there yet. I think we should revisit this once the feature has landed in the spec. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701105059 From duke at openjdk.org Fri Aug 2 05:41:46 2024 From: duke at openjdk.org (8Mi_Yile) Date: Fri, 2 Aug 2024 05:41:46 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v21] In-Reply-To: References: <25Sx4vlpR8treQXteqIY5Y29pvbekVmxhzoa5c5ojLE=.bab9f182-6c73-4460-80c9-ed5c7dfe50bc@github.com> Message-ID: On Sat, 8 Jun 2024 09:11:03 GMT, Glavo wrote: >> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits: >> >> - Merge branch 'refs/heads/master' into new_ime >> - Merge branch 'master' into new_ime >> - Add signals to avoid warnings >> - Merge branch 'master' into new_ime >> >> # Conflicts: >> # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp >> - Add check for jview >> - - Fix comment path >> - - Fix double keyrelease >> - - Use a work-around to relative positioning (until wayland is not officially supported) >> - Unref pango attr list >> - Merge branch 'master' into new_ime >> - Account the case of !filtered >> - ... and 85 more: https://git.openjdk.org/jfx/compare/94aa2b68...8c152c80 > > I also tested it on GNOME and KDE and it worked just fine, I didn?t face any issues. > > I have provided it to some Linux x86-64/ARM64/LoongArch64 users and they have not had any issues so far. @Glavo @andy-goryachev-oracle i'm tried test @Glavo build can get this report > [!TIP] > ???? (these is Chinese) Linux??? ?? 20.9 ???? 5.17.3 ????? 3.5.8.251 ???Java?? ???????? ???log https://mclo.gs/C1XiAVu ?????????? https://mclo.gs/ajAjNju ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2264598621 From hmeda at openjdk.org Fri Aug 2 06:41:03 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 2 Aug 2024 06:41:03 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 Message-ID: Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen ------------- Commit messages: - Update libxslt to v1.1.42 Changes: https://git.openjdk.org/jfx/pull/1527/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1527&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336941 Stats: 288 lines in 18 files changed: 111 ins; 126 del; 51 mod Patch: https://git.openjdk.org/jfx/pull/1527.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1527/head:pull/1527 PR: https://git.openjdk.org/jfx/pull/1527 From fkirmaier at openjdk.org Fri Aug 2 09:37:38 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 2 Aug 2024 09:37:38 GMT Subject: RFR: 8337656 iOS WebView Position In-Reply-To: References: Message-ID: <2deowhT-3jGtQVwX8dBtvDn0m39smJojLKnJp8gtlhI=.c057784f-f20e-4c4a-92f8-d5d210dcb676@github.com> On Thu, 1 Aug 2024 11:40:06 GMT, Florian Kirmaier wrote: > Fixing WebView on iOS > (I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.) > > @johanvos > If this looks reasonable to you, can you provide a test build for @dlemmermann ? > Then he can test it with his JFX-Central iOS version. Some Background: Dirk made a new jfx-central mobile version, in the hope of getting it through the app review. But in this version the WebView is buggy. So I looked into the code, and I assume, my change would fix it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1526#issuecomment-2264971784 From duke at openjdk.org Fri Aug 2 10:11:36 2024 From: duke at openjdk.org (danielpeintner) Date: Fri, 2 Aug 2024 10:11:36 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: <4JnTmcqWMFRGiISe8BHeQntGJIb38rNdlOgBnS54jDE=.67aa1637-303f-40bc-be87-56cc9b0a2af8@github.com> Message-ID: On Wed, 31 Jul 2024 15:08:44 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 157: >> >>> 155: * @since 999 TODO >>> 156: */ >>> 157: public class RichTextArea extends Control { >> >> The *old* `TextField` and `TextArea` controls extend `TextInputControl`. >> >> I wonder whether there is a a _good_ reason not doing the same for `RichTextArea`? >> Doing so would allow to more easily switch between one or the other. > > Thank you for a very good question! > > The main reason is that RichTextArea (RTA) can work with a large text model which needs to be represented differently from **TextInputControl**'s simple String **text** property. Other things, like position within the text is also very different, using `{paragraphIndex,charOffset}` instead of a simple `int` offset. The fact that the model is separated from the control also makes it very different. > > At the end, there is simply no benefit in dragging the `TextInputControl` into the picture. I was hoping to be able to easily replace one (old) control with the _new_ one. I mean `RichTextArea` still fulfilling the requirements of `TextInputControl`. Anyhow, I understand you rational not going along this path ? Let me provide the use-case I have in mind (which may explain better what I am looking for). I would like to use/keep textfields and textareas with pure text. Anyhow, having the possibility to _squiggly_ parts of the text showing spelling mistakes. Since I assume that loading many `RichTextArea` controls (i.e., in tables) will take much longer I expect to offer spelling suggestions (and `RichTextArea` loading) on request only. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1701641116 From jvos at openjdk.org Fri Aug 2 13:10:05 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 2 Aug 2024 13:10:05 GMT Subject: [jfx21u] RFR: 8329011: Update SQLite to 3.45.3 Message-ID: 8329011: Update SQLite to 3.45.3 ------------- Commit messages: - Backport 581e3a70a45a550a97e391e06735f4837336ada8 Changes: https://git.openjdk.org/jfx21u/pull/67/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=67&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329011 Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod Patch: https://git.openjdk.org/jfx21u/pull/67.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/67/head:pull/67 PR: https://git.openjdk.org/jfx21u/pull/67 From jvos at openjdk.org Fri Aug 2 13:14:50 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 2 Aug 2024 13:14:50 GMT Subject: [jfx17u] RFR: 8329011: Update SQLite to 3.45.3 Message-ID: 8329011: Update SQLite to 3.45.3 ------------- Commit messages: - Backport 581e3a70a45a550a97e391e06735f4837336ada8 Changes: https://git.openjdk.org/jfx17u/pull/197/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=197&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329011 Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod Patch: https://git.openjdk.org/jfx17u/pull/197.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/197/head:pull/197 PR: https://git.openjdk.org/jfx17u/pull/197 From jvos at openjdk.org Fri Aug 2 14:10:41 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 2 Aug 2024 14:10:41 GMT Subject: [jfx21u] Integrated: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 13:04:30 GMT, Johan Vos wrote: > 8329011: Update SQLite to 3.45.3 This pull request has now been integrated. Changeset: 454ac50c Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/454ac50cea8f93f5c8bd7c30393d0ca2648b245f Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod 8329011: Update SQLite to 3.45.3 Backport-of: 581e3a70a45a550a97e391e06735f4837336ada8 ------------- PR: https://git.openjdk.org/jfx21u/pull/67 From jvos at openjdk.org Fri Aug 2 14:10:41 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 2 Aug 2024 14:10:41 GMT Subject: [jfx17u] Integrated: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 13:08:26 GMT, Johan Vos wrote: > 8329011: Update SQLite to 3.45.3 This pull request has now been integrated. Changeset: eb330d88 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/eb330d883d32b9cc1f9d0c894b01b160b2bfe2c3 Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod 8329011: Update SQLite to 3.45.3 Backport-of: 581e3a70a45a550a97e391e06735f4837336ada8 ------------- PR: https://git.openjdk.org/jfx17u/pull/197 From jhendrikx at openjdk.org Fri Aug 2 14:39:49 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Aug 2024 14:39:49 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v6] In-Reply-To: References: Message-ID: > Fixes an infinite loop that can occur while resolving lookups. > > There were 2 bugs: > - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates > - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far > > Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into feature/fix-stackoverflow-in-resolve-lookups - Add lines I forgot to commit - Add check on errorProperty - Merge branch 'master' of https://git.openjdk.org/jfx into feature/fix-stackoverflow-in-resolve-lookups - Fix formatting and spelling - Fix loop detection in resolveLookups ------------- Changes: https://git.openjdk.org/jfx/pull/1505/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=05 Stats: 171 lines in 2 files changed: 158 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1505.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505 PR: https://git.openjdk.org/jfx/pull/1505 From angorya at openjdk.org Fri Aug 2 14:54:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 14:54:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com> On Fri, 2 Aug 2024 02:13:16 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 1956: >> >>> 1954: >>> 1955: // If both instances are equal, return this instance to prevent the creation of numerous small objects. >>> 1956: if (t <= 0.0 || equals(endValue)) return this; >> >> This question might be outside of the current PR, but I think the naive color interpolation algorithm is a bad choice here (L1960). >> >> See for example >> https://www.alanzucconi.com/2016/01/06/colour-interpolation/ >> >> The question that is relevant to this PR is whether we should enable the user to specify the interpolation algorithm. > > CSS Transitions 1 is a feature-complete spec, and it doesn't include an option to specify the transition color space. That might come with CSS Transitions 2, but it's not there yet. I think we should revisit this once the feature has landed in the spec. pardon my ignorance, could you clarify what a "CSS Transition 1" is? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701960667 From jhendrikx at openjdk.org Fri Aug 2 15:02:13 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Aug 2024 15:02:13 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7] In-Reply-To: References: Message-ID: > Fixes an infinite loop that can occur while resolving lookups. > > There were 2 bugs: > - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates > - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far > > Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Update CssStyleHelper.java ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1505/files - new: https://git.openjdk.org/jfx/pull/1505/files/72d64b0f..ff5788c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1505.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505 PR: https://git.openjdk.org/jfx/pull/1505 From jhendrikx at openjdk.org Fri Aug 2 15:02:13 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Aug 2024 15:02:13 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v5] In-Reply-To: References: Message-ID: <9YIR4N0_FlczeBabLT5g5UUzUBaTWUvkyj0-fGa3Ggk=.613a1420-871d-49dd-8531-d0134547cbc9@github.com> On Thu, 25 Jul 2024 14:54:46 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 699: >> >>> 697: >>> 698: // Note: on Windows, the message is using inconsistent line endings (sometimes Windows, sometimes Linux) >>> 699: // so I've stripped it. >> >> would looking for substrings be a better solution? for example: >> >> >> contains("Caught java.lang.IllegalArgumentException: Loop detected in *.root{") && >> contains("while resolving '-fx-base'' while calculating value for '-fx-background-color' from rule '*.pane' in stylesheet" > > Yeah, this seems less fragile. If we ever run into a problem because the message changes slightly, we could consider such a change in the future. I'm not sure what way is being advocated. It seems both of you favor a contains check? For me, I always verify strings intended for user consumption completely so that any change would fail a test. If the change is intended (like fixing the missing line feeds), then the string can be fixed at the same time. With the complete string, the test also serves as a way to see the full output (which in this case, is a bit abysmal, so perhaps we should follow up with a fix). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1701968325 From angorya at openjdk.org Fri Aug 2 15:03:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 15:03:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 01:25:06 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 273: >> >>> 271: >>> 272: private StyleOrigin origin = null; >>> 273: private TransitionController controller = null; >> >> minor: `= null` is unnecessary > > I agree. Not sure if I should remove it from all of the StyleableProperty implementations, as the `origin = null` is already there. I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes" as long as the new code omits `= null` we should be fine. (rationale for omitting: explicit initialization creates an unnecessary step in the debugger) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701970897 From angorya at openjdk.org Fri Aug 2 15:07:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 15:07:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 01:25:26 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9010: >> >>> 9008: * >>> 9009: * @param property the {@code StyleableProperty} >>> 9010: * @param result the map into which results are stored, should be {@code null} >> >> should be or could be? >> see L9032 > > _Should_ be `null` to get the non-allocating behavior if nothing is found, but _could_ also be non-null if we want to provide our own output map. I suggest we clarify this behavior in the method description. Simply saying "should" increases cognitive load and creates a question: why have this argument in the first place, and the need to search the code for an explanation. (yes, I understand we could also create a private method with the `map` argument) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701974659 From mstrauss at openjdk.org Fri Aug 2 15:07:40 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 15:07:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com> Message-ID: On Fri, 2 Aug 2024 14:52:21 GMT, Andy Goryachev wrote: >> CSS Transitions 1 is a feature-complete spec, and it doesn't include an option to specify the transition color space. That might come with CSS Transitions 2, but it's not there yet. I think we should revisit this once the feature has landed in the spec. > > pardon my ignorance, could you clarify what a "CSS Transition 1" is? It's basically the feature level of the specification. Here's level 1: https://www.w3.org/TR/css-transitions-1/ (this is implemented in JavaFX) Here's level 2: https://www.w3.org/TR/css-transitions-2/ There seems to be an ongoing discussion around different color interpolation options, but nothing has made it into the level 2 specification yet. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701975936 From mstrauss at openjdk.org Fri Aug 2 15:37:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 15:37:16 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v4] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add test for inherited transitions ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/7a92bbf6..8f53f3a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=02-03 Stats: 147 lines in 2 files changed: 116 ins; 28 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Fri Aug 2 15:37:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 15:37:16 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Thu, 1 Aug 2024 22:05:50 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 210: > >> 208: // the running transition by adding its mediator to the newly created transition controller >> 209: // that manages the hover->base transition. In this way, the new transition controller will >> 210: // continue to aggregate the effects of the pre-existing transition. > > is there a unit test for this scenario? Done: `StyleableProperty_transition_Test.testExistingTransitionOfComponentTransitionableIsPreserved` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702014530 From mstrauss at openjdk.org Fri Aug 2 15:41:11 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 15:41:11 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v5] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - update documentation - remove redundant null initialization ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/8f53f3a8..3b8fa919 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=03-04 Stats: 14 lines in 7 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Fri Aug 2 15:44:37 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 15:44:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 15:00:38 GMT, Andy Goryachev wrote: >> I agree. Not sure if I should remove it from all of the StyleableProperty implementations, as the `origin = null` is already there. > > I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes" > > as long as the new code omits `= null` we should be fine. > > (rationale for omitting: explicit initialization creates an unnecessary step in the debugger) I've removed the `= null` for consistency on both fields. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702023744 From mstrauss at openjdk.org Fri Aug 2 15:47:36 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 15:47:36 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 15:03:48 GMT, Andy Goryachev wrote: >> _Should_ be `null` to get the non-allocating behavior if nothing is found, but _could_ also be non-null if we want to provide our own output map. > > I suggest we clarify this behavior in the method description, since this is a public API documentation. > > Simply saying "should" increases cognitive load and immediately triggers a question: why have this argument at all?, and the need to search the code for an explanation. > > (yes, I understand we could also create a private method with the `map` argument) I've worded it more strongly such that callers _must_ pass in `null`. This is a private method, so we don't need to account for other usage scenarios. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702027303 From kcr at openjdk.org Fri Aug 2 15:51:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 15:51:36 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v5] In-Reply-To: <9YIR4N0_FlczeBabLT5g5UUzUBaTWUvkyj0-fGa3Ggk=.613a1420-871d-49dd-8531-d0134547cbc9@github.com> References: <9YIR4N0_FlczeBabLT5g5UUzUBaTWUvkyj0-fGa3Ggk=.613a1420-871d-49dd-8531-d0134547cbc9@github.com> Message-ID: On Fri, 2 Aug 2024 14:58:32 GMT, John Hendrikx wrote: > It seems both of you favor a contains check? Yeah, that is what I was saying, but I don't mind either way. And you raise a good point about the advantage of having any change to the string cause a failure (as long as the string isn't prone to spurious changes). So I have no objection to your leaving it as is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1702031515 From kcr at openjdk.org Fri Aug 2 15:54:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 15:54:38 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 15:02:13 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update CssStyleHelper.java Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2215916092 From mstrauss at openjdk.org Fri Aug 2 15:55:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 15:55:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Thu, 1 Aug 2024 22:51:06 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 301: > >> 299: boolean opaqueFill = false; >> 300: >> 301: // We need to iterate over all of the supplied elements in the fills list. > > is there a unit test for this scenario? The closest one I can find is `BackgroundTest.backgroundOutsetsAreDefinedByFills`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702036374 From kcr at openjdk.org Fri Aug 2 16:00:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 16:00:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 15:41:36 GMT, Michael Strau? wrote: >> I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes" >> >> as long as the new code omits `= null` we should be fine. >> >> (rationale for omitting: explicit initialization creates an unnecessary step in the debugger) > > I've removed the `= null` for consistency on both fields. > I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes" Yes, that is what I would say. :) > as long as the new code omits `= null` we should be fine. > > (rationale for omitting: explicit initialization creates an unnecessary step in the debugger) In this case, omitting it is fine. There are cases where I prefer to explicitly initialize fields to `null`, `false`, or `0`, for clarity, even though those values are the default. I don't care that it creates an unnecessary step in your debugger. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702041658 From angorya at openjdk.org Fri Aug 2 16:13:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 16:13:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 01:39:11 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - fix since tag > - adjust table styling Thank you for this contribution! This is the second batch of code review comments. Will probably have more after testing. modules/javafx.graphics/src/main/java/javafx/scene/paint/Stop.java line 162: > 160: // re-allocating when we run out of space. In general, we expect the size of stop lists > 161: // to be quite small (a single-digit number of stops at most). > 162: Stop[] stops = new Stop[firstList.size() + secondList.size()]; are there unit tests to cover most of the scenarios, at least using short sequences? modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopListTest.java line 264: > 262: new Stop(1, color2)), > 263: res); > 264: } Do you think any other combinations should be added, for completeness sake? For example, let's consider two lists with 2 points each. We might want to test scenarios: -- -- --| |-- --- --- ----| ---| ------ -- |----- |-- |---| |---| |-- --| --- -- and also have the two lists swapped maybe? what do you think? ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2215836542 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702023646 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702046900 From angorya at openjdk.org Fri Aug 2 16:13:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 16:13:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 01:24:59 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java line 157: >> >>> 155: @Override >>> 156: public boolean updateReversingAdjustedStartValue(TransitionMediator existingMediator) { >>> 157: var mediator = (TransitionMediatorImpl)existingMediator; >> >> minor: should we use an instanceof pattern here, or do we want to throw ClassCastException? >> (here and elsewhere) >> >> example: >> >> if(existingMediator instanceof TransitionMediatorImpl mediator) { >> ... >> } > > A reversing mediator must be the same type, otherwise something is seriously broken. I prefer a `ClassCastException` to highlight that this is very unexpected. that's what I thought, thanks for clarification. >> modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundFill.java line 157: >> >>> 155: return this.fill == fill >>> 156: && this.radii == radii >>> 157: && this.insets == insets; >> >> are you sure these don't need equals()? > > This is an internal optimization, see the comment at L135. Since we control the implementation of all types here, we _know_ that these types will return the existing instance if the intermediate value is equal to either the start value or the end value. Using `equals()` here is not necessary, and is not required for correctness. I see, so it only checks for hitting the start/end point. thanks for clarification! >> modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 270: >> >>> 268: case ROUND -> BackgroundRepeat.ROUND; >>> 269: case SPACE -> BackgroundRepeat.SPACE; >>> 270: case STRETCH -> BackgroundRepeat.NO_REPEAT; >> >> what do you think of adding default: case? >> this code will not compile if BorderRepeat ever acquires a new value. > > Yes, I think that's good, as it will alert us to the impact of adding a new enum value. We would probably need to account for the new value here (there's no good default we can choose). IllegalArgumentException? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701991167 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702001112 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702004500 From angorya at openjdk.org Fri Aug 2 16:13:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 16:13:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Thu, 1 Aug 2024 22:45:43 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9184: > >> 9182: * >> 9183: * @param metadata the CSS metadata of the property >> 9184: * @param result the map into which results are stored, should be {@code null} > > same comment, `could be null`? or perhaps remove it by adding a private method with the second argument? what do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701996909 From angorya at openjdk.org Fri Aug 2 16:13:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 16:13:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com> Message-ID: On Fri, 2 Aug 2024 15:04:50 GMT, Michael Strau? wrote: >> pardon my ignorance, could you clarify what a "CSS Transition 1" is? > > It's basically the feature level of the specification. > Here's level 1: https://www.w3.org/TR/css-transitions-1/ (this is implemented in JavaFX) > Here's level 2: https://www.w3.org/TR/css-transitions-2/ > There seems to be an ongoing discussion around different color interpolation options, but nothing has made it into the level 2 specification yet. thank you for clarification! would it make sense to add an option for programmatic interpolation, i.e. when the app developer does it in code as opposed to CSS? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702015968 From angorya at openjdk.org Fri Aug 2 16:21:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 16:21:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: <9oq88dfCt9HRiDyl8zizIpvYlkDIggCzO5VwBcs9-TY=.3649f067-6a4d-4ed5-84e1-7a818cc27fdf@github.com> On Thu, 1 Aug 2024 21:54:18 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a bug > > modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 136: > >> 134: @Override >> 135: public void onUpdate(double progress) { >> 136: set(progress < 1 ? startValue + (long)((endValue - startValue) * progress) : endValue); > > minor: should it use (long)Math.round() ? edit: I think it should. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702063665 From angorya at openjdk.org Fri Aug 2 16:21:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 16:21:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 01:24:56 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57: >> >>> 55: * >>> 56: * >>> 57: * (see prose) >> >> "see prose" - could you be more specific? maybe give an example? > > An example would be `LinearGradient.stops`, but this is rather arbitrary. This table is not exhaustive, and the last line is meant to mention that it's not exhaustive. I'm not sure how an example helps, as every example will probably be different. I just feel a bit confused by the last entry in this table, or may be the choice of word "prose" (the description is good). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702061354 From mstrauss at openjdk.org Fri Aug 2 16:21:40 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 16:21:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com> Message-ID: On Fri, 2 Aug 2024 15:35:14 GMT, Andy Goryachev wrote: >> It's basically the feature level of the specification. >> Here's level 1: https://www.w3.org/TR/css-transitions-1/ (this is implemented in JavaFX) >> Here's level 2: https://www.w3.org/TR/css-transitions-2/ >> There seems to be an ongoing discussion around different color interpolation options, but nothing has made it into the level 2 specification yet. > > thank you for clarification! > > would it make sense to add an option for programmatic interpolation, i.e. when the app developer does it in code as opposed to CSS? Yes, I think this would be a good enhancement. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702064093 From angorya at openjdk.org Fri Aug 2 16:25:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 16:25:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 15:44:41 GMT, Michael Strau? wrote: >> I suggest we clarify this behavior in the method description, since this is a public API documentation. >> >> Simply saying "should" increases cognitive load and immediately triggers a question: why have this argument at all?, and the need to search the code for an explanation. >> >> (yes, I understand we could also create a private method with the `map` argument) > > I've worded it more strongly such that callers _must_ pass in `null`. This is a private method, so we don't need to account for other usage scenarios. oh, right, it is private! never mind then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702066372 From mstrauss at openjdk.org Fri Aug 2 16:25:38 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 16:25:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> Message-ID: On Fri, 2 Aug 2024 15:28:37 GMT, Andy Goryachev wrote: >> Yes, I think that's good, as it will alert us to the impact of adding a new enum value. We would probably need to account for the new value here (there's no good default we can choose). > > IllegalArgumentException? Sure, but that would be a runtime errro as compared to a compile-time error, so we run the risk of missing it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702067250 From kcr at openjdk.org Fri Aug 2 16:54:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 16:54:35 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. The code changes look good. I tested it on Windows 11 and it now looks correct. @arapte or @andy-goryachev-oracle can one of you be the second reviewer? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1525#pullrequestreview-2216020305 PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2265790174 From kcr at openjdk.org Fri Aug 2 16:58:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 16:58:41 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 In-Reply-To: References: Message-ID: <_2Qqjyrc_vR1iG8cSXs0L6UNjGgwgbYPjmmaqNi0_mY=.f6c8ef35-e06e-4206-968c-0fba96ca7751@github.com> On Fri, 2 Aug 2024 06:36:22 GMT, Hima Bindu Meda wrote: > Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen Reviewers: @kevinrushforth @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2265795518 From quizynox at gmail.com Fri Aug 2 17:43:11 2024 From: quizynox at gmail.com (quizynox at gmail.com) Date: Fri, 2 Aug 2024 21:43:11 +0400 Subject: Font hinting on Linux Message-ID: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com> Hello, Sorry for asking here, but I seem to have tried everything I could find on SO/Reddit/JBS etc. Could someone please share what font settings I should be using to get decent font hinting on Linux? Please see the screenshot. https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view I'm not very picky, but the font I see is just not suitable for presenting app to customers. I've tried enabling and disabling hinting and autohinting, using different hinting styles, changing the font smoothing type and prism.lcdtext etc. Unfortunately no matter what I do, the font hinting is always bad. Fedora, KDE, all latest versions. From angorya at openjdk.org Fri Aug 2 17:53:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 17:53:39 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 15:02:13 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update CssStyleHelper.java re-tested on macOS, works as expected. also tested in the Monkey Tester with the CSS provided in the ticket (errors appear in stderr as expected), and after the offending CSS is removed (gets back to normal). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2216111787 From angorya at openjdk.org Fri Aug 2 18:02:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 18:02:35 GMT Subject: Integrated: 8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole In-Reply-To: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com> References: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com> Message-ID: On Thu, 18 Jul 2024 19:00:06 GMT, Andy Goryachev wrote: > Minor clarifications in Javadoc > > **AccessibleAttribute**: > - Point2D and Bound values uses screen coordinates. Example: `BOUNDS`, `BOUNDS_FOR_RANGE`, `OFFSET_AT_POINT`, ... > - clarified the meaning of `SELECTION_END`, `SELECTION_START` > > **Accessible Role**: > - missing accessible action `SHOW_TEXT_RANGE` > > This will be a minor clarification, so no CSR is required. This pull request has now been integrated. Changeset: 41de0202 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/41de02023571d146f392de012a55011a5f87fc9d Stats: 13 lines in 3 files changed: 4 ins; 0 del; 9 mod 8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole Reviewed-by: arapte, kizune ------------- PR: https://git.openjdk.org/jfx/pull/1512 From kcr at openjdk.org Fri Aug 2 18:19:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 18:19:44 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 06:36:22 GMT, Hima Bindu Meda wrote: > Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen Looks good, although I notice one difference between the upstream libxslt repo and this PR in a now-unmaintained config file: diff -u -w -r $JFX/modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt.m4 $LIBXML/libxslt.m4 --- $JFX/modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt.m4 2023-07-27 15:08:29.124274800 -0700 +++ $LIBXML/libxslt.m4 2024-08-02 10:18:29.007649600 -0700 @@ -5,6 +5,8 @@ # Configure paths for GLIB # Owen Taylor 97-11-3 # +# Deprecated and unmaintained. Use pkg-config or xslt-config. +# # Modified to work with libxslt by Thomas Schraitle 2002/10/25 # Fixed by Edward Rudd 2004/05/12 Do we use `libxslt.m4` when we run configure to generate the platform-specific headers? If not, I recommend that you remove it from our repo. If we do, please add the two lines from the above patch so that we match the upstream. Note that the deprecation comment was added by: https://gitlab.gnome.org/GNOME/libxslt/-/commit/200ee26982b4c8cbe165555ae36aa684a744ccf4 so we will eventually need to stop using it if we still are. ------------- PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2216151444 From kevin.rushforth at oracle.com Fri Aug 2 18:31:46 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 2 Aug 2024 11:31:46 -0700 Subject: JavaFX 23 is in Rampdown Phase Two (RDP2) Message-ID: <821ff1d7-3f5c-4b25-9dd9-16941959668d@oracle.com> To: JavaFX Developers As a reminder, JavaFX 23 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bug fixes, and test or doc fixes of any priority, can be fixed during RDP2. Explicit approval is needed for all bug fixes and enhancements (except for doc and test fixes) to go in to the jfx23 branch [2]. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in JavaFX 23. We need to be extremely careful about including anything that introduces risk. We will use the same rules for RDP2 that the JDK uses [3], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 23 release. As an obvious choice, derived from the JBS fix version, we will use "jfx23-fix-request", "jfx23-fix-yes", "jfx23-fix-no" and "jfx23-fix-nmi", "jfx23-enhancement-request", "jfx23-enhancement-yes", "jfx23-enhancement-no" and "jfx23-enhancement-nmi" as corresponding labels. REMINDER: In this release we will integrate almost all stabilization changes via backports from the master branch [4]. ? * Almost all fixes intended for the jfx23 stabilization branch will also be applicable to the master branch. Integrate such a change into the master branch first. Then, after you have obtained any required approvals, backport it to the stabilization branch using the Skara `/backport` command or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash.? (The JDK Developers? Guide contains more information on working with backports [5].) ? * Some fixes will be specific to the stabilization branch and not applicable to the master branch. Integrate such a change directly into the stabilization branch. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (JavaFX 24 as of today). This is usually what we want. A backport PR should be targeted to `jfx23` if, and only if, it is intended for JavaFX 23 and meets the criteria for the current rampdown phase (we're in RDP2 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx23`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 24 (or withdrawn if it is a backport of a fix already in `master`). Reviewers also need to be extra careful when reviewing PRs targeted to jfx23 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. This should be less of a problem for this release, since almost all PRs for jfx23 will be done as backport-style PRs, but it can still be a problem if the developer mistakenly merges master into their backport branch. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-May/046924.html [2] https://github.com/openjdk/jfx/tree/jfx23 [3] http://openjdk.org/jeps/3 [4] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [5] https://openjdk.org/guide/#working-with-backports-in-jbs From angorya at openjdk.org Fri Aug 2 18:32:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 18:32:36 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: <4JnTmcqWMFRGiISe8BHeQntGJIb38rNdlOgBnS54jDE=.67aa1637-303f-40bc-be87-56cc9b0a2af8@github.com> Message-ID: <7AtaWg8Dvq0G0cJmEacIqaZICd0t6tzzEU05IoeHrEU=.460b03ad-08b9-44ca-bd01-58d5aa15b5d6@github.com> On Fri, 2 Aug 2024 10:09:21 GMT, danielpeintner wrote: >> Thank you for a very good question! >> >> The main reason is that RichTextArea (RTA) can work with a large text model which needs to be represented differently from **TextInputControl**'s simple String **text** property. Other things, like position within the text is also very different, using `{paragraphIndex,charOffset}` instead of a simple `int` offset. The fact that the model is separated from the control also makes it very different. >> >> At the end, there is simply no benefit in dragging the `TextInputControl` into the picture. > > I was hoping to be able to easily replace one (old) control with the _new_ one. I mean `RichTextArea` still fulfilling the requirements of `TextInputControl`. Anyhow, I understand you rational not going along this path ? > > Let me provide the use-case I have in mind (which may explain better what I am looking for). > I would like to use/keep textfields and textareas with pure text. Anyhow, having the possibility to _squiggly_ parts of the text showing spelling mistakes. Since I assume that loading many `RichTextArea` controls (i.e., in tables) will take much longer I expect to offer spelling suggestions (and `RichTextArea` loading) on request only. It looks like in this particular case you do want to preserve the semantics and APIs of TextArea, rather than switch to a new API. You could simply extend TextArea/Skin and add functionality to superimpose the squiggly on top of TextArea. You'll need to listen to several properties and make sure the clipping is set up correctly and you handle the scrolling et cetera, but I think it's doable. Of course, once you decide that you need to further decorate your text, with let's say highlighted areas, then you might as well use the new component. By the way, **CodeArea** is specifically designed for that purpose, even has `getText()` and `setText()` - but no textProperty because it's designed to work with large documents. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1702187490 From angorya at openjdk.org Fri Aug 2 18:37:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Aug 2024 18:37:38 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: <7AtaWg8Dvq0G0cJmEacIqaZICd0t6tzzEU05IoeHrEU=.460b03ad-08b9-44ca-bd01-58d5aa15b5d6@github.com> References: <4JnTmcqWMFRGiISe8BHeQntGJIb38rNdlOgBnS54jDE=.67aa1637-303f-40bc-be87-56cc9b0a2af8@github.com> <7AtaWg8Dvq0G0cJmEacIqaZICd0t6tzzEU05IoeHrEU=.460b03ad-08b9-44ca-bd01-58d5aa15b5d6@github.com> Message-ID: On Fri, 2 Aug 2024 18:30:22 GMT, Andy Goryachev wrote: >> I was hoping to be able to easily replace one (old) control with the _new_ one. I mean `RichTextArea` still fulfilling the requirements of `TextInputControl`. Anyhow, I understand you rational not going along this path ? >> >> Let me provide the use-case I have in mind (which may explain better what I am looking for). >> I would like to use/keep textfields and textareas with pure text. Anyhow, having the possibility to _squiggly_ parts of the text showing spelling mistakes. Since I assume that loading many `RichTextArea` controls (i.e., in tables) will take much longer I expect to offer spelling suggestions (and `RichTextArea` loading) on request only. > > It looks like in this particular case you do want to preserve the semantics and APIs of TextArea, rather than switch to a new API. > > You could simply extend TextArea/Skin and add functionality to superimpose the squiggly on top of TextArea. You'll need to listen to several properties and make sure the clipping is set up correctly and you handle the scrolling et cetera, but I think it's doable. > > Of course, once you decide that you need to further decorate your text, with let's say highlighted areas, then you might as well use the new component. > > By the way, **CodeArea** is specifically designed for that purpose, even has `getText()` and `setText()` - but no textProperty because it's designed to work with large documents. You might be right about impact on performance when trying to use many RichTextArea (RTA) controls as table cells - it is indeed a heavier component, but as long as you ensure there are no memory leaks and your table does not show 1000s of cells on screen we should be ok. If performance is an issue, a full blown editor might indeed be overkill, and you might be better off created a subclass of Labeled adorned with decorations instead. You can always set up RTA as an editor if you need to. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1702191592 From mfox at openjdk.org Fri Aug 2 19:12:47 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Aug 2024 19:12:47 GMT Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is handled differently depending on the useSystemMenuBar value Message-ID: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crash at the event before it works its way out to the menu bar. We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item. This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar. I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into sysmenudup - Updated robot test to run on other platforms - Added Robot test - If JavaFX processes a shortcut it is not sent on to the system menu bar Changes: https://git.openjdk.org/jfx/pull/1528/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8087863 Stats: 279 lines in 12 files changed: 242 ins; 0 del; 37 mod Patch: https://git.openjdk.org/jfx/pull/1528.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1528/head:pull/1528 PR: https://git.openjdk.org/jfx/pull/1528 From andy.goryachev at oracle.com Fri Aug 2 19:41:00 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 2 Aug 2024 19:41:00 +0000 Subject: RichTextArea: API Review Message-ID: Dear fellow developers: Thank you for the early feedback on the RichTextArea proposal [0]. We are moving to the next phase by submitting the public pull request [1]. The main goal is to include the new control in an incubating module [8], hopefully in jfx24, as a means of putting non-final API in the hands of developers while the API and implementation progress towards either finalization or removal in a future release. For your convenience, two test applications are provided - RichTextAreaDemoApp and CodeAreaDemoApp which demonstrate the new controls with a number of different models. In addition to these two testers, please check out a simple standalone rich text editor application, RichEditorDemoApp, We would encourage anyone - the javafx developers, and especially the application developers, to take a look at the public API [3]. It's probably less important at this stage to do a deep code review of the implementation, but we would certainly appreciate and welcome your code review comments. Thank you in advance, -andy [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md [1] Pull request: https://github.com/openjdk/jfx/pull/1524 [2] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md [3] API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc [4] CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html [5] Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 [7] Previous (now obsolete) draft pull request: https://github.com/openjdk/jfx/pull/1374 [8] Incubator module JEP: https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Aug 2 20:15:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 20:15:37 GMT Subject: RFR: 8337281: build.gradle assumes all modules are named "javafx.$project" [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 12:41:24 GMT, Johan Vos wrote: > In general, these changes look ok (and are indeed fixing an issue). Thanks. > I keep hoping that changes to build.gradle lead to a smaller file, but the monolith is only getting bigger (more lines). It would be great if more logic can be split into a separate file, which would make the huge build.gradle a bit more maintainable, but I understand this is not trivial. Yeah, that would be a big job, ------------- PR Comment: https://git.openjdk.org/jfx/pull/1518#issuecomment-2266078265 From kcr at openjdk.org Fri Aug 2 20:15:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 20:15:38 GMT Subject: RFR: 8337281: build.gradle assumes all modules are named "javafx.$project" [v2] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 23:00:33 GMT, Kevin Rushforth wrote: >> This PR fixes a bad assumption in a few places in `build.gradle`, which assumes that the module name can be derived from the name of the gradle project name by prepending `"javafx."` to the name rather than using the `moduleName` property of the project. In many of these places, the logic replaces dots with dashes in the name, but it does so by prefixing the project name with `"javafx-"` rather than doing a string replacement. This means that a module with more than one dot will only have the first one replaced. >> >> I discovered this while working on the following two RFEs, both of which hit this bug: >> >> [JDK-8309381](https://bugs.openjdk.org/browse/JDK-8309381): Support JavaFX incubator modules >> [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280): Include jdk.jsobject module with JavaFX >> >> Both of them need this bug to be fixed, so I am separating it out into its own issue. >> >> ### Notes to reviewers >> >> Most of the problematic logic is in the maven publication method, which is only enabled via `gradle -PMAVEN_PUBLISH=true` (in the absence of any other params, that won't actually try to publish anything, so is safe to use for testing). I left in some print statements for the purpose of testing, that I will remove with the next commit. >> >> I tested this with the following branch, which is a preliminary prototype of adding jdk.jsobject to the build with the fix from _this_ PR applied: [test-module-name-jsobject](https://github.com/kevinrushforth/jfx/tree/test-module-name-jsobject). > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug where String was being used as if it were a Project Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1518#issuecomment-2266078522 From kcr at openjdk.org Fri Aug 2 20:15:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 20:15:39 GMT Subject: RFR: 8337281: build.gradle assumes all modules are named "javafx.$project" [v2] In-Reply-To: <9u2HU2DxK7ZCQmm9RDI9l43nkRIQxZQ8ncXpfCWQCzA=.79c198ab-8588-4be8-8206-8293b0e5964b@github.com> References: <9u2HU2DxK7ZCQmm9RDI9l43nkRIQxZQ8ncXpfCWQCzA=.79c198ab-8588-4be8-8206-8293b0e5964b@github.com> Message-ID: On Mon, 29 Jul 2024 23:11:04 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bug where String was being used as if it were a Project > > build.gradle line 970: > >> 968: >> 969: if (HAS_JAVAFX_MODULES) { >> 970: List modsWithNative = [ 'javafx.graphics', 'javafx.media', 'javafx.web' ] > > very minor: maybe one entry per line? I'd prefer not to at this point. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1518#discussion_r1702279337 From kcr at openjdk.org Fri Aug 2 20:15:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 20:15:39 GMT Subject: Integrated: 8337281: build.gradle assumes all modules are named "javafx.$project" In-Reply-To: References: Message-ID: <5bu-XqMLuInu-43K81ffoGWHUD-DMmQPlRNZ8tF7aOY=.d09e07b7-1516-4c82-a635-c8cf31f90b3b@github.com> On Fri, 26 Jul 2024 17:04:17 GMT, Kevin Rushforth wrote: > This PR fixes a bad assumption in a few places in `build.gradle`, which assumes that the module name can be derived from the name of the gradle project name by prepending `"javafx."` to the name rather than using the `moduleName` property of the project. In many of these places, the logic replaces dots with dashes in the name, but it does so by prefixing the project name with `"javafx-"` rather than doing a string replacement. This means that a module with more than one dot will only have the first one replaced. > > I discovered this while working on the following two RFEs, both of which hit this bug: > > [JDK-8309381](https://bugs.openjdk.org/browse/JDK-8309381): Support JavaFX incubator modules > [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280): Include jdk.jsobject module with JavaFX > > Both of them need this bug to be fixed, so I am separating it out into its own issue. > > ### Notes to reviewers > > Most of the problematic logic is in the maven publication method, which is only enabled via `gradle -PMAVEN_PUBLISH=true` (in the absence of any other params, that won't actually try to publish anything, so is safe to use for testing). I left in some print statements for the purpose of testing, that I will remove with the next commit. > > I tested this with the following branch, which is a preliminary prototype of adding jdk.jsobject to the build with the fix from _this_ PR applied: [test-module-name-jsobject](https://github.com/kevinrushforth/jfx/tree/test-module-name-jsobject). This pull request has now been integrated. Changeset: 0fa50cbb Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0fa50cbbd9878ca7ec0e1bfcc5567bf52e3b8db2 Stats: 19 lines in 1 file changed: 13 ins; 0 del; 6 mod 8337281: build.gradle assumes all modules are named "javafx.$project" Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1518 From almatvee at openjdk.org Fri Aug 2 20:43:38 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 2 Aug 2024 20:43:38 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com> Message-ID: On Thu, 1 Aug 2024 23:56:57 GMT, Andy Goryachev wrote: > > I think this issue/PR should specify it. > > The main reason to mention what needs to be corrected is to help the person who will be working on JDK-8337686 many years from now ;-) Done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2266118943 From jhendrikx at openjdk.org Fri Aug 2 22:36:57 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Aug 2024 22:36:57 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Fri, 2 Aug 2024 21:30:49 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix since tag >> - adjust table styling > > modules/javafx.graphics/src/main/java/javafx/css/ComponentTransitionable.java line 35: > >> 33: * Identifies a class that supports component-wise CSS transitions. >> 34: *

>> 35: * Component-wise transitions offer more flexibility than {@link Interpolatable} transitions. > > Why is the name not `ComponentInterpolatable`? I see two uses of this interface, both in combination with `Interpolatable`. Should this just extend `Interpolatable`, or are there cases to be expected where this marker is present but `Interpolatable` is not? Also, have you considered adding a default method to `Interpolatable` to indicate it supports component wise interpolation? It looks modelled after `RandomAccess`, but the reasons for that being a marker interface are not similar to this situation (it is a marker interface so it can also mark the old collections, like `Vector`). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702341296 From jhendrikx at openjdk.org Fri Aug 2 22:36:57 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Aug 2024 22:36:57 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> On Fri, 2 Aug 2024 01:39:11 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - fix since tag > - adjust table styling I only managed to get partially through this, it's a lot of changes. Left some comments so far. modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 78: > 76: > 77: int index = 0; > 78: int numNonNullValues = 0; It seems to me, just one of these variables is sufficient. They both start at `0` and both are incremented at the same time. modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 81: > 79: > 80: @SuppressWarnings("unchecked") > 81: T[] newValues = (T[])new Object[list.size()]; With many `null`s this array may be too big. If that's intended, then ignore this comment. modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 123: > 121: if (elements[i] != null) { > 122: newValues[j++] = elements[i]; > 123: ++numNonNullValues; Both `j` and `numNonNullValues` are always the same. Could eliminate one. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/paint/PaintUtils.java line 102: > 100: source.getEndX(), source.getEndY(), > 101: source.isProportional(), > 102: source.getCycleMethod(), Should these be copied from the source? When the gradient is solid, they could be set to constants. modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 183: > 181: *

  • If the intermediate list is shallow-equal to the first list passed into the method (i.e. its > 182: * elements are references to the same objects), the existing list is returned. > 183: *
  • If a new list is returned, it is unmodifiable. Well, it's documented, but I'd rather see this return an unmodifiable list in all cases (and not one of the input lists if it was determined to be modifiable). Perhaps ensure this is compatible with `List.copyOf` so that copies are only made when needed. modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 197: > 195: if (secondList.isEmpty()) { > 196: return firstList.isEmpty() ? firstList : secondList; > 197: } This logic looks odd. If the second list is empty, we return the first list **if** it is empty (and so empty is returned), otherwise the second list (which is also empty). So, this is equivalent? Suggestion: if (secondList.isEmpty()) { return List.of(); // suggested here, as the two input lists are not guaranteed to be immutable } modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 230: > 228: * shallow-equal to the list that is passed into this method, i.e. its elements are references > 229: * to the same objects. The existing list is returned in this case. > 230: */ Was there a performance problem here? Allocating 8 locals should be equivalent to an array of 8 elements that never escapes (ie. JIT optimizes this). Then either JIT is smart enough to conditionally allocate a heap object and copy the array there, or you can help it by cloning that local array and letting only the clone escape. modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 311: > 309: } > 310: } > 311: } You could write this without nesting using `switch`: switch(listSize) { case 8: newArray[7] = item7; // fallthrough case 7: newArray[6] = item6; case 6: newArray[5] = item5; // etc } modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 330: > 328: > 329: if (secondArraySeries.length == 0) { > 330: return firstArraySeries.length == 0 ? firstArraySeries : secondArraySeries; Same comment as on the other function. I find it suspect. Is there code relying on a **specific** array being returned? If so then that probably should be documented. Otherwise just immediately return `secondArraySeries`? modules/javafx.graphics/src/main/java/javafx/css/ComponentTransitionable.java line 35: > 33: * Identifies a class that supports component-wise CSS transitions. > 34: *

    > 35: * Component-wise transitions offer more flexibility than {@link Interpolatable} transitions. Why is the name not `ComponentInterpolatable`? modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 268: > 266: * @since 24 > 267: */ > 268: public Map, Object> convertBack(T value) { I know the name `convert` wasn't all that great (it probably should have been `construct`, `parse` or `deserialize`), but I think `convertBack` is not that great either. Have you considered `toMetaData`, `revert`, `serialize` or `deconstruct`? modules/javafx.graphics/src/main/java/javafx/geometry/Insets.java line 117: > 115: * > 116: * @throws NullPointerException {@inheritDoc} > 117: * @since 23 Should this be `24`? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9020: > 9018: if (timer != null) { > 9019: if (result == null) { > 9020: result = new HashMap<>(5); I think that when you specify map sizes like this, it might be worth a comment at the intent. Did you intend to create a map that can hold 6 items before resizing? (5 becomes 8, which is sufficient for 6 mappings with a 75% load factor). If you want to express the intent more clearly, use `HashMap.newHashMap(5)`. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9106: > 9104: > 9105: // Make a copy of the list, because completing the timers causes them to be removed > 9106: // from the list, which would result in a ConcurrentModificationException. Comment is out of date modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9107: > 9105: // Make a copy of the list, because completing the timers causes them to be removed > 9106: // from the list, which would result in a ConcurrentModificationException. > 9107: for (TransitionTimer timer : Map.copyOf(transitionTimers).values()) { If you only need a copy of the values, copying the whole map is a bit overkill. How about `List.copyOf(transitionTimers.values())` ? Lists are also much faster than maps for this purpose. ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2215813399 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701977895 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701979810 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701980936 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701997212 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702322235 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702318609 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702330147 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702331405 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702333480 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702335141 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702351819 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702368300 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702373249 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702373633 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702374898 From mstrauss at openjdk.org Fri Aug 2 23:50:12 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Aug 2024 23:50:12 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v6] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/3b8fa919..10705a32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=04-05 Stats: 12 lines in 3 files changed: 0 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sat Aug 3 00:17:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Aug 2024 00:17:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Fri, 2 Aug 2024 21:38:04 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/ComponentTransitionable.java line 35: >> >>> 33: * Identifies a class that supports component-wise CSS transitions. >>> 34: *

    >>> 35: * Component-wise transitions offer more flexibility than {@link Interpolatable} transitions. >> >> Why is the name not `ComponentInterpolatable`? > > I see two uses of this interface, both in combination with `Interpolatable`. Should this just extend `Interpolatable`, or are there cases to be expected where this marker is present but `Interpolatable` is not? > > Also, have you considered adding a default method to `Interpolatable` to indicate it supports component wise interpolation? > > It looks modelled after `RandomAccess`, but the reasons for that being a marker interface are not similar to this situation (it is a marker interface so it can also mark the old collections, like `Vector`). `ComponentTransitionable` is kind of orthogonal to `Interpolatable`. It tells us to first decompose the object, and then transition each component separately. `Border` and `Background` implement both interfaces, but `Interpolatable` is not used for CSS transitions (i.e. `Border.interpolate()` is not called). It doesn't make much sense to add a default method to `Interpolatable` to indicate component-wise transitions, because we can't use the `interpolate()` method for component-wise transitions. This should be thought of as two paths: we either use `Interpolatable`, or we use the decompose-reconstruct route (which is only available to CSS, but not programmatically). Now, the name might also be `ComponentInterpolatable`, but this suggests a close proximity to `Interpolatable` (being in the `javafx.animation` package, having a programmatic API, etc). However, `ComponentTransitionable` only works for objects that expose their components to CSS (which is why it is located in `javafx.css` and not `javafx.animation`). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415097 From mstrauss at openjdk.org Sat Aug 3 00:17:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Aug 2024 00:17:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Fri, 2 Aug 2024 15:06:29 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix since tag >> - adjust table styling > > modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 78: > >> 76: >> 77: int index = 0; >> 78: int numNonNullValues = 0; > > It seems to me, just one of these variables is sufficient. They both start at `0` and both are incremented at the same time. Yes, I've removed one of the variables. > modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 81: > >> 79: >> 80: @SuppressWarnings("unchecked") >> 81: T[] newValues = (T[])new Object[list.size()]; > > With many `null`s this array may be too big. If that's intended, then ignore this comment. That may be the case, but I think that's preferrable to requiring two iterations of the list (one to figure out how many non-null values it contains, the second to copy over the values). In practice, there shouldn't be any nulls in most cases, as I don't know why someone would construct a `Background` or `Border` with many nulls in there. > modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 123: > >> 121: if (elements[i] != null) { >> 122: newValues[j++] = elements[i]; >> 123: ++numNonNullValues; > > Both `j` and `numNonNullValues` are always the same. Could eliminate one. You're right. > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/paint/PaintUtils.java line 102: > >> 100: source.getEndX(), source.getEndY(), >> 101: source.isProportional(), >> 102: source.getCycleMethod(), > > Should these be copied from the source? When the gradient is solid, they could be set to constants. We can't interpolate between relative and absolute gradients (the interpolate method lacks the context necessary to convert between the two), so we need to copy these from source instead of always choosing one or the other. > modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 183: > >> 181: *

  • If the intermediate list is shallow-equal to the first list passed into the method (i.e. its >> 182: * elements are references to the same objects), the existing list is returned. >> 183: *
  • If a new list is returned, it is unmodifiable. > > Well, it's documented, but I'd rather see this return an unmodifiable list in all cases (and not one of the input lists if it was determined to be modifiable). Perhaps ensure this is compatible with `List.copyOf` so that copies are only made when needed. In practice, any list that is passed into this method is already unmodifiable. This isn't a general-purpose method, it's tailored towards its usage for `Border` and `Background` interpolation, and the optimization scheme that is used in these classes. > modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 197: > >> 195: if (secondList.isEmpty()) { >> 196: return firstList.isEmpty() ? firstList : secondList; >> 197: } > > This logic looks odd. If the second list is empty, we return the first list **if** it is empty (and so empty is returned), otherwise the second list (which is also empty). So, this is equivalent? > Suggestion: > > if (secondList.isEmpty()) { > return List.of(); // suggested here, as the two input lists are not guaranteed to be immutable > } The point of this excercise is to preferrably return existing instances, even when they are empty. `Border` and `Background` can contain quite a lot of objects, and often only one component is changed in a transition, while all of the rest is left unchanged. We want to elide the allocation of new objects if possible during transitions, which is why most classes check whether the result of an interpolation happens to be the same instance as either the start value or the end value. > modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 268: > >> 266: * @since 24 >> 267: */ >> 268: public Map, Object> convertBack(T value) { > > I know the name `convert` wasn't all that great (it probably should have been `construct`, `parse` or `deserialize`), but I think `convertBack` is not that great either. Have you considered `toMetaData`, `revert`, `serialize` or `deconstruct`? I considered `deconstruct` and `decompose`, but I wanted to stress that it's the inverse of `convert`. > modules/javafx.graphics/src/main/java/javafx/geometry/Insets.java line 117: > >> 115: * >> 116: * @throws NullPointerException {@inheritDoc} >> 117: * @since 23 > > Should this be `24`? Yes. > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9107: > >> 9105: // Make a copy of the list, because completing the timers causes them to be removed >> 9106: // from the list, which would result in a ConcurrentModificationException. >> 9107: for (TransitionTimer timer : Map.copyOf(transitionTimers).values()) { > > If you only need a copy of the values, copying the whole map is a bit overkill. How about `List.copyOf(transitionTimers.values())` ? Lists are also much faster than maps for this purpose. Good idea. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415018 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415036 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415039 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415068 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415084 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415079 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415105 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415114 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415138 From kizune at openjdk.org Sat Aug 3 00:26:36 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Sat, 3 Aug 2024 00:26:36 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: <1P12hjtrcnoWBrPFdRhiSHXWYOju06wOBrZQqwJv_Ls=.0dfb0f2e-a804-4678-9061-065a66b4bd62@github.com> On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev wrote: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/CellArrangement.java line 263: > 261: */ > 262: private int binarySearch(double localY, int low, int high) { > 263: //System.err.println(" binarySearch off=" + off + ", high=" + high + ", low=" + low); // FIX Looks like remnants of the debugging session. Do you still need it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1702417057 From mstrauss at openjdk.org Sat Aug 3 00:42:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Aug 2024 00:42:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v7] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: use switch instead of nested if ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/10705a32..3d12f772 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=05-06 Stats: 63 lines in 1 file changed: 0 ins; 35 del; 28 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sat Aug 3 00:50:52 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Aug 2024 00:50:52 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v8] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: use switch instead of nested if ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/3d12f772..6667dd55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=06-07 Stats: 64 lines in 1 file changed: 0 ins; 35 del; 29 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sat Aug 3 00:56:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Aug 2024 00:56:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v9] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/6667dd55..14e91f14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sat Aug 3 10:06:38 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Aug 2024 10:06:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Fri, 2 Aug 2024 21:22:09 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix since tag >> - adjust table styling > > modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 230: > >> 228: * shallow-equal to the list that is passed into this method, i.e. its elements are references >> 229: * to the same objects. The existing list is returned in this case. >> 230: */ > > Was there a performance problem here? > > Allocating 8 locals should be equivalent to an array of 8 elements that never escapes (ie. JIT optimizes this). Then either JIT is smart enough to conditionally allocate a heap object and copy the array there, or you can help it by cloning that local array and letting only the clone escape. There's no performance problem in the sense that my test application runs slowly in any noticeble way. It's one more piece of trying to minimize the allocation of objects in the very common case where nothing has changed. Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior? With your other suggestion of using `switch`, the code looks much cleaner already. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702668699 From jhendrikx at openjdk.org Sat Aug 3 10:10:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Aug 2024 10:10:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 00:14:20 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 197: >> >>> 195: if (secondList.isEmpty()) { >>> 196: return firstList.isEmpty() ? firstList : secondList; >>> 197: } >> >> This logic looks odd. If the second list is empty, we return the first list **if** it is empty (and so empty is returned), otherwise the second list (which is also empty). So, this is equivalent? >> Suggestion: >> >> if (secondList.isEmpty()) { >> return List.of(); // suggested here, as the two input lists are not guaranteed to be immutable >> } > > The point of this excercise is to preferrably return existing instances, even when they are empty. `Border` and `Background` can contain quite a lot of objects, and often only one component is changed in a transition, while all of the rest is left unchanged. We want to elide the allocation of new objects if possible during transitions, which is why most classes check whether the result of an interpolation happens to be the same instance as either the start value or the end value. But you are checking this with `equals` I hope? `List.of()` is a constant, it doesn't allocate anything. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702670114 From mstrauss at openjdk.org Sat Aug 3 10:10:41 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Aug 2024 10:10:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Fri, 2 Aug 2024 22:30:25 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix since tag >> - adjust table styling > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9020: > >> 9018: if (timer != null) { >> 9019: if (result == null) { >> 9020: result = new HashMap<>(5); > > I think that when you specify map sizes like this, it might be worth a comment at the intent. Did you intend to create a map that can hold 6 items before resizing? (5 becomes 8, which is sufficient for 6 mappings with a 75% load factor). If you want to express the intent more clearly, use `HashMap.newHashMap(5)`. I feel that the default initial capacity of 16 is more than can be reasonably expected for transitions. However, I did not use any rigorous methodology to come up with the number 5. I can add a comment, though. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702670457 From jhendrikx at openjdk.org Sat Aug 3 11:49:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Aug 2024 11:49:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 10:04:00 GMT, Michael Strau? wrote: > Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior? If the code leads to less questions and is more readable for it, and there is no reason to optimize in the first place (ie. you didn't see a problem), then yes, definitely. Premature optimization only leads to questions by reviewers and future maintainers (they will wonder why the code was optimized, but probably assume there was a good reason for it). Optimized code is harder to reason about and harder to refactor. For example, reading your code I've been left wondering: - Why is it significant to return a specific instance? Are you using `==` to compare these in callers? That's very counter to the nature of Java, and so deserves at a minimum a justification ("performance") and a warning ("careful, callers use `==`") - The extra code paths for `RandomAccess` or not, in an attempt to avoid an iterator allocation (which may not even happen when inlined). Is this even happening in practice (are there any non-`RandomAccesss` lists used?) Is the performance gain worth the extra complexity? Is it worth not having these functions inline into callers, as larger functions mean JIT won't inline them? - Avoiding allocating small arrays; was this a performance problem that would justify writing a function that is now too large to inline? You're trading potential JIT inlining for an almost free heap allocation (Java allocation's are the equivalent of a pointer increment + background GC activity on likely **idling** CPU cores). Would it not have been much better to write the code as simple as possible first, get it passed review well understood by everyone, then maybe, possibly get back to it later with an optimizing PR if there is a performance problem? That last bit is entirely optional and may never happen if it turns out these few transition allocations are but a drop in the bucket of the overall CSS performance. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702717395 From mhanl at openjdk.org Sat Aug 3 13:53:36 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 3 Aug 2024 13:53:36 GMT Subject: RFR: 8320232: Cells duplicated when table collapsed and expanded In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 18:45:23 GMT, Marius Hanl wrote: > This PR fixes a bug where a `TableView` inside a `TitledPane` may 'duplicate' the cells. This actually has nothing to do with the `TitledPane`, but it triggered the bug easily due to its nature to change the size of his content when collapsing. > > The expansion change of a `TitledPane` triggered an event where the underlying `VirtualFlow` was adding cells to the pile (for reuse) and later cleaning them all up without resetting the index to -1. > This led to a bug where two cells had the same index and therefore received an edit event, although just one should (and is visible, the other cell has no parent -> orphan node). > > The fix is to always reset the index to -1. This was already done before, just not everywhere, for all cells. > So before we clear the pile (or cells), we always reset the index to -1. > Added a bunch of tests, some pass before and after. I agree the minor change is unrelated, but since it is that small for a test I had written in the past, I decided to keep it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1521#issuecomment-2266718230 From mhanl at openjdk.org Sat Aug 3 13:53:36 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 3 Aug 2024 13:53:36 GMT Subject: Integrated: 8320232: Cells duplicated when table collapsed and expanded In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 18:45:23 GMT, Marius Hanl wrote: > This PR fixes a bug where a `TableView` inside a `TitledPane` may 'duplicate' the cells. This actually has nothing to do with the `TitledPane`, but it triggered the bug easily due to its nature to change the size of his content when collapsing. > > The expansion change of a `TitledPane` triggered an event where the underlying `VirtualFlow` was adding cells to the pile (for reuse) and later cleaning them all up without resetting the index to -1. > This led to a bug where two cells had the same index and therefore received an edit event, although just one should (and is visible, the other cell has no parent -> orphan node). > > The fix is to always reset the index to -1. This was already done before, just not everywhere, for all cells. > So before we clear the pile (or cells), we always reset the index to -1. > Added a bunch of tests, some pass before and after. This pull request has now been integrated. Changeset: 28e3ccc7 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/28e3ccc7331952b4d323941c8efc97509348b1e2 Stats: 184 lines in 4 files changed: 177 ins; 0 del; 7 mod 8320232: Cells duplicated when table collapsed and expanded Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1521 From jhendrikx at openjdk.org Sat Aug 3 14:11:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Aug 2024 14:11:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 11:43:12 GMT, John Hendrikx wrote: >> There's no performance problem in the sense that my test application runs slowly in any noticeble way. It's one more piece of trying to minimize the allocation of objects in the very common case where nothing has changed. >> >> Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior? With your other suggestion of using `switch`, the code looks much cleaner already. > >> Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior? > > If the code leads to less questions and is more readable for it, and there is no reason to optimize in the first place (ie. you didn't see a problem), then yes, definitely. > > Premature optimization only leads to questions by reviewers and future maintainers (they will wonder why the code was optimized, but probably assume there was a good reason for it). Optimized code is harder to reason about and harder to refactor. For example, reading your code I've been left wondering: > > - Why is it significant to return a specific instance? Are you using `==` to compare these in callers? That's very counter to the nature of Java, and so deserves at a minimum a justification ("performance") and a warning ("careful, callers use `==`") > - The extra code paths for `RandomAccess` or not, in an attempt to avoid an iterator allocation (which may not even happen when inlined). Is this even happening in practice (are there any non-`RandomAccesss` lists used?) Is the performance gain worth the extra complexity? Is it worth not having these functions inline into callers, as larger functions mean JIT won't inline them? > - Avoiding allocating small arrays; was this a performance problem that would justify writing a function that is now too large to inline? You're trading potential JIT inlining for an almost free heap allocation (Java allocation's are the equivalent of a pointer increment + background GC activity on likely **idling** CPU cores). > > Would it not have been much better to write the code as simple as possible first, get it passed review well understood by everyone, then maybe, possibly get back to it later with an optimizing PR if there is a performance problem? That last bit is entirely optional and may never happen if it turns out these few transition allocations are but a drop in the bucket of the overall CSS performance. Sorry if this came across as a bit negative, it's not intended in that way. I just think optimizing too early has far more drawbacks than it has benefits. In part this is also a reflection on a lot of FX code; some code is clearly optimized from a C/C++ developer perspective which not only translates poorly to Java, but also makes the code "too dangerous" to modify. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702784473 From jhendrikx at openjdk.org Sat Aug 3 14:23:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Aug 2024 14:23:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <_VXULhjdYS0V_KY3m0CHZrfVAevz1mkKmpniLOSxUfA=.a9670e8c-1297-4e43-a0c3-bcb12ae077b7@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> <_VXULhjdYS0V_KY3m0CHZrfVAevz1mkKmpniLOSxUfA=.a9670e8c-1297-4e43-a0c3-bcb12ae077b7@github.com> Message-ID: On Fri, 2 Aug 2024 01:32:09 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 331: >> >>> 329: >>> 330: for (int i = 0, max = strokes.size(); i < max; i++) { >>> 331: final BorderStroke stroke = strokes.get(i); >> >> just curious: do we really need `final` keyword for local variables after java8? > > I don't use it, but I didn't change the existing code here. > just curious: do we really need `final` keyword for local variables after java8? It's superfluous, and only useful if you are not initializing it immediately and you still want to force a single assignment. If you always immediately initialize locals (either using a method call or through a ternary (`?:`)) then the `final` keyword is definitely just noise. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702788647 From jhendrikx at openjdk.org Sat Aug 3 14:48:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Aug 2024 14:48:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 00:14:28 GMT, Michael Strau? wrote: >> I see two uses of this interface, both in combination with `Interpolatable`. Should this just extend `Interpolatable`, or are there cases to be expected where this marker is present but `Interpolatable` is not? >> >> Also, have you considered adding a default method to `Interpolatable` to indicate it supports component wise interpolation? >> >> It looks modelled after `RandomAccess`, but the reasons for that being a marker interface are not similar to this situation (it is a marker interface so it can also mark the old collections, like `Vector`). > > `ComponentTransitionable` is kind of orthogonal to `Interpolatable`. It tells us to first decompose the object, and then transition each component separately. `Border` and `Background` implement both interfaces, but `Interpolatable` is not used for CSS transitions (i.e. `Border.interpolate()` is not called). > > It doesn't make much sense to add a default method to `Interpolatable` to indicate component-wise transitions, because we can't use the `interpolate()` method for component-wise transitions. > > This should be thought of as two paths: we either use `Interpolatable`, or we use the decompose-reconstruct route (which is only available to CSS, but not programmatically). > > Now, the name might also be `ComponentInterpolatable`, but this suggests a close proximity to `Interpolatable` (being in the `javafx.animation` package, having a programmatic API, etc). However, `ComponentTransitionable` only works for objects that expose their components to CSS (which is why it is located in `javafx.css` and not `javafx.animation`). I've taken a closer look, and I have the feeling that `ComponentTransitionable` is more of an indicator that the corresponding `StyleConverter` has implemented `convertBack`. I think noting this information closer to the source would therefore be a good idea. >From what I can see, `applyComponentTransition` already falls back to calling `set(T)` if there is anything out of the ordinary (like missing CSS meta data or a missing StyleConverter). For both interpolation cases (`Interpotable` and `ComponentTransitionable`) you are getting the CSS meta data. You can externalize that part. When you have the meta data, you can get the `StyleConverter` and check if it supports deconstruction (instead of having a marker on the final result). You can either: - put the marker on `StyleConverter` - have `convertBack` return an `Optional` or `null` if unsupported (there are already several `null` checks for missing CSS meta data or the missing converter, one more here seems not unreasonable). - have a method on `StyleConverter` that indicates its capabilities (true/false, `SUPPORTS_DECONSTRUCTION`, etc..) The advantage of this IMHO is that it keeps CSS concerns (component transitionable) in the CSS realm (with StyleConverter), while leaving simple classes that are just value holders (Border, Background) untouched. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702797888 From kcr at openjdk.org Sat Aug 3 16:10:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 3 Aug 2024 16:10:38 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 19:51:09 GMT, Martin Fox wrote: >> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). >> >> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. >> >> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. >> >> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. >> >> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback: floating point precision in test, ensure unsigned int handling in Robot The code changes all look good. Everything looks good on macOS. I finished all my testing, including testing with the metal pipeline. The only thing needed is a timeout value on one of the tests to avoid hanging on Linux when running with a Wayland display server. I'll approve once you make that change. tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 218: > 216: // colors but they might both be working in the wrong space. We use an > 217: // AWT Robot to verify that they are working in sRGB. > 218: @Test This test needs a timeout value to avoid hanging the test job on Linux with Wayland. See [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). I recommend: @Test(timeout = 15000) ------------- PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2217065570 PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1702793337 From mfox at openjdk.org Sat Aug 3 16:30:08 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 3 Aug 2024 16:30:08 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v6] In-Reply-To: References: Message-ID: > When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). > > In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. > > Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. > > I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. > > I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Added timeout to test due to potential hang when using XWayland ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1473/files - new: https://git.openjdk.org/jfx/pull/1473/files/2dad883c..92b9c562 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1473.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1473/head:pull/1473 PR: https://git.openjdk.org/jfx/pull/1473 From kcr at openjdk.org Sat Aug 3 16:35:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 3 Aug 2024 16:35:37 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v6] In-Reply-To: References: Message-ID: On Sat, 3 Aug 2024 16:30:08 GMT, Martin Fox wrote: >> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). >> >> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. >> >> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. >> >> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. >> >> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Added timeout to test due to potential hang when using XWayland Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2217103583 From philip.race at oracle.com Sat Aug 3 21:41:44 2024 From: philip.race at oracle.com (Philip Race) Date: Sat, 3 Aug 2024 14:41:44 -0700 Subject: Font hinting on Linux In-Reply-To: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com> References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com> Message-ID: <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com> There's not many knobs available. Hinting is not enabled - and that's commonly the case on modern plartforms. LCD is your best option for readibility of static text, which is why it is the default for UI Controls, It should reduce the pixel grid fitting uneveness you highlight but doesn't eliminate it. Note : this presumes that the freetype on your system enables LCD .. if it doesn't there's nothing FX can do about that. -phil. On 8/2/24 10:43 AM, quizynox at gmail.com wrote: > Hello, > > Sorry for asking here, but I seem to have tried everything I could > find on SO/Reddit/JBS etc. Could someone please share what font > settings I should be using to get decent font hinting on Linux? Please > see the screenshot. > > https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view > > I'm not very picky, but the font I see is just not suitable for > presenting app to customers. I've tried enabling and disabling hinting > and autohinting, using different hinting styles, changing the font > smoothing type and prism.lcdtext etc. Unfortunately no matter what I > do, the font hinting is always bad. > > Fedora, KDE, all latest versions. > From mstrauss at openjdk.org Sun Aug 4 14:25:22 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 14:25:22 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v10] In-Reply-To: References: Message-ID: <5Y2cOCDIkHehbJwQY37ZrNosMUeNzKNVz9EQpkj-vj4=.5f041280-38cb-468b-8007-031f5ac7b114@github.com> > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: move interpolation helpers to separate file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/14e91f14..4257d2f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=08-09 Stats: 891 lines in 21 files changed: 415 ins; 408 del; 68 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sun Aug 4 14:33:18 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 14:33:18 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v11] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/4257d2f6..843713bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=09-10 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sun Aug 4 14:54:36 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 14:54:36 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com> On Sat, 3 Aug 2024 14:09:19 GMT, John Hendrikx wrote: >>> Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior? >> >> If the code leads to less questions and is more readable for it, and there is no reason to optimize in the first place (ie. you didn't see a problem), then yes, definitely. >> >> Premature optimization only leads to questions by reviewers and future maintainers (they will wonder why the code was optimized, but probably assume there was a good reason for it). Optimized code is harder to reason about and harder to refactor. For example, reading your code I've been left wondering: >> >> - Why is it significant to return a specific instance? Are you using `==` to compare these in callers? That's very counter to the nature of Java, and so deserves at a minimum a justification ("performance") and a warning ("careful, callers use `==`") >> - The extra code paths for `RandomAccess` or not, in an attempt to avoid an iterator allocation (which may not even happen when inlined). Is this even happening in practice (are there any non-`RandomAccesss` lists used?) Is the performance gain worth the extra complexity? Is it worth not having these functions inline into callers, as larger functions mean JIT won't inline them? >> - Avoiding allocating small arrays; was this a performance problem that would justify writing a function that is now too large to inline? You're trading potential JIT inlining for an almost free heap allocation (Java allocation's are the equivalent of a pointer increment + background GC activity on likely **idling** CPU cores). >> >> Would it not have been much better to write the code as simple as possible first, get it passed review well understood by everyone, then maybe, possibly get back to it later with an optimizing PR if there is a performance problem? That last bit is entirely optional and may never happen if it turns out these few transition allocations are but a drop in the bucket of the overall CSS performance. > > Sorry if this came across as a bit negative, it's not intended in that way. I just think optimizing too early has far more drawbacks than it has benefits. In part this is also a reflection on a lot of FX code; some code is clearly optimized from a C/C++ developer perspective which not only translates poorly to Java, but also makes the code "too dangerous" to modify. I don't understand this argument at all. Why would it be reasonable to _only_ build a more efficient architecture _if_ there's such a huge problem with the "naive" alternative that this alone would be readily apparent? If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance. Here's the thing: this code could reasonably be executed tens of thousands of times per second. Think of a complex user interface that changes its visual state for many nodes at once. What you seem to perceive as a micro-optimization is actually a part of an architecture that involves many types in the `Background` and `Border` area. The basic idea is: if I can rely on `interpolate()` returning existing instances (either the start value or the end value) if nothing has changed, then the "parent object's" interpolate method can use an identity comparison (which is basically for free) to choose whether to return itself (or the end value), or return a new instance. Let's look at the `Border.interpolate()` implementation: @Override public Border interpolate(Border endValue, double t) { Objects.requireNonNull(endValue, "endValue cannot be null"); if (t <= 0) return this; if (t >= 1) return endValue; // interpolateListsPairwise() is implemented such that it returns existing list instances // (i.e. the 'this.images' or 'endValue.images' arguments) as an indication that the result // is shallow-equal to either of the input arguments. This allows us to very quickly detect // if we can return 'this' or 'endValue' without allocating a new Border instance. List newImages = images == endValue.images ? images : InterpolationUtils.interpolateListsPairwise(images, endValue.images, t); List newStrokes = strokes == endValue.strokes ? strokes : InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t); if (images == newImages && strokes == newStrokes) { return this; } if (endValue.images == newImages && endValue.strokes == newStrokes) { return endValue; } return new Border(newStrokes, newImages); } `interpolateListsPairwise()` _already knows_ whether both lists are equal, which makes the `return this` and `return endValue` branches after the interpolation basically free. The alternative to this would be to either pointlessly call `equals()` on a large object graph again and again, or to always return a new `Border` instance. This optimization scheme works precisely because all types that are involved make sure to return existing instances when the result is known to be interchangable with an existing instance. This is also the reason why your other suggestion of returning `List.of()` instead of an existing empty list wouldn't work. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703242183 From mstrauss at openjdk.org Sun Aug 4 15:09:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 15:09:16 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v12] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: move tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/843713bf..0def5d1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=10-11 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sun Aug 4 15:35:13 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 15:35:13 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v13] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: remove ComponentTransitionable ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/0def5d1a..34372675 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=11-12 Stats: 87 lines in 8 files changed: 11 ins; 59 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sun Aug 4 15:35:13 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 15:35:13 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 14:45:50 GMT, John Hendrikx wrote: >> `ComponentTransitionable` is kind of orthogonal to `Interpolatable`. It tells us to first decompose the object, and then transition each component separately. `Border` and `Background` implement both interfaces, but `Interpolatable` is not used for CSS transitions (i.e. `Border.interpolate()` is not called). >> >> It doesn't make much sense to add a default method to `Interpolatable` to indicate component-wise transitions, because we can't use the `interpolate()` method for component-wise transitions. >> >> This should be thought of as two paths: we either use `Interpolatable`, or we use the decompose-reconstruct route (which is only available to CSS, but not programmatically). >> >> Now, the name might also be `ComponentInterpolatable`, but this suggests a close proximity to `Interpolatable` (being in the `javafx.animation` package, having a programmatic API, etc). However, `ComponentTransitionable` only works for objects that expose their components to CSS (which is why it is located in `javafx.css` and not `javafx.animation`). > > I've taken a closer look, and I have the feeling that `ComponentTransitionable` is more of an indicator that the corresponding `StyleConverter` has implemented `convertBack`. I think noting this information closer to the source would therefore be a good idea. > > From what I can see, `applyComponentTransition` already falls back to calling `set(T)` if there is anything out of the ordinary (like missing CSS meta data or a missing StyleConverter). > > For both interpolation cases (`Interpolatable` and `ComponentTransitionable`) you are getting the CSS meta data. You can externalize that part. When you have the meta data, you can get the `StyleConverter` and check if it supports deconstruction (instead of having a marker on the final result). You can either: > > - put the marker on `StyleConverter` > - have `convertBack` return an `Optional` or `null` if unsupported (there are already several `null` checks for missing CSS meta data or the missing converter, one more here seems not unreasonable). > - have a method on `StyleConverter` that indicates its capabilities (true/false, `SUPPORTS_DECONSTRUCTION`, etc..) > > The advantage of this IMHO is that it keeps CSS concerns (component transitionable) in the CSS realm (with StyleConverter), while leaving simple classes that are just value holders (Border, Background) untouched. I don't quite like returning any particular value from `convertBack` as a signal for "this style converter doesn't support deconstruction", so I've made it more explicit with the marker interface `StyleConverter.SupportsDeconstruction`. This removes the marker interface `ComponentTransitionable` entirely. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703262056 From mstrauss at openjdk.org Sun Aug 4 16:03:52 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 16:03:52 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v14] In-Reply-To: References: Message-ID: <5jZChobMyF-s5WEUnhFtOdmC36ng_JzZN84eAmTLeMY=.9ea6ae36-686c-4c3c-8c6d-470246b2aa44@github.com> > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/34372675..b545617f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=12-13 Stats: 110 lines in 1 file changed: 89 ins; 1 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sun Aug 4 18:58:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 18:58:14 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v15] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add test for stop lists ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/b545617f..a2d0d6c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=13-14 Stats: 28 lines in 2 files changed: 21 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sun Aug 4 18:58:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 18:58:14 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: <2ZHL3FmFygI4CKpYQFzNXIVubhO7ERuGJw5FyXvoHws=.524505a5-b580-4ef3-93a5-ea4981b2f0ca@github.com> On Fri, 2 Aug 2024 16:02:43 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix since tag >> - adjust table styling > > modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopListTest.java line 264: > >> 262: new Stop(1, color2)), >> 263: res); >> 264: } > > Do you think any other combinations should be added, for completeness sake? > > For example, let's consider two lists with 2 points each. We might want to test scenarios: > > > -- > -- > > --| > |-- > > --- > --- > > ----| > ---| > > ------ > -- > > |----- > |-- > > |---| > |---| > > |-- > --| > > --- > -- > > > and also have the two lists swapped maybe? > > what do you think? I've added another test, which gives us 100% coverage for all code paths. I would consider this complete. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703348960 From mstrauss at openjdk.org Sun Aug 4 19:08:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 19:08:14 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v16] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: use HashMap.newHashMap() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/a2d0d6c1..d7f21872 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=14-15 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sun Aug 4 19:08:15 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 19:08:15 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 10:08:14 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9020: >> >>> 9018: if (timer != null) { >>> 9019: if (result == null) { >>> 9020: result = new HashMap<>(5); >> >> I think that when you specify map sizes like this, it might be worth a comment at the intent. Did you intend to create a map that can hold 6 items before resizing? (5 becomes 8, which is sufficient for 6 mappings with a 75% load factor). If you want to express the intent more clearly, use `HashMap.newHashMap(5)`. > > I feel that the default initial capacity of 16 is more than can be reasonably expected for transitions. However, I did not use any rigorous methodology to come up with the number 5. I can add a comment, though. I've added a comment and switched to `HashMap.newHashMap` as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703353352 From swong at fcsllc.us Sun Aug 4 20:37:24 2024 From: swong at fcsllc.us (Shing Wong) Date: Sun, 4 Aug 2024 15:37:24 -0500 Subject: javafx.com is down. Can't find fxml schema. Message-ID: Hi, Before I posted this message, I already searched the list and Google. I didn't find anything about javafx.com being down. As a result, my old fxml code with xmlns pointed to javafx.com/fxml are having problems. Does anybody know what the deal is with javafx.com being down, and where can I find a copy of the schema for fxml? -- Shing Wong TEL: (504)913-6502 From jhendrikx at openjdk.org Sun Aug 4 22:54:36 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 4 Aug 2024 22:54:36 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com> References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com> Message-ID: On Sun, 4 Aug 2024 14:51:47 GMT, Michael Strau? wrote: >> Sorry if this came across as a bit negative, it's not intended in that way. I just think optimizing too early has far more drawbacks than it has benefits. In part this is also a reflection on a lot of FX code; some code is clearly optimized from a C/C++ developer perspective which not only translates poorly to Java, but also makes the code "too dangerous" to modify. > > I don't understand this argument at all. Why would it be reasonable to _only_ build a more efficient architecture _if_ there's such a huge problem with the "naive" alternative that this alone would be readily apparent? If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance. > > Here's the thing: this code could reasonably be executed tens of thousands of times per second. Think of a complex user interface that changes its visual state for many nodes at once. What you seem to perceive as a micro-optimization is actually a part of an architecture that involves many types in the `Background` and `Border` area. > > The basic idea is: if I can rely on `interpolate()` returning existing instances (either the start value or the end value) if nothing has changed, then the "parent object's" interpolate method can use an identity comparison (which is basically for free) to choose whether to return itself (or the end value), or return a new instance. > > Let's look at the `Border.interpolate()` implementation: > > @Override > public Border interpolate(Border endValue, double t) { > Objects.requireNonNull(endValue, "endValue cannot be null"); > if (t <= 0) return this; > if (t >= 1) return endValue; > > // interpolateListsPairwise() is implemented such that it returns existing list instances > // (i.e. the 'this.images' or 'endValue.images' arguments) as an indication that the result > // is shallow-equal to either of the input arguments. This allows us to very quickly detect > // if we can return 'this' or 'endValue' without allocating a new Border instance. > List newImages = images == endValue.images ? > images : InterpolationUtils.interpolateListsPairwise(images, endValue.images, t); > > List newStrokes = strokes == endValue.strokes ? > strokes : InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t); > > if (images == newImages && strokes == newStrokes) { > return this; > } > > if (endValue.images == newImages && endValue.strokes == newStrokes) { > return endValue; > } > > return new Border(newStrokes, newImages); > } > > > `interpolateListsPairwise()` _already knows_ whether both lists are equal, which makes the `return this` and `return endValue` branches after the interpolation basically free. The alternative to this would be to either pointle... I think you said that you didn't actually test this, so we don't know if this will perform better. It's based on an assumption of what Java will do, and on assumptions what is "bad" and what is "good". Without having tested this, you are optimizing blind. I would be entirely satisfied if you had said "I tested this with a few thousand transitions, the allocation turned out to be a hot spot, so I optimized it which is the reason this code looks a bit out of the ordinary". I also would have liked a comment explaining any pitfalls introduced by the optimization; the use of `==` by callers is unusual, and a crucial piece of information when I see code like: if (secondList.isEmpty()) { return firstList.isEmpty() ? firstList : secondList; } It would deserve at least an explanation that you're specifically returning one of the passed in arguments so callers can do reference equality checks. So you may have been wasting your time, and perhaps future maintainer time as well, making code less flexible, and harder to understand, maybe containing new bugs and edge cases for no real reason. Java's JIT is very finicky. For example, an earlier comment asked if the first `if` case is the most common one. The assumption being that this will improve performance. However, you can't make that assumption at all (I've done tests that show it's almost impossible to predict which "if order" will be faster on the JVM); re-arranging a function or "unrolling" it can have large negative consequences if that means the JIT will no longer inline your function. Now, I will give you that this **probably** will be faster, but I'm making an assumption here... I really can't be sure. That still leaves some explanatory comments that I think you should add with the assumptions that were made for this optimization. > If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance. No, when hunting for performance problems, it will be readily apparent what total process is taking up all the time, and how often parts of it are being called and how much time they take in total. Put a profiler on it, and see where the actual time is being spent on a case with a lot of transitions if you want to optimize it. What optimization generally does is it that it makes code harder to understand (almost unavoidable when optimizing), the code will make more assumptions (which is where performance is gained), and will often require more debugging time and dealing with edge cases (more complex code has more bugs and edge cases, requiring more tests). When applied randomly to a code base (ie. without profiling) it only makes things harder for no tangible benefits, and closes off easy improvements later (undoing optimizations for a better alternative has been the topic of several of my PR's). So if you're going to make something more complicated, and harder to refactor and extend later (which can have far greater pay-offs), then I'm saying there should be a good reason for it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703410399 From jhendrikx at openjdk.org Sun Aug 4 22:58:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 4 Aug 2024 22:58:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v16] In-Reply-To: References: Message-ID: On Sun, 4 Aug 2024 19:08:14 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > use HashMap.newHashMap() This is still a large PR, and I do want to help reviewing it, I will do my best to look it over further this week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2267859957 From jhendrikx at openjdk.org Sun Aug 4 22:58:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 4 Aug 2024 22:58:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: <0vyp4GYEi2g96MOznMJFipCmWUqF6xGccSY-vXrt-BQ=.ad55b0fe-0226-4683-b045-f4e69333725a@github.com> On Sun, 4 Aug 2024 15:32:10 GMT, Michael Strau? wrote: >> I've taken a closer look, and I have the feeling that `ComponentTransitionable` is more of an indicator that the corresponding `StyleConverter` has implemented `convertBack`. I think noting this information closer to the source would therefore be a good idea. >> >> From what I can see, `applyComponentTransition` already falls back to calling `set(T)` if there is anything out of the ordinary (like missing CSS meta data or a missing StyleConverter). >> >> For both interpolation cases (`Interpolatable` and `ComponentTransitionable`) you are getting the CSS meta data. You can externalize that part. When you have the meta data, you can get the `StyleConverter` and check if it supports deconstruction (instead of having a marker on the final result). You can either: >> >> - put the marker on `StyleConverter` >> - have `convertBack` return an `Optional` or `null` if unsupported (there are already several `null` checks for missing CSS meta data or the missing converter, one more here seems not unreasonable). >> - have a method on `StyleConverter` that indicates its capabilities (true/false, `SUPPORTS_DECONSTRUCTION`, etc..) >> >> The advantage of this IMHO is that it keeps CSS concerns (component transitionable) in the CSS realm (with StyleConverter), while leaving simple classes that are just value holders (Border, Background) untouched. > > I don't quite like returning any particular value from `convertBack` as a signal for "this style converter doesn't support deconstruction", so I've made it more explicit with the marker interface `StyleConverter.SupportsDeconstruction`. This removes the marker interface `ComponentTransitionable` entirely. Thanks, I think having this with the StyleConverter makes more sense. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703410832 From jhendrikx at openjdk.org Sun Aug 4 23:04:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 4 Aug 2024 23:04:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 00:14:23 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 183: >> >>> 181: *
  • If the intermediate list is shallow-equal to the first list passed into the method (i.e. its >>> 182: * elements are references to the same objects), the existing list is returned. >>> 183: *
  • If a new list is returned, it is unmodifiable. >> >> Well, it's documented, but I'd rather see this return an unmodifiable list in all cases (and not one of the input lists if it was determined to be modifiable). Perhaps ensure this is compatible with `List.copyOf` so that copies are only made when needed. > > In practice, any list that is passed into this method is already unmodifiable. This isn't a general-purpose method, it's tailored towards its usage for `Border` and `Background` interpolation, and the optimization scheme that is used in these classes. Alright, I get how it works now, and that there is a lot of reference equality checking going on by callers. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703411678 From jhendrikx at openjdk.org Sun Aug 4 23:12:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 4 Aug 2024 23:12:39 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 17:51:00 GMT, Andy Goryachev wrote: > re-tested on macOS, works as expected. > > also tested in the Monkey Tester with the CSS provided in the ticket (errors appear in stderr as expected), and after the offending CSS is removed (gets back to normal). Thanks for the extensive testing :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2267882804 From jhendrikx at openjdk.org Sun Aug 4 23:12:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 4 Aug 2024 23:12:39 GMT Subject: Integrated: 8336389: Infinite loop occurs while resolving lookups In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 13:21:53 GMT, John Hendrikx wrote: > Fixes an infinite loop that can occur while resolving lookups. > > There were 2 bugs: > - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates > - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far > > Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). This pull request has now been integrated. Changeset: f7ad5cdc Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/f7ad5cdccb03162dc19fffb8eed570d4fbef490c Stats: 171 lines in 2 files changed: 158 ins; 9 del; 4 mod 8336389: Infinite loop occurs while resolving lookups Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1505 From john.hendrikx at gmail.com Sun Aug 4 23:30:16 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 5 Aug 2024 01:30:16 +0200 Subject: Detecting threading problems faster Message-ID: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Hi list, I know of quite some bugs and users that have been bitten by the threading model used by JavaFX.? Basically, anything directly or indirectly linked to an active Scene must be accessed on the FX thread.? However, as FX also allows manipulating nodes and properties before they're displayed, there can be no "hard" check everywhere to ensure we are on the FX thread (specifically, in properties). Now, I think this situation is annoying, as a simple mistake where a Platform.runLater wrapper was forgotten usually results in programs operating mostly flawlessly, but then fail in mysterious and random and hard to reproduce ways.? The blame is often put on FX as the resulting exceptions will almost never show the user code which was the actual culprit.? It can result in FX being perceived as unstable or buggy. So I've been thinking if there isn't something we can do to detect these bugs originating from user code much earlier, similar to the `ConcurrentModificationException` the collection classes do when accessed in nested or concurrent contexts. I think it may be possible to have properties check whether they're part of an active scene without too much of an performance impact, possibly even behind a switch. It would work like this: Properties involved with Nodes will have an associated bean instance (`getBean`).? This is an object, but we could check here if this instance implements an interface: ???? if (getBean() instanceof MayBePartOfSceneGraph x) { ?????????? if (x.isPartOfActiveScene() && !isOnFxThread()) { ??????????????? throw new IllegalStateException("Property must only be used from the FX Application Thread"); ?????????? } ???? } This check could be done on every set of the property, and potentially on every get as well.? It should be relatively cheap, but will expose problematic code patterns at a much earlier stage.? There's a chance that this will "break" some programs that seemed to be behaving correctly as well, so we may want to put it behind a switch until such programs (or libraries) can be fixed. What do you all think? --John (*) Names of methods/interfaces are only used for illustration purposes, we can think of good names if this moves forward. From mstrauss at openjdk.org Sun Aug 4 23:56:41 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Aug 2024 23:56:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sun, 4 Aug 2024 23:01:48 GMT, John Hendrikx wrote: >> In practice, any list that is passed into this method is already unmodifiable. This isn't a general-purpose method, it's tailored towards its usage for `Border` and `Background` interpolation, and the optimization scheme that is used in these classes. > > Alright, I get how it works now, and that there is a lot of reference equality checking going on by callers. Let me explain how I got here in the first place. My observation is that `Background` and `Border` graphs can be quite large, and they are deeply immutable. But often, only tiny parts of it change during a transition. So my question was: wouldn't it be nice if we could re-use the unmodified parts of the graph, instead of copying it entirely, potentially tens of thousands of times per second? The `Interpolatable` contract gives us permission to return an existing instance (and thereby reusing unmodified parts of the graph), so that's good. An initial implementation might look like this (note: this is not the implementation of this PR): public Border interpolate(Border endValue, double t) { Objects.requireNonNull(endValue, "endValue cannot be null"); 1: if (t <= 0 || equals(endValue)) { return this; } if (t >= 1) { return endValue; } List newImages = InterpolationUtils.interpolateListsPairwise(images, endValue.images, t); List newStrokes = InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t); 2: if (this.images.equals(newImages) && this.strokes.equals(newStrokes)) { return this; } 3: if (endValue.images.equals(newImages) && endValue.strokes.equals(newStrokes)) { return endValue; } return new Border(newStrokes, newImages); } I've marked three important lines with `1:` to `3:`. These equality comparisons traverse through the object graph many times, and unnecessarily so: each of the sub-objects' `interpolate` method will do the same thing, comparing the same objects recursively again. So instead of doing a "root to leaf" equality comparison (i.e. starting at `Border` and comparing upwards), I figured that a "leaf to root" comparison would be much simpler in terms of the raw amount of computation required. This reduces a complete sub-graph traversal to a simple identity comparison (but requires cooperating `interpolate()` implementations). I didn't benchmark whether the time spent on naively copying the entire object graph, or doing the "root to leaf" equality comparison amounts to a significant share of computation, or when it starts becoming a problem (is it hundreds or tens of thousands of transitions?). But I do think that the approach is sound. At this time, I am not inclined to change the implementation, but to improve the code documentation to make it easier to understand what's going on. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703420442 From quizynox at gmail.com Mon Aug 5 03:40:46 2024 From: quizynox at gmail.com (quizynox) Date: Mon, 5 Aug 2024 07:40:46 +0400 Subject: Detecting threading problems faster In-Reply-To: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: Hello, Wouldn't it be better to implement this check in assert to avoid any impact in production? ??, 5 ???. 2024??. ? 03:30, John Hendrikx : > Hi list, > > I know of quite some bugs and users that have been bitten by the > threading model used by JavaFX. Basically, anything directly or > indirectly linked to an active Scene must be accessed on the FX thread. > However, as FX also allows manipulating nodes and properties before > they're displayed, there can be no "hard" check everywhere to ensure we > are on the FX thread (specifically, in properties). > > Now, I think this situation is annoying, as a simple mistake where a > Platform.runLater wrapper was forgotten usually results in programs > operating mostly flawlessly, but then fail in mysterious and random and > hard to reproduce ways. The blame is often put on FX as the resulting > exceptions will almost never show the user code which was the actual > culprit. It can result in FX being perceived as unstable or buggy. > > So I've been thinking if there isn't something we can do to detect these > bugs originating from user code much earlier, similar to the > `ConcurrentModificationException` the collection classes do when > accessed in nested or concurrent contexts. > > I think it may be possible to have properties check whether they're part > of an active scene without too much of an performance impact, possibly > even behind a switch. It would work like this: > > Properties involved with Nodes will have an associated bean instance > (`getBean`). This is an object, but we could check here if this > instance implements an interface: > > if (getBean() instanceof MayBePartOfSceneGraph x) { > if (x.isPartOfActiveScene() && !isOnFxThread()) { > throw new IllegalStateException("Property must only be > used from the FX Application Thread"); > } > } > > This check could be done on every set of the property, and potentially > on every get as well. It should be relatively cheap, but will expose > problematic code patterns at a much earlier stage. There's a chance > that this will "break" some programs that seemed to be behaving > correctly as well, so we may want to put it behind a switch until such > programs (or libraries) can be fixed. > > What do you all think? > > --John > > (*) Names of methods/interfaces are only used for illustration purposes, > we can think of good names if this moves forward. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quizynox at gmail.com Mon Aug 5 04:09:53 2024 From: quizynox at gmail.com (quizynox) Date: Mon, 5 Aug 2024 08:09:53 +0400 Subject: Font hinting on Linux In-Reply-To: <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com> References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com> <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com> Message-ID: Hello, Thanks for the answer. I've found a couple of very long but very informative threads that have given me some pointers. Poor quality font rendering https://mail.openjdk.org/pipermail/openjfx-dev/2013-August/009958.html The crisp fonts saga https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044234.html In my case there were two problems: - I had SceneAntialiasing enabled, which seems to prevent -fx-smoothing-type=lcd from working - I forgot that -fx-smoothing-type is only enabled for .text nodes, but not for all Text nodes by default I also assumed that Linux fontconfig settings would have some effect on JavaFX font rendering, but judging from tests this isn't the case. Perhaps the only thing that matters is freetype compilation flags. I've found that Fedora enabled ClearType font rendering some time ago ( https://www.phoronix.com/news/Fedora-ClearType-Subpixel-Font). As for -fx-smooth-type=gray, with some fonts such as Open Sans, Liberation Sans or Montserrat it may look quite close to acceptable. ??, 4 ???. 2024??. ? 01:41, Philip Race : > There's not many knobs available. Hinting is not enabled - and that's > commonly the case on modern plartforms. > LCD is your best option for readibility of static text, which is why it > is the default for UI Controls, > It should reduce the pixel grid fitting uneveness you highlight but > doesn't eliminate it. > Note : this presumes that the freetype on your system enables LCD .. if > it doesn't there's nothing FX can do about that. > > -phil. > > > On 8/2/24 10:43 AM, quizynox at gmail.com wrote: > > Hello, > > > > Sorry for asking here, but I seem to have tried everything I could > > find on SO/Reddit/JBS etc. Could someone please share what font > > settings I should be using to get decent font hinting on Linux? Please > > see the screenshot. > > > > https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view > > > > I'm not very picky, but the font I see is just not suitable for > > presenting app to customers. I've tried enabling and disabling hinting > > and autohinting, using different hinting styles, changing the font > > smoothing type and prism.lcdtext etc. Unfortunately no matter what I > > do, the font hinting is always bad. > > > > Fedora, KDE, all latest versions. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Aug 5 14:59:23 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 5 Aug 2024 07:59:23 -0700 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> > Wouldn't it be better to implement this check in assert to avoid any > impact in production? No. Using an assert in a case like this is an anti-pattern. A call to assert in a library such as JavaFX is only appropriate for checking an invariant in internal logic. If we are going to go down this route of doing a thread check when mutating properties of "live" nodes, we will throw the same IllegalStateException that is currently thrown by some methods on Stage and Scene. As for the proposal itself, adding this check is an interesting idea. We considered doing this back in the JDK 7 (JavaFX 2) time frame, but decided not to pursue it then. I think the idea is worth further discussion. I would limit any thread checking to setting the property. It would be too restrictive (and largely unnecessary) to prevent reading a property from the application thread. The things to consider would be: 1. What is the performance hit of doing this check on the setting of every property? 2. What is the effect on bound properties? 3. How intrusive is it in the code? 4. Should we add a property to enable / disable the thread check, possibly a three- or four-valued property (allow|warn|debug?|deny), as was recently done in JEP 471 for sun.misc.Unsafe memory access methods. If so, what should the default be? My quick take is that if this can be done in a minimally intrusive manner with low overhead, we should consider pursing this. As for 4, my preference would be to add a three- or four-valued system property to control the check, with "warn" as the default initially, changing the default to "disallow" in a subsequent version. This would, of course, require a lot of testing. -- Kevin On 8/4/2024 8:40 PM, quizynox wrote: > Hello, > > Wouldn't it be better to implement this check in assert to avoid any > impact in production? > > ??, 5 ???. 2024??. ? 03:30, John Hendrikx : > > Hi list, > > I know of quite some bugs and users that have been bitten by the > threading model used by JavaFX.? Basically, anything directly or > indirectly linked to an active Scene must be accessed on the FX > thread. > However, as FX also allows manipulating nodes and properties before > they're displayed, there can be no "hard" check everywhere to > ensure we > are on the FX thread (specifically, in properties). > > Now, I think this situation is annoying, as a simple mistake where a > Platform.runLater wrapper was forgotten usually results in programs > operating mostly flawlessly, but then fail in mysterious and > random and > hard to reproduce ways.? The blame is often put on FX as the > resulting > exceptions will almost never show the user code which was the actual > culprit.? It can result in FX being perceived as unstable or buggy. > > So I've been thinking if there isn't something we can do to detect > these > bugs originating from user code much earlier, similar to the > `ConcurrentModificationException` the collection classes do when > accessed in nested or concurrent contexts. > > I think it may be possible to have properties check whether > they're part > of an active scene without too much of an performance impact, > possibly > even behind a switch. It would work like this: > > Properties involved with Nodes will have an associated bean instance > (`getBean`).? This is an object, but we could check here if this > instance implements an interface: > > ????? if (getBean() instanceof MayBePartOfSceneGraph x) { > ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) { > ???????????????? throw new IllegalStateException("Property must > only be > used from the FX Application Thread"); > ??????????? } > ????? } > > This check could be done on every set of the property, and > potentially > on every get as well.? It should be relatively cheap, but will expose > problematic code patterns at a much earlier stage.? There's a chance > that this will "break" some programs that seemed to be behaving > correctly as well, so we may want to put it behind a switch until > such > programs (or libraries) can be fixed. > > What do you all think? > > --John > > (*) Names of methods/interfaces are only used for illustration > purposes, > we can think of good names if this moves forward. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Mon Aug 5 15:01:25 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 5 Aug 2024 15:01:25 +0000 Subject: Detecting threading problems faster In-Reply-To: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: John: Can you cite a bug or give an example of such a problem? During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe. It is possible that I use the system trivially and not to the full extent. Both swing and javafx are single threaded by design. Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would you want to do that? -andy From: openjfx-dev on behalf of John Hendrikx Date: Sunday, August 4, 2024 at 16:30 To: openjfx-dev at openjdk.org Subject: Detecting threading problems faster Hi list, I know of quite some bugs and users that have been bitten by the threading model used by JavaFX. Basically, anything directly or indirectly linked to an active Scene must be accessed on the FX thread. However, as FX also allows manipulating nodes and properties before they're displayed, there can be no "hard" check everywhere to ensure we are on the FX thread (specifically, in properties). Now, I think this situation is annoying, as a simple mistake where a Platform.runLater wrapper was forgotten usually results in programs operating mostly flawlessly, but then fail in mysterious and random and hard to reproduce ways. The blame is often put on FX as the resulting exceptions will almost never show the user code which was the actual culprit. It can result in FX being perceived as unstable or buggy. So I've been thinking if there isn't something we can do to detect these bugs originating from user code much earlier, similar to the `ConcurrentModificationException` the collection classes do when accessed in nested or concurrent contexts. I think it may be possible to have properties check whether they're part of an active scene without too much of an performance impact, possibly even behind a switch. It would work like this: Properties involved with Nodes will have an associated bean instance (`getBean`). This is an object, but we could check here if this instance implements an interface: if (getBean() instanceof MayBePartOfSceneGraph x) { if (x.isPartOfActiveScene() && !isOnFxThread()) { throw new IllegalStateException("Property must only be used from the FX Application Thread"); } } This check could be done on every set of the property, and potentially on every get as well. It should be relatively cheap, but will expose problematic code patterns at a much earlier stage. There's a chance that this will "break" some programs that seemed to be behaving correctly as well, so we may want to put it behind a switch until such programs (or libraries) can be fixed. What do you all think? --John (*) Names of methods/interfaces are only used for illustration purposes, we can think of good names if this moves forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Aug 5 15:05:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Aug 2024 15:05:40 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v6] In-Reply-To: References: Message-ID: On Sat, 3 Aug 2024 16:30:08 GMT, Martin Fox wrote: >> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). >> >> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. >> >> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. >> >> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. >> >> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Added timeout to test due to potential hang when using XWayland Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2219233586 From angorya at openjdk.org Mon Aug 5 15:05:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Aug 2024 15:05:41 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: On Sat, 3 Aug 2024 14:33:47 GMT, Kevin Rushforth wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback: floating point precision in test, ensure unsigned int handling in Robot > > tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 218: > >> 216: // colors but they might both be working in the wrong space. We use an >> 217: // AWT Robot to verify that they are working in sRGB. >> 218: @Test > > This test needs a timeout value to avoid hanging the test job on Linux with Wayland. See [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). I recommend: > > > @Test(timeout = 15000) Maybe there is a way to skip the test on Wayland until we find a proper solution? Asking for completeness sake - simply adding a timeout works too. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704255339 From angorya at openjdk.org Mon Aug 5 15:05:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Aug 2024 15:05:41 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 14:59:55 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 218: >> >>> 216: // colors but they might both be working in the wrong space. We use an >>> 217: // AWT Robot to verify that they are working in sRGB. >>> 218: @Test >> >> This test needs a timeout value to avoid hanging the test job on Linux with Wayland. See [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). I recommend: >> >> >> @Test(timeout = 15000) > > Maybe there is a way to skip the test on Wayland until we find a proper solution? > Asking for completeness sake - simply adding a timeout works too. Q: is this the only test that needs explicit timeout? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704258754 From thiago.sayao at gmail.com Mon Aug 5 15:17:05 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 5 Aug 2024 12:17:05 -0300 Subject: Detecting threading problems faster In-Reply-To: <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> Message-ID: Hi, Interesting idea. We have this problem specially when Junior developers touch the code. The other way around would be nice too - if some I/O task executes on the FX thread. This can make the OS think the application hanged and offer to kill it, since it won't respond to "pings". And I/O tasks processing time may vary between installations. Also causes "white screens" since it blocks painting. -- Thiago. Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > Wouldn't it be better to implement this check in assert to avoid any > impact in production? > > > No. Using an assert in a case like this is an anti-pattern. A call to > assert in a library such as JavaFX is only appropriate for checking an > invariant in internal logic. If we are going to go down this route of doing > a thread check when mutating properties of "live" nodes, we will throw the > same IllegalStateException that is currently thrown by some methods on > Stage and Scene. > > As for the proposal itself, adding this check is an interesting idea. We > considered doing this back in the JDK 7 (JavaFX 2) time frame, but decided > not to pursue it then. I think the idea is worth further discussion. I > would limit any thread checking to setting the property. It would be too > restrictive (and largely unnecessary) to prevent reading a property from > the application thread. > > The things to consider would be: > > 1. What is the performance hit of doing this check on the setting of every > property? > 2. What is the effect on bound properties? > 3. How intrusive is it in the code? > 4. Should we add a property to enable / disable the thread check, possibly > a three- or four-valued property (allow|warn|debug?|deny), as was recently > done in JEP 471 for sun.misc.Unsafe memory access methods. If so, what > should the default be? > > My quick take is that if this can be done in a minimally intrusive manner > with low overhead, we should consider pursing this. As for 4, my preference > would be to add a three- or four-valued system property to control the > check, with "warn" as the default initially, changing the default to > "disallow" in a subsequent version. This would, of course, require a lot of > testing. > > -- Kevin > > > On 8/4/2024 8:40 PM, quizynox wrote: > > Hello, > > Wouldn't it be better to implement this check in assert to avoid any > impact in production? > > ??, 5 ???. 2024??. ? 03:30, John Hendrikx : > >> Hi list, >> >> I know of quite some bugs and users that have been bitten by the >> threading model used by JavaFX. Basically, anything directly or >> indirectly linked to an active Scene must be accessed on the FX thread. >> However, as FX also allows manipulating nodes and properties before >> they're displayed, there can be no "hard" check everywhere to ensure we >> are on the FX thread (specifically, in properties). >> >> Now, I think this situation is annoying, as a simple mistake where a >> Platform.runLater wrapper was forgotten usually results in programs >> operating mostly flawlessly, but then fail in mysterious and random and >> hard to reproduce ways. The blame is often put on FX as the resulting >> exceptions will almost never show the user code which was the actual >> culprit. It can result in FX being perceived as unstable or buggy. >> >> So I've been thinking if there isn't something we can do to detect these >> bugs originating from user code much earlier, similar to the >> `ConcurrentModificationException` the collection classes do when >> accessed in nested or concurrent contexts. >> >> I think it may be possible to have properties check whether they're part >> of an active scene without too much of an performance impact, possibly >> even behind a switch. It would work like this: >> >> Properties involved with Nodes will have an associated bean instance >> (`getBean`). This is an object, but we could check here if this >> instance implements an interface: >> >> if (getBean() instanceof MayBePartOfSceneGraph x) { >> if (x.isPartOfActiveScene() && !isOnFxThread()) { >> throw new IllegalStateException("Property must only be >> used from the FX Application Thread"); >> } >> } >> >> This check could be done on every set of the property, and potentially >> on every get as well. It should be relatively cheap, but will expose >> problematic code patterns at a much earlier stage. There's a chance >> that this will "break" some programs that seemed to be behaving >> correctly as well, so we may want to put it behind a switch until such >> programs (or libraries) can be fixed. >> >> What do you all think? >> >> --John >> >> (*) Names of methods/interfaces are only used for illustration purposes, >> we can think of good names if this moves forward. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at martinfox.com Mon Aug 5 15:32:43 2024 From: martin at martinfox.com (Martin Fox) Date: Mon, 5 Aug 2024 08:32:43 -0700 Subject: Font hinting on Linux In-Reply-To: References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com> <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com> Message-ID: I don?t see how hinting issues can cause this degree of character misplacement. This looks more like, say, a glyph cache bug. I had no problem reproducing this with the software pipeline. When I force the GPU I get much better results (prism.forceGPU=true). In both cases the text is a little on the fuzzy side but the es2 pipeline is placing the glyphs correctly. > On Aug 4, 2024, at 9:09?PM, quizynox wrote: > > Hello, > > Thanks for the answer. I've found a couple of very long but very informative threads that have given me some pointers. > > Poor quality font rendering > https://mail.openjdk.org/pipermail/openjfx-dev/2013-August/009958.html > > The crisp fonts saga > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044234.html > > In my case there were two problems: > > - I had SceneAntialiasing enabled, which seems to prevent -fx-smoothing-type=lcd from working > - I forgot that -fx-smoothing-type is only enabled for .text nodes, but not for all Text nodes by default > > I also assumed that Linux fontconfig settings would have some effect on JavaFX font rendering, but judging from tests this isn't the case. Perhaps the only thing that matters is freetype compilation flags. I've found that Fedora enabled ClearType font rendering some time ago (https://www.phoronix.com/news/Fedora-ClearType-Subpixel-Font). > > As for -fx-smooth-type=gray, with some fonts such as Open Sans, Liberation Sans or Montserrat it may look quite close to acceptable. > > ??, 4 ???. 2024??. ? 01:41, Philip Race >: >> There's not many knobs available. Hinting is not enabled - and that's >> commonly the case on modern plartforms. >> LCD is your best option for readibility of static text, which is why it >> is the default for UI Controls, >> It should reduce the pixel grid fitting uneveness you highlight but >> doesn't eliminate it. >> Note : this presumes that the freetype on your system enables LCD .. if >> it doesn't there's nothing FX can do about that. >> >> -phil. >> >> >> On 8/2/24 10:43 AM, quizynox at gmail.com wrote: >> > Hello, >> > >> > Sorry for asking here, but I seem to have tried everything I could >> > find on SO/Reddit/JBS etc. Could someone please share what font >> > settings I should be using to get decent font hinting on Linux? Please >> > see the screenshot. >> > >> > https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view >> > >> > I'm not very picky, but the font I see is just not suitable for >> > presenting app to customers. I've tried enabling and disabling hinting >> > and autohinting, using different hinting styles, changing the font >> > smoothing type and prism.lcdtext etc. Unfortunately no matter what I >> > do, the font hinting is always bad. >> > >> > Fedora, KDE, all latest versions. >> > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Mon Aug 5 15:35:01 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 5 Aug 2024 17:35:01 +0200 Subject: Detecting threading problems faster In-Reply-To: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: Hi John, this seems to be a very similar idea to what I've proposed a year ago: https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/041925.html I think the potential performance impact needs to be carefully considered. From thiago.sayao at gmail.com Mon Aug 5 15:36:32 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 5 Aug 2024 12:36:32 -0300 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: It seems Task<> has thread checks, it would even correct the thread on updateMessage(). So, it seems to be a problem if Task<> is not used? Em seg., 5 de ago. de 2024 ?s 12:01, Andy Goryachev < andy.goryachev at oracle.com> escreveu: > John: > > > > Can you cite a bug or give an example of such a problem? > > > > During all my time of actively using javafx (since about 2015) I have > never encountered an issue with threading you describe. It is possible > that I use the system trivially and not to the full extent. Both swing and > javafx are single threaded by design. Yes, there might be occasions when > one can use multiple threads and it is sort of allowed, but doing so may > lead to unpleasant issues down the road, so the question is why would you > want to do that? > > > > -andy > > > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Sunday, August 4, 2024 at 16:30 > *To: *openjfx-dev at openjdk.org > *Subject: *Detecting threading problems faster > > Hi list, > > I know of quite some bugs and users that have been bitten by the > threading model used by JavaFX. Basically, anything directly or > indirectly linked to an active Scene must be accessed on the FX thread. > However, as FX also allows manipulating nodes and properties before > they're displayed, there can be no "hard" check everywhere to ensure we > are on the FX thread (specifically, in properties). > > Now, I think this situation is annoying, as a simple mistake where a > Platform.runLater wrapper was forgotten usually results in programs > operating mostly flawlessly, but then fail in mysterious and random and > hard to reproduce ways. The blame is often put on FX as the resulting > exceptions will almost never show the user code which was the actual > culprit. It can result in FX being perceived as unstable or buggy. > > So I've been thinking if there isn't something we can do to detect these > bugs originating from user code much earlier, similar to the > `ConcurrentModificationException` the collection classes do when > accessed in nested or concurrent contexts. > > I think it may be possible to have properties check whether they're part > of an active scene without too much of an performance impact, possibly > even behind a switch. It would work like this: > > Properties involved with Nodes will have an associated bean instance > (`getBean`). This is an object, but we could check here if this > instance implements an interface: > > if (getBean() instanceof MayBePartOfSceneGraph x) { > if (x.isPartOfActiveScene() && !isOnFxThread()) { > throw new IllegalStateException("Property must only be > used from the FX Application Thread"); > } > } > > This check could be done on every set of the property, and potentially > on every get as well. It should be relatively cheap, but will expose > problematic code patterns at a much earlier stage. There's a chance > that this will "break" some programs that seemed to be behaving > correctly as well, so we may want to put it behind a switch until such > programs (or libraries) can be fixed. > > What do you all think? > > --John > > (*) Names of methods/interfaces are only used for illustration purposes, > we can think of good names if this moves forward. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Mon Aug 5 15:46:36 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 5 Aug 2024 15:46:36 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 15:02:31 GMT, Andy Goryachev wrote: >> Maybe there is a way to skip the test on Wayland until we find a proper solution? >> Asking for completeness sake - simply adding a timeout works too. > > Q: is this the only test that needs explicit timeout? I don't see any way to query whether we're running under Wayland or not. That would be nice to have. This is the only test that uses the AWT Robot on Linux. The window background test also uses the AWT Robot but only runs on Mac. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704317349 From mfox at openjdk.org Mon Aug 5 15:46:37 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 5 Aug 2024 15:46:37 GMT Subject: Integrated: 8325445: [macOS] Colors are not displayed in sRGB color space In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 18:29:00 GMT, Martin Fox wrote: > When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). > > In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. > > Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. > > I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. > > I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. This pull request has now been integrated. Changeset: 19d09e6c Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/19d09e6c2e15683de1c69d0e841f32e337da2031 Stats: 300 lines in 8 files changed: 289 ins; 2 del; 9 mod 8325445: [macOS] Colors are not displayed in sRGB color space Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1473 From lkostyra at openjdk.org Mon Aug 5 16:05:47 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 5 Aug 2024 16:05:47 GMT Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs Message-ID: In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible. This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs. Both D3D and ES2 Prism backends were updated to properly handle these changes. NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change. I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples. ------------- Commit messages: - Provide Shader name in ShaderFactory.createShader Changes: https://git.openjdk.org/jfx/pull/1530/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1530&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336624 Stats: 15 lines in 6 files changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1530.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1530/head:pull/1530 PR: https://git.openjdk.org/jfx/pull/1530 From lkostyra at openjdk.org Mon Aug 5 16:05:47 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 5 Aug 2024 16:05:47 GMT Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs In-Reply-To: References: Message-ID: <3bc6rRtMGIdtvMvgzUDLf5BG47hJeQcWspAwkgmeHjg=.a8d8c1fd-7c99-41a0-b821-740c02e54542@github.com> On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra wrote: > In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible. > > This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs. > > Both D3D and ES2 Prism backends were updated to properly handle these changes. > > NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change. > > I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples. @arapte Please take a look at this and confirm if those changes will be good for Metal ------------- PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2269416642 From kcr at openjdk.org Mon Aug 5 16:13:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Aug 2024 16:13:40 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 15:43:03 GMT, Martin Fox wrote: >> Q: is this the only test that needs explicit timeout? > > I don't see any way to query whether we're running under Wayland or not. That would be nice to have. > > This is the only test that uses the AWT Robot on Linux. The window background test also uses the AWT Robot but only runs on Mac. @alexeysemenyukoracle added an [`isOnWayland`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeBase.java#L194) method to `SwingNodeBase.java`. I'll file a new testbug to skip tests that use AWT Robot on Wayland pending the fix for [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). As part of that, we can move `isOnWayland` to [`Util.java`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/util/Util.java) (and fix it to first check `PlatformUtil::isLinux`). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704352887 From angorya at openjdk.org Mon Aug 5 16:19:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Aug 2024 16:19:40 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: Message-ID: <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com> On Mon, 5 Aug 2024 16:10:33 GMT, Kevin Rushforth wrote: >> I don't see any way to query whether we're running under Wayland or not. That would be nice to have. >> >> This is the only test that uses the AWT Robot on Linux. The window background test also uses the AWT Robot but only runs on Mac. > > @alexeysemenyukoracle added an [`isOnWayland`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeBase.java#L194) method to `SwingNodeBase.java`. I'll file a new testbug to skip tests that use AWT Robot on Wayland pending the fix for [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). As part of that, we can move `isOnWayland` to [`Util.java`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/util/Util.java) (and fix it to first check `PlatformUtil::isLinux`). maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first? what do you think? edit: never mind, this PR is already integrated. aren't we supposed to wait 24 hrs before integrating? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704358262 From angorya at openjdk.org Mon Aug 5 16:25:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Aug 2024 16:25:37 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: <1P12hjtrcnoWBrPFdRhiSHXWYOju06wOBrZQqwJv_Ls=.0dfb0f2e-a804-4678-9061-065a66b4bd62@github.com> References: <1P12hjtrcnoWBrPFdRhiSHXWYOju06wOBrZQqwJv_Ls=.0dfb0f2e-a804-4678-9061-065a66b4bd62@github.com> Message-ID: On Sat, 3 Aug 2024 00:24:10 GMT, Alexander Zuev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/CellArrangement.java line 263: > >> 261: */ >> 262: private int binarySearch(double localY, int low, int high) { >> 263: //System.err.println(" binarySearch off=" + off + ", high=" + high + ", low=" + low); // FIX > > Looks like remnants of the debugging session. Do you still need it? yes, indeed it is (to be cleaned up later). I would encourage the reviewers to focus on the public API rather than the implementation at this stage. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1704366454 From kcr at openjdk.org Mon Aug 5 16:34:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Aug 2024 16:34:40 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com> References: <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com> Message-ID: On Mon, 5 Aug 2024 16:15:17 GMT, Andy Goryachev wrote: >> @alexeysemenyukoracle added an [`isOnWayland`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeBase.java#L194) method to `SwingNodeBase.java`. I'll file a new testbug to skip tests that use AWT Robot on Wayland pending the fix for [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). As part of that, we can move `isOnWayland` to [`Util.java`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/util/Util.java) (and fix it to first check `PlatformUtil::isLinux`). > > maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first? what do you think? > > edit: never mind, this PR is already integrated. aren't we supposed to wait 24 hrs before integrating? I filed https://bugs.openjdk.org/browse/JDK-8337827 to track this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704375807 From kcr at openjdk.org Mon Aug 5 17:09:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Aug 2024 17:09:36 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: References: <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com> Message-ID: <_8JOo4dxr1WdFWmFyUMWhB_Z45JRfkJn2aD6vIWsaZ4=.fe72d96b-04ee-4d26-adce-88afd7f45457@github.com> On Mon, 5 Aug 2024 16:31:31 GMT, Kevin Rushforth wrote: >> maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first? what do you think? >> >> edit: never mind, this PR is already integrated. aren't we supposed to wait 24 hrs before integrating? > > I filed https://bugs.openjdk.org/browse/JDK-8337827 to track this. > maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first? what do you think? Not as part of this PR, no. > edit: never mind, this PR is already integrated. aren't we supposed to wait 24 hrs before integrating? That's 24 hours after "rfr". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704408716 From angorya at openjdk.org Mon Aug 5 17:09:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Aug 2024 17:09:36 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v5] In-Reply-To: <_8JOo4dxr1WdFWmFyUMWhB_Z45JRfkJn2aD6vIWsaZ4=.fe72d96b-04ee-4d26-adce-88afd7f45457@github.com> References: <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com> <_8JOo4dxr1WdFWmFyUMWhB_Z45JRfkJn2aD6vIWsaZ4=.fe72d96b-04ee-4d26-adce-88afd7f45457@github.com> Message-ID: On Mon, 5 Aug 2024 17:04:33 GMT, Kevin Rushforth wrote: >> I filed https://bugs.openjdk.org/browse/JDK-8337827 to track this. > >> maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first? what do you think? > > Not as part of this PR, no. > >> edit: never mind, this PR is already integrated. aren't we supposed to wait 24 hrs before integrating? > > That's 24 hours after "rfr". it's all good then. thanks for filing [JDK-8337827](https://bugs.openjdk.org/browse/JDK-8337827) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704410859 From arapte at openjdk.org Tue Aug 6 05:18:41 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Aug 2024 05:18:41 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v3] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 22:41:05 GMT, Alexander Zuev wrote: >> Initial implementation of the protocol. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1507#pullrequestreview-2220296759 From hmeda at openjdk.org Tue Aug 6 08:08:09 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 6 Aug 2024 08:08:09 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2] In-Reply-To: References: Message-ID: > Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Remove deprecated file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1527/files - new: https://git.openjdk.org/jfx/pull/1527/files/92dd8395..650d1d20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1527&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1527&range=00-01 Stats: 190 lines in 1 file changed: 0 ins; 190 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1527.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1527/head:pull/1527 PR: https://git.openjdk.org/jfx/pull/1527 From arapte at openjdk.org Tue Aug 6 08:36:38 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Aug 2024 08:36:38 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1525#pullrequestreview-2220641216 From duke at openjdk.org Tue Aug 6 09:16:38 2024 From: duke at openjdk.org (Clearvision92) Date: Tue, 6 Aug 2024 09:16:38 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove deprecated file Help me download ------------- PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2220748425 From kcr at openjdk.org Tue Aug 6 12:13:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Aug 2024 12:13:42 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove deprecated file Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2221123181 From lkostyra at openjdk.org Tue Aug 6 12:55:43 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 6 Aug 2024 12:55:43 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v5] In-Reply-To: References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> Message-ID: <6ykhx2Ylax-_y78REsCQby8emph_X3Oe6SroyWCXutc=.886defbc-0d80-4c83-9e19-b985afc13b72@github.com> On Mon, 29 Jul 2024 14:29:17 GMT, Thiago Milczarek Sayao wrote: >> Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). >> >> It's not specific to DEBIAN, it depends on the window manager (kwin is affected). > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Revert idea file > - Fix only the original bug LGTM. I confirmed it works on latest Ubuntu 23.04 with KDE Plasma. Gnome behavior is unchanged (correct and KDE matches Gnome behavior). ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1460#pullrequestreview-2221218851 From tsayao at openjdk.org Tue Aug 6 13:05:40 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Aug 2024 13:05:40 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v5] In-Reply-To: References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> Message-ID: On Mon, 29 Jul 2024 14:29:17 GMT, Thiago Milczarek Sayao wrote: >> Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). >> >> It's not specific to DEBIAN, it depends on the window manager (kwin is affected). > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Revert idea file > - Fix only the original bug Is it ok to integrate? I got the e-mail saying so, but not really sure. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2271241922 From kcr at openjdk.org Tue Aug 6 13:08:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Aug 2024 13:08:41 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v5] In-Reply-To: References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> Message-ID: On Tue, 6 Aug 2024 13:03:15 GMT, Thiago Milczarek Sayao wrote: > Is it ok to integrate? I got the e-mail saying so, but not really sure. Yes. There are two approving reviews, and no outstanding comments or questions. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2271248232 From tsayao at openjdk.org Tue Aug 6 13:11:40 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Aug 2024 13:11:40 GMT Subject: Integrated: 8332222: Linux Debian: Maximized stage shrinks when opening another stage In-Reply-To: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> Message-ID: On Wed, 22 May 2024 21:28:47 GMT, Thiago Milczarek Sayao wrote: > Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > It's not specific to DEBIAN, it depends on the window manager (kwin is affected). This pull request has now been integrated. Changeset: 304704da Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/304704da06365b9878b1b556c5dc35fb618ae584 Stats: 23 lines in 1 file changed: 15 ins; 8 del; 0 mod 8332222: Linux Debian: Maximized stage shrinks when opening another stage Reviewed-by: jpereda, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1460 From aghaisas at openjdk.org Tue Aug 6 14:05:40 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 6 Aug 2024 14:05:40 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev wrote: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 451: > 449:
  • Incubator Modules > 450:
      > 451:
    • jfx.incubator.scene.control.rich module name typo : rich -> richtext modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 454: > 452:
        > 453:
      • CodeArea
      • > 454:
      • RichTextArea
      • The order of these 2 items should be reversed to match order present in the description. modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 6391: > 6389: > 6390: > 6391: jfx.incubator.scene.control.rich module name typo : rich -> richtext ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705394006 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705396243 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705394317 From angorya at openjdk.org Tue Aug 6 14:28:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 14:28:42 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 11:47:23 GMT, Ajit Ghaisas wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 454: > >> 452:
          >> 453:
        • CodeArea
        • >> 454:
        • RichTextArea
        • > > The order of these 2 items should be reversed to match order present in the description. I think the general convention is to list the classes in alphabetical order. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705639393 From angorya at openjdk.org Tue Aug 6 15:05:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 15:05:38 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v3] In-Reply-To: References: Message-ID: <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com> On Thu, 1 Aug 2024 22:41:05 GMT, Alexander Zuev wrote: >> Initial implementation of the protocol. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested. I don't see crashes, but I noticed a few things when testing with the Monkey Tester: 1. on the AreaChart page, I was unable to see the a11y focus rectangle around the elements of the chart, even though I can hear what sounded like announcements for various elements on the chart. This behavior differed from e.g. BarChart where I could navigate with a11y focus using the TAB key. What's more interesting, this behavior appears to be the same regardless of the 'focus traversable' enabled property 2. On the BarChart (and on other chart pages) I could not place a11y focus on any of the chart elements using the mouse; but the TAB key worked. Why is that? 3. HtmlEditor: the focus rectangle is fixed at the small area in the top left corner, regardless of the text entered (see the screenshot) ![Screenshot 2024-08-06 at 07 44 42](https://github.com/user-attachments/assets/b2ed255a-f13a-4f6e-89ee-113cd75cbd51) 4. In the WebView page, enter the https://github.com address and press enter. I see the following output in stderr (which is absent with VoiceOver off): Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Applicatio n Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thr ead "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Excep tion in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" state:SCHEDULED state:RUNNING ------------- PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2271514079 From kcr at openjdk.org Tue Aug 6 15:44:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Aug 2024 15:44:37 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v3] In-Reply-To: <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com> References: <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com> Message-ID: On Tue, 6 Aug 2024 15:02:48 GMT, Andy Goryachev wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested. > > I don't see crashes, but I noticed a few things when testing with the Monkey Tester: > > 1. on the AreaChart page, I was unable to see the a11y focus rectangle around the elements of the chart, even though I can hear what sounded like announcements for various elements on the chart. This behavior differed from e.g. BarChart where I could navigate with a11y focus using the TAB key. What's more interesting, this behavior appears to be the same regardless of the 'focus traversable' enabled property > 2. On the BarChart (and on other chart pages) I could not place a11y focus on any of the chart elements using the mouse; but the TAB key worked. Why is that? > 3. HtmlEditor: the focus rectangle is fixed at the small area in the top left corner, regardless of the text entered (see the screenshot) > > ![Screenshot 2024-08-06 at 07 44 42](https://github.com/user-attachments/assets/b2ed255a-f13a-4f6e-89ee-113cd75cbd51) > > 4. In the WebView page, enter the https://github.com address and press enter. I see the following output in stderr (which is absent with VoiceOver off): > > Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Applicat ion Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Applica... @andy-goryachev-oracle Can you run the same tests with mainline (i.e., without the fix from this PR)? Those problems that only occur with this patch should be addressed as part of this PR. Problems that occur both with and without this patch should be tracked separately. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2271597988 From angorya at openjdk.org Tue Aug 6 17:19:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 17:19:36 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v3] In-Reply-To: References: <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com> Message-ID: On Tue, 6 Aug 2024 15:41:32 GMT, Kevin Rushforth wrote: > Can you run the same tests with mainline Items 1-3 can be seen with mainline, so these might be (new) issues. Item 4 seems to have been introduced by this PR - don't see the issue with the master branch. Also, notice that we don't get a stack trace but a bunch of concatenated messages. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2271771014 From angorya at openjdk.org Tue Aug 6 17:26:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 17:26:36 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: <2e-mbpiyZ2dmyifwGUHVXg-jPVc9VdfVoMOyGkmEyzU=.a940a439-77df-415f-ba23-26825e7dbbcf@github.com> On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. not yet a review. noticed an issue on macOS. to reproduce, open a clip from the ticket, hit "play" and then drag the position slider someplace else. in the master branch, I see these in stderr: 2024-08-06 10:19:04.010 java[52568:1934744] CMTimeMakeWithSeconds(159.122 seconds, timescale 1): warning: error of -0.122 introduced due to very low timescale 2024-08-06 10:19:09.380 java[52568:1934744] CMTimeMakeWithSeconds(287.769 seconds, timescale 1): warning: error of -0.769 introduced due to very low timescale with this change, I see an exception in com.sun.media.jfxmediaimpl.NativeMediaPlayer:1530 because VideoResolution is being constructed with width=0 and height=0 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271782737 From angorya at openjdk.org Tue Aug 6 17:42:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 17:42:38 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. on my windows 11, I hear the audio but see no video (with this PR). am I missing any codecs? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271806495 From kcr at openjdk.org Tue Aug 6 17:42:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Aug 2024 17:42:39 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. Anything seen on macOS is unrelated to this PR. This PR only modifies Windows-specific platform code. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271807845 From kcr at openjdk.org Tue Aug 6 17:42:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Aug 2024 17:42:39 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Tue, 6 Aug 2024 17:37:16 GMT, Andy Goryachev wrote: > on my windows 11, I hear the audio but see no video (with this PR). am I missing any codecs? It should show the video as well. The expected behavior is that the video is shown with incorrect colors without this fix and shown with correct colors with the fix. I wouldn't expect any specific codec needed, but @sashamatveev can confirm. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271811937 From angorya at openjdk.org Tue Aug 6 18:39:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 18:39:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com> Message-ID: On Sun, 4 Aug 2024 22:51:33 GMT, John Hendrikx wrote: >> I don't understand this argument at all. Why would it be reasonable to _only_ build a more efficient architecture _if_ there's such a huge problem with the "naive" alternative that this alone would be readily apparent? If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance. >> >> Here's the thing: this code could reasonably be executed tens of thousands of times per second. Think of a complex user interface that changes its visual state for many nodes at once. What you seem to perceive as a micro-optimization is actually a part of an architecture that involves many types in the `Background` and `Border` area. >> >> The basic idea is: if I can rely on `interpolate()` returning existing instances (either the start value or the end value) if nothing has changed, then the "parent object's" interpolate method can use an identity comparison (which is basically for free) to choose whether to return itself (or the end value), or return a new instance. >> >> Let's look at the `Border.interpolate()` implementation: >> >> @Override >> public Border interpolate(Border endValue, double t) { >> Objects.requireNonNull(endValue, "endValue cannot be null"); >> if (t <= 0) return this; >> if (t >= 1) return endValue; >> >> // interpolateListsPairwise() is implemented such that it returns existing list instances >> // (i.e. the 'this.images' or 'endValue.images' arguments) as an indication that the result >> // is shallow-equal to either of the input arguments. This allows us to very quickly detect >> // if we can return 'this' or 'endValue' without allocating a new Border instance. >> List newImages = images == endValue.images ? >> images : InterpolationUtils.interpolateListsPairwise(images, endValue.images, t); >> >> List newStrokes = strokes == endValue.strokes ? >> strokes : InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t); >> >> if (images == newImages && strokes == newStrokes) { >> return this; >> } >> >> if (endValue.images == newImages && endValue.strokes == newStrokes) { >> return endValue; >> } >> >> return new Border(newStrokes, newImages); >> } >> >> >> `interpolateListsPairwise()` _already knows_ whether both lists are equal, which makes the `return this` and `return endValue` branches after the interp... > > I think you said that you didn't actually test this, so we don't know if this will perform better. It's based on an assumption of what Java will do, and on assumptions what is "bad" and what is "good". Without having tested this, you are optimizing blind. I would be entirely satisfied if you had said "I tested this with a few thousand transitions, the allocation turned out to be a hot spot, so I optimized it which is the reason this code looks a bit out of the ordinary". > > I also would have liked a comment explaining any pitfalls introduced by the optimization; the use of `==` by callers is unusual, and a crucial piece of information when I see code like: > > if (secondList.isEmpty()) { > return firstList.isEmpty() ? firstList : secondList; > } > > It would deserve at least an explanation that you're specifically returning one of the passed in arguments so callers can do reference equality checks. > > Java's JIT is very finicky. For example, an earlier comment asked if the first `if` case is the most common one. The assumption being that this will improve performance. However, you can't make that assumption at all (I've done tests that show it's almost impossible to predict which "if order" will be faster on the JVM); re-arranging a function or "unrolling" it can have large negative consequences if that means the JIT will no longer inline your function. > > Now, I will give you that this **probably** will be faster, but I'm making an assumption here... I really can't be sure. That still leaves some explanatory comments that I think you should add with the assumptions that were made for this optimization. > >> If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance. > > No, when hunting for performance problems, it will be readily apparent what total process is taking up all the time, and how often parts of it are being called and how much time they take in total. Put a profiler on it, and see where the actual time is being spent on a case with a lot of transitions if you want to optimize it. Even the JVM itself does this, not bothering to even compile code that isn't executed at least a certain amount of times, or not bothering to further optimize code after compilation if that code isn't in a hot path. > > What optimization generally does is it that it makes code harder to understand (almost unavoid... I think what is being done in this PR is fine, even though your arguments @hjohn are perfectly valid. One feature that I think has value is the fact that this design tries to limit new allocations, and I think it's a good thing. One interesting point you bring up is that we have no good performance test for CSS. What would represent a good performance test? Create a thousand of labels and measure the time it takes to update? Does it matter if it's a label or something else? And do we have a reliable way to measure? What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1705961254 From angorya at openjdk.org Tue Aug 6 18:39:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 18:39:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Fri, 2 Aug 2024 21:24:21 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix since tag >> - adjust table styling > > modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 311: > >> 309: } >> 310: } >> 311: } > > You could write this without nesting using `switch`: > > > switch(listSize) { > case 8: newArray[7] = item7; // fallthrough > case 7: newArray[6] = item6; > case 6: newArray[5] = item5; > // etc > } +1 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1705962174 From angorya at openjdk.org Tue Aug 6 19:17:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 19:17:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v16] In-Reply-To: References: Message-ID: On Sun, 4 Aug 2024 19:08:14 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > use HashMap.newHashMap() The code does not build in Eclipse. Could you please replace modules/graphics/.classpath with this: (that simply adds a missing dependency `:javafx.base/test.util=javafx.graphics` ) And also merge the latest master in please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2271972593 From angorya at openjdk.org Tue Aug 6 19:26:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 19:26:38 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. rebuilt the code with `rm -rf ./build; /bin/sh gradlew -PCOMPILE_MEDIA=true -PBUILD_TOOLS_DOWNLOAD_SCRIPT=../build-tools.gradle clean sdk apps javadoc` command. Still see no video (but I can hear audio). What gives? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271988770 From angorya at openjdk.org Tue Aug 6 19:35:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 19:35:38 GMT Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: <8lGkSwC0O10F4b8u330sNfWuz-oatuBqMOXog8V9Id4=.bbb3e2f9-7b52-4adb-9644-1358c9c7f17e@github.com> On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. the code changes look ok to me. can't test bc codec, but two other people have tested. Apparently, one needs to pay Microsoft $0.99 for HEVC codecs https://apps.microsoft.com/detail/9nmzlz57r3t7?hl=en-US&gl=US ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1525#pullrequestreview-2222087199 PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271999812 From mstrauss at openjdk.org Tue Aug 6 20:04:21 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Aug 2024 20:04:21 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v17] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... 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 38 additional commits since the last revision: - Merge branch 'refs/heads/master' into feature/interpolatable - add export - use HashMap.newHashMap() - add test for stop lists - add tests - remove ComponentTransitionable - move tests - added comments - move interpolation helpers to separate file - fix trailing whitespace - ... and 28 more: https://git.openjdk.org/jfx/compare/1c065481...eb9700a8 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/d7f21872..eb9700a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=15-16 Stats: 352910 lines in 7432 files changed: 186542 ins; 107958 del; 58410 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From almatvee at openjdk.org Tue Aug 6 20:46:49 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Aug 2024 20:46:49 GMT Subject: Integrated: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com> Message-ID: <6Z-4pKojjTAG52B3fhzW7fNCzq0MZi81JQCN4gZUpJQ=.4e9163f5-ac7d-483e-985a-6a6790f5f28b@github.com> On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev wrote: > - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format. > - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering. > - To detect such condition we will propose media format and then read it back to determine actual decoder output format. > - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV. > - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics. > - Added debug trace for formats. Disabled by default. This pull request has now been integrated. Changeset: 635a09c7 Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/635a09c7855351eac8001b60e240c826db3a6bff Stats: 628 lines in 2 files changed: 467 ins; 61 del; 100 mod 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 Reviewed-by: kcr, arapte, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1525 From almatvee at openjdk.org Tue Aug 6 20:56:52 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Aug 2024 20:56:52 GMT Subject: [jfx23u] RFR: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 Message-ID: - Clean backport of JDK-8336277. ------------- Commit messages: - Backport 635a09c7855351eac8001b60e240c826db3a6bff Changes: https://git.openjdk.org/jfx23u/pull/7/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=7&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336277 Stats: 628 lines in 2 files changed: 467 ins; 61 del; 100 mod Patch: https://git.openjdk.org/jfx23u/pull/7.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/7/head:pull/7 PR: https://git.openjdk.org/jfx23u/pull/7 From almatvee at openjdk.org Tue Aug 6 22:10:37 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Aug 2024 22:10:37 GMT Subject: [jfx23u] Integrated: 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 20:52:26 GMT, Alexander Matveev wrote: > - Clean backport of JDK-8336277. This pull request has now been integrated. Changeset: d0c5cd42 Author: Alexander Matveev URL: https://git.openjdk.org/jfx23u/commit/d0c5cd42d46be7773e5872dca0ceb442354755dd Stats: 628 lines in 2 files changed: 467 ins; 61 del; 100 mod 8336277: Colors are incorrect when playing H.265/HEVC on Windows 11 Backport-of: 635a09c7855351eac8001b60e240c826db3a6bff ------------- PR: https://git.openjdk.org/jfx23u/pull/7 From angorya at openjdk.org Tue Aug 6 22:46:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Aug 2024 22:46:43 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v4] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 17:58:30 GMT, John Hendrikx wrote: >> it looks to me readBinary should be static, and writeBinary an instance method - this is a normal pattern. the asymmetry is dictated by the fact that we don't have an instance when reading, so typically read() methods read the stream and create an instance at the last moment with the specific constructor. unless, of course, the design allows for mutation and the fields can be set(). >> >> Alternatively, readBinary() could be moved to another class (helper? reader?) to avoid making this an API change. >> >> what do you think? > > I can see if I can externalize this or if that would run into issues. Also please note, although technically an API change, it is NOT an accessible API (and so can be removed at any time) because only the permitted types can access this API. > > In other words, this could wait and be done separately or never. what is the resolution, @hjohn ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1706186666 From mstrauss at openjdk.org Tue Aug 6 23:47:13 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Aug 2024 23:47:13 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: replace StyleConverter.SupportsDeconstruction interface with annotation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/eb9700a8..61d595fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=16-17 Stats: 23 lines in 4 files changed: 16 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Tue Aug 6 23:49:40 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Aug 2024 23:49:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: <0vyp4GYEi2g96MOznMJFipCmWUqF6xGccSY-vXrt-BQ=.ad55b0fe-0226-4683-b045-f4e69333725a@github.com> References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> <0vyp4GYEi2g96MOznMJFipCmWUqF6xGccSY-vXrt-BQ=.ad55b0fe-0226-4683-b045-f4e69333725a@github.com> Message-ID: On Sun, 4 Aug 2024 22:55:22 GMT, John Hendrikx wrote: >> I don't quite like returning any particular value from `convertBack` as a signal for "this style converter doesn't support deconstruction", so I've made it more explicit with the marker interface `StyleConverter.SupportsDeconstruction`. This removes the marker interface `ComponentTransitionable` entirely. > > Thanks, I think having this with the StyleConverter makes more sense. I've replaced the marker interface with an annotation, since it seems to be more of a meta-statement about the type. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1706220057 From almatvee at openjdk.org Wed Aug 7 00:30:50 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 Aug 2024 00:30:50 GMT Subject: RFR: 8336938: Update libFFI to 3.4.6 Message-ID: - libFFI updated to 3.4.6. - No additional changes are done. - Tested on Windows, macOS and Linux with all supported formats. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into JDK-8336938 - 8336938: Update libFFI to 3.4.6 Changes: https://git.openjdk.org/jfx/pull/1531/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1531&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336938 Stats: 1055 lines in 26 files changed: 388 ins; 373 del; 294 mod Patch: https://git.openjdk.org/jfx/pull/1531.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1531/head:pull/1531 PR: https://git.openjdk.org/jfx/pull/1531 From jhendrikx at openjdk.org Wed Aug 7 01:10:25 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 01:10:25 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v5] In-Reply-To: References: Message-ID: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Make match fields private by moving match creation logic - Move binary CSS serialization code to internal class ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1333/files - new: https://git.openjdk.org/jfx/pull/1333/files/4702972d..efe1beea Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=03-04 Stats: 390 lines in 6 files changed: 221 ins; 156 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From jhendrikx at openjdk.org Wed Aug 7 01:38:55 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 01:38:55 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v6] In-Reply-To: References: Message-ID: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Improve error message - Merge remote-tracking branch 'origin/master' into feature/selectors-to-private-api-standalone - Make match fields private by moving match creation logic - Move binary CSS serialization code to internal class - Fix review comments - Merge branch 'master' of https://git.openjdk.org/jfx into feature/selectors-to-private-api-standalone - Add since tags - Move SimpleSelector and CompoundSelector to private classes ------------- Changes: https://git.openjdk.org/jfx/pull/1333/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=05 Stats: 1830 lines in 14 files changed: 907 ins; 887 del; 36 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From jhendrikx at openjdk.org Wed Aug 7 02:13:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 02:13:12 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix bug ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1333/files - new: https://git.openjdk.org/jfx/pull/1333/files/7d77e43e..39c94408 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=05-06 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From jhendrikx at openjdk.org Wed Aug 7 02:13:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 02:13:12 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 22:43:48 GMT, Andy Goryachev wrote: >> I can see if I can externalize this or if that would run into issues. Also please note, although technically an API change, it is NOT an accessible API (and so can be removed at any time) because only the permitted types can access this API. >> >> In other words, this could wait and be done separately or never. > > what is the resolution, @hjohn ? - I've moved the serialization logic to `BinarySerializer` and removed the two methods from `Selector`. `writeBinary` was `protected` but couldn't be accessed before anyway as it was impossible to subclass `Selector` (as it had a package private constructor) - I've moved most of the code to create a `Match` to the `Match` class so the relevant fields can now be `private`. Let me know if this is an improvement. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1706292988 From duke at openjdk.org Wed Aug 7 05:36:46 2024 From: duke at openjdk.org (robbiezl) Date: Wed, 7 Aug 2024 05:36:46 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec I tested it in the following two Linux environments, and the Chinese input looks fine. Env1: ????:LinxOS 6.0.99 EL20.03-SP3 20240531 \n \l ???Linux version 4.19.90-2206.2.0.0154.vlx15.v99_2003.x86_64 (root at runner-sdczntp1-project-3842-concurrent-0) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 29 10:22:41 CST 2024 Env2: ????:[dist] name = KylinSec-Server-PG milestone = V3-240605-1330 arch = x86_64 dist_id = KylinSec-Server-PG-V3-240605-1330-x86_64 [os] installtype = graphical-server-environment ???Linux version 4.19.90-2405.3.0.0276.kb1.ky3_4.x86_64 (mockbuild at localhost.localdomain) (gcc version 7.3.0 (GCC)) #1 SMP Thu May 23 16:22:59 CST 2024 > @Glavo did you get any feedback? > > I can provide a build with this PR included, if that's getting on the way. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2272653202 From arapte at openjdk.org Wed Aug 7 14:44:39 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 7 Aug 2024 14:44:39 GMT Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra wrote: > In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible. > > This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs. > > Both D3D and ES2 Prism backends were updated to properly handle these changes. > > NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change. > > I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples. Marked as reviewed by arapte (Reviewer). The change looks good. D3D and ES2 pipeline work as expected after a clean build. It seems good for Metal pipeline too. Merge requires a few minor expected changes(similar to D3D/ES2 in this PR + another). ------------- PR Review: https://git.openjdk.org/jfx/pull/1530#pullrequestreview-2225412705 PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2273642280 From angorya at openjdk.org Wed Aug 7 14:53:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 14:53:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > replace StyleConverter.SupportsDeconstruction interface with annotation modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 108: > 106: public @interface SupportsReconstruction {} > 107: > 108: final boolean supportsReconstruction; would it be easier just to pass a boolean to the constructor? we are changing the public API anyway... also: since the boolean is package protected, should we have a (short) javadoc for it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707173763 From mstrauss at openjdk.org Wed Aug 7 15:23:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 15:23:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 14:50:39 GMT, Andy Goryachev wrote: > would it be easier just to pass a boolean to the constructor? we are changing the public API anyway... Usually boolean parameters are not a good API choice, but I have no strong opinion on this one. What do you prefer? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707218233 From angorya at openjdk.org Wed Aug 7 15:23:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 15:23:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> On Wed, 7 Aug 2024 15:08:30 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 108: >> >>> 106: public @interface SupportsReconstruction {} >>> 107: >>> 108: final boolean supportsReconstruction; >> >> would it be easier just to pass a boolean to the constructor? >> we are changing the public API anyway... >> >> also: since the boolean is package protected, should we have a (short) javadoc for it? > >> would it be easier just to pass a boolean to the constructor? we are changing the public API anyway... > > Usually boolean parameters are not a good API choice, but I have no strong opinion on this one. What do you prefer? I just think it's much simpler than an annotation... Or it could be a public instance method `boolean isSupportReconstruction()` for the child classes to override, saving N (1? 8?) bytes per instance. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707228516 From jhendrikx at openjdk.org Wed Aug 7 15:23:43 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 15:23:43 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> Message-ID: On Wed, 7 Aug 2024 15:12:22 GMT, Andy Goryachev wrote: >>> would it be easier just to pass a boolean to the constructor? we are changing the public API anyway... >> >> Usually boolean parameters are not a good API choice, but I have no strong opinion on this one. What do you prefer? > > I just think it's much simpler than an annotation... > > Or it could be a public instance method `boolean isSupportReconstruction()` for the child classes to override, saving N (1? 8?) bytes per instance. But the annotation costs no bytes per instance, if that even matters, as I thought these were singletons so it looks like we're quite into micro-optimization territory here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707250058 From mstrauss at openjdk.org Wed Aug 7 15:37:41 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 15:37:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> Message-ID: <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> On Wed, 7 Aug 2024 15:21:18 GMT, John Hendrikx wrote: >> I just think it's much simpler than an annotation... >> >> Or it could be a public instance method `boolean isSupportReconstruction()` for the child classes to override, saving N (1? 8?) bytes per instance. > > But the annotation costs no bytes per instance, if that even matters, as I thought these were singletons so it looks like we're quite into micro-optimization territory here. Whether a style converter supports reconstruction should be a statement about the type, not a statement about the instance. For this reason, I don't prefer an instance method like `isSupportReconstruction()`. In any case, these are our options: 1. Boolean parameter / Feature enum passed to constructor 2. Instance method `isSupportReconstruction()` 3. Annotation 4. Empty marker interface 5. Interface with the `convertBack` method 6. Subclassing I lean slightly towards the annotation, but I'm generally okay with either option. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707281230 From angorya at openjdk.org Wed Aug 7 16:06:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 16:06:43 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Wed, 7 Aug 2024 15:34:37 GMT, Michael Strau? wrote: >> But the annotation costs no bytes per instance, if that even matters, as I thought these were singletons so it looks like we're quite into micro-optimization territory here. > > Whether a style converter supports reconstruction should be a statement about the type, not a statement about the instance. For this reason, I don't prefer an instance method like `isSupportReconstruction()`. In any case, these are our options: > 1. Boolean parameter / Feature enum passed to constructor > 2. Instance method `isSupportReconstruction()` > 3. Annotation > 4. Empty marker interface > 5. Interface with the `convertBack` method > 6. Subclassing > > I lean slightly towards the annotation, but I'm generally okay with either option. I just saw a boolean variable being instantiated from an annotation and thought "why jump through the multiple hoops?". since there is a boolean, why not pass it directly? it's less about memory allocation (though I would prefer to minimize that as well, but as @hjohn pointed out the difference is just a few bytes), but more about "entities must not be multiplied beyond necessity". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707345002 From quizynox at gmail.com Wed Aug 7 16:20:35 2024 From: quizynox at gmail.com (quizynox at gmail.com) Date: Wed, 7 Aug 2024 20:20:35 +0400 Subject: Linux memory leak? Message-ID: Hello, Through developing JavaFX apps on Linux (X11, KDE) I always see the pattern when process (native?) memory doesn't get released back to the OS. 1. when app starts, the Java process consumes a relatively small amount of RAM (I track this via top or DE system monitor), usually around 120Mb. 2. if you do any manipulation with Stage (like resize it several times, or open the context menu several times) the memory process usage goes up to 130Mb. 3. then comes GC, which collects some _heap_ memory and returns it back to the OS depending on JVM settings, let say -5Mb 4. I repeat step 2, and JVM process process usage goes up again, +10Mb 5. again GC collects some _heap_ memory and uncommits it back to OS, -5Mb I have profiled the application with JDK 21 / JavaFX 21 and the following settings: -Xms32m -Xmx64m -XX:+UseZGC -XX:+ZUncommit -XX:ZUncommitDelay=30 Heap is not a problem, it's always ~20-30MB. Metaspace is not a problem either, it's always around 2-4MB. It looks like native (stack, thread?) memory leaks, so never returned to the OS. I've never seen JavaFX app process memory usage return (not even close) to the same value it started with. RAM usage increases gradually and can be 1.5, 2, 3 times the initial value. Yet the heap usage never rises above the -Xms value. I run the same application (it's basically an empty stage) on Windows and see no such behavior. Process memory usage returns back to initial value almost immediately. Also, on Windows the JVM is freeing memory even without using ZGC. How should I profile this? Any hints? From angorya at openjdk.org Wed Aug 7 16:23:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 16:23:45 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > replace StyleConverter.SupportsDeconstruction interface with annotation This transition does not interpolate linearly. Should it? .button { } .button:hover { -fx-font-size:200%; transition: -fx-font-size 2s linear; } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2273849547 From mstrauss at openjdk.org Wed Aug 7 16:46:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 16:46:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 16:21:11 GMT, Andy Goryachev wrote: > This transition does not interpolate linearly. Should it? > > ``` > .button { > } > > .button:hover { > -fx-font-size:200%; > transition: > -fx-font-size 2s linear; > } > ``` `Font` is not `Interpolatable`, and its style converter does not support reconstruction. Thus it falls back to discrete interpolation. I'll file a new ticket to track this enhancement. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2273888259 From thiago.sayao at gmail.com Wed Aug 7 16:57:32 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 7 Aug 2024 13:57:32 -0300 Subject: Linux memory leak? In-Reply-To: References: Message-ID: Hi, There are some tips in this post (I've never tried them). GTK related environment variables generally work. https://stackoverflow.com/questions/16659781/memory-leaks-in-gtk-hello-world-program valgrind and java: https://stackoverflow.com/questions/9216815/valgrind-and-java -- Thiago Em qua., 7 de ago. de 2024 ?s 13:20, escreveu: > Hello, > > Through developing JavaFX apps on Linux (X11, KDE) I always see the > pattern when process (native?) memory doesn't get released back to the OS. > > 1. when app starts, the Java process consumes a relatively small amount > of RAM (I track this via top or DE system monitor), usually around 120Mb. > 2. if you do any manipulation with Stage (like resize it several times, > or open the context menu several times) the memory process usage goes up > to 130Mb. > 3. then comes GC, which collects some _heap_ memory and returns it back > to the OS depending on JVM settings, let say -5Mb > 4. I repeat step 2, and JVM process process usage goes up again, +10Mb > 5. again GC collects some _heap_ memory and uncommits it back to OS, -5Mb > > I have profiled the application with JDK 21 / JavaFX 21 and the > following settings: > -Xms32m > -Xmx64m > -XX:+UseZGC > -XX:+ZUncommit > -XX:ZUncommitDelay=30 > > Heap is not a problem, it's always ~20-30MB. > Metaspace is not a problem either, it's always around 2-4MB. > > It looks like native (stack, thread?) memory leaks, so never returned to > the OS. I've never seen JavaFX app process memory usage return (not even > close) to the same value it started with. RAM usage increases gradually > and can be 1.5, 2, 3 times the initial value. Yet the heap usage never > rises above the -Xms value. > > I run the same application (it's basically an empty stage) on Windows > and see no such behavior. Process memory usage returns back to initial > value almost immediately. Also, on Windows the JVM is freeing memory > even without using ZGC. > > How should I profile this? Any hints? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Aug 7 17:44:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 17:44:45 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > replace StyleConverter.SupportsDeconstruction interface with annotation I could not find in cssref.html any reference to which properties are interpolatable, and which components of interpolatable and which support reconstruction. I think we need to update the spec with this information. For example, the following does not interpolate, is it because I am doing something wrong or the border radius is not interpolatable? .button { -fx-border-radius: 100; } .button:hover { -fx-border-radius: 1; transition: -fx-border-radius 2s linear; } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2273997052 From angorya at openjdk.org Wed Aug 7 17:49:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 17:49:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > replace StyleConverter.SupportsDeconstruction interface with annotation Somewhat tangential question: perhaps this enhancement needs a JEP (or a JEP-formatted doc) for future reference. The github infrastructure may one day disappear but I think these kinds of documents should be preserved. Even more tangential question is where to put these docs? For example, I think a good place might be in /doc-files somewhere, makes the review process easier. We've been creating these docs in private repos which I think is not a good place for the final product (i.e. when the feature is integrated). What do you think? (I will also post this question in the mailing list). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274004355 From quizynox at gmail.com Wed Aug 7 17:54:49 2024 From: quizynox at gmail.com (mkpaz) Date: Wed, 7 Aug 2024 21:54:49 +0400 Subject: Linux memory leak? In-Reply-To: References: Message-ID: <6deba86d-21ac-487c-85b8-2c4cf497e7cd@gmail.com> I tried using jemalloc, but the generated output (attachment) looks useless to me. https://gist.github.com/thomasdarimont/79b3cef01e5786210309 On 07/08/2024 20.57, Thiago Milczarek Say?o wrote: > Hi, > > There are some tips in this post (I've?never tried them). GTK related > environment variables generally work. > https://stackoverflow.com/questions/16659781/memory-leaks-in-gtk-hello-world-program > > valgrind and java: > https://stackoverflow.com/questions/9216815/valgrind-and-java > > > -- Thiago > > > Em qua., 7 de ago. de 2024 ?s 13:20, escreveu: > > Hello, > > Through developing JavaFX apps on Linux (X11, KDE) I always see the > pattern when process (native?) memory doesn't get released back to > the OS. > > 1. when app starts, the Java process consumes a relatively small > amount > of RAM (I track this via top or DE system monitor), usually around > 120Mb. > 2. if you do any manipulation with Stage (like resize it several > times, > or open the context menu several times) the memory process usage > goes up > to 130Mb. > 3. then comes GC, which collects some _heap_ memory and returns it > back > to the OS depending on JVM settings, let say -5Mb > 4. I repeat step 2, and JVM process process usage goes up again, +10Mb > 5. again GC collects some _heap_ memory and uncommits it back to > OS, -5Mb > > I have profiled the application with JDK 21 / JavaFX 21 and the > following settings: > -Xms32m > -Xmx64m > -XX:+UseZGC > -XX:+ZUncommit > -XX:ZUncommitDelay=30 > > Heap is not a problem, it's always ~20-30MB. > Metaspace is not a problem either, it's always around 2-4MB. > > It looks like native (stack, thread?) memory leaks, so never > returned to > the OS. I've never seen JavaFX app process memory usage return > (not even > close) to the same value it started with. RAM usage increases > gradually > and can be 1.5, 2, 3 times the initial value. Yet the heap usage > never > rises above the -Xms value. > > I run the same application (it's basically an empty stage) on Windows > and see no such behavior. Process memory usage returns back to > initial > value almost immediately. Also, on Windows the JVM is freeing memory > even without using ZGC. > > How should I profile this? Any hints? > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: app-profiling.pdf Type: application/pdf Size: 16923 bytes Desc: not available URL: From andy.goryachev at oracle.com Wed Aug 7 17:58:43 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 7 Aug 2024 17:58:43 +0000 Subject: No Place for JEPs Message-ID: Dear fellow developers: We often create JEPs and JEP-formatted documents as we propose and develop new features. These help us during the review process and I am sure are of some benefit for application developers as they try to learn the new functionality in depth. Presently, we've been creating these files in personal repositories, or presented as descriptions for pull requests, see for example [0]. I think there is a value in making these documents a part of the main repository, maybe under /doc-files. Doing so would help with the review process as the markdown files are both human-readable and easily diff'ed. Also, I think it might be more convenient to keep them in the same repo as the code, as opposed to the some personal repositories or wikis. What do you think? -andy References [0] https://github.com/openjdk/jfx/pull/1522 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Aug 7 18:34:38 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 18:34:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 17:42:29 GMT, Andy Goryachev wrote: > I could not find in `cssref.html` any reference to which properties are interpolatable, and which components of interpolatable and which support reconstruction. I think we need to update the spec with this information. > > For example, the following does not interpolate, is it because I am doing something wrong or the border radius is not interpolatable? > > ``` > .button { > -fx-border-radius: 100; > } > > .button:hover { > -fx-border-radius: 1; > transition: > -fx-border-radius 2s linear; > } > ``` You probably don't see anything because Modena's button doesn't have a visible border. Try specifying some color to make it visible: .button { -fx-border-radius: 10, -fx-border-color: red; } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274084408 From mstrauss at openjdk.org Wed Aug 7 18:47:38 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 18:47:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 17:47:08 GMT, Andy Goryachev wrote: > Somewhat tangential question: perhaps this enhancement needs a JEP (or a JEP-formatted doc) for future reference. The github infrastructure may one day disappear but I think these kinds of documents should be preserved. > > Even more tangential question is where to put these docs? For example, I think a good place might be in /doc-files somewhere, makes the review process easier. We've been creating these docs in private repos which I think is not a good place for the final product (i.e. when the feature is integrated). > > What do you think? (I will also post this question in the mailing list). Isn't this the purpose of the CSR documents? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274118227 From john.hendrikx at gmail.com Wed Aug 7 18:52:32 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 7 Aug 2024 20:52:32 +0200 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: <4058b4c3-94fc-4bc6-9604-c6c93e7d8c15@gmail.com> Hey Michael, Thanks, I totally forgotten about that post apparently, perhaps we can make this work. I thought of something else as well. We seem to be assuming that checking the Thread is the expensive part, where it in reality is one of the cheapest checks that we can do.? We could always check the thread, and only do a further investigation if that thread is NOT the FX thread, perhaps something like this: ??? if (getBean() != null && !Thread.currentThread().equals(FXThread)) { ????????? // Investigate further... we're either offline (safe) or online (not safe) ????????? if (notSafe()) throw exception; ??? } ??? // proceed as normal The above checks are both incredibly cheap. In the case where we want to do a deeper investigation, we're either offline where performance will be a lot less important (graphs can be built by other threads), or we're online, which is the case that we want to warn users about.? In both cases, a somewhat reduced performance won't matter much, while the case when the graph is live and is called correctly will be perform almost unimpeded. --John On 05/08/2024 17:35, Michael Strau? wrote: > Hi John, > > this seems to be a very similar idea to what I've proposed a year ago: > https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/041925.html > > I think the potential performance impact needs to be carefully considered. From john.hendrikx at gmail.com Wed Aug 7 18:55:09 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 7 Aug 2024 20:55:09 +0200 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> Message-ID: <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com> For detecting long running tasks on the FX thread, there are some other options which you can do as a user (but perhaps we can support it directly within FX).? I use this kind of code to detect long running things on the FX thread: /** * Adds a slow event warning whenever an event takes more than 10 msto process. Note * that time spent in nested event loops cannot be properly taken into account as time * spent in nested event loops will be part of the event that triggered it giving false * positives. In order for this time to be accurately reflected, the methods to enter * a nested event loop in this class should be used instead of the ones in {@link Platform}. * * @paramscene a Scene to which to add the slow event warning detection, cannot be null */ publicstaticvoidaddSlowEventWarning(Scene scene) { finalEventDispatcher eventDispatcher = scene.getEventDispatcher(); scene.setEventDispatcher(newEventDispatcher() { privateScheduledFuture future; @Override publicEvent dispatchEvent(Event event, EventDispatchChain tail) { if(future!= null) { future.cancel(false); } longstartTime = System.currentTimeMillis(); TIME_TRACKER.enterNested(startTime); // nesting can happen in two ways, an event triggering another event, or when a nested event loop is entered Event returnedEvent = eventDispatcher.dispatchEvent(event, tail); longendTime = System.currentTimeMillis(); longtimeSpentInNested = TIME_TRACKER.exitNested(endTime); if(timeSpentInNested > 10) { longtotal = endTime - startTime; LOGGER.warning("Slow Event (self/total: "+ timeSpentInNested + "/"+ total + " ms @ level "+ TIME_TRACKER.getCurrentLevel() + "): "+ event); } returnreturnedEvent; } }); } --John On 05/08/2024 17:17, Thiago Milczarek Say?o wrote: > Hi, > > Interesting idea. We have this problem specially when Junior > developers touch the code. > > The other way around would be nice too - if some I/O task executes on > the FX thread. > > This can make the OS think the application hanged and offer to kill > it, since it won't respond to "pings". And I/O tasks processing time > may vary between installations. Also causes "white screens" since it > blocks painting. > > -- Thiago. > > Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth > escreveu: > >> Wouldn't it be better to implement this check in assert to avoid >> any impact in production? > > No. Using an assert in a case like this is an anti-pattern. A call > to assert in a library such as JavaFX is only appropriate for > checking an invariant in internal logic. If we are going to go > down this route of doing a thread check when mutating properties > of "live" nodes, we will throw the same IllegalStateException that > is currently thrown by some methods on Stage and Scene. > > As for the proposal itself, adding this check is an interesting > idea. We considered doing this back in the JDK 7 (JavaFX 2) time > frame, but decided not to pursue it then. I think the idea is > worth further discussion. I would limit any thread checking to > setting the property. It would be too restrictive (and largely > unnecessary) to prevent reading a property from the application > thread. > > The things to consider would be: > > 1. What is the performance hit of doing this check on the setting > of every property? > 2. What is the effect on bound properties? > 3. How intrusive is it in the code? > 4. Should we add a property to enable / disable the thread check, > possibly a three- or four-valued property > (allow|warn|debug?|deny), as was recently done in JEP 471 for > sun.misc.Unsafe memory access methods. If so, what should the > default be? > > My quick take is that if this can be done in a minimally intrusive > manner with low overhead, we should consider pursing this. As for > 4, my preference would be to add a three- or four-valued system > property to control the check, with "warn" as the default > initially, changing the default to "disallow" in a subsequent > version. This would, of course, require a lot of testing. > > -- Kevin > > > On 8/4/2024 8:40 PM, quizynox wrote: >> Hello, >> >> Wouldn't it be better to implement this check in assert to avoid >> any impact in production? >> >> ??, 5 ???. 2024??. ? 03:30, John Hendrikx : >> >> Hi list, >> >> I know of quite some bugs and users that have been bitten by the >> threading model used by JavaFX.? Basically, anything directly or >> indirectly linked to an active Scene must be accessed on the >> FX thread. >> However, as FX also allows manipulating nodes and properties >> before >> they're displayed, there can be no "hard" check everywhere to >> ensure we >> are on the FX thread (specifically, in properties). >> >> Now, I think this situation is annoying, as a simple mistake >> where a >> Platform.runLater wrapper was forgotten usually results in >> programs >> operating mostly flawlessly, but then fail in mysterious and >> random and >> hard to reproduce ways.? The blame is often put on FX as the >> resulting >> exceptions will almost never show the user code which was the >> actual >> culprit.? It can result in FX being perceived as unstable or >> buggy. >> >> So I've been thinking if there isn't something we can do to >> detect these >> bugs originating from user code much earlier, similar to the >> `ConcurrentModificationException` the collection classes do when >> accessed in nested or concurrent contexts. >> >> I think it may be possible to have properties check whether >> they're part >> of an active scene without too much of an performance impact, >> possibly >> even behind a switch. It would work like this: >> >> Properties involved with Nodes will have an associated bean >> instance >> (`getBean`).? This is an object, but we could check here if this >> instance implements an interface: >> >> ????? if (getBean() instanceof MayBePartOfSceneGraph x) { >> ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) { >> ???????????????? throw new IllegalStateException("Property >> must only be >> used from the FX Application Thread"); >> ??????????? } >> ????? } >> >> This check could be done on every set of the property, and >> potentially >> on every get as well.? It should be relatively cheap, but >> will expose >> problematic code patterns at a much earlier stage. There's a >> chance >> that this will "break" some programs that seemed to be behaving >> correctly as well, so we may want to put it behind a switch >> until such >> programs (or libraries) can be fixed. >> >> What do you all think? >> >> --John >> >> (*) Names of methods/interfaces are only used for >> illustration purposes, >> we can think of good names if this moves forward. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Aug 7 18:58:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 18:58:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 18:45:00 GMT, Michael Strau? wrote: > Isn't this the purpose of the CSR documents? These two are related but not the same, per https://wiki.openjdk.org/display/csr/CSR+FAQs : Q: What is the relationship between a CSR and a JEP? A: A JEP ([JDK Enhancement-Proposal](http://openjdk.java.net/jeps/0)) initially describes a project to update some aspect of the JDK. The exact details of the updates are usually not yet known when the JEP begins. Before a JEP is advanced to the Candidate state, it is strongly recommended the CSRs of a JEP go through at least the first phase of CSR review to Provisional state. Before a JEP is advanced to the Proposed to Target state, CSRs associated with the JEP must have advanced through to at least the CSR Provisional state. For Proposed to Target, the CSRs covering the work of a JEP may also go fully through the CSR process to the Approved state rather than the Provisional state. As the JEP matures, the updates to the JDK associated with the JEP are pushed under one or more changesets. Each changeset that involves a specification change (or sufficiently large compatibility impact) would also require CSR review, just as done for other changes to the JDK. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274142010 From john.hendrikx at gmail.com Wed Aug 7 19:01:44 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 7 Aug 2024 21:01:44 +0200 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: Hi Andy, Problems that occur due to modifying the scene graph (like adding/removing children, or changing certain properties) can be incredibly subtle, and almost never point out the code that is the actual culprit.? I suspect that the PR below is one of those for example, but there are likely many more. https://github.com/openjdk/jfx/pull/1123 Issues that complain about some kind of odd bug in the FX code (like a NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, etc) could all be caused by user code doing things on the wrong thread, but its really hard to diagnose as the stack traces provided will never point out the user code that may be the culprit.? I've investigated PR 1123 extensively, and I can't see any bugs in the FX code at all **assuming** it is used from a single thread... --John On 05/08/2024 17:01, Andy Goryachev wrote: > > John: > > Can you cite a bug or give an example of such a problem? > > During all my time of actively using javafx (since about 2015) I have > never encountered an issue with threading you describe.? It is > possible that I use the system trivially and not to the full extent.? > Both swing and javafx are single threaded by design.? Yes, there might > be occasions when one can use multiple threads and it is sort of > allowed, but doing so may lead to unpleasant issues down the road, so > the question is why would you want to do that? > > -andy > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Sunday, August 4, 2024 at 16:30 > *To: *openjfx-dev at openjdk.org > *Subject: *Detecting threading problems faster > > Hi list, > > I know of quite some bugs and users that have been bitten by the > threading model used by JavaFX.? Basically, anything directly or > indirectly linked to an active Scene must be accessed on the FX thread. > However, as FX also allows manipulating nodes and properties before > they're displayed, there can be no "hard" check everywhere to ensure we > are on the FX thread (specifically, in properties). > > Now, I think this situation is annoying, as a simple mistake where a > Platform.runLater wrapper was forgotten usually results in programs > operating mostly flawlessly, but then fail in mysterious and random and > hard to reproduce ways.? The blame is often put on FX as the resulting > exceptions will almost never show the user code which was the actual > culprit.? It can result in FX being perceived as unstable or buggy. > > So I've been thinking if there isn't something we can do to detect these > bugs originating from user code much earlier, similar to the > `ConcurrentModificationException` the collection classes do when > accessed in nested or concurrent contexts. > > I think it may be possible to have properties check whether they're part > of an active scene without too much of an performance impact, possibly > even behind a switch. It would work like this: > > Properties involved with Nodes will have an associated bean instance > (`getBean`).? This is an object, but we could check here if this > instance implements an interface: > > ????? if (getBean() instanceof MayBePartOfSceneGraph x) { > ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) { > ???????????????? throw new IllegalStateException("Property must only be > used from the FX Application Thread"); > ??????????? } > ????? } > > This check could be done on every set of the property, and potentially > on every get as well.? It should be relatively cheap, but will expose > problematic code patterns at a much earlier stage. There's a chance > that this will "break" some programs that seemed to be behaving > correctly as well, so we may want to put it behind a switch until such > programs (or libraries) can be fixed. > > What do you all think? > > --John > > (*) Names of methods/interfaces are only used for illustration purposes, > we can think of good names if this moves forward. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Aug 7 19:38:33 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 7 Aug 2024 19:38:33 +0000 Subject: [External] : Re: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: John: Looks like the issue in PR#1123 was caused by application code accessing FX from a non-FX thread. I know the discussion is about trying to detect thread misuse early on, as a way to help the application developers. I vaguely recall the discussion we had at some point about adding the check to property invalidation code or some such, and the general consensus was that it might pose a compatibility risk or something along these lines. Perhaps there is a place where such a check might be safely made (I don't know of any such place though)? We did, after all, step on the path of simplification (?) for the sake of students (see https://openjdk.org/jeps/445 ). Perhaps such a check could be hidden behind a system property so as not to break existing, if poorly written, applications. Personally, I feel that it should be the first thing taught - always call FX from the FX application thread. I am curious what other members of community think of this issue. -andy From: John Hendrikx Date: Wednesday, August 7, 2024 at 12:01 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Detecting threading problems faster Hi Andy, Problems that occur due to modifying the scene graph (like adding/removing children, or changing certain properties) can be incredibly subtle, and almost never point out the code that is the actual culprit. I suspect that the PR below is one of those for example, but there are likely many more. https://github.com/openjdk/jfx/pull/1123 Issues that complain about some kind of odd bug in the FX code (like a NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, etc) could all be caused by user code doing things on the wrong thread, but its really hard to diagnose as the stack traces provided will never point out the user code that may be the culprit. I've investigated PR 1123 extensively, and I can't see any bugs in the FX code at all **assuming** it is used from a single thread... --John On 05/08/2024 17:01, Andy Goryachev wrote: John: Can you cite a bug or give an example of such a problem? During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe. It is possible that I use the system trivially and not to the full extent. Both swing and javafx are single threaded by design. Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would you want to do that? -andy From: openjfx-dev on behalf of John Hendrikx Date: Sunday, August 4, 2024 at 16:30 To: openjfx-dev at openjdk.org Subject: Detecting threading problems faster Hi list, I know of quite some bugs and users that have been bitten by the threading model used by JavaFX. Basically, anything directly or indirectly linked to an active Scene must be accessed on the FX thread. However, as FX also allows manipulating nodes and properties before they're displayed, there can be no "hard" check everywhere to ensure we are on the FX thread (specifically, in properties). Now, I think this situation is annoying, as a simple mistake where a Platform.runLater wrapper was forgotten usually results in programs operating mostly flawlessly, but then fail in mysterious and random and hard to reproduce ways. The blame is often put on FX as the resulting exceptions will almost never show the user code which was the actual culprit. It can result in FX being perceived as unstable or buggy. So I've been thinking if there isn't something we can do to detect these bugs originating from user code much earlier, similar to the `ConcurrentModificationException` the collection classes do when accessed in nested or concurrent contexts. I think it may be possible to have properties check whether they're part of an active scene without too much of an performance impact, possibly even behind a switch. It would work like this: Properties involved with Nodes will have an associated bean instance (`getBean`). This is an object, but we could check here if this instance implements an interface: if (getBean() instanceof MayBePartOfSceneGraph x) { if (x.isPartOfActiveScene() && !isOnFxThread()) { throw new IllegalStateException("Property must only be used from the FX Application Thread"); } } This check could be done on every set of the property, and potentially on every get as well. It should be relatively cheap, but will expose problematic code patterns at a much earlier stage. There's a chance that this will "break" some programs that seemed to be behaving correctly as well, so we may want to put it behind a switch until such programs (or libraries) can be fixed. What do you all think? --John (*) Names of methods/interfaces are only used for illustration purposes, we can think of good names if this moves forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Aug 7 20:03:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 20:03:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v19] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: interpolate integers in real number space ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/61d595fd..c36c6c05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=17-18 Stats: 67 lines in 3 files changed: 55 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Wed Aug 7 20:03:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 20:03:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <9oq88dfCt9HRiDyl8zizIpvYlkDIggCzO5VwBcs9-TY=.3649f067-6a4d-4ed5-84e1-7a818cc27fdf@github.com> References: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com> <9oq88dfCt9HRiDyl8zizIpvYlkDIggCzO5VwBcs9-TY=.3649f067-6a4d-4ed5-84e1-7a818cc27fdf@github.com> Message-ID: On Fri, 2 Aug 2024 16:19:15 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 136: >> >>> 134: @Override >>> 135: public void onUpdate(double progress) { >>> 136: set(progress < 1 ? startValue + (long)((endValue - startValue) * progress) : endValue); >> >> minor: should it use (long)Math.round() ? > > edit: I think it should. You're right, I've updated the implementation and added tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707796319 From angorya at openjdk.org Wed Aug 7 20:54:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 20:54:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v19] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 20:03:17 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > interpolate integers in real number space Regarding `cssref.html`: 1. I think it might make sense to add a section after "Transitions" talking about component transitions, maybe with examples. 2. I think we should to mention interpolation behavior next to each property name somehow. Either mark the properties that do support it, or only those that do not support. It is already documented in javadoc, but cssref.html is a normative document for CSS. what do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274327067 From jhendrikx at openjdk.org Wed Aug 7 21:01:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 21:01:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Wed, 7 Aug 2024 16:03:59 GMT, Andy Goryachev wrote: >> Whether a style converter supports reconstruction should be a statement about the type, not a statement about the instance. For this reason, I don't prefer an instance method like `isSupportReconstruction()`. In any case, these are our options: >> 1. Boolean parameter / Feature enum passed to constructor >> 2. Instance method `isSupportReconstruction()` >> 3. Annotation >> 4. Empty marker interface >> 5. Interface with the `convertBack` method >> 6. Subclassing >> >> I lean slightly towards the annotation, but I'm generally okay with either option. > > I just saw a boolean variable being instantiated from an annotation and thought "why jump through the multiple hoops?". since there is a boolean, why not pass it directly? > > it's less about memory allocation (though I would prefer to minimize that as well, but as @hjohn pointed out the difference is just a few bytes), but more about "entities must not be multiplied beyond necessity". Although I'm not advocating for a specific change, I think looking at how `T convert(Map)` works when it was newly introduced in Java 9 should be taken into account as well. There seem to be a couple of general approaches: 1. Have a marker that can be checked from the outside - Annotation (checked from the outside) - Unusual for this kind of check - Marker interface - Seen more often, but unusual to not put the new method there - Subtype - Bad idea, you can only inherit once 2. Introduce a new interface with the new method - Defines the method and serves as the marker at the same time 3. Have a method that can be called that guards a 2nd method call - Doesn't matter how this is fed (constructor, annotation, override) - You see this more often, but it's not a great pattern (2 method calls for the price of one...) 4. Return a special value from a method that may be unsupported - The most obvious (modern) candidate is to return `Optional` but is a bit unusual to indicate support/non-support - Throw `UnsupportedOperationException` -- although standard, I think it indicates a programmer mistake that should be avoided (in other words, encountering this exception in production code should result in a code fix) - Return `null` Now the very last option (returning `null`) was the way this was handled when `T convert(Map)` was introduced in Java 9. Even though it may not be the prettiest solution, it has two things going for it: - It's fast (probably the fastest of the above options, although for most by just a slim margin) - It fits in with the existing design So, my order of preference: - Just return `null` - A new interface, which includes the new method - A marker only interface - A supportsXYZ method (regardless of how that is approached) I don't think I could get behind any of the other options, because they either stick out like a sore thumb versus the existing design, limit future options or just perform too poorly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707899228 From john.hendrikx at gmail.com Wed Aug 7 21:53:04 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 7 Aug 2024 23:53:04 +0200 Subject: [External] : Re: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: On 07/08/2024 21:38, Andy Goryachev wrote: > > John: > > Looks like the issue in PR#1123 was caused by application code > accessing FX from a non-FX thread. > That does seem likely, but it is incredibly hard to be sure. > > I know the discussion is about trying to detect thread misuse early > on, as a way to help the application developers.? I vaguely recall the > discussion we had at some point about adding the check to property > invalidation code or some such, and the general consensus was that it > might pose a compatibility risk or something along these lines. > > Perhaps there is a place where such a check might be safely made (I > don't know of any such place though)?? ?We did, after all, step on the > path of simplification (?) for the sake of students (see > https://openjdk.org/jeps/445 ).? Perhaps such a check could be hidden > behind a system property so as not to break existing, if poorly > written, applications. > I agree that we should be careful not to break anything, it is a check, but I also think that most developers will want this check on (but probably not by default initially, but definitely **after** they fixed any mistakes it detected to avoid recurrence). There is nothing worse than code that only rarely and inexplicably fails on other machines. For me, I wouldn't hesitate for a moment to turn checks on that alert me of incorrect use of FX?-- I value my time, and bugs resulting from these threading problems can be very costly to track down. I already wrote my own check that scans for dead "nodes" (ie. nodes that were once part of a scene graph, but are no longer, but are still not being GC'd). > Personally, I feel that it should be the first thing taught - always > call FX from the FX application thread. > Even Java collections will help you avoid threading problems by throwing ConcurrentModificationException.? Imagine a moment a world where this check did not exist, as it does cost some performance (a mod counter is increased on every collection modification): - Concurrent access to things like HashMap and ArrayList would seem to work fine - Sometimes randomly, an item goes missing, is overwritten or duplicated, or the code gets stuck in an infinite loop (these are all possible outcomes of concurrent collection access, as the check isn't perfect, so when you do see it, you must investigate thoroughly) - The bug is reported (collection framework is buggy!) - After analysis, culprit is that the user somewhere in their 100.000+ line code base is accessing a collection on different threads... sorry, we can't help you further. - Except, they could help us further: ConcurrentModificationException was included at a slight cost of performance. It can't even be disabled (I'm not implying this was a later addition, the designers were just aware that this would lead to hard to track bugs and added this immediately). The parallels with the FX threading model, and also with weak references are huge: - Both "seem" to work fine, until they don't - Failures are very random, may not occur at all on some setups (like the developer's), and failures can be subtle, deceiving or complete - The bug is reported (FX doesn't even check for nulls in Scene code!) - After analysis, culprit is (likely) that the user?somewhere in their 100.000+ line code base is accessing the scene graph on different threads / forgot to maintain a hard reference... sorry, we can't help you further. These kinds of mistakes are not just happening to beginners. This can happen when code gets rearranged, its original operating parameters long forgotten by you, or some future maintainer.? All it takes is a moment of inattention and you have a bug that you may never personally encounter, and when it does occur is impossible to reproduce with any certainty and does NOT give any indication of the cause (you see only symptoms).? Such bugs are the nastiest kind, and it is (IMHO) a failure of a framework to not help you detect these as early as possible. --John > I am curious what other members of community think of this issue. > > -andy > > *From: *John Hendrikx > *Date: *Wednesday, August 7, 2024 at 12:01 > *To: *Andy Goryachev , > openjfx-dev at openjdk.org > *Subject: *[External] : Re: Detecting threading problems faster > > Hi Andy, > > Problems that occur due to modifying the scene graph (like > adding/removing children, or changing certain properties) can be > incredibly subtle, and almost never point out the code that is the > actual culprit.? I suspect that the PR below is one of those for > example, but there are likely many more. > > https://github.com/openjdk/jfx/pull/1123 > > > Issues that complain about some kind of odd bug in the FX code (like a > NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, > etc) could all be caused by user code doing things on the wrong > thread, but its really hard to diagnose as the stack traces provided > will never point out the user code that may be the culprit. I've > investigated PR 1123 extensively, and I can't see any bugs in the FX > code at all **assuming** it is used from a single thread... > > --John > > On 05/08/2024 17:01, Andy Goryachev wrote: > > John: > > Can you cite a bug or give an example of such a problem? > > During all my time of actively using javafx (since about 2015) I > have never encountered an issue with threading you describe.? It > is possible that I use the system trivially and not to the full > extent. Both swing and javafx are single threaded by design.? Yes, > there might be occasions when one can use multiple threads and it > is sort of allowed, but doing so may lead to unpleasant issues > down the road, so the question is why would you want to do that? > > -andy > > *From: *openjfx-dev > on behalf of John Hendrikx > > *Date: *Sunday, August 4, 2024 at 16:30 > *To: *openjfx-dev at openjdk.org > > *Subject: *Detecting threading problems faster > > Hi list, > > I know of quite some bugs and users that have been bitten by the > threading model used by JavaFX.? Basically, anything directly or > indirectly linked to an active Scene must be accessed on the FX > thread. > However, as FX also allows manipulating nodes and properties before > they're displayed, there can be no "hard" check everywhere to > ensure we > are on the FX thread (specifically, in properties). > > Now, I think this situation is annoying, as a simple mistake where a > Platform.runLater wrapper was forgotten usually results in programs > operating mostly flawlessly, but then fail in mysterious and > random and > hard to reproduce ways.? The blame is often put on FX as the > resulting > exceptions will almost never show the user code which was the actual > culprit.? It can result in FX being perceived as unstable or buggy. > > So I've been thinking if there isn't something we can do to detect > these > bugs originating from user code much earlier, similar to the > `ConcurrentModificationException` the collection classes do when > accessed in nested or concurrent contexts. > > I think it may be possible to have properties check whether > they're part > of an active scene without too much of an performance impact, > possibly > even behind a switch. It would work like this: > > Properties involved with Nodes will have an associated bean instance > (`getBean`).? This is an object, but we could check here if this > instance implements an interface: > > ????? if (getBean() instanceof MayBePartOfSceneGraph x) { > ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) { > ???????????????? throw new IllegalStateException("Property must > only be > used from the FX Application Thread"); > ??????????? } > ????? } > > This check could be done on every set of the property, and > potentially > on every get as well.? It should be relatively cheap, but will expose > problematic code patterns at a much earlier stage.? There's a chance > that this will "break" some programs that seemed to be behaving > correctly as well, so we may want to put it behind a switch until > such > programs (or libraries) can be fixed. > > What do you all think? > > --John > > (*) Names of methods/interfaces are only used for illustration > purposes, > we can think of good names if this moves forward. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Aug 7 22:12:59 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 7 Aug 2024 22:12:59 +0000 Subject: [External] : Re: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> Message-ID: > > Looks like the issue in PR#1123 was caused by application code accessing FX from a non-FX thread. > That does seem likely, but it is incredibly hard to be sure. There is literally an exception logged from a non-FX thread, see here https://github.com/openjdk/jfx/pull/1123#issuecomment-1535930576 :-) But you do have a point in trying to save developers' time. And, if we decide to hide the check behind a system property not enabled by default, we also avoid any risk of regression. So the question is reduced to where we should put the check. One such spot could be Parent.requestLayout(), since pretty much any changes to the scene graph result in a layout request. Another possibility we can consider is to create a special convenience class for background processing, along the lines of SwingWorker. For example, it could extend Runnable, have utility methods to runAndWait(), and launch itself in a Thread or (later) in a virtual thread. This way the app devs can stop worrying and simply move any kind of background processing to the instances of these classes. Just a thought. -andy From: John Hendrikx Date: Wednesday, August 7, 2024 at 14:53 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: Re: [External] : Re: Detecting threading problems faster On 07/08/2024 21:38, Andy Goryachev wrote: John: Looks like the issue in PR#1123 was caused by application code accessing FX from a non-FX thread. That does seem likely, but it is incredibly hard to be sure. I know the discussion is about trying to detect thread misuse early on, as a way to help the application developers. I vaguely recall the discussion we had at some point about adding the check to property invalidation code or some such, and the general consensus was that it might pose a compatibility risk or something along these lines. Perhaps there is a place where such a check might be safely made (I don't know of any such place though)? We did, after all, step on the path of simplification (?) for the sake of students (see https://openjdk.org/jeps/445 ). Perhaps such a check could be hidden behind a system property so as not to break existing, if poorly written, applications. I agree that we should be careful not to break anything, it is a check, but I also think that most developers will want this check on (but probably not by default initially, but definitely **after** they fixed any mistakes it detected to avoid recurrence). There is nothing worse than code that only rarely and inexplicably fails on other machines. For me, I wouldn't hesitate for a moment to turn checks on that alert me of incorrect use of FX -- I value my time, and bugs resulting from these threading problems can be very costly to track down. I already wrote my own check that scans for dead "nodes" (ie. nodes that were once part of a scene graph, but are no longer, but are still not being GC'd). Personally, I feel that it should be the first thing taught - always call FX from the FX application thread. Even Java collections will help you avoid threading problems by throwing ConcurrentModificationException. Imagine a moment a world where this check did not exist, as it does cost some performance (a mod counter is increased on every collection modification): - Concurrent access to things like HashMap and ArrayList would seem to work fine - Sometimes randomly, an item goes missing, is overwritten or duplicated, or the code gets stuck in an infinite loop (these are all possible outcomes of concurrent collection access, as the check isn't perfect, so when you do see it, you must investigate thoroughly) - The bug is reported (collection framework is buggy!) - After analysis, culprit is that the user somewhere in their 100.000+ line code base is accessing a collection on different threads... sorry, we can't help you further. - Except, they could help us further: ConcurrentModificationException was included at a slight cost of performance. It can't even be disabled (I'm not implying this was a later addition, the designers were just aware that this would lead to hard to track bugs and added this immediately). The parallels with the FX threading model, and also with weak references are huge: - Both "seem" to work fine, until they don't - Failures are very random, may not occur at all on some setups (like the developer's), and failures can be subtle, deceiving or complete - The bug is reported (FX doesn't even check for nulls in Scene code!) - After analysis, culprit is (likely) that the user somewhere in their 100.000+ line code base is accessing the scene graph on different threads / forgot to maintain a hard reference... sorry, we can't help you further. These kinds of mistakes are not just happening to beginners. This can happen when code gets rearranged, its original operating parameters long forgotten by you, or some future maintainer. All it takes is a moment of inattention and you have a bug that you may never personally encounter, and when it does occur is impossible to reproduce with any certainty and does NOT give any indication of the cause (you see only symptoms). Such bugs are the nastiest kind, and it is (IMHO) a failure of a framework to not help you detect these as early as possible. --John I am curious what other members of community think of this issue. -andy From: John Hendrikx Date: Wednesday, August 7, 2024 at 12:01 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Detecting threading problems faster Hi Andy, Problems that occur due to modifying the scene graph (like adding/removing children, or changing certain properties) can be incredibly subtle, and almost never point out the code that is the actual culprit. I suspect that the PR below is one of those for example, but there are likely many more. https://github.com/openjdk/jfx/pull/1123 Issues that complain about some kind of odd bug in the FX code (like a NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, etc) could all be caused by user code doing things on the wrong thread, but its really hard to diagnose as the stack traces provided will never point out the user code that may be the culprit. I've investigated PR 1123 extensively, and I can't see any bugs in the FX code at all **assuming** it is used from a single thread... --John On 05/08/2024 17:01, Andy Goryachev wrote: John: Can you cite a bug or give an example of such a problem? During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe. It is possible that I use the system trivially and not to the full extent. Both swing and javafx are single threaded by design. Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would you want to do that? -andy From: openjfx-dev on behalf of John Hendrikx Date: Sunday, August 4, 2024 at 16:30 To: openjfx-dev at openjdk.org Subject: Detecting threading problems faster Hi list, I know of quite some bugs and users that have been bitten by the threading model used by JavaFX. Basically, anything directly or indirectly linked to an active Scene must be accessed on the FX thread. However, as FX also allows manipulating nodes and properties before they're displayed, there can be no "hard" check everywhere to ensure we are on the FX thread (specifically, in properties). Now, I think this situation is annoying, as a simple mistake where a Platform.runLater wrapper was forgotten usually results in programs operating mostly flawlessly, but then fail in mysterious and random and hard to reproduce ways. The blame is often put on FX as the resulting exceptions will almost never show the user code which was the actual culprit. It can result in FX being perceived as unstable or buggy. So I've been thinking if there isn't something we can do to detect these bugs originating from user code much earlier, similar to the `ConcurrentModificationException` the collection classes do when accessed in nested or concurrent contexts. I think it may be possible to have properties check whether they're part of an active scene without too much of an performance impact, possibly even behind a switch. It would work like this: Properties involved with Nodes will have an associated bean instance (`getBean`). This is an object, but we could check here if this instance implements an interface: if (getBean() instanceof MayBePartOfSceneGraph x) { if (x.isPartOfActiveScene() && !isOnFxThread()) { throw new IllegalStateException("Property must only be used from the FX Application Thread"); } } This check could be done on every set of the property, and potentially on every get as well. It should be relatively cheap, but will expose problematic code patterns at a much earlier stage. There's a chance that this will "break" some programs that seemed to be behaving correctly as well, so we may want to put it behind a switch until such programs (or libraries) can be fixed. What do you all think? --John (*) Names of methods/interfaces are only used for illustration purposes, we can think of good names if this moves forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Aug 7 22:19:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 22:19:44 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v19] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 20:03:17 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > interpolate integers in real number space Just wanted to mention that so far my testing using the Monkey Tester look good - the behavior is as expected (except for interpolating colors which does not use the _right_ algorithm, but that's a different issue). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274441851 From angorya at openjdk.org Wed Aug 7 22:28:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 22:28:02 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed Message-ID: Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. ------------- Commit messages: - only if consumed - only when consumed - propagate - cleanup - simpler - event helper - copy for test - propagate consume action Changes: https://git.openjdk.org/jfx/pull/1523/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1523&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337246 Stats: 117 lines in 4 files changed: 102 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1523.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1523/head:pull/1523 PR: https://git.openjdk.org/jfx/pull/1523 From angorya at openjdk.org Wed Aug 7 22:42:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 22:42:38 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug this PR has been out for too long, could you please merge the latest master branch in? modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 106: > 104: */ > 105: > 106: is.readByte(); should we still check the value and throw an IOE if it is wrong _for security reasons_? modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 111: > 109: } > 110: > 111: int nRelationships = is.readShort(); same here: should we check for a positive value? as a general rule, we should be validating the input as it might come from untrusted sources, right? L79 and other places? modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 126: > 124: else { > 125: assert false : "error deserializing CompoundSelector: Combinator = " + ordinal; > 126: relationships.add(Combinator.DESCENDANT); throw an exception instead? modules/javafx.graphics/src/main/java/com/sun/javafx/css/CompoundSelector.java line 75: > 73: /** > 74: * The relationships between the selectors > 75: * @return Immutable List<Combinator> minor: would {@code List} be a better choice here, if it works? ------------- PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2226298430 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708023638 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708025694 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708026625 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708029774 From jhendrikx at openjdk.org Wed Aug 7 22:50:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 22:50:39 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 22:40:29 GMT, Andy Goryachev wrote: > this PR has been out for too long, could you please merge the latest master branch in? I did yesterday, or did something go wrong? > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 111: > >> 109: } >> 110: >> 111: int nRelationships = is.readShort(); > > same here: should we check for a positive value? > > as a general rule, we should be validating the input as it might come from untrusted sources, right? L79 and other places? I considered doing more here, but as this is all just moved code, I'm hesitant to change it as part of this PR. For example, if there is a faulty binary CSS file which has a negative value for the short, then the original code will just skip the loop. If I add a check, it will change the behavior. > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 126: > >> 124: else { >> 125: assert false : "error deserializing CompoundSelector: Combinator = " + ordinal; >> 126: relationships.add(Combinator.DESCENDANT); > > throw an exception instead? This is original code, just moved. Do you want me to change it still? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2274473668 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708049742 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708047126 From angorya at openjdk.org Wed Aug 7 22:50:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 22:50:40 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug oops, yes, you did, my mistake. the master progressed since then, got me confused. I got a bunch of errors again after switching: Description Resource Type Path Location Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3024 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3214 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3267 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3282 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3607 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3651 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2274476433 From angorya at openjdk.org Wed Aug 7 22:56:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Aug 2024 22:56:41 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 22:48:07 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 111: >> >>> 109: } >>> 110: >>> 111: int nRelationships = is.readShort(); >> >> same here: should we check for a positive value? >> >> as a general rule, we should be validating the input as it might come from untrusted sources, right? L79 and other places? > > I considered doing more here, but as this is all just moved code, I'm hesitant to change it as part of this PR. For example, if there is a faulty binary CSS file which has a negative value for the short, then the original code will just skip the loop. If I add a check, it will change the behavior. Well, we could create a separate ticket. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708057352 From jhendrikx at openjdk.org Wed Aug 7 23:01:36 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 23:01:36 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 22:27:10 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bug > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 106: > >> 104: */ >> 105: >> 106: is.readByte(); > > should we still check the value and throw an IOE if it is wrong _for security reasons_? I'm not entirely sure what security reasons you may be referring to; we're not instantiating classes by string for example, and Java doesn't suffer from out of bounds memory accesses due to a bad interpretation of a binary format. However, this code is a bit more lenient than the original. The original code would deserialize this as a `CompoundSelector` but then subsequently fail with a `ClassCastException` as it assumes it will be a `SimpleSelector`. I could make it fully compatible in this regard, although it is extremely unlikely that there are any bad files out there where this would apply (as the old implementation would never load it). Anyway, I'm fine with rejecting values that are not `TYPE_SIMPLE`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708062962 From jhendrikx at openjdk.org Wed Aug 7 23:09:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Aug 2024 23:09:40 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: <04-gHGslUPwHc1LplzCXEUcwSi-J63hiSyZczM-D_u4=.6d502dbe-7896-486b-8915-9c97320e57de@github.com> On Wed, 7 Aug 2024 22:54:10 GMT, Andy Goryachev wrote: >> I considered doing more here, but as this is all just moved code, I'm hesitant to change it as part of this PR. For example, if there is a faulty binary CSS file which has a negative value for the short, then the original code will just skip the loop. If I add a check, it will change the behavior. > > Well, we could create a separate ticket. I already cleaned it up without altering the behavior. It probably isn't worth investing more time in. The whole binary CSS code is AFAICS basically only used to create binary versions of the FX standard css files, like `modena.css`, by calling the main method of `Css2Bin` during the gradle build. This probably saves some time for JavaFX startup as the binary version will load faster than the text versions (or so I hope, I didn't check if that's true). I have doubts it is used anywhere else, so although this has creeped into a few public API's, it's practically for internal use only. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708072735 From mstrauss at openjdk.org Wed Aug 7 23:46:54 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 23:46:54 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v20] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: replace reconstruction annotation with interface ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/c36c6c05..03c54965 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=18-19 Stats: 56 lines in 6 files changed: 17 ins; 23 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Wed Aug 7 23:58:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Aug 2024 23:58:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Wed, 7 Aug 2024 20:58:53 GMT, John Hendrikx wrote: >> I just saw a boolean variable being instantiated from an annotation and thought "why jump through the multiple hoops?". since there is a boolean, why not pass it directly? >> >> it's less about memory allocation (though I would prefer to minimize that as well, but as @hjohn pointed out the difference is just a few bytes), but more about "entities must not be multiplied beyond necessity". > > Although I'm not advocating for a specific change, I think looking at how `T convert(Map)` works when it was newly introduced in Java 9 should be taken into account as well. > > There seem to be a couple of general approaches: > > 1. Have a marker that can be checked from the outside > - Annotation (checked from the outside) > - Unusual for this kind of check > - Marker interface > - Seen more often, but unusual to not put the new method there > - Subtype > - Bad idea, you can only inherit once > 2. Introduce a new interface with the new method > - Defines the method and serves as the marker at the same time > 3. Have a method that can be called that guards a 2nd method call > - Doesn't matter how this is fed (constructor, annotation, override) > - You see this more often, but it's not a great pattern (2 method calls for the price of one...) > 4. Return a special value from a method that may be unsupported > - The most obvious (modern) candidate is to return `Optional` but is a bit unusual to indicate support/non-support > - Throw `UnsupportedOperationException` -- although standard, I think it indicates a programmer mistake that should be avoided (in other words, encountering this exception in production code should result in a code fix) > - Return `null` > > Now the very last option (returning `null`) was the way this was handled when `T convert(Map)` was introduced in Java 9. Even though it may not be the prettiest solution, it has two things going for it: > > - It's fast (probably the fastest of the above options, although for most by just a slim margin) > - It fits in with the existing design > > So, my order of preference: > - Just return `null` > - A new interface, which includes the new method > - A marker only interface > - A supportsXYZ method (regardless of how that is approached) > > I don't think I could get behind any of the other options, because they either stick out like a sore thumb versus the existing design, limit future options or just perform too poorly. Returning `null` seems fine from the perspective of `StyleConverter`, but it makes the calling code very awkward. Remember, we ended up here because we needed a way to detect whether an object would support component-wise transitions. If we can't detect that without invoking `convertBack`, we would need to either: 1. Speculatively decompose the value without knowing whether there even are any transitions defined on the node. This is bad because most of the time, there will be no transitions; we will end up deconstructing many objects for no reason. 2. _Assume_ that an object is component-transitionable, look up all potential transitions, and decompose the value; then, if we were wrong with out assumption, go back to the start and try again with another code path (`Interpolatable` or no transition). Instead, what I've implemented now is a new interface `StyleConverter.WithReconstructionSupport`, which contains both methods: public interface WithReconstructionSupport { T convert(Map, Object> values); Map, Object> convertBack(T value); } This allows us to use object deconstruction and reconstruction with a single interface reference, and also allows us to detect such support very easily. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1708139444 From mstrauss at openjdk.org Thu Aug 8 00:10:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Aug 2024 00:10:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v21] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add more documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/03c54965..2bc00001 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=19-20 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Thu Aug 8 01:47:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Aug 2024 01:47:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v19] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 20:51:59 GMT, Andy Goryachev wrote: > Regarding `cssref.html`: > > 1. I think it might make sense to add a section after "Transitions" talking about component transitions, maybe with examples. > 2. I think we should to mention interpolation behavior next to each property name somehow. Either mark the properties that do support it, or only those that do not support. It is already documented in javadoc, but cssref.html is a normative document for CSS. > > what do you think? I'm not sure what to say here, and I question whether introducing the concept of component-wise transitions to users is useful at all. This is more of an implementation detail, as from the perspective of CSS (where transitions are specified), there is no such thing: the reason why you can target `-fx-border-color` with a transition is because the property type is `Paint`, which implements `Interpolatable`. The fact that `Interpolatable` types support transitions is already mentioned in `cssref.html`; elaborating on terminology that has no further use in CSS might be even more confusing for users. There shouldn't be any need to either document support or non-support with regards to transitions, because the current language is already clear that if the property is not `Interpolatable`, there will be no transition. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274773280 From mstrauss at openjdk.org Thu Aug 8 02:07:35 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Aug 2024 02:07:35 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev wrote: > Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. > > This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. > > The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. I don't think that we should introduce functionality to the event system that is only accessible to controls shipped with JavaFX, but not to third-party controls. Either this is an important feature for control authors, then it should be accessible for third-party controls as well. Or it is not important, then it shouldn't be added in the first place. In my opinion, `javafx.controls` shouldn't be a special citizen, but just a consumer of JavaFX APIs. I know that that is not the case right now, but let's not make the situation more entrenched than it currently is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2274800328 From mstrauss at openjdk.org Thu Aug 8 04:00:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Aug 2024 04:00:16 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v22] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: only call get() when necessary ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/2bc00001..1abd6887 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=21 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=20-21 Stats: 31 lines in 1 file changed: 6 ins; 9 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From lkostyra at openjdk.org Thu Aug 8 06:29:38 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 8 Aug 2024 06:29:38 GMT Subject: RFR: 8337400: [Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao wrote: > On Ubuntu 24.04 with Xorg windows are not shown centered. > > This is due a configure event being received with position 0,0 which is wrong. > > The fix ignores the configure events until the window is mapped. LGTM, fixes the problem on Ubuntu 24.04. Noticed no regressions otherwise. I did see some new test failures on 24.04, but these don't go away after this patch. Must be some different reason for them. ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1520#pullrequestreview-2226961754 From craigraw at gmail.com Thu Aug 8 09:19:13 2024 From: craigraw at gmail.com (Craig Raw) Date: Thu, 8 Aug 2024 11:19:13 +0200 Subject: Update on the headless platform (sandbox) In-Reply-To: References: Message-ID: Hi, Is there any progress update on this? It appears (I may be wrong) to be a low risk addition to JavaFX, but with significant benefits, particularly as Monocle is no longer part of JavaFX builds. Thanks, Craig On Thu, Apr 25, 2024 at 12:49?PM Johan Vos wrote: > Hi, > > I did some more work on the JavaFX Headless platform that is available in > [1] and I am using it to run the systemtests. I am not yet running the > robot-based systemtests, but there is already some robot code in the > Headless platform. > > The other systemtests are going pretty well. On my linux, > > export _JAVA_OPTIONS="-Dglass.platform=Headless" > sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest :systemTests:test > > is currently returning > 552 tests completed, 3 failed, 24 skipped > > I understand why the 3 failed tests are failing, and I will move to > robot-based tests soon. > > [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Thu Aug 8 10:47:35 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 8 Aug 2024 07:47:35 -0300 Subject: Detecting threading problems faster In-Reply-To: <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com> References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com> Message-ID: Nice! I will steal it if you don't mind. Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx escreveu: > For detecting long running tasks on the FX thread, there are some other > options which you can do as a user (but perhaps we can support it directly > within FX). I use this kind of code to detect long running things on the > FX thread: > > /** > > * Adds a slow event warning whenever an event takes more than 10 ms to > process. Note > > * that time spent in nested event loops cannot be properly taken into > account as time > > * spent in nested event loops will be part of the event that triggered it > giving false > > * positives. In order for this time to be accurately reflected, the > methods to enter > > * a nested event loop in this class should be used instead of the ones in {@link > Platform}. > > * > > * @param scene a Scene to which to add the slow event warning detection, > cannot be null > > */ > > public static void addSlowEventWarning(Scene scene) { > > final EventDispatcher eventDispatcher = scene.getEventDispatcher(); > > scene.setEventDispatcher(new EventDispatcher() { > > private ScheduledFuture future; > > @Override > > public Event dispatchEvent(Event event, EventDispatchChain tail) { > > if(future != null) { > > future.cancel(false); > > } > > long startTime = System.currentTimeMillis(); > > TIME_TRACKER.enterNested(startTime); // nesting can happen in two ways, > an event triggering another event, or when a nested event loop is entered > > Event returnedEvent = eventDispatcher.dispatchEvent(event, tail); > > long endTime = System.currentTimeMillis(); > > long timeSpentInNested = TIME_TRACKER.exitNested(endTime); > > if(timeSpentInNested > 10) { > > long total = endTime - startTime; > > LOGGER.warning("Slow Event (self/total: " + timeSpentInNested + "/" + > total + " ms @ level " + TIME_TRACKER.getCurrentLevel() + "): " + event); > > } > > return returnedEvent; > > } > > }); > > } > > --John > > On 05/08/2024 17:17, Thiago Milczarek Say?o wrote: > > Hi, > > Interesting idea. We have this problem specially when Junior developers > touch the code. > > The other way around would be nice too - if some I/O task executes on the > FX thread. > > This can make the OS think the application hanged and offer to kill it, > since it won't respond to "pings". And I/O tasks processing time may vary > between installations. Also causes "white screens" since it blocks painting. > > -- Thiago. > > Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth < > kevin.rushforth at oracle.com> escreveu: > >> Wouldn't it be better to implement this check in assert to avoid any >> impact in production? >> >> >> No. Using an assert in a case like this is an anti-pattern. A call to >> assert in a library such as JavaFX is only appropriate for checking an >> invariant in internal logic. If we are going to go down this route of doing >> a thread check when mutating properties of "live" nodes, we will throw the >> same IllegalStateException that is currently thrown by some methods on >> Stage and Scene. >> >> As for the proposal itself, adding this check is an interesting idea. We >> considered doing this back in the JDK 7 (JavaFX 2) time frame, but decided >> not to pursue it then. I think the idea is worth further discussion. I >> would limit any thread checking to setting the property. It would be too >> restrictive (and largely unnecessary) to prevent reading a property from >> the application thread. >> >> The things to consider would be: >> >> 1. What is the performance hit of doing this check on the setting of >> every property? >> 2. What is the effect on bound properties? >> 3. How intrusive is it in the code? >> 4. Should we add a property to enable / disable the thread check, >> possibly a three- or four-valued property (allow|warn|debug?|deny), as was >> recently done in JEP 471 for sun.misc.Unsafe memory access methods. If so, >> what should the default be? >> >> My quick take is that if this can be done in a minimally intrusive manner >> with low overhead, we should consider pursing this. As for 4, my preference >> would be to add a three- or four-valued system property to control the >> check, with "warn" as the default initially, changing the default to >> "disallow" in a subsequent version. This would, of course, require a lot of >> testing. >> >> -- Kevin >> >> >> On 8/4/2024 8:40 PM, quizynox wrote: >> >> Hello, >> >> Wouldn't it be better to implement this check in assert to avoid any >> impact in production? >> >> ??, 5 ???. 2024??. ? 03:30, John Hendrikx : >> >>> Hi list, >>> >>> I know of quite some bugs and users that have been bitten by the >>> threading model used by JavaFX. Basically, anything directly or >>> indirectly linked to an active Scene must be accessed on the FX thread. >>> However, as FX also allows manipulating nodes and properties before >>> they're displayed, there can be no "hard" check everywhere to ensure we >>> are on the FX thread (specifically, in properties). >>> >>> Now, I think this situation is annoying, as a simple mistake where a >>> Platform.runLater wrapper was forgotten usually results in programs >>> operating mostly flawlessly, but then fail in mysterious and random and >>> hard to reproduce ways. The blame is often put on FX as the resulting >>> exceptions will almost never show the user code which was the actual >>> culprit. It can result in FX being perceived as unstable or buggy. >>> >>> So I've been thinking if there isn't something we can do to detect these >>> bugs originating from user code much earlier, similar to the >>> `ConcurrentModificationException` the collection classes do when >>> accessed in nested or concurrent contexts. >>> >>> I think it may be possible to have properties check whether they're part >>> of an active scene without too much of an performance impact, possibly >>> even behind a switch. It would work like this: >>> >>> Properties involved with Nodes will have an associated bean instance >>> (`getBean`). This is an object, but we could check here if this >>> instance implements an interface: >>> >>> if (getBean() instanceof MayBePartOfSceneGraph x) { >>> if (x.isPartOfActiveScene() && !isOnFxThread()) { >>> throw new IllegalStateException("Property must only be >>> used from the FX Application Thread"); >>> } >>> } >>> >>> This check could be done on every set of the property, and potentially >>> on every get as well. It should be relatively cheap, but will expose >>> problematic code patterns at a much earlier stage. There's a chance >>> that this will "break" some programs that seemed to be behaving >>> correctly as well, so we may want to put it behind a switch until such >>> programs (or libraries) can be fixed. >>> >>> What do you all think? >>> >>> --John >>> >>> (*) Names of methods/interfaces are only used for illustration purposes, >>> we can think of good names if this moves forward. >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Thu Aug 8 12:42:07 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 8 Aug 2024 12:42:07 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image Message-ID: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. This change fixes this mistake. Now drag image should be properly offset. ------------- Commit messages: - GlassViewDelegate: Restore offset calculation on startDrag Changes: https://git.openjdk.org/jfx/pull/1532/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333919 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1532.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1532/head:pull/1532 PR: https://git.openjdk.org/jfx/pull/1532 From lkostyra at openjdk.org Thu Aug 8 12:42:07 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 8 Aug 2024 12:42:07 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra wrote: > When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. > > This change fixes this mistake. Now drag image should be properly offset. I have one more question to this, as I don't have the best way to test this. I'm not sure how offsets should be interpreted and if they are interpreted the right way. At this point: * For X offset: positive values shift image RIGHT (mouse cursor is closer to the LEFT side of drag image), negative shift LEFT (mouse cursor is closer to the RIGHT side of drag image) * For Y offset: positive values shift image DOWN (mouse cursor is closer to the TOP of the drag image), negative values shift UP (mouse cursor is closer to the BOTTOM of the drag image) Let me know if this behavior is desired and if it matches pre-[JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) behavior. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2275721478 From arapte at openjdk.org Thu Aug 8 13:47:36 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 8 Aug 2024 13:47:36 GMT Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra wrote: > In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible. > > This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs. > > Both D3D and ES2 Prism backends were updated to properly handle these changes. > > NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change. > > I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples. The change seems quite straight forward, single reviewer should be sufficient. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2275873580 From lkostyra at openjdk.org Thu Aug 8 13:51:38 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 8 Aug 2024 13:51:38 GMT Subject: Integrated: 8336624: Improve Decora Shader loading for modern APIs In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra wrote: > In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible. > > This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs. > > Both D3D and ES2 Prism backends were updated to properly handle these changes. > > NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change. > > I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples. This pull request has now been integrated. Changeset: abb6dfef Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/abb6dfefae840ac17893a12e4ac086140c83e451 Stats: 15 lines in 6 files changed: 5 ins; 0 del; 10 mod 8336624: Improve Decora Shader loading for modern APIs Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1530 From andy.goryachev at oracle.com Thu Aug 8 14:25:48 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 8 Aug 2024 14:25:48 +0000 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com> Message-ID: One should probably use System.nanoTime() instead of .currentTimeMillis() ... -andy From: openjfx-dev on behalf of Thiago Milczarek Say?o Date: Thursday, August 8, 2024 at 03:47 To: John Hendrikx Cc: openjfx-dev at openjdk.org Subject: Re: Detecting threading problems faster Nice! I will steal it if you don't mind. Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx > escreveu: For detecting long running tasks on the FX thread, there are some other options which you can do as a user (but perhaps we can support it directly within FX). I use this kind of code to detect long running things on the FX thread: /** * Adds a slow event warning whenever an event takes more than 10 ms to process. Note * that time spent in nested event loops cannot be properly taken into account as time * spent in nested event loops will be part of the event that triggered it giving false * positives. In order for this time to be accurately reflected, the methods to enter * a nested event loop in this class should be used instead of the ones in {@link Platform}. * * @param scene a Scene to which to add the slow event warning detection, cannot be null */ public static void addSlowEventWarning(Scene scene) { final EventDispatcher eventDispatcher = scene.getEventDispatcher(); scene.setEventDispatcher(new EventDispatcher() { private ScheduledFuture future; @Override public Event dispatchEvent(Event event, EventDispatchChain tail) { if(future != null) { future.cancel(false); } long startTime = System.currentTimeMillis(); TIME_TRACKER.enterNested(startTime); // nesting can happen in two ways, an event triggering another event, or when a nested event loop is entered Event returnedEvent = eventDispatcher.dispatchEvent(event, tail); long endTime = System.currentTimeMillis(); long timeSpentInNested = TIME_TRACKER.exitNested(endTime); if(timeSpentInNested > 10) { long total = endTime - startTime; LOGGER.warning("Slow Event (self/total: " + timeSpentInNested + "/" + total + " ms @ level " + TIME_TRACKER.getCurrentLevel() + "): " + event); } return returnedEvent; } }); } --John On 05/08/2024 17:17, Thiago Milczarek Say?o wrote: Hi, Interesting idea. We have this problem specially when Junior developers touch the code. The other way around would be nice too - if some I/O task executes on the FX thread. This can make the OS think the application hanged and offer to kill it, since it won't respond to "pings". And I/O tasks processing time may vary between installations. Also causes "white screens" since it blocks painting. -- Thiago. Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth > escreveu: Wouldn't it be better to implement this check in assert to avoid any impact in production? No. Using an assert in a case like this is an anti-pattern. A call to assert in a library such as JavaFX is only appropriate for checking an invariant in internal logic. If we are going to go down this route of doing a thread check when mutating properties of "live" nodes, we will throw the same IllegalStateException that is currently thrown by some methods on Stage and Scene. As for the proposal itself, adding this check is an interesting idea. We considered doing this back in the JDK 7 (JavaFX 2) time frame, but decided not to pursue it then. I think the idea is worth further discussion. I would limit any thread checking to setting the property. It would be too restrictive (and largely unnecessary) to prevent reading a property from the application thread. The things to consider would be: 1. What is the performance hit of doing this check on the setting of every property? 2. What is the effect on bound properties? 3. How intrusive is it in the code? 4. Should we add a property to enable / disable the thread check, possibly a three- or four-valued property (allow|warn|debug?|deny), as was recently done in JEP 471 for sun.misc.Unsafe memory access methods. If so, what should the default be? My quick take is that if this can be done in a minimally intrusive manner with low overhead, we should consider pursing this. As for 4, my preference would be to add a three- or four-valued system property to control the check, with "warn" as the default initially, changing the default to "disallow" in a subsequent version. This would, of course, require a lot of testing. -- Kevin On 8/4/2024 8:40 PM, quizynox wrote: Hello, Wouldn't it be better to implement this check in assert to avoid any impact in production? ??, 5 ???. 2024??. ? 03:30, John Hendrikx >: Hi list, I know of quite some bugs and users that have been bitten by the threading model used by JavaFX. Basically, anything directly or indirectly linked to an active Scene must be accessed on the FX thread. However, as FX also allows manipulating nodes and properties before they're displayed, there can be no "hard" check everywhere to ensure we are on the FX thread (specifically, in properties). Now, I think this situation is annoying, as a simple mistake where a Platform.runLater wrapper was forgotten usually results in programs operating mostly flawlessly, but then fail in mysterious and random and hard to reproduce ways. The blame is often put on FX as the resulting exceptions will almost never show the user code which was the actual culprit. It can result in FX being perceived as unstable or buggy. So I've been thinking if there isn't something we can do to detect these bugs originating from user code much earlier, similar to the `ConcurrentModificationException` the collection classes do when accessed in nested or concurrent contexts. I think it may be possible to have properties check whether they're part of an active scene without too much of an performance impact, possibly even behind a switch. It would work like this: Properties involved with Nodes will have an associated bean instance (`getBean`). This is an object, but we could check here if this instance implements an interface: if (getBean() instanceof MayBePartOfSceneGraph x) { if (x.isPartOfActiveScene() && !isOnFxThread()) { throw new IllegalStateException("Property must only be used from the FX Application Thread"); } } This check could be done on every set of the property, and potentially on every get as well. It should be relatively cheap, but will expose problematic code patterns at a much earlier stage. There's a chance that this will "break" some programs that seemed to be behaving correctly as well, so we may want to put it behind a switch until such programs (or libraries) can be fixed. What do you all think? --John (*) Names of methods/interfaces are only used for illustration purposes, we can think of good names if this moves forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Thu Aug 8 15:37:57 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 8 Aug 2024 16:37:57 +0100 Subject: Update on the headless platform (sandbox) In-Reply-To: References: Message-ID: Hi Craig, There were 3 system tests that were still failing, and once I fixed those, I believe this is ready to be reviewed. I'm out of office until end of next week, and I plan to resume work on that soon after that. - Johan On Thu, Aug 8, 2024 at 10:19?AM Craig Raw wrote: > Hi, > > Is there any progress update on this? It appears (I may be wrong) to be a > low risk addition to JavaFX, but with significant benefits, particularly as > Monocle is no longer part of JavaFX builds. > > Thanks, > Craig > > On Thu, Apr 25, 2024 at 12:49?PM Johan Vos wrote: > >> Hi, >> >> I did some more work on the JavaFX Headless platform that is available in >> [1] and I am using it to run the systemtests. I am not yet running the >> robot-based systemtests, but there is already some robot code in the >> Headless platform. >> >> The other systemtests are going pretty well. On my linux, >> >> export _JAVA_OPTIONS="-Dglass.platform=Headless" >> sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest >> :systemTests:test >> >> is currently returning >> 552 tests completed, 3 failed, 24 skipped >> >> I understand why the 3 failed tests are failing, and I will move to >> robot-based tests soon. >> >> [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Aug 8 15:41:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 15:41:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v19] In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 01:44:41 GMT, Michael Strau? wrote: > the current language is already clear that if the property is not `Interpolatable`, there will be no transition. I am talking about `cssref.html` and not the code. One should be able to see whether a property is interpolatable from reading the `cssref.html` spec without having to dig into the code. The word "interpolatable" occurs in `cssref.html` in exactly one place. What I think the reader should be able to do is to find out whether a property is interpolatable from reading the section about said property in `cssref.html`. In other words, there should be info about interpolation in the property table: ![Screenshot 2024-08-08 at 08 29 32](https://github.com/user-attachments/assets/cf43ce83-0cb0-43ff-b782-18ac67af1c11) Since probably most of the properties are "interpolatable" we can mention that the particular property does not support interpolation instead. Another example: until [JDK-8338002](https://bugs.openjdk.org/browse/JDK-8338002) is implemented, -fx-font* interpolates discretely, which should be reflected in the css spec. Or am I missing something? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2276130402 From angorya at openjdk.org Thu Aug 8 15:48:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 15:48:45 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Wed, 7 Aug 2024 23:55:39 GMT, Michael Strau? wrote: >> Although I'm not advocating for a specific change, I think looking at how `T convert(Map)` works when it was newly introduced in Java 9 should be taken into account as well. >> >> There seem to be a couple of general approaches: >> >> 1. Have a marker that can be checked from the outside >> - Annotation (checked from the outside) >> - Unusual for this kind of check >> - Marker interface >> - Seen more often, but unusual to not put the new method there >> - Subtype >> - Bad idea, you can only inherit once >> 2. Introduce a new interface with the new method >> - Defines the method and serves as the marker at the same time >> 3. Have a method that can be called that guards a 2nd method call >> - Doesn't matter how this is fed (constructor, annotation, override) >> - You see this more often, but it's not a great pattern (2 method calls for the price of one...) >> 4. Return a special value from a method that may be unsupported >> - The most obvious (modern) candidate is to return `Optional` but is a bit unusual to indicate support/non-support >> - Throw `UnsupportedOperationException` -- although standard, I think it indicates a programmer mistake that should be avoided (in other words, encountering this exception in production code should result in a code fix) >> - Return `null` >> >> Now the very last option (returning `null`) was the way this was handled when `T convert(Map)` was introduced in Java 9. Even though it may not be the prettiest solution, it has two things going for it: >> >> - It's fast (probably the fastest of the above options, although for most by just a slim margin) >> - It fits in with the existing design >> >> So, my order of preference: >> - Just return `null` >> - A new interface, which includes the new method >> - A marker only interface >> - A supportsXYZ method (regardless of how that is approached) >> >> I don't think I could get behind any of the other options, because they either stick out like a sore thumb versus the existing design, limit future options or just perform too poorly. > > Returning `null` seems fine from the perspective of `StyleConverter`, but it makes the calling code very awkward. Remember, we ended up here because we needed a way to detect whether an object would support component-wise transitions. If we can't detect that without invoking `convertBack`, we would need to either: > 1. Speculatively decompose the value without knowing whether there even are any transitions defined on the node. This is bad because most of the time, there will be no transitions; we will end up deconstructing many objects for no reason. > 2. _Assume_ that an object is component-transitionable, look up all potential transitions, and decompose the value; then, if we were wrong with out assumption, go back to the start and try again with another code path (`Interpolatable` or no transition). > > Instead, what I've implemented now is a new interface `StyleConverter.WithReconstructionSupport`, which contains both methods: > > public interface WithReconstructionSupport { > T convert(Map, Object> values); > Map, Object> convertBack(T value); > } > > > This allows us to use object deconstruction and reconstruction with a single interface reference, and also allows us to detect such support very easily. +1 for `StyleConverter.WithReconstructionSupport` maybe use a shorter name, like `StyleConverter.WithReconstruction` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1709803243 From angorya at openjdk.org Thu Aug 8 15:48:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 15:48:46 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v22] In-Reply-To: References: Message-ID: <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com> On Thu, 8 Aug 2024 04:00:16 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only call get() when necessary modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 113: > 111: * @return a {@code Map} of the constituent values > 112: */ > 113: Map, Object> convertBack(T value); perhaps `convertToMap` might be better? or something along the lines of `toInstance`/`toMap` ? `decompose` / `reconstruct` ? (though decompose might evoke wrong associations) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1709796311 From angorya at openjdk.org Thu Aug 8 15:59:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 15:59:36 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: <8R6B76rdIfBpIuU8MMeacMPr2BEPvB14rXEvwcknoDY=.11537e34-f9f5-4102-a960-9e3f472a886b@github.com> On Thu, 8 Aug 2024 02:04:32 GMT, Michael Strau? wrote: > but not to third-party controls Does it mean you propose to make the `Event.propagateConsume()` method public? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276162255 From mfox at openjdk.org Thu Aug 8 15:59:36 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 8 Aug 2024 15:59:36 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev wrote: > Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. > > This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. > > The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. This PR assumes that during dispatch events are copied using copyFor. But the documentation states that an EventDispatcher can do whatever it wants in `dispatchEvent`. A developer could provide a dispatcher that creates entirely new events rather than just copy existing ones and that would break this code. The only thing that?s guaranteed is that the dispatcher will return null to stop event dispatch and that's all that the solution in [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) relies on. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276166334 From jpereda at openjdk.org Thu Aug 8 16:04:36 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 8 Aug 2024 16:04:36 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra wrote: > When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. > > This change fixes this mistake. Now drag image should be properly offset. I'm testing this PR, and I see that on macOS the offsets are now taken into account. However, comparing to Windows the behaviour is different: - On Windows, offset 0,0 means the cursor is at the most top-left coordinates of the dragView image. Setting positive offsets in x, y goes to the right and down of the image (which goes in line with the usual JavaFX coordinate system) - On macOS, with this PR, offset 0, 0 is at the centre of the dragView image, and positive offsets go to the opposite direction >From the test attached to the issue, and with this PR: WritableImage snapshot = source.snapshot(null, null); db.setDragView(snapshot); db.setDragViewOffsetX(0); db.setDragViewOffsetY(0); on Windows -> cursor at the most top-left corner of the dragView on macOS -> cursor at the centre of the dragView. And: WritableImage snapshot = source.snapshot(null, null); db.setDragView(snapshot); db.setDragViewOffsetX(snapshot.getWidth() / 2); db.setDragViewOffsetY(snapshot.getHeight() / 2); on Windows -> cursor at the centre of the dragView on macOS -> cursor at the most top-left corner of the dragView. So I'd say macOS should do the same as Windows, and for that you could try: - dragPoint.x -= ([image size].width/2.0f); - dragPoint.y -= ([image size].height/2.0f); + // dragPoint.x -= ([image size].width/2.0f); + // dragPoint.y -= ([image size].height/2.0f); - dragPoint.x += offset.x; - dragPoint.y += offset.y; + dragPoint.x -= offset.x; + dragPoint.y -= offset.y; Does that make sense to you? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2276175583 From mstrauss at openjdk.org Thu Aug 8 16:15:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Aug 2024 16:15:42 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: <8R6B76rdIfBpIuU8MMeacMPr2BEPvB14rXEvwcknoDY=.11537e34-f9f5-4102-a960-9e3f472a886b@github.com> References: <8R6B76rdIfBpIuU8MMeacMPr2BEPvB14rXEvwcknoDY=.11537e34-f9f5-4102-a960-9e3f472a886b@github.com> Message-ID: On Thu, 8 Aug 2024 15:55:01 GMT, Andy Goryachev wrote: > > but not to third-party controls > > Does it mean you propose to make the `Event.propagateConsume()` method public? If we agree that this is the right API, then yes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276195031 From angorya at openjdk.org Thu Aug 8 16:26:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 16:26:37 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 15:57:04 GMT, Martin Fox wrote: > This PR assumes that during dispatch events are copied using copyFor. But the documentation states that an EventDispatcher can do whatever it wants in `dispatchEvent`. A developer could provide a dispatcher that creates entirely new events rather than just copy existing ones and that would break this code. The only thing that?s guaranteed is that the dispatcher will return null to stop event dispatch and that's all that the solution in [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) relies on. a) If the EventDispatcher does something different like creating the new events, it is up to that ED to deal with consequences. It means the developer wants to create new events and not to have the link between the events. b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary. The bigger issue I see, as I mentioned earlier, is that 1. the `Event` has the target field which is absolutely, totally unnecessary (the target already knows who the target is, it is the target) and is an anti-pattern because 2. it forces the dispatcher to create new event instances for new targets, breaking the `isConsumed` logic I don't think we'll ever change the event dispatching mechanism and remove the target field from Event. So the only remaining solutions are little hacks and workarounds here and there. I don't think adding return value to the dispatcher is the right solution. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276213463 From mfox at openjdk.org Thu Aug 8 17:04:35 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 8 Aug 2024 17:04:35 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 16:23:43 GMT, Andy Goryachev wrote: > b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary. We would not be adding anything. Consuming an event is how a developer communicates to one EventDispatcher that the event was dealt with. But this information is propagated through the dispatch chain by returning null from dispatchEvent. That's all in place already. There's a variant of `EventUtil.fireEvent` that returns the result of dispatchEvent so a client can check for null to see if the event was consumed. And there are already places in the code where this happens. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) calls for this to be cleaned up and made public. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276277201 From angorya at openjdk.org Thu Aug 8 17:21:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 17:21:36 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 17:01:47 GMT, Martin Fox wrote: >>> This PR assumes that during dispatch events are copied using copyFor. But the documentation states that an EventDispatcher can do whatever it wants in `dispatchEvent`. A developer could provide a dispatcher that creates entirely new events rather than just copy existing ones and that would break this code. The only thing that?s guaranteed is that the dispatcher will return null to stop event dispatch and that's all that the solution in [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) relies on. >> >> a) If the EventDispatcher does something different like creating the new events, it is up to that ED to deal with consequences. It means the developer wants to create new events and not to have the link between the events. >> >> b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary. >> >> The bigger issue I see, as I mentioned earlier, is that >> 1. the `Event` has the target field which is absolutely, totally unnecessary (the target already knows who the target is, it is the target) and is an anti-pattern because >> 2. it forces the dispatcher to create new event instances for new targets, breaking the `isConsumed` logic >> >> I don't think we'll ever change the event dispatching mechanism and remove the target field from Event. So the only remaining solutions are little hacks and workarounds here and there. >> >> I don't think adding return value to the dispatcher is the right solution. > >> b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary. > > We would not be adding anything. Consuming an event is how a developer communicates to one EventDispatcher that the event was dealt with. But this information is propagated through the dispatch chain by returning null from dispatchEvent. That's all in place already. > > There's a variant of `EventUtil.fireEvent` that returns the result of dispatchEvent so a client can check for null to see if the event was consumed. And there are already places in the code where this happens. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) calls for this to be cleaned up and made public. @beldenfox : EventUtil is not a public API. Checking the return value of the dispatchEvent is, in my opinion, an anti-pattern. The right pattern is this (TabPaneBehavior:85): public boolean canCloseTab(Tab tab) { Event event = new Event(tab,tab,Tab.TAB_CLOSE_REQUEST_EVENT); Event.fireEvent(tab, event); return ! event.isConsumed(); } Using your own argument, a dev can write a dispatcher which returns garbage from its `dispatchEvent` method, breaking the thing. So I am still not convinced. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276304526 From martin at martinfox.com Thu Aug 8 17:38:10 2024 From: martin at martinfox.com (Martin Fox) Date: Thu, 8 Aug 2024 10:38:10 -0700 Subject: Font hinting on Linux In-Reply-To: References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com> <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com> Message-ID: <00F1B57C-BA79-4CA9-838A-1EDC8955B37E@martinfox.com> (OK, I?m caught up now. Forget whatever I said about hinting.) I think there is a bug here. LCD text with the software renderer produces particularly bad results. Part of the code is shifting the glyphs along the X axis to set up the LCD shader even though it?s not used with the software renderer. The software renderer is then truncating to the nearest pixel boundary. The result is that glyphs at a fractional X of 0.8333 or less move left and all others move right. Rounding to the nearest pixel boundary produces better results (in line with grayscale text) though the only really clean results come from using LCD text with the hardware pipeline. I ended up using the software renderer by accident; I?m running in a VM and get the software renderer unless I force the GPU. Martin > On Aug 5, 2024, at 8:32?AM, Martin Fox wrote: > > I don?t see how hinting issues can cause this degree of character misplacement. This looks more like, say, a glyph cache bug. > > I had no problem reproducing this with the software pipeline. When I force the GPU I get much better results (prism.forceGPU=true). In both cases the text is a little on the fuzzy side but the es2 pipeline is placing the glyphs correctly. > >> On Aug 4, 2024, at 9:09?PM, quizynox wrote: >> >> Hello, >> >> Thanks for the answer. I've found a couple of very long but very informative threads that have given me some pointers. >> >> Poor quality font rendering >> https://mail.openjdk.org/pipermail/openjfx-dev/2013-August/009958.html >> >> The crisp fonts saga >> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044234.html >> >> In my case there were two problems: >> >> - I had SceneAntialiasing enabled, which seems to prevent -fx-smoothing-type=lcd from working >> - I forgot that -fx-smoothing-type is only enabled for .text nodes, but not for all Text nodes by default >> >> I also assumed that Linux fontconfig settings would have some effect on JavaFX font rendering, but judging from tests this isn't the case. Perhaps the only thing that matters is freetype compilation flags. I've found that Fedora enabled ClearType font rendering some time ago (https://www.phoronix.com/news/Fedora-ClearType-Subpixel-Font). >> >> As for -fx-smooth-type=gray, with some fonts such as Open Sans, Liberation Sans or Montserrat it may look quite close to acceptable. >> >> ??, 4 ???. 2024??. ? 01:41, Philip Race >: >>> There's not many knobs available. Hinting is not enabled - and that's >>> commonly the case on modern plartforms. >>> LCD is your best option for readibility of static text, which is why it >>> is the default for UI Controls, >>> It should reduce the pixel grid fitting uneveness you highlight but >>> doesn't eliminate it. >>> Note : this presumes that the freetype on your system enables LCD .. if >>> it doesn't there's nothing FX can do about that. >>> >>> -phil. >>> >>> >>> On 8/2/24 10:43 AM, quizynox at gmail.com wrote: >>> > Hello, >>> > >>> > Sorry for asking here, but I seem to have tried everything I could >>> > find on SO/Reddit/JBS etc. Could someone please share what font >>> > settings I should be using to get decent font hinting on Linux? Please >>> > see the screenshot. >>> > >>> > https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view >>> > >>> > I'm not very picky, but the font I see is just not suitable for >>> > presenting app to customers. I've tried enabling and disabling hinting >>> > and autohinting, using different hinting styles, changing the font >>> > smoothing type and prism.lcdtext etc. Unfortunately no matter what I >>> > do, the font hinting is always bad. >>> > >>> > Fedora, KDE, all latest versions. >>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Aug 8 17:40:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 17:40:37 GMT Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is handled differently depending on the useSystemMenuBar value In-Reply-To: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com> References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com> Message-ID: On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox wrote: > macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crash at the event before it works its way out to the menu bar. > > We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item. > > This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar. > > I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers. Thinking out loud for a moment: wouldn't it be better to use a kind of EventFilter specifically for the shortcuts, before the normal dispatching happens? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2276339875 From mfox at openjdk.org Thu Aug 8 20:20:35 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 8 Aug 2024 20:20:35 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 17:18:56 GMT, Andy Goryachev wrote: >>> b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary. >> >> We would not be adding anything. Consuming an event is how a developer communicates to one EventDispatcher that the event was dealt with. But this information is propagated through the dispatch chain by returning null from dispatchEvent. That's all in place already. >> >> There's a variant of `EventUtil.fireEvent` that returns the result of dispatchEvent so a client can check for null to see if the event was consumed. And there are already places in the code where this happens. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) calls for this to be cleaned up and made public. > > @beldenfox : > EventUtil is not a public API. Checking the return value of the dispatchEvent is, in my opinion, an anti-pattern. The right pattern is this (TabPaneBehavior:85): > > > public boolean canCloseTab(Tab tab) { > Event event = new Event(tab,tab,Tab.TAB_CLOSE_REQUEST_EVENT); > Event.fireEvent(tab, event); > return ! event.isConsumed(); > } > > > Using your own argument, a dev can write a dispatcher which returns garbage from its `dispatchEvent` method, breaking the thing. So I am still not convinced. @andy-goryachev-oracle I agree that propagating the consumed flag is clearer and would lead to less surprises. Once upon a time I also thought that I could call fireEvent and then check the event's consumed flag afterward. I had to dig around a bit to figure out that all these copies were being made. It is confusing. For that matter you can't really infer that an event was consumed just because the dispatch chain returned null. The EventDispatcher documentation is a little hazy on this but in theory a dispatcher could return null for other reasons. It seems to be mostly a matter of convention that null indicates that an event was consumed. With that said in this PR changing the consumed flag in one event can change the consumed state of another event and that also seems like unexpected and surprising behavior. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276584223 From duke at openjdk.org Thu Aug 8 20:22:06 2024 From: duke at openjdk.org (Loay Ghreeb) Date: Thu, 8 Aug 2024 20:22:06 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid Message-ID: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order. ------------- Commit messages: - Merge branch 'master' into SortedList - Merge branch 'master' into SortedList - Add test case - Fix SortedList to maintain insertion order for equal elements Changes: https://git.openjdk.org/jfx/pull/1519/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301761 Stats: 37 lines in 2 files changed: 28 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1519.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1519/head:pull/1519 PR: https://git.openjdk.org/jfx/pull/1519 From duke at openjdk.org Thu Aug 8 20:22:06 2024 From: duke at openjdk.org (Loay Ghreeb) Date: Thu, 8 Aug 2024 20:22:06 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid In-Reply-To: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: On Sun, 28 Jul 2024 04:13:30 GMT, Loay Ghreeb wrote: > Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order. I submitted the OCA, but it's still under review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2259685053 From angorya at openjdk.org Thu Aug 8 20:33:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Aug 2024 20:33:35 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev wrote: > Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. > > This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. > > The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. Yeah, that's why I tried to hide this from the public. I see the whole create-multiple-events idea as a _bad design_ (tm), so the proposed change is a hack^H^H^H workaround to be used internally by FX in a few specific cases (Note1). The current PR also makes the fix localized to the specific scenario, further reducing the regression risk. I don't think this functionality should be made public, contrary to what @mstr2 and @kleopatra say (sorry!). I don't have any better ideas, and let's admit it, the current event dispatching paradigm will never be changed. Note 1: There might be more scenarios where FX needs to know whether any of the secondary events got consumed. It's unlikely that trivial use of FX triggers the issue, but we can look through the bug list to see if we have any more mentioning `isConsumed()`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276602986 From mstrauss at openjdk.org Fri Aug 9 02:20:45 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 02:20:45 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v19] In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 15:38:36 GMT, Andy Goryachev wrote: > Since probably most of the properties are "interpolatable" we can mention that the particular property does not support interpolation instead. > > Another example: until [JDK-8338002](https://bugs.openjdk.org/browse/JDK-8338002) is implemented, -fx-font* interpolates discretely, which should be reflected in the css spec. > > Or am I missing something? Maybe we should do that as a separate ticket. Changing the documentation of properties that have nothing to do with backgrounds and borders is probably a bit out of scope for this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2277022380 From mstrauss at openjdk.org Fri Aug 9 02:25:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 02:25:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v22] In-Reply-To: <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com> References: <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com> Message-ID: On Thu, 8 Aug 2024 15:41:54 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> only call get() when necessary > > modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 113: > >> 111: * @return a {@code Map} of the constituent values >> 112: */ >> 113: Map, Object> convertBack(T value); > > perhaps `convertToMap` might be better? or something along the lines of `toInstance`/`toMap` ? `decompose` / `reconstruct` ? (though decompose might evoke wrong associations) `reconstruct` is a misnomer, as reconstruction is a two-step operation (`convertBack` followed by `convert`). To be fair, I don't like any of these better than `convertBack`, mostly because I want to stress that those two operations are closely related, and none of the alternatives evoke that sentiment. That being said, this is a minor API and I don't really mind either way, but absent a compelling reason, I'd prefer to stick to `convertBack`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1710584650 From mstrauss at openjdk.org Fri Aug 9 03:21:37 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 03:21:37 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 20:18:09 GMT, Martin Fox wrote: > For that matter you can't really infer that an event was consumed just because the dispatch chain returned null. The EventDispatcher documentation is a little hazy on this but in theory a dispatcher could return null for other reasons. It seems to be mostly a matter of convention that null indicates that an event was consumed. It seems much more likely that we could clean this up by explicitly specifying this behavior. Here's what I would do: 1. Implement [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) 2. Specify that `dispatchEvent` must only return `null` if the event was consumed. 3. Explicitly document that `Event.isConsumed()` can only be used inside of an event handler, but not to detect whether an event was consumed at the place where the event is fired. This would be sufficient to solve the problem at hand, and will also enable third-party controls to do the same. Going further, I question whether we need the `isConsumed()` method at all. Consumed events shouldn't be propagated, and the current behavior is very strange to say the least (events on the same level are propagated even though they're consumed). If consumed events are not propagated, there should be no need to check whether an event was consumed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2277066533 From duke at openjdk.org Fri Aug 9 03:30:09 2024 From: duke at openjdk.org (Loay Ghreeb) Date: Fri, 9 Aug 2024 03:30:09 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid [v2] In-Reply-To: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: > Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order. Loay Ghreeb has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into SortedList - Merge branch 'master' into SortedList - Merge branch 'master' into SortedList - Add test case - Fix SortedList to maintain insertion order for equal elements ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1519/files - new: https://git.openjdk.org/jfx/pull/1519/files/fa2deb48..15f1a9ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=00-01 Stats: 643 lines in 8 files changed: 472 ins; 61 del; 110 mod Patch: https://git.openjdk.org/jfx/pull/1519.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1519/head:pull/1519 PR: https://git.openjdk.org/jfx/pull/1519 From lkostyra at openjdk.org Fri Aug 9 08:13:16 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 9 Aug 2024 08:13:16 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> > When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. > > This change fixes this mistake. Now drag image should be properly offset. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: GlassViewDelegate: Correctly set origin and offset in dragImage - Centering to dragImage was removed - origin is now top-left of dragImage - Offset direction was swapped ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1532/files - new: https://git.openjdk.org/jfx/pull/1532/files/92c190e2..c922de84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1532.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1532/head:pull/1532 PR: https://git.openjdk.org/jfx/pull/1532 From lkostyra at openjdk.org Fri Aug 9 08:13:16 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 9 Aug 2024 08:13:16 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra wrote: > When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. > > This change fixes this mistake. Now drag image should be properly offset. I did not realize that Windows/macOS behavior was matched in this regard, so I'll use Windows as reference for further testing. Thanks! I agree offsets should be flipped (with `-=` rather than `+=`) so that is working well. I also removed the centering of the drag image, so now both shift directions and offset origin match Windows. However, from my initial testing, it seems like macOS prefers the mouse cursor to be always within the drag image bounds. As an example, `DndTest.java` defined the Y offset equal to -30. While the drag image is initially offset correctly, macOS immediately "snaps" it back so that the mouse cursor stays within the drag image bounds. This seems to be a platform-specific behavior though (Windows keeps the offset as we define it). I'll do some more experiments and see if that can be remedied somehow, but for now I doubt it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2277396417 From jhendrikx at openjdk.org Fri Aug 9 11:24:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Aug 2024 11:24:39 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Thu, 8 Aug 2024 15:45:37 GMT, Andy Goryachev wrote: >> Returning `null` seems fine from the perspective of `StyleConverter`, but it makes the calling code very awkward. Remember, we ended up here because we needed a way to detect whether an object would support component-wise transitions. If we can't detect that without invoking `convertBack`, we would need to either: >> 1. Speculatively decompose the value without knowing whether there even are any transitions defined on the node. This is bad because most of the time, there will be no transitions; we will end up deconstructing many objects for no reason. >> 2. _Assume_ that an object is component-transitionable, look up all potential transitions, and decompose the value; then, if we were wrong with out assumption, go back to the start and try again with another code path (`Interpolatable` or no transition). >> >> Instead, what I've implemented now is a new interface `StyleConverter.WithReconstructionSupport`, which contains both methods: >> >> public interface WithReconstructionSupport { >> T convert(Map, Object> values); >> Map, Object> convertBack(T value); >> } >> >> >> This allows us to use object deconstruction and reconstruction with a single interface reference, and also allows us to detect such support very easily. > > +1 for `StyleConverter.WithReconstructionSupport` > > maybe use a shorter name, like > > `StyleConverter.WithReconstruction` Clear, thanks MIchael. I would suggest `Reconstructable` as the name, which seems more inline with interface naming (especially `Interpolatable`). Reads nice also: if (converter instanceof Reconstructable r) { ... } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1711286120 From mstrauss at openjdk.org Fri Aug 9 13:39:43 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 13:39:43 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Fri, 9 Aug 2024 11:20:55 GMT, John Hendrikx wrote: >> +1 for `StyleConverter.WithReconstructionSupport` >> >> maybe use a shorter name, like >> >> `StyleConverter.WithReconstruction` > > Clear, thanks MIchael. I would suggest `Reconstructable` as the name, which seems more inline with interface naming (especially `Interpolatable`). Reads nice also: > > if (converter instanceof Reconstructable r) { ... } But the converter is not reconstructable (in comparison to Interpolatable, which is something the marked types actually are). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1711480351 From michaelstrau2 at gmail.com Fri Aug 9 14:31:04 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 9 Aug 2024 16:31:04 +0200 Subject: No Place for JEPs In-Reply-To: References: Message-ID: Hi Andy, wouldn't these documents risk getting outdated when the codebase is evolved? JEPs seem to be most relevant at the time when a feature is proposed. I think I'd rather have documentation colocated with the code itself, this makes it easier to keep the documentation in sync with the actual implementation. On Wed, Aug 7, 2024 at 8:46?PM Andy Goryachev wrote: > > Dear fellow developers: > > > > We often create JEPs and JEP-formatted documents as we propose and develop new features. These help us during the review process and I am sure are of some benefit for application developers as they try to learn the new functionality in depth. Presently, we've been creating these files in personal repositories, or presented as descriptions for pull requests, see for example [0]. > > > > I think there is a value in making these documents a part of the main repository, maybe under /doc-files. Doing so would help with the review process as the markdown files are both human-readable and easily diff'ed. Also, I think it might be more convenient to keep them in the same repo as the code, as opposed to the some personal repositories or wikis. > > > > What do you think? > > > > -andy > > > > > > References > > > > [0] https://github.com/openjdk/jfx/pull/1522 From angorya at openjdk.org Fri Aug 9 14:40:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Aug 2024 14:40:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v22] In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 04:00:16 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only call get() when necessary > Maybe we should do that as a separate ticket. Changing the documentation of properties that have nothing to do with backgrounds and borders is probably a bit out of scope for this PR. I am afraid I'd disagree here: I would like to see the CSS reference reflect the new changes, to be in sync with the javadoc. I think this is still a part of the same changeset. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2278099177 From angorya at openjdk.org Fri Aug 9 14:54:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Aug 2024 14:54:43 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev wrote: > Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. > > This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. > > The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. > * Implement [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) > * Specify that `dispatchEvent` must only return `null` if the event was consumed. > * Explicitly document that `Event.isConsumed()` can only be used inside of an event handler, but not to detect whether an event was consumed at the place where the event is fired. I am afraid this makes no sense to me. I still think the root cause of the issue(s) is the cloning of events, where the cloning code ignores the possible consumption of the secondary events. I don't think we should redefine semantics of `Event.isConsumed()`, this method worked well in AWT/Swing and elsewhere (QT). If anything, the code that clones an event for the purposes of changing its target needs to look at the isConsumed() flag and propagate it to the original event. The problem is that `Event.copyFor()` is also used for other purposes as well. Looks like we've reached an impasse (again). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2278135889 From kcr at openjdk.org Fri Aug 9 15:05:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Aug 2024 15:05:46 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v22] In-Reply-To: References: Message-ID: <-2v4p-hrGdbP3zE3Xgr9jz4owM8NFosVIdxUfCEYKZ0=.0e21a1d3-152b-4e31-9387-fda9318242f2@github.com> On Fri, 9 Aug 2024 14:37:38 GMT, Andy Goryachev wrote: > > Maybe we should do that as a separate ticket. Changing the documentation of properties that have nothing to do with backgrounds and borders is probably a bit out of scope for this PR. > > I am afraid I'd disagree here: I would like to see the CSS reference reflect the new changes, to be in sync with the javadoc. I think this is still a part of the same changeset. I'm a bit behind this week due to other commitments, but wanted to chime in briefly. The main question in my mind is whether (and how) this particular aspect of a property should be documented in the cssref. We don't duplicate all aspects of each styleable property in cssref. So, is the fact that a property is interpolatable important enough to CSS operation that it should be duplicated in cssref or not? I haven't had time to form an opinion, but that's the question that should be answered first. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2278160387 From angorya at openjdk.org Fri Aug 9 15:12:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Aug 2024 15:12:39 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug You are right, @hjohn , we probably should not alter the behavior in this PR. The rest looks good. If you decide to make the minor changes I've mentioned, I'll re-approve. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2230449949 From andy.goryachev at oracle.com Fri Aug 9 15:28:29 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 9 Aug 2024 15:28:29 +0000 Subject: No Place for JEPs In-Reply-To: References: Message-ID: Michael: Yes, by design. I think the JEPs still have value even after the actual changes were made. Also, nothing prevents us from creating an index.html file that lists the JEPs in chronological order and mentions the state of the implemented features and whether and how the actual implementation differs from the JEP. Sorry, I did not quite understand what you mean by "documentation colocated with the code" - isn't that what I am proposing? At the same time, I wanted to consider other possibilities, such as - wikis (same drawbacks as github PRs, even harder to review / keep track of changes / lack of co-location) - separate doc repo (not co-located with the code) - ?? What do you think? -andy From: openjfx-dev on behalf of Michael Strau? Date: Friday, August 9, 2024 at 07:31 To: Cc: openjfx-dev at openjdk.org Subject: Re: No Place for JEPs Hi Andy, wouldn't these documents risk getting outdated when the codebase is evolved? JEPs seem to be most relevant at the time when a feature is proposed. I think I'd rather have documentation colocated with the code itself, this makes it easier to keep the documentation in sync with the actual implementation. On Wed, Aug 7, 2024 at 8:46?PM Andy Goryachev wrote: > > Dear fellow developers: > > > > We often create JEPs and JEP-formatted documents as we propose and develop new features. These help us during the review process and I am sure are of some benefit for application developers as they try to learn the new functionality in depth. Presently, we've been creating these files in personal repositories, or presented as descriptions for pull requests, see for example [0]. > > > > I think there is a value in making these documents a part of the main repository, maybe under /doc-files. Doing so would help with the review process as the markdown files are both human-readable and easily diff'ed. Also, I think it might be more convenient to keep them in the same repo as the code, as opposed to the some personal repositories or wikis. > > > > What do you think? > > > > -andy > > > > > > References > > > > [0] https://github.com/openjdk/jfx/pull/1522 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Aug 9 15:40:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Aug 2024 15:40:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v22] In-Reply-To: References: <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com> Message-ID: On Fri, 9 Aug 2024 02:23:11 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 113: >> >>> 111: * @return a {@code Map} of the constituent values >>> 112: */ >>> 113: Map, Object> convertBack(T value); >> >> perhaps `convertToMap` might be better? or something along the lines of `toInstance`/`toMap` ? `decompose` / `reconstruct` ? (though decompose might evoke wrong associations) > > `reconstruct` is a misnomer, as reconstruction is a two-step operation (`convertBack` followed by `convert`). To be fair, I don't like any of these better than `convertBack`, mostly because I want to stress that those two operations are closely related, and none of the alternatives evoke that sentiment. That being said, this is a minor API and I don't really mind either way, but absent a compelling reason, I'd prefer to stick to `convertBack`. That's fine, I just think `convertBack` implies an arrow of time or a preferred spatial direction. Maybe `toMap()`, but as long as the method is sufficiently documented, we should be fine. Naming _is_ hard. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1711692474 From perini.davide at dpsoftware.org Fri Aug 9 15:56:02 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 9 Aug 2024 17:56:02 +0200 Subject: JEP Vector API (Incubator). A funny use case and a question. Message-ID: <3e924999-43dc-41c9-ae19-08e4249351c5@dpsoftware.org> Hi there, thanks for the opportunity that you give us to write on this mailing-list. I'm am playing with the Vector API bundled in Java 22 and wow, they are amazing. I have some serious benefits using them even for simple tasks on my AMD Ryzen 9 7950X3D CPU that uses Zen4 architecture. Can't wait to see how bigger the benefits will be on the upcoming processors that has some serious optimized AVX512 instructions (AMD Zen5 architecture and Intel AV10 instructions). I'll try to give you some context. I am writing an open source software that is basically a free clone of the Philips Ambilight effect. What is it? Basically you put a LED strip behind your monitor/TV, the software capture the screen, it calculates the average colors of your screen, and sends those average values to a microcontroller (arduino) that drives the strip and light up the LEDs accordingly. This effect is also known as dynamic bias light. More info here if you are curious: https://github.com/sblantipodi/firefly_luciferin Most of the computations involved are on the GPU side but some intensive ones are on the CPU side. Let's go deeper on the Vector API. GPU acquire the screen image 60 times per seconds (or even more), every frame is a Buffer that contains colors information for each pixel of the frame. This buffer is a Java Direct IntBuffer that doesn't have a corresponding array inside the heap for performance reason. Once I have this IntBuffer I need to calculate the average colors of the screen and this thing can be made on the fly on the IntBuffer without copying the IntBuffer inside an Array. This kind of copy is really really heavy and degrade performance. Just a snippet that shows it without using the Vector API... for (int y =0; y < pixelInUseY; y++) { for (int x =0; x < pixelInUseX; x++) { int offsetX = (xCoordinate + x); int offsetY = (yCoordinate + y); int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY >16 &0xFF; g += rgb >>8 &0xFF; b += rgb &0xFF; pickNumber++; } } leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber); Now I'm trying to use the Vector API to accelerate this computations even more and hey, it worked awesome. Using AVX512 (Species512) the computations is 40%-80% faster than without the Vector API. int firstLimit; int secondLimit; // Processing the buffer in the correct order is crucial for SIMD performance if (pixelInUseX < pixelInUseY) { firstLimit = pixelInUseX; secondLimit = pixelInUseY; }else { firstLimit = pixelInUseY; secondLimit = pixelInUseX; } // SIMD iteration for (int x =0; x < firstLimit; x++) { for (int y =0; y < secondLimit; y += MainSingleton.getInstance().SPECIES.length()) { int offsetX; int offsetY; if (pixelInUseX < pixelInUseY) { offsetX = (xCoordinate + x); offsetY = (yCoordinate + y); }else { offsetX = (xCoordinate + y); offsetY = (yCoordinate + x); } int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY >16 &0xFF; g += rgbVector.lane(1) >>8 &0xFF; b += rgbVector.lane(2) &0xFF; pickNumber++; } } leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber); The computation itself is at least ten times faster but at the end it's only 40%-80% faster because I'm not able to process the IntBuffer on the fly using Vector API. As you can see in the previous snippet I need to copy part of the IntBuffer into an int[] array and then process it using the Vector API. This copy alone is the thing that requires more time. Is it possible to process a direct IntBuffer with the Vector API without loosing time in an array copy? Thank you for this wonderful API. Kind regards Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: From perini.davide at dpsoftware.org Fri Aug 9 15:57:49 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 9 Aug 2024 17:57:49 +0200 Subject: JEP Vector API (Incubator). A funny use case and a question. In-Reply-To: <3e924999-43dc-41c9-ae19-08e4249351c5@dpsoftware.org> References: <3e924999-43dc-41c9-ae19-08e4249351c5@dpsoftware.org> Message-ID: <2ea2f5ab-a2ae-4ae7-86ce-66f0c9a9e01b@dpsoftware.org> sorry to everyone. wrong list :( Il 09/08/2024 17:56, Davide Perini ha scritto: > Hi there, > thanks for the opportunity that you give us to write on this mailing-list. > > I'm am playing with the Vector API bundled in Java 22 and wow, they > are amazing. > I have some serious benefits using them even for simple tasks on my > AMD Ryzen 9 7950X3D CPU that uses Zen4 architecture. > > Can't wait to see how bigger the benefits will be on the upcoming > processors that has some serious optimized AVX512 instructions (AMD > Zen5 architecture and Intel AV10 instructions). > > I'll try to give you some context. > I am writing an open source software that is basically a free clone of > the Philips Ambilight effect. > > What is it? > Basically you put a LED strip behind your monitor/TV, the software > capture the screen, > it calculates the average colors of your screen, and sends those > average values to a microcontroller (arduino) that drives the strip > and light up the LEDs accordingly. > This effect is also known as dynamic bias light. > More info here if you are curious: > https://github.com/sblantipodi/firefly_luciferin > > Most of the computations involved are on the GPU side but some > intensive ones are on the CPU side. > > Let's go deeper on the Vector API. > GPU acquire the screen image 60 times per seconds (or even more), > every frame is a Buffer that contains colors information for each > pixel of the frame. > This buffer is a Java Direct IntBuffer that doesn't have a > corresponding array inside the heap for performance reason. > > Once I have this IntBuffer I need to calculate the average colors of > the screen and this thing can be made on the fly on the IntBuffer > without copying the IntBuffer inside an Array. This kind of copy is > really really heavy and degrade performance. > > Just a snippet that shows it without using the Vector API... > for (int y =0; y < pixelInUseY; y++) { > for (int x =0; x < pixelInUseX; x++) { > int offsetX = (xCoordinate + x); > int offsetY = (yCoordinate + y); > int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY int rgb =rgbBuffer.get(Math.min(rgbBuffer.capacity() -1, bufferOffset)); > r += rgb >>16 &0xFF; > g += rgb >>8 &0xFF; > b += rgb &0xFF; > pickNumber++; > } > } > leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber); > > Now I'm trying to use the Vector API to accelerate this computations > even more and hey, it worked awesome. > Using AVX512 (Species512) the computations is 40%-80% faster than > without the Vector API. > int firstLimit; > int secondLimit; > // Processing the buffer in the correct order is crucial for SIMD > performance if (pixelInUseX < pixelInUseY) { > firstLimit = pixelInUseX; > secondLimit = pixelInUseY; > }else { > firstLimit = pixelInUseY; > secondLimit = pixelInUseX; > } > // SIMD iteration for (int x =0; x < firstLimit; x++) { > for (int y =0; y < secondLimit; y += MainSingleton.getInstance().SPECIES.length()) { > int offsetX; > int offsetY; > if (pixelInUseX < pixelInUseY) { > offsetX = (xCoordinate + x); > offsetY = (yCoordinate + y); > }else { > offsetX = (xCoordinate + y); > offsetY = (yCoordinate + x); > } > int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY // Load RGB values using SIMD int[] rgbArray =new int[MainSingleton.getInstance().SPECIES.length()]; > rgbBuffer.position(bufferOffset); > rgbBuffer.get(rgbArray,0, Math.min(MainSingleton.getInstance().SPECIES.length(),rgbBuffer.remaining())); > IntVector rgbVector = IntVector.fromArray(MainSingleton.getInstance().SPECIES, rgbArray,0); > r += rgbVector.lane(0) >>16 &0xFF; > g += rgbVector.lane(1) >>8 &0xFF; > b += rgbVector.lane(2) &0xFF; > pickNumber++; > } > } > leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber); > > The computation itself is at least ten times faster but at the end > it's only 40%-80% faster because I'm not able to process the IntBuffer > on the fly using Vector API. > As you can see in the previous snippet I need to copy part of the > IntBuffer into an int[] array and then process it using the Vector API. > This copy alone is the thing that requires more time. > > Is it possible to process a direct IntBuffer with the Vector API > without loosing time in an array copy? > > Thank you for this wonderful API. > > Kind regards > Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: From vdyakov at openjdk.org Fri Aug 9 16:39:40 2024 From: vdyakov at openjdk.org (Victor Dyakov) Date: Fri, 9 Aug 2024 16:39:40 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove deprecated file @arapte please review ------------- PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2278333797 From angorya at openjdk.org Fri Aug 9 16:41:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Aug 2024 16:41:36 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev wrote: > Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. > > This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. > > The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. Actually, no CSR is required if I revert the `final` keyword changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2278336752 From mstrauss at openjdk.org Fri Aug 9 17:00:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 17:00:14 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v23] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: non-interpolatable values should always transition discretely ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/1abd6887..abef4325 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=22 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=21-22 Stats: 174 lines in 3 files changed: 128 ins; 15 del; 31 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Fri Aug 9 18:11:19 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 18:11:19 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v24] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - fix line separators - StyleableStringProperty should be transitionable ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/abef4325..a0557b8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=23 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=22-23 Stats: 111 lines in 2 files changed: 103 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From jhendrikx at openjdk.org Fri Aug 9 19:13:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Aug 2024 19:13:37 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid [v2] In-Reply-To: References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: On Fri, 9 Aug 2024 03:30:09 GMT, Loay Ghreeb wrote: >> Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order. > > Loay Ghreeb has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into SortedList > - Merge branch 'master' into SortedList > - Merge branch 'master' into SortedList > - Add test case > - Fix SortedList to maintain insertion order for equal elements The PR title "The sorting of the SortedList can become invalid" seems to imply that the sorting can become incorrect, as in the incorrect order. This is not the case. The sorting is still correct. Claiming that the sorting is invalid because a newly added item was not placed in a specific location relative to other equal items is a bit of misrepresentation. So, if this PR wants to move forward, I think we first need to decide if we want to guarantee a specific behavior when inserting new but equal elements. If we do, then it should be documented, and also maintained when the list gets resorted (ie. resorts must be stable). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2278581112 From john.hendrikx at gmail.com Fri Aug 9 19:15:05 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 9 Aug 2024 21:15:05 +0200 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com> Message-ID: <0d5bc648-a487-4052-b592-219066ffe9d8@gmail.com> Feel free, it is also somewhere on my github.? I'm not entirely confident it works for all cases, but it can be tweaked. Here's the missing piece you may need: /** * Tracks time spent (in milliseconds) between calls of {@link #enterNested()}and {@link #exitNested()} * excluding time spent in deeper nested levels. This allows to find the time spent at a certain * nesting level without including time spent at any deeper nestings. */ publicclassNestedTimeTracker{ privatefinalDeque startTimes= newArrayDeque<>(); privatefinalDeque cumulativeDurations= newArrayDeque<>(); { cumulativeDurations.add(0L); // Add root level, always present (this is never used, the entry is there to avoid having to check if we're at root level) } publicintgetCurrentLevel() { returnstartTimes.size(); } publicvoidenterNested() { enterNested(System.currentTimeMillis()); } publicvoidenterNested(longcurrentTimeMillis) { startTimes.addLast(currentTimeMillis); cumulativeDurations.add(0L); } publicvoidexitNested() { exitNested(System.currentTimeMillis()); } publiclongexitNested(longcurrentTimeMillis) { longstartTime = startTimes.removeLast(); longtimeSpentInNested = cumulativeDurations.removeLast(); // nested time, not part of this level longtotalTime = currentTimeMillis - startTime; // total time, including nested levels longtimeSpentAtThisLevel = totalTime - timeSpentInNested; // Consolidate total time spent in next higher level: cumulativeDurations.addLast(cumulativeDurations.removeLast() + totalTime); returntimeSpentAtThisLevel; } } --John On 08/08/2024 12:47, Thiago Milczarek Say?o wrote: > Nice! I will steal it if you don't mind. > > Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx > escreveu: > > For detecting long running tasks on the FX thread, there are some > other options which you can do as a user (but perhaps we can > support it directly within FX).? I use this kind of code to detect > long running things on the FX thread: > > /** > > * Adds a slow event warning whenever an event takes more than 10 > msto process. Note > > * that time spent in nested event loops cannot be properly taken > into account as time > > * spent in nested event loops will be part of the event that > triggered it giving false > > * positives. In order for this time to be accurately reflected, > the methods to enter > > * a nested event loop in this class should be used instead of the > ones in {@link Platform}. > > * > > * @paramscene a Scene to which to add the slow event warning > detection, cannot be null > > */ > > publicstaticvoidaddSlowEventWarning(Scene scene) { > > finalEventDispatcher eventDispatcher = scene.getEventDispatcher(); > > scene.setEventDispatcher(newEventDispatcher() { > > privateScheduledFuture future; > > @Override > > publicEvent dispatchEvent(Event event, EventDispatchChain tail) { > > if(future!= null) { > > future.cancel(false); > > } > > longstartTime = System.currentTimeMillis(); > > TIME_TRACKER.enterNested(startTime); // nesting can happen in two > ways, an event triggering another event, or when a nested event > loop is entered > > Event returnedEvent = eventDispatcher.dispatchEvent(event, tail); > > longendTime = System.currentTimeMillis(); > > longtimeSpentInNested = TIME_TRACKER.exitNested(endTime); > > if(timeSpentInNested > 10) { > > longtotal = endTime - startTime; > > LOGGER.warning("Slow Event (self/total: "+ timeSpentInNested + > "/"+ total + " ms @ level "+ TIME_TRACKER.getCurrentLevel() + "): > "+ event); > > } > > returnreturnedEvent; > > } > > }); > > } > > --John > > On 05/08/2024 17:17, Thiago Milczarek Say?o wrote: >> Hi, >> >> Interesting idea. We have this problem specially when Junior >> developers touch the code. >> >> The other way around would be nice too - if some I/O task >> executes on the FX thread. >> >> This can make the OS think the application hanged and offer to >> kill it, since it won't respond to "pings". And I/O tasks >> processing time may vary between installations. Also causes >> "white screens" since it blocks painting. >> >> -- Thiago. >> >> Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth >> escreveu: >> >>> Wouldn't it be better to implement this check in assert to >>> avoid any impact in production? >> >> No. Using an assert in a case like this is an anti-pattern. A >> call to assert in a library such as JavaFX is only >> appropriate for checking an invariant in internal logic. If >> we are going to go down this route of doing a thread check >> when mutating properties of "live" nodes, we will throw the >> same IllegalStateException that is currently thrown by some >> methods on Stage and Scene. >> >> As for the proposal itself, adding this check is an >> interesting idea. We considered doing this back in the JDK 7 >> (JavaFX 2) time frame, but decided not to pursue it then. I >> think the idea is worth further discussion. I would limit any >> thread checking to setting the property. It would be too >> restrictive (and largely unnecessary) to prevent reading a >> property from the application thread. >> >> The things to consider would be: >> >> 1. What is the performance hit of doing this check on the >> setting of every property? >> 2. What is the effect on bound properties? >> 3. How intrusive is it in the code? >> 4. Should we add a property to enable / disable the thread >> check, possibly a three- or four-valued property >> (allow|warn|debug?|deny), as was recently done in JEP 471 for >> sun.misc.Unsafe memory access methods. If so, what should the >> default be? >> >> My quick take is that if this can be done in a minimally >> intrusive manner with low overhead, we should consider >> pursing this. As for 4, my preference would be to add a >> three- or four-valued system property to control the check, >> with "warn" as the default initially, changing the default to >> "disallow" in a subsequent version. This would, of course, >> require a lot of testing. >> >> -- Kevin >> >> >> On 8/4/2024 8:40 PM, quizynox wrote: >>> Hello, >>> >>> Wouldn't it be better to implement this check in assert to >>> avoid any impact in production? >>> >>> ??, 5 ???. 2024??. ? 03:30, John Hendrikx >>> : >>> >>> Hi list, >>> >>> I know of quite some bugs and users that have been >>> bitten by the >>> threading model used by JavaFX.? Basically, anything >>> directly or >>> indirectly linked to an active Scene must be accessed on >>> the FX thread. >>> However, as FX also allows manipulating nodes and >>> properties before >>> they're displayed, there can be no "hard" check >>> everywhere to ensure we >>> are on the FX thread (specifically, in properties). >>> >>> Now, I think this situation is annoying, as a simple >>> mistake where a >>> Platform.runLater wrapper was forgotten usually results >>> in programs >>> operating mostly flawlessly, but then fail in mysterious >>> and random and >>> hard to reproduce ways.? The blame is often put on FX as >>> the resulting >>> exceptions will almost never show the user code which >>> was the actual >>> culprit.? It can result in FX being perceived as >>> unstable or buggy. >>> >>> So I've been thinking if there isn't something we can do >>> to detect these >>> bugs originating from user code much earlier, similar to >>> the >>> `ConcurrentModificationException` the collection classes >>> do when >>> accessed in nested or concurrent contexts. >>> >>> I think it may be possible to have properties check >>> whether they're part >>> of an active scene without too much of an performance >>> impact, possibly >>> even behind a switch. It would work like this: >>> >>> Properties involved with Nodes will have an associated >>> bean instance >>> (`getBean`).? This is an object, but we could check here >>> if this >>> instance implements an interface: >>> >>> ????? if (getBean() instanceof MayBePartOfSceneGraph x) { >>> ??????????? if (x.isPartOfActiveScene() && >>> !isOnFxThread()) { >>> ???????????????? throw new >>> IllegalStateException("Property must only be >>> used from the FX Application Thread"); >>> ??????????? } >>> ????? } >>> >>> This check could be done on every set of the property, >>> and potentially >>> on every get as well.? It should be relatively cheap, >>> but will expose >>> problematic code patterns at a much earlier stage.? >>> There's a chance >>> that this will "break" some programs that seemed to be >>> behaving >>> correctly as well, so we may want to put it behind a >>> switch until such >>> programs (or libraries) can be fixed. >>> >>> What do you all think? >>> >>> --John >>> >>> (*) Names of methods/interfaces are only used for >>> illustration purposes, >>> we can think of good names if this moves forward. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Fri Aug 9 19:19:50 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 9 Aug 2024 21:19:50 +0200 Subject: Detecting threading problems faster In-Reply-To: References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com> <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com> <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com> Message-ID: I noticed the copy/paste I did wasn't great, you don't need the `future` variable or code that manipulates it (I had a different version before, but this works quite well for now) --John On 08/08/2024 12:47, Thiago Milczarek Say?o wrote: > Nice! I will steal it if you don't mind. > > Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx > escreveu: > > For detecting long running tasks on the FX thread, there are some > other options which you can do as a user (but perhaps we can > support it directly within FX).? I use this kind of code to detect > long running things on the FX thread: > > /** > > * Adds a slow event warning whenever an event takes more than 10 > msto process. Note > > * that time spent in nested event loops cannot be properly taken > into account as time > > * spent in nested event loops will be part of the event that > triggered it giving false > > * positives. In order for this time to be accurately reflected, > the methods to enter > > * a nested event loop in this class should be used instead of the > ones in {@link Platform}. > > * > > * @paramscene a Scene to which to add the slow event warning > detection, cannot be null > > */ > > publicstaticvoidaddSlowEventWarning(Scene scene) { > > finalEventDispatcher eventDispatcher = scene.getEventDispatcher(); > > scene.setEventDispatcher(newEventDispatcher() { > > privateScheduledFuture future; > > @Override > > publicEvent dispatchEvent(Event event, EventDispatchChain tail) { > > if(future!= null) { > > future.cancel(false); > > } > > longstartTime = System.currentTimeMillis(); > > TIME_TRACKER.enterNested(startTime); // nesting can happen in two > ways, an event triggering another event, or when a nested event > loop is entered > > Event returnedEvent = eventDispatcher.dispatchEvent(event, tail); > > longendTime = System.currentTimeMillis(); > > longtimeSpentInNested = TIME_TRACKER.exitNested(endTime); > > if(timeSpentInNested > 10) { > > longtotal = endTime - startTime; > > LOGGER.warning("Slow Event (self/total: "+ timeSpentInNested + > "/"+ total + " ms @ level "+ TIME_TRACKER.getCurrentLevel() + "): > "+ event); > > } > > returnreturnedEvent; > > } > > }); > > } > > --John > > On 05/08/2024 17:17, Thiago Milczarek Say?o wrote: >> Hi, >> >> Interesting idea. We have this problem specially when Junior >> developers touch the code. >> >> The other way around would be nice too - if some I/O task >> executes on the FX thread. >> >> This can make the OS think the application hanged and offer to >> kill it, since it won't respond to "pings". And I/O tasks >> processing time may vary between installations. Also causes >> "white screens" since it blocks painting. >> >> -- Thiago. >> >> Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth >> escreveu: >> >>> Wouldn't it be better to implement this check in assert to >>> avoid any impact in production? >> >> No. Using an assert in a case like this is an anti-pattern. A >> call to assert in a library such as JavaFX is only >> appropriate for checking an invariant in internal logic. If >> we are going to go down this route of doing a thread check >> when mutating properties of "live" nodes, we will throw the >> same IllegalStateException that is currently thrown by some >> methods on Stage and Scene. >> >> As for the proposal itself, adding this check is an >> interesting idea. We considered doing this back in the JDK 7 >> (JavaFX 2) time frame, but decided not to pursue it then. I >> think the idea is worth further discussion. I would limit any >> thread checking to setting the property. It would be too >> restrictive (and largely unnecessary) to prevent reading a >> property from the application thread. >> >> The things to consider would be: >> >> 1. What is the performance hit of doing this check on the >> setting of every property? >> 2. What is the effect on bound properties? >> 3. How intrusive is it in the code? >> 4. Should we add a property to enable / disable the thread >> check, possibly a three- or four-valued property >> (allow|warn|debug?|deny), as was recently done in JEP 471 for >> sun.misc.Unsafe memory access methods. If so, what should the >> default be? >> >> My quick take is that if this can be done in a minimally >> intrusive manner with low overhead, we should consider >> pursing this. As for 4, my preference would be to add a >> three- or four-valued system property to control the check, >> with "warn" as the default initially, changing the default to >> "disallow" in a subsequent version. This would, of course, >> require a lot of testing. >> >> -- Kevin >> >> >> On 8/4/2024 8:40 PM, quizynox wrote: >>> Hello, >>> >>> Wouldn't it be better to implement this check in assert to >>> avoid any impact in production? >>> >>> ??, 5 ???. 2024??. ? 03:30, John Hendrikx >>> : >>> >>> Hi list, >>> >>> I know of quite some bugs and users that have been >>> bitten by the >>> threading model used by JavaFX.? Basically, anything >>> directly or >>> indirectly linked to an active Scene must be accessed on >>> the FX thread. >>> However, as FX also allows manipulating nodes and >>> properties before >>> they're displayed, there can be no "hard" check >>> everywhere to ensure we >>> are on the FX thread (specifically, in properties). >>> >>> Now, I think this situation is annoying, as a simple >>> mistake where a >>> Platform.runLater wrapper was forgotten usually results >>> in programs >>> operating mostly flawlessly, but then fail in mysterious >>> and random and >>> hard to reproduce ways.? The blame is often put on FX as >>> the resulting >>> exceptions will almost never show the user code which >>> was the actual >>> culprit.? It can result in FX being perceived as >>> unstable or buggy. >>> >>> So I've been thinking if there isn't something we can do >>> to detect these >>> bugs originating from user code much earlier, similar to >>> the >>> `ConcurrentModificationException` the collection classes >>> do when >>> accessed in nested or concurrent contexts. >>> >>> I think it may be possible to have properties check >>> whether they're part >>> of an active scene without too much of an performance >>> impact, possibly >>> even behind a switch. It would work like this: >>> >>> Properties involved with Nodes will have an associated >>> bean instance >>> (`getBean`).? This is an object, but we could check here >>> if this >>> instance implements an interface: >>> >>> ????? if (getBean() instanceof MayBePartOfSceneGraph x) { >>> ??????????? if (x.isPartOfActiveScene() && >>> !isOnFxThread()) { >>> ???????????????? throw new >>> IllegalStateException("Property must only be >>> used from the FX Application Thread"); >>> ??????????? } >>> ????? } >>> >>> This check could be done on every set of the property, >>> and potentially >>> on every get as well.? It should be relatively cheap, >>> but will expose >>> problematic code patterns at a much earlier stage.? >>> There's a chance >>> that this will "break" some programs that seemed to be >>> behaving >>> correctly as well, so we may want to put it behind a >>> switch until such >>> programs (or libraries) can be fixed. >>> >>> What do you all think? >>> >>> --John >>> >>> (*) Names of methods/interfaces are only used for >>> illustration purposes, >>> we can think of good names if this moves forward. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri Aug 9 19:45:41 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Aug 2024 19:45:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Fri, 9 Aug 2024 13:36:34 GMT, Michael Strau? wrote: >> Clear, thanks MIchael. I would suggest `Reconstructable` as the name, which seems more inline with interface naming (especially `Interpolatable`). Reads nice also: >> >> if (converter instanceof Reconstructable r) { ... } > > But the converter is not reconstructable (in comparison to Interpolatable, which is something the marked types actually are). Sorry to keep harping on this, but so far, I think all the options are quite poor from the perspective of the user, and from a perspective of "could it have been designed this way in the first place". I also think I smell something fishy. The `StyleConverter` seems to serve two unrelated purposes. One is to convert raw parsed values for the CSS parser (`convert(ParsedValue, Font)`) to a Java object. The other is to support sub-properties (which you can also detect by checking if `CssMetaData.getSubProperties` is not empty). Although that method is also called `convert` it is only used by `CssStyleHelper`, which is completely unrelated to parsing. A more accurate name for that method would be "consolidateSubPropertyValues" (and the opposite would then be something like "extractSubPropertyValues", or `consolidate` and `extract` for short). There does not seem to be any overlap between these two purposes. That is it to say, a style converter that is used for decoding sub-properties is never used for parsing, and vice versa. FX also does not support special syntax for specifying say a border in short hand form (like `-fx-border: dashed red`). I think it may be a good idea to perhaps have a look if these purposes shouldn't just be split. On the one hand, you have a style converter which uses `convert` for parsing. On the other hand, you have `CssMetaData`, which when it has sub-properties **must** support a back-and-forth translation (`convert` + `convertBack`) -- this is currently not enforced (ie. you can create `CssMetaData` with sub-properties but then **not** implement `convert(Map)` in the used style converter... this causes problems later on. The only CSS property currently that supports both short-hand and sub-properties is actually the newly introduced `transition` property. This could either implement two interfaces, or it could just be two classes. I've done a quick attempt to do such a split (not looking too much at API) and the whole thing compiles and passes all tests still. This is surprising, because I deleted several pieces of code, that are apparently never used (or perhaps not tested for, we can investigate this further). See here: #1533 Diff: https://github.com/openjdk/jfx/pull/1533/commits/8f6d1e56a43068184599ad1ea47b4da98eb70bff#diff-fc96cf3204909a6110e64c37a935927be56efedc9f3f4f6f6843cc4fa7da5a1f Let me know if you feel this has merit. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712057854 From mfox at openjdk.org Fri Aug 9 20:18:36 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 9 Aug 2024 20:18:36 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev wrote: > Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. > > This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. > > The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. The cloning of an event is necessary in order to update the `target` when the event is fired and the `source` when the event is passed to a handler. The alternative would be to modify those fields in-place which sounds like a bookkeeping nightmare particularly if an event is re-fired (something this PR does). I can see why the JavaFX designers decided to make copies instead. @andy-goryachev-oracle wrote: > a) If the EventDispatcher does something different like creating the new events, it is up to that ED to deal with consequences. It means the developer wants to create new events and not to have the link between the events. An EventDispatcher that creates a new event without linking it to the original will break this PR. But that's a consequence you're creating. You can't say the developer is making a choice about event linking when the very notion is new with this PR. I agree with @mstr2, the dispatch machinery has an existing publicly accessible mechanism for communicating whether an event was consumed and it works fine. The documentation might be fuzzy around the edges but that can be solved. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2278679307 From mstrauss at openjdk.org Fri Aug 9 22:32:46 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 22:32:46 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v25] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: remove StyleConverter.WithReconstructionSupport ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/a0557b8f..9bdea0a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=24 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=23-24 Stats: 99 lines in 7 files changed: 62 ins; 27 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Fri Aug 9 22:38:48 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Aug 2024 22:38:48 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Fri, 9 Aug 2024 19:42:56 GMT, John Hendrikx wrote: >> But the converter is not reconstructable (in comparison to Interpolatable, which is something the marked types actually are). > > Sorry to keep harping on this, but so far, I think all the options are quite poor from the perspective of the user, and from a perspective of "could it have been designed this way in the first place". > > I also think I smell something fishy. The `StyleConverter` seems to serve two unrelated purposes. One is to convert raw parsed values for the CSS parser (`convert(ParsedValue, Font)`) to a Java object. > > The other is to support sub-properties (which you can also detect by checking if `CssMetaData.getSubProperties` is not empty). Although that method is also called `convert` it is only used by `CssStyleHelper`, which is completely unrelated to parsing. A more accurate name for that method would be "consolidateSubPropertyValues" (and the opposite would then be something like "extractSubPropertyValues", or `consolidate` and `extract` for short). > > There does not seem to be any overlap between these two purposes. That is it to say, a style converter that is used for decoding sub-properties is never used for parsing, and vice versa. FX also does not support special syntax for specifying say a border in short hand form (like `-fx-border: dashed red`). > > I think it may be a good idea to perhaps have a look if these purposes shouldn't just be split. On the one hand, you have a style converter which uses `convert` for parsing. On the other hand, you have `CssMetaData`, which when it has sub-properties **must** support a back-and-forth translation (`convert` + `convertBack`) -- this is currently not enforced (ie. you can create `CssMetaData` with sub-properties but then **not** implement `convert(Map)` in the used style converter... this causes problems later on. > > The only CSS property currently that supports both short-hand and sub-properties is actually the newly introduced `transition` property. This could either implement two interfaces, or it could just be two classes. > > I've done a quick attempt to do such a split (not looking too much at API) and the whole thing compiles and passes all tests still. This is surprising, because I deleted several pieces of code, that are apparently never used (or perhaps not tested for, we can investigate this further). > > See here: #1533 > > Diff: https://github.com/openjdk/jfx/pull/1533/commits/8f6d1e56a43068184599ad1ea47b4da98eb70bff#diff-fc96cf3204909a6110e64c37a935927be56efedc9f3f4f6f6843cc4fa7da5a1f > > Let me know if you feel this has merit. I also think that we're probably dealing with two different things that are mixed up in `StyleConverter`. But instead of having this discussion here, it probably makes more sense to have it in the context of [JDK-8333121](https://bugs.openjdk.org/browse/JDK-8333121) because it seems relevant to eventually support both short-hand and long-hand property notations. I've renamed `WithReconstructionSupport` to `SubPropertyConverter` and moved it to an internal package for now. Since both `BackgroundConverter` and `BorderConverter` are not public, we can change it any way we want at a later time. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712306610 From mstrauss at openjdk.org Sat Aug 10 01:07:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 10 Aug 2024 01:07:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v22] In-Reply-To: References: <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com> Message-ID: On Fri, 9 Aug 2024 15:37:56 GMT, Andy Goryachev wrote: >> `reconstruct` is a misnomer, as reconstruction is a two-step operation (`convertBack` followed by `convert`). To be fair, I don't like any of these better than `convertBack`, mostly because I want to stress that those two operations are closely related, and none of the alternatives evoke that sentiment. That being said, this is a minor API and I don't really mind either way, but absent a compelling reason, I'd prefer to stick to `convertBack`. > > That's fine, I just think `convertBack` implies an arrow of time or a preferred spatial direction. > > Maybe `toMap()`, but as long as the method is sufficiently documented, we should be fine. Naming _is_ hard. I've moved this to an internal interface (it doesn't need to be public for this PR), so we can have the discussion later if we choose to make this API public (and if so, how we go about doing that). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712445361 From duke at openjdk.org Sat Aug 10 07:12:37 2024 From: duke at openjdk.org (Loay Ghreeb) Date: Sat, 10 Aug 2024 07:12:37 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid [v2] In-Reply-To: References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: On Fri, 9 Aug 2024 19:11:24 GMT, John Hendrikx wrote: > This is not the case. The sorting is still correct. Claiming that the sorting is invalid because a newly added item was not placed in a specific location relative to other equal items is a bit of misrepresentation. > > So, if this PR wants to move forward, I think we first need to decide if we want to guarantee a specific behavior when inserting new but equal elements. The issue isn?t just with adding new elements. It also affects the `TableView` that populated with items from a `SortedList`, The `SortedList`'s comparator is bound to the `TableView`'s comparator. When the table is sorted by multiple columns, removing a column from the sort order should reorder the items. However, currently, removing any column from the sort order doesn't change the items order until all sorting columns are removed. At that point, the items returned to the default insertion order. For example: ![image](https://github.com/user-attachments/assets/9ed8b2ea-9879-4dc9-a285-4d03be2d2691) 1. The initial order is [0, 1, 2, 3] (index column). 2. Sort by `Col1`, the order will be: [1, 0, 2, 3]. 3. Add a second sort (Shift + Click) on `Col2`, the order will be: [1, 2, 3, 0]. 4. Shift + Click again on `Col2` to sort in descending order: [1, 0, 3, 2]. 5. Shift + Click again on `Col2` to remove the sort from `Col2`. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2.
          Code import javafx.application.Application; import javafx.beans.property.ReadOnlyObjectWrapper; import javafx.collections.FXCollections; import javafx.collections.ObservableList; import javafx.collections.transformation.SortedList; import javafx.scene.Scene; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.stage.Stage; public class Main extends Application { @Override public void start(Stage primaryStage) { primaryStage.setScene(new Scene(createTableView())); primaryStage.show(); } private TableView createTableView() { TableView tableView = new TableView<>(); TableColumn indexColumn = new TableColumn<>("#"); indexColumn.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().index())); indexColumn.setSortable(false); TableColumn column1 = new TableColumn<>("Col1"); column1.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().val1())); TableColumn column2 = new TableColumn<>("Col2"); column2.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().val2())); tableView.getColumns().addAll(indexColumn, column1, column2); ObservableList data = FXCollections.observableArrayList( new Data(0, 5, 4), new Data(1, 1, 7), new Data(2, 5, 2), new Data(3, 5, 3) ); SortedList sortedData = new SortedList<>(data); sortedData.comparatorProperty().bind(tableView.comparatorProperty()); tableView.setItems(sortedData); return tableView; } public record Data(int index, int val1, int val2) { } }
          ------------- PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2279897597 From jhendrikx at openjdk.org Sat Aug 10 11:27:41 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Aug 2024 11:27:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Fri, 9 Aug 2024 22:36:03 GMT, Michael Strau? wrote: >> Sorry to keep harping on this, but so far, I think all the options are quite poor from the perspective of the user, and from a perspective of "could it have been designed this way in the first place". >> >> I also think I smell something fishy. The `StyleConverter` seems to serve two unrelated purposes. One is to convert raw parsed values for the CSS parser (`convert(ParsedValue, Font)`) to a Java object. >> >> The other is to support sub-properties (which you can also detect by checking if `CssMetaData.getSubProperties` is not empty). Although that method is also called `convert` it is only used by `CssStyleHelper`, which is completely unrelated to parsing. A more accurate name for that method would be "consolidateSubPropertyValues" (and the opposite would then be something like "extractSubPropertyValues", or `consolidate` and `extract` for short). >> >> There does not seem to be any overlap between these two purposes. That is it to say, a style converter that is used for decoding sub-properties is never used for parsing, and vice versa. FX also does not support special syntax for specifying say a border in short hand form (like `-fx-border: dashed red`). >> >> I think it may be a good idea to perhaps have a look if these purposes shouldn't just be split. On the one hand, you have a style converter which uses `convert` for parsing. On the other hand, you have `CssMetaData`, which when it has sub-properties **must** support a back-and-forth translation (`convert` + `convertBack`) -- this is currently not enforced (ie. you can create `CssMetaData` with sub-properties but then **not** implement `convert(Map)` in the used style converter... this causes problems later on. >> >> The only CSS property currently that supports both short-hand and sub-properties is actually the newly introduced `transition` property. This could either implement two interfaces, or it could just be two classes. >> >> I've done a quick attempt to do such a split (not looking too much at API) and the whole thing compiles and passes all tests still. This is surprising, because I deleted several pieces of code, that are apparently never used (or perhaps not tested for, we can investigate this further). >> >> See here: #1533 >> >> Diff: https://github.com/openjdk/jfx/pull/1533/commits/8f6d1e56a43068184599ad1ea47b4da98eb70bff#diff-fc96cf3204909a6110e64c37a935927be56efedc9f3f4f6f6843cc4fa7da5a1f >> >> Let me know if you feel this has merit. > > I also think that we're probably dealing with two different things that are mixed up in `StyleConverter`. But instead of having this discussion here, it probably makes more sense to have it in the context of [JDK-8333121](https://bugs.openjdk.org/browse/JDK-8333121) because it seems relevant to eventually support both short-hand and long-hand property notations. > > I've renamed `WithReconstructionSupport` to `SubPropertyConverter` and moved it to an internal package for now. Since both `BackgroundConverter` and `BorderConverter` are not public, we can change it any way we want at a later time. Yes, that's a good idea, I was mainly worried about introducing a new public API that we can't remove later when we haven't figured out yet what the best direction would be. With this API removed, I think we can get this merged. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712627157 From jhendrikx at openjdk.org Sat Aug 10 11:36:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Aug 2024 11:36:38 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: On Sat, 10 Aug 2024 11:24:34 GMT, John Hendrikx wrote: >> I also think that we're probably dealing with two different things that are mixed up in `StyleConverter`. But instead of having this discussion here, it probably makes more sense to have it in the context of [JDK-8333121](https://bugs.openjdk.org/browse/JDK-8333121) because it seems relevant to eventually support both short-hand and long-hand property notations. >> >> I've renamed `WithReconstructionSupport` to `SubPropertyConverter` and moved it to an internal package for now. Since both `BackgroundConverter` and `BorderConverter` are not public, we can change it any way we want at a later time. > > Yes, that's a good idea, I was mainly worried about introducing a new public API that we can't remove later when we haven't figured out yet what the best direction would be. With this API removed, I think we can get this merged. One more thing. You introduced `transition` short hand version. Is it maybe a good idea to not do this yet until we have a better idea how to deal with them? Shorthand properties are just a convenience; the feature will work without them. If it was already released, then can ignore this as we're too late. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712628315 From jhendrikx at openjdk.org Sat Aug 10 11:55:35 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Aug 2024 11:55:35 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid [v2] In-Reply-To: References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: On Sat, 10 Aug 2024 07:10:03 GMT, Loay Ghreeb wrote: > Shift + Click again on Col2 to remove the sort from Col2. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2. Why is that the expected order? It is "a" possible, but valid order. When only sorting on `Col1` then in my opinion [1, 0, 2, 3], [1, 0, 3, 2], [1, 2, 0, 3], etc.. are all valid sort orders. If we want to distinguish between equal elements to give them a fixed sub-ordering (and the inverse one I suppose when the sort is descending) then what should the distinguishing factor be? Its position in the underlying unsorted list? The time it was added to the underlying list? They need not be the same. Using the position in the underlying list could be quite random if the source of the list doesn't guarantee a fixed position (from an unsorted database query for example). What if the underlying list is another sorted list or a filtered list, can we even rely on the indices those provide? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2281285791 From mstrauss at openjdk.org Sat Aug 10 14:08:40 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 10 Aug 2024 14:08:40 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v18] In-Reply-To: References: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com> <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com> Message-ID: <0eR3BWkeKqg7_CTsngqHnlHyoQXDZ2uBl1DY8ZUIuUo=.2a1acb89-14bb-4c13-b3a1-718458378168@github.com> On Sat, 10 Aug 2024 11:33:43 GMT, John Hendrikx wrote: >> Yes, that's a good idea, I was mainly worried about introducing a new public API that we can't remove later when we haven't figured out yet what the best direction would be. With this API removed, I think we can get this merged. > > One more thing. You introduced `transition` short hand version. Is it maybe a good idea to not do this yet until we have a better idea how to deal with them? Shorthand properties are just a convenience; the feature will work without them. If it was already released, then can ignore this as we're too late. The `transition` shorthand is already on track to be released, and we?re deep into RDP2. However, `TransitionDefinitionConverter` is not public API, it?s implementation can move around freely. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712646742 From mfox at openjdk.org Sat Aug 10 16:13:35 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 10 Aug 2024 16:13:35 GMT Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is handled differently depending on the useSystemMenuBar value In-Reply-To: References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com> Message-ID: On Thu, 8 Aug 2024 17:38:19 GMT, Andy Goryachev wrote: > Thinking out loud for a moment: wouldn't it be better to use a kind of EventFilter specifically for the shortcuts, before the normal dispatching happens? I think I see where you?re going here. We could send the KeyEvent into the scene graph and then catch it on the back end to be processed by the system menu bar. If the KeyEvent reaches the KeyboardAcceleratorHandler we know that it?s time for the menu bar to process it. I?ve thought about this but it would tricky to implement. Currently we only send a subset of key events to the system menu bar (the one?s that are delivered to us via performKeyEquivalent). Once a KeyEvent is injected into the scene graph we lose track of whether it was generated by performKeyEquivalent or keyDown. We could also see KeyEvents that weren?t created by glass (anyone can create one). We would have to find a way to sort this out on the back end. What truly makes me nervous is how we would have to alter the normal performKeyEquivalent flow. Usually NSApplication controls the order in which key equivalents are presented to different components (windows, views, the system menu bar, etc.) To implement this alternative approach we would have to short circuit the NSApplication flow and present events to the system menu bar manually. This PR is the most conservative one I could come up with since it doesn?t change the order of event processing and fits into the normal performKeyEquivalent flow that NSApplication expects. It just avoids double-processing of the same event. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2282197287 From mmack at openjdk.org Sat Aug 10 16:21:11 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 10 Aug 2024 16:21:11 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v3] In-Reply-To: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> References: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> Message-ID: On Sat, 13 Jul 2024 10:00:31 GMT, Markus Mack wrote: >> This PR is a fix for another IOOBE that I discovered while working on #1476. >> >> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. >> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. >> >> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. >> >> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. >> >> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. >> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > fix "negative" style class when series is changed I've added asserts verifying that the "negative" style class is added to the relevant tests, plus a new test to assert it is removed when data is changed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2282198878 From mmack at openjdk.org Sat Aug 10 16:21:12 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 10 Aug 2024 16:21:12 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v3] In-Reply-To: References: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> Message-ID: On Mon, 15 Jul 2024 16:32:58 GMT, Andy Goryachev wrote: >> Markus Mack has updated the pull request incrementally with one additional commit since the last revision: >> >> fix "negative" style class when series is changed > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java line 305: > >> 303: BarChart chart = new BarChart<>(new CategoryAxis(), new NumberAxis()); >> 304: XYChart.Series series = new XYChart.Series<>(); >> 305: chart.getData().add(series); > > speaking of negative values - could we check **all** the possible ways where the 'negative' class is added? or removed? > > I think it might be possible to add a check to the exiting tests, to reuse the setup. > > Lastly, I think we also need to test the case when the data point becomes non-negative after explicit XYChart.Data.setValue(), do you think? good idea, done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1488#discussion_r1712669740 From mmack at openjdk.org Sat Aug 10 16:21:11 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 10 Aug 2024 16:21:11 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v4] In-Reply-To: References: Message-ID: > This PR is a fix for another IOOBE that I discovered while working on #1476. > > The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. > As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. > > Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. > > Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. > > Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. > Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - test "negative" style class in BarChartTest tests - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series - fix "negative" style class when series is changed - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java - BarChart: Fix adding non-empty series - BarChart: Add styleClass "negative" for added data ------------- Changes: https://git.openjdk.org/jfx/pull/1488/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1488&range=03 Stats: 125 lines in 2 files changed: 94 ins; 28 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1488.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1488/head:pull/1488 PR: https://git.openjdk.org/jfx/pull/1488 From mmack at openjdk.org Sat Aug 10 16:24:36 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 10 Aug 2024 16:24:36 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v3] In-Reply-To: References: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> Message-ID: On Mon, 15 Jul 2024 16:42:33 GMT, Andy Goryachev wrote: > I am going to ask this question - unrelated to this PR, but in the context of this PR. > > Consider the case of a context menu, where the application needs to know the data point from the screen/local coordinates. > > Currently, we can get the Node from the Data instance (XYChart.Data.node property), but not the other way around - that is, given the chart, and given the PickResult of a MouseEvent, it is impossible to get the data point corresponding to a Node. In other words, we have the model->view path but not the view->model one. > > In theory, the app developer could monitor the `node` property of Data and use `Node.getProperties()` map to set the Data instance on the node, or they could iterate through all the visible data points, matching the node with the data point, so it is not a big issue. > > I am interested in your opinion. What do you think? Good question, I'd say it is easy enough to loop through the chart's data items to find the correct node in that case, so I don't see a need to add this on the jfx side. Also, currently Data.getNode() just returns an opaque Node, so I don't see a good place where to expose that without either changing that API. Adding an Node.getProperties() entry should probably be done only by application developers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2282199843 From kcr at openjdk.org Sat Aug 10 17:26:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Aug 2024 17:26:36 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2] In-Reply-To: References: Message-ID: <_HVoTjY-P7QxnDqYzPXGqcwWR20Hi1ZcdQCyZJleZOs=.75202cb0-e6e4-467e-9cca-965a1260a89e@github.com> On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove deprecated file @tiainen Do you want a chance to review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2282217801 From kcr at openjdk.org Sat Aug 10 17:28:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Aug 2024 17:28:35 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: On Thu, 8 Aug 2024 16:01:59 GMT, Jose Pereda wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > I'm testing this PR, and I see that on macOS the offsets are now taken into account. > > However, comparing to Windows the behaviour is different: > > - On Windows, offset 0,0 means the cursor is at the most top-left coordinates of the dragView image. Setting positive offsets in x, y goes to the right and down of the image (which goes in line with the usual JavaFX coordinate system) > > - On macOS, with this PR, offset 0, 0 is at the centre of the dragView image, and positive offsets go to the opposite direction > > From the test attached to the issue, and with this PR: > > > WritableImage snapshot = source.snapshot(null, null); > > db.setDragView(snapshot); > db.setDragViewOffsetX(0); > > db.setDragViewOffsetY(0); > > on Windows -> cursor at the most top-left corner of the dragView > on macOS -> cursor at the centre of the dragView. > > And: > > WritableImage snapshot = source.snapshot(null, null); > > db.setDragView(snapshot); > db.setDragViewOffsetX(snapshot.getWidth() / 2); > > db.setDragViewOffsetY(snapshot.getHeight() / 2); > > on Windows -> cursor at the centre of the dragView > on macOS -> cursor at the most top-left corner of the dragView. > > So I'd say macOS should do the same as Windows, and for that you could try: > > - dragPoint.x -= ([image size].width/2.0f); > - dragPoint.y -= ([image size].height/2.0f); > + // dragPoint.x -= ([image size].width/2.0f); > + // dragPoint.y -= ([image size].height/2.0f); > > - dragPoint.x += offset.x; > - dragPoint.y += offset.y; > + dragPoint.x -= offset.x; > + dragPoint.y -= offset.y; > > > Does that make sense to you? Reviewers: @jperedadnr @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2282218190 From mstrauss at openjdk.org Sat Aug 10 18:02:41 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 10 Aug 2024 18:02:41 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v25] In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 22:32:46 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > remove StyleConverter.WithReconstructionSupport CSS properties don't always correspond to JavaFX properties (for example, `-fx-background-color` has no corresponding JavaFX property, it is combined with other CSS properties and mapped to `backgroundProperty()`). It might be a good idea to add a column to the CSS property tables, indicating the animation type of each CSS property. It would look like this: ![animationtype](https://github.com/user-attachments/assets/4f1437f5-4b31-4800-aefa-ec7d7a80d95e) However, this is a large documentation change in and of itself, and I strongly suggest to do this as part of [JDK-8338121](https://bugs.openjdk.org/browse/JDK-8338121) to keep this PR manageable and focused. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2282228208 From mfox at openjdk.org Sat Aug 10 18:41:35 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 10 Aug 2024 18:41:35 GMT Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is handled differently depending on the useSystemMenuBar value In-Reply-To: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com> References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com> Message-ID: <0EFkEwrKbfny1v9H1rfzTSPo_miMCpXKiUCe8MZuS5w=.4a2fc26c-1c62-4b7f-87c5-9f660e0eae6f@github.com> On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox wrote: > macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crash at the event before it works its way out to the menu bar. > > We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item. > > This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar. > > I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers. I'm marking this PR as draft for now. Turns out we're relying on double-processing of key events to make IM's work. macOS sends a navigation key to us via performKeyEquivalent. That includes Home, End, and any arrow key. Currently we let the scene graph act on the event first and if a TextInput control has the focus the event is usually consumed. If we stop processing the event (and we should since it's consumed) it will never reach the IM. In other words, the current system relies on having the same navigation key event sent to both performKeyEquivalent and keyDown. It gets acted on twice, once by the TextInput control and again by the IM. This is wrong but prioritizing the TextInput control over the IM is more wrong. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2282240246 From ashley.hales at gmail.com Sun Aug 11 07:11:54 2024 From: ashley.hales at gmail.com (Ashley Hales) Date: Sun, 11 Aug 2024 08:11:54 +0100 Subject: Fwd: Scene 3D objects throw exception on Android deivces In-Reply-To: References: Message-ID: Hi, I have been compiling a JavaFX app for Android using the Dalvik SDK. I have managed to resolve all the dependencies and compile into an APK. This APK will install on Android devices but doesn't work on all of them. I have modified the HelloWorld app included with the Dalvik SDK to debug my problem. It works on all of my devices with just a label on the screen but as soon as I add a sphere into the scene it just displays a black screen on some devices. I have searched on the internet and suggestions indicate that this may be a memory issue but I have tried setting android.monocle.stacksize = 12800 in the javafx.platform.properties but this has had no effect. After reading other posts on the forum I was wondering if this might be due to a lack of 3D support on embedded (although this is an Android device). I have tried modifying the javafx.platform.properties by setting android.com.sun.javafx.isEmbedded=false or com.sun.javafx.experimental.embedded.3d=true but neither have any effect. I have also tried printing out the result of Platform.isSupported(ConditionalFeature.SCENE3D) but confusingly this shows true despite the error. I have tested on a couple of devices so far. The error occurs every time on my MBOX MINIM8S II (Android 6.0.1) but never on my Samsung Galaxy Table Model SM-T230 (Android 4.4.2) device. I have also shared the compiled APK on Google Drive which you may access from https://drive.google.com/file/d/1QLA21gg2g9-ODrKctSqac6pNC2cxzCtx/view?usp=drive_link . Here is the logcat report for the issue? 05-12 09:10:06.584 4053 4181 I ActivityManager: Start proc 8921:org.javafxports.helloworld/u0a56 for activity org.javafxports.helloworld/javafxports.android.FXActivity 05-12 09:10:06.649 8921 8921 I art : Not late-enabling -Xcheck:jni (already on) 05-12 09:10:06.731 8921 8921 I MultiDex: VM with version 2.1.0 has multidex support 05-12 09:10:06.731 8921 8921 I MultiDex: install 05-12 09:10:06.731 8921 8921 I MultiDex: VM has multidex support, MultiDex support library is disabled. 05-12 09:10:06.735 8921 8921 V FXActivity: Initializing JavaFX Platform, using 8.60.9-SNAPSHOT 05-12 09:10:06.745 8921 8921 V FXActivity native: Loading JavaFXDalvik library 05-12 09:10:06.751 8921 8921 I System.out: usetextureview = false, useswipekeyboard = false 05-12 09:10:06.753 8921 8921 V FXActivity: onCreate called, using 8.60.9-SNAPSHOT 05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue instance created. 05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue started 05-12 09:10:06.758 4172 4172 V PhoneStatusBar: setLightsOn(true) 05-12 09:10:06.789 8921 8921 V FXActivity native: appDataDir: /data/user/0/org.javafxports.helloworld 05-12 09:10:06.790 8921 8921 V FXActivity: onStart 05-12 09:10:06.790 8921 8921 V FXActivity: onResume 05-12 09:10:06.827 8921 8921 V FXEntity: Surface created. 05-12 09:10:06.828 8921 8921 V FXActivity native: [JVDBG] SURFACE created native android window at 0xf4a94608, surface = 0xffda7390 05-12 09:10:06.970 8921 8921 I System.out: user.locale=en-US 05-12 09:10:06.970 8921 8921 I System.out: monocle.stackSize=128000 05-12 09:10:06.970 8921 8921 I System.out: prism.text=native 05-12 09:10:06.970 8921 8921 I System.out: java.vendor.url= http://www.android.com/ 05-12 09:10:06.970 8921 8921 I System.out: java.ext.dirs= 05-12 09:10:06.970 8921 8921 I System.out: line.separator= 05-12 09:10:06.970 8921 8921 I System.out: file.encoding=UTF-8 05-12 09:10:06.970 8921 8921 I System.out: java.runtime.version=0.9 05-12 09:10:06.970 8921 8921 I System.out: prism.dirtyopts=true 05-12 09:10:06.970 8921 8921 I System.out: user.name=root 05-12 09:10:06.970 8921 8921 I System.out: monocle.input.touchRadius=1 05-12 09:10:06.970 8921 8921 I System.out: java.compiler= 05-12 09:10:06.970 8921 8921 I System.out: android.icu.unicode.version=7.0 05-12 09:10:06.970 8921 8921 I System.out: prism.debugfonts=true 05-12 09:10:06.970 8921 8921 I System.out: java.version=0 05-12 09:10:06.970 8921 8921 I System.out: android.icu.library.version=55.1 05-12 09:10:06.970 8921 8921 I System.out: use.egl=true 05-12 09:10:06.971 8921 8921 I System.out: embedded=monocle 05-12 09:10:06.971 8921 8921 I System.out: prism.lcdtext=false 05-12 09:10:06.971 8921 8921 I System.out: os.arch=armv8l 05-12 09:10:06.971 8921 8921 I System.out: java.io.tmpdir=/data/user/0/org.javafxports.hellowor... 05-12 09:10:06.971 8921 8921 I System.out: glass.platform=Monocle 05-12 09:10:06.971 8921 8921 I System.out: android.zlib.version=1.2.8 05-12 09:10:06.971 8921 8921 I System.out: user.language=en 05-12 09:10:06.971 8921 8921 I System.out: java.vm.version=2.1.0 05-12 09:10:06.971 8921 8921 I System.out: com.sun.javafx.isEmbedded=true 05-12 09:10:06.971 8921 8921 I System.out: prism.glDepthSize=16 05-12 09:10:06.971 8921 8921 I System.out: path.separator=: 05-12 09:10:06.971 8921 8921 I System.out: java.runtime.name=Android Runtime 05-12 09:10:06.971 8921 8921 I System.out: java.specification.version=0.9 05-12 09:10:06.971 8921 8921 I System.out: user.dir=/ 05-12 09:10:06.971 8921 8921 I System.out: prism.maxTextureSize=2048 05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.vendor=The Android Project 05-12 09:10:06.971 8921 8921 I System.out: java.vm.name=Dalvik 05-12 09:10:06.971 8921 8921 I System.out: monocle.platform=Android 05-12 09:10:06.971 8921 8921 I System.out: log.lens=FINEST 05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.version=0.9 05-12 09:10:06.971 8921 8921 I System.out: user.home= 05-12 09:10:06.971 8921 8921 I System.out: java.specification.name=Dalvik Core Library 05-12 09:10:06.971 8921 8921 I System.out: file.separator=/ 05-12 09:10:06.971 8921 8921 I System.out: java.library.path=/vendor/lib:/system/lib 05-12 09:10:06.971 8921 8921 I System.out: user.variant= 05-12 09:10:06.971 8921 8921 I System.out: os.version=3.14.29 05-12 09:10:06.971 8921 8921 I System.out: java.boot.class.path=/system/framework/core-libart.jar:/sy... 05-12 09:10:06.971 8921 8921 I System.out: DALVIK.prism.verbose=true 05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.name=Dalvik Virtual Machine Specification 05-12 09:10:06.971 8921 8921 I System.out: javafx.platform=android 05-12 09:10:06.971 8921 8921 I System.out: glass.lens=eglfb 05-12 09:10:06.971 8921 8921 I System.out: os.name=Linux 05-12 09:10:06.971 8921 8921 I System.out: user.region=US 05-12 09:10:06.971 8921 8921 I System.out: java.class.path=. 05-12 09:10:06.971 8921 8921 I System.out: android.icu.impl.ICUBinary.dataPath=/data/misc/zoneinfo/current/icu:/syst... 05-12 09:10:06.971 8921 8921 I System.out: prism.verbose=true 05-12 09:10:06.971 8921 8921 I System.out: prism.vsync=false 05-12 09:10:06.971 8921 8921 I System.out: java.specification.vendor=The Android Project 05-12 09:10:06.971 8921 8921 I System.out: java.vm.vendor=The Android Project 05-12 09:10:06.971 8921 8921 I System.out: prism.allowhidpi=false 05-12 09:10:06.972 8921 8921 I System.out: java.vendor=The Android Project 05-12 09:10:06.972 8921 8921 I System.out: http.agent=Dalvik/2.1.0 (Linux; U; Android 6.0.1... 05-12 09:10:06.972 8921 8921 I System.out: android.icu.cldr.version=27.0.1 05-12 09:10:06.972 8921 8921 I System.out: android.openssl.version=BoringSSL 05-12 09:10:06.972 8921 8921 I System.out: java.home=/system 05-12 09:10:06.972 8921 8921 I System.out: java.vm.vendor.url= http://www.android.com/ 05-12 09:10:06.972 8921 8921 I System.out: java.class.version=50.0 05-12 09:10:06.972 8921 8921 V DalvikLauncher: Launch JavaFX application on DALVIK vm. 05-12 09:10:06.976 8921 8921 V DalvikLauncher: We have JavaFX on our current (base) classpath, registered exit listener 05-12 09:10:06.978 8921 8921 V DalvikLauncher: application class: [class org.javafxports.helloworld.HelloAndroid] 05-12 09:10:06.978 8921 8921 V DalvikLauncher: preloader class: [null] 05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx application class: [class javafx.application.Application] 05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx launcher class: [class com.sun.javafx.application.LauncherImpl] 05-12 09:10:06.978 8921 8921 V DalvikLauncher: launch application method: [public static void com.sun.javafx.application.LauncherImpl.launchApplication(java.lang.Class,java.lang.Class,java.lang.String[])] 05-12 09:10:06.979 8921 8921 V FXEntity: Called Surface changed [1280, 696], format 4 05-12 09:10:06.979 8921 8921 V FXActivity native: [JVDBG] SURFACE created native android window at 0xf4a94608, surface = 0xffda7370 05-12 09:10:06.980 8921 8921 V FXEntity: Called Surface redraw needed 05-12 09:10:06.989 8921 8921 V FXEntity: Called Surface redraw needed 05-12 09:10:07.018 4053 4075 I ActivityManager: Displayed org.javafxports.helloworld/javafxports.android.FXActivity: +461ms 05-12 09:10:07.020 8921 8938 I System.out: Prism pipeline init order: es2 05-12 09:10:07.020 8921 8938 I System.out: Using native-based Pisces rasterizer 05-12 09:10:07.020 8921 8938 I System.out: Using dirty region optimizations 05-12 09:10:07.020 8921 8938 I System.out: Using system sized mask for primitives 05-12 09:10:07.021 8921 8938 I System.out: Not forcing power of 2 sizes for textures 05-12 09:10:07.021 8921 8938 I System.out: Using hardware CLAMP_TO_ZERO mode 05-12 09:10:07.021 8921 8938 I System.out: Not opting in for HiDPI pixel scaling 05-12 09:10:07.026 8921 8939 I System.out: Prism pipeline name = com.sun.prism.es2.ES2Pipeline 05-12 09:10:07.029 8921 8939 I System.out: Loading ES2 native library ... prism_es2_monocle 05-12 09:10:07.039 8921 8939 I System.out: succeeded. 05-12 09:10:07.040 8921 8939 I System.out: GLFactory using com.sun.prism.es2.MonocleGLFactory 05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libGLESv2.so 05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712dd04 05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libEGL.so 05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712d9c4 05-12 09:10:07.053 8921 8939 I GLASS : Binding to libactivity.so 05-12 09:10:07.054 8921 8939 I GLASS : GetNativeWindow = 0xf4ad86dc, getDensitiy = 0xf4ad86ec 05-12 09:10:07.054 8921 8935 V FXEntity: notify_glassHasStarted called in FXActivity. register device now. 05-12 09:10:07.072 8921 8939 E libEGL : eglMakeCurrent:800 error 3009 (EGL_BAD_MATCH) 05-12 09:10:07.076 8921 8939 I System.out: (X) Got class = class com.sun.prism.es2.ES2Pipeline 05-12 09:10:07.077 8921 8939 I System.out: Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline 05-12 09:10:07.083 8921 8943 I DENSITY : GETDENSITY, answer = 1.000000 05-12 09:10:07.097 8921 8939 I System.out: Maximum supported texture size: 4096 05-12 09:10:07.097 8921 8939 I System.out: Maximum texture size clamped to 2048 05-12 09:10:07.097 8921 8939 I System.out: Non power of two texture support = true 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of vertex attributes = 16 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform vertex components = 1024 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform fragment components = 1024 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of varying components = 48 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units usable in a vertex shader = 0 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units usable in a fragment shader = 8 05-12 09:10:07.098 8921 8939 I System.out: Graphics Vendor: ARM 05-12 09:10:07.098 8921 8939 I System.out: Renderer: Mali-450 MP 05-12 09:10:07.098 8921 8939 I System.out: Version: OpenGL ES 2.0 05-12 09:10:07.104 8921 8935 I System.out: register device done 05-12 09:10:07.107 8921 8943 W System.err: vsync: false vpipe: true 05-12 09:10:07.107 8921 8943 I System.out: [MON] Create device 05-12 09:10:07.109 8921 8943 I System.out: [MON] Create device done, add done 05-12 09:10:07.257 8921 8943 W System.err: Loading FontFactory com.sun.javafx.font.freetype.FTFactory 05-12 09:10:07.258 8921 8943 W System.err: Subpixel: enabled 05-12 09:10:07.272 8921 8943 W System.err: Freetype2 Loaded (version 2.10.0) 05-12 09:10:07.272 8921 8943 W System.err: LCD support Enabled 05-12 09:10:07.302 8921 8943 W art : Before Android 4.1, method void com.sun.javafx.scene.transform.TransformUtils$ImmutableTransform.ensureCanTransform2DPoint() would have incorrectly overridden the package-private method in javafx.scene.transform.Transform 05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double javafx.scene.text.TextFlow.computeChildPrefAreaHeight(javafx.scene.Node, javafx.geometry.Insets) would have incorrectly overridden the package-private method in javafx.scene.layout.Region 05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double javafx.scene.text.TextFlow.computeChildPrefAreaWidth(javafx.scene.Node, javafx.geometry.Insets) would have incorrectly overridden the package-private method in javafx.scene.layout.Region 05-12 09:10:08.001 8921 8939 I System.out: max rectangle texture cell size = 62 05-12 09:10:08.019 8921 8939 I System.out: wrap rectangle texture = 2 x 2 05-12 09:10:08.024 8921 8939 I System.out: ES2ResourceFactory: Prism - createStockShader: AlphaTexture_Color.frag 05-12 09:10:08.287 8921 8939 E javafx : Program link log: L0010 Uniform 'color' differ on precision 05-12 09:10:08.287 8921 8939 W System.err: java.lang.RuntimeException: Error creating shader program 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:158) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:190) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.prism.es2.ES2Context.getPhongShader(ES2Context.java:122) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.prism.es2.ES2Context.renderMeshView(ES2Context.java:451) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.prism.es2.ES2MeshView.render(ES2MeshView.java:119) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGShape3D.renderMeshView(NGShape3D.java:179) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGShape3D.renderContent(NGShape3D.java:201) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:330) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) 05-12 09:10:08.288 8921 8939 W System.err: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423) 05-12 09:10:08.288 8921 8939 W System.err: at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) 05-12 09:10:08.288 8921 8939 W System.err: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113) 05-12 09:10:08.288 8921 8939 W System.err: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588) 05-12 09:10:08.288 8921 8939 W System.err: at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) 05-12 09:10:08.288 8921 8939 W System.err: at java.lang.Thread.run(Thread.java:818) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Mon Aug 12 07:59:32 2024 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 12 Aug 2024 10:59:32 +0300 Subject: Scene 3D objects throw exception on Android deivces In-Reply-To: References: Message-ID: This is not a JavaFX problem. From the stack trace, you're using javafxports, which is a 3rd party (Gluon) technology. It was EOL years ago and replaced by their client plugin [1][2]. See https://docs.gluonhq.com on how to compile JavaFX to mobile. There is, however, a 3D lighting issue with the OpenGL pipeline that affects Android, as shown in [3] for example. It's probably something wrong in the shader, but won't stop your application from running. - Nir [1] https://github.com/gluonhq/gluonfx-maven-plugin [2] https://github.com/gluonhq/gluonfx-gradle-plugin [3] https://stackoverflow.com/questions/50163758/issue-with-point-lights-when-on-mobile On Sun, Aug 11, 2024 at 10:12?AM Ashley Hales wrote: > Hi, I have been compiling a JavaFX app for Android using the Dalvik SDK. I > have managed to resolve all the dependencies and compile into an APK. This > APK will install on Android devices but doesn't work on all of them. > > I have modified the HelloWorld app included with the Dalvik SDK to debug > my problem. It works on all of my devices with just a label on the screen > but as soon as I add a sphere into the scene it just displays a black > screen on some devices. I have searched on the internet and suggestions > indicate that this may be a memory issue but I have tried setting > android.monocle.stacksize = 12800 in the javafx.platform.properties but > this has had no effect. After reading other posts on the forum I was > wondering if this might be due to a lack of 3D support on embedded > (although this is an Android device). I have tried modifying > the javafx.platform.properties by > setting android.com.sun.javafx.isEmbedded=false or com.sun.javafx.experimental.embedded.3d=true > but neither have any effect. I have also tried printing out the result > of Platform.isSupported(ConditionalFeature.SCENE3D) but confusingly this > shows true despite the error. > > I have tested on a couple of devices so far. The error occurs every time > on my MBOX MINIM8S II (Android 6.0.1) but never on my Samsung Galaxy > Table Model SM-T230 (Android 4.4.2) device. > > I have also shared the compiled APK on Google Drive which you may access > from > https://drive.google.com/file/d/1QLA21gg2g9-ODrKctSqac6pNC2cxzCtx/view?usp=drive_link > . > > Here is the logcat report for the issue? > > 05-12 09:10:06.584 4053 4181 I ActivityManager: Start proc > 8921:org.javafxports.helloworld/u0a56 for activity > org.javafxports.helloworld/javafxports.android.FXActivity > 05-12 09:10:06.649 8921 8921 I art : Not late-enabling -Xcheck:jni > (already on) > 05-12 09:10:06.731 8921 8921 I MultiDex: VM with version 2.1.0 has > multidex support > 05-12 09:10:06.731 8921 8921 I MultiDex: install > 05-12 09:10:06.731 8921 8921 I MultiDex: VM has multidex support, MultiDex > support library is disabled. > 05-12 09:10:06.735 8921 8921 V FXActivity: Initializing JavaFX Platform, > using 8.60.9-SNAPSHOT > 05-12 09:10:06.745 8921 8921 V FXActivity native: Loading JavaFXDalvik > library > 05-12 09:10:06.751 8921 8921 I System.out: usetextureview = false, > useswipekeyboard = false > 05-12 09:10:06.753 8921 8921 V FXActivity: onCreate called, using > 8.60.9-SNAPSHOT > 05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue > instance created. > 05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue > started > 05-12 09:10:06.758 4172 4172 V PhoneStatusBar: setLightsOn(true) > 05-12 09:10:06.789 8921 8921 V FXActivity native: appDataDir: > /data/user/0/org.javafxports.helloworld > 05-12 09:10:06.790 8921 8921 V FXActivity: onStart > 05-12 09:10:06.790 8921 8921 V FXActivity: onResume > 05-12 09:10:06.827 8921 8921 V FXEntity: Surface created. > 05-12 09:10:06.828 8921 8921 V FXActivity native: [JVDBG] SURFACE created > native android window at 0xf4a94608, surface = 0xffda7390 > 05-12 09:10:06.970 8921 8921 I System.out: user.locale=en-US > 05-12 09:10:06.970 8921 8921 I System.out: monocle.stackSize=128000 > 05-12 09:10:06.970 8921 8921 I System.out: prism.text=native > 05-12 09:10:06.970 8921 8921 I System.out: java.vendor.url= > http://www.android.com/ > 05-12 09:10:06.970 8921 8921 I System.out: java.ext.dirs= > 05-12 09:10:06.970 8921 8921 I System.out: line.separator= > 05-12 09:10:06.970 8921 8921 I System.out: file.encoding=UTF-8 > 05-12 09:10:06.970 8921 8921 I System.out: java.runtime.version=0.9 > 05-12 09:10:06.970 8921 8921 I System.out: prism.dirtyopts=true > 05-12 09:10:06.970 8921 8921 I System.out: user.name=root > 05-12 09:10:06.970 8921 8921 I System.out: monocle.input.touchRadius=1 > 05-12 09:10:06.970 8921 8921 I System.out: java.compiler= > 05-12 09:10:06.970 8921 8921 I System.out: android.icu.unicode.version=7.0 > 05-12 09:10:06.970 8921 8921 I System.out: prism.debugfonts=true > 05-12 09:10:06.970 8921 8921 I System.out: java.version=0 > 05-12 09:10:06.970 8921 8921 I System.out: android.icu.library.version=55.1 > 05-12 09:10:06.970 8921 8921 I System.out: use.egl=true > 05-12 09:10:06.971 8921 8921 I System.out: embedded=monocle > 05-12 09:10:06.971 8921 8921 I System.out: prism.lcdtext=false > 05-12 09:10:06.971 8921 8921 I System.out: os.arch=armv8l > 05-12 09:10:06.971 8921 8921 I System.out: > java.io.tmpdir=/data/user/0/org.javafxports.hellowor... > 05-12 09:10:06.971 8921 8921 I System.out: glass.platform=Monocle > 05-12 09:10:06.971 8921 8921 I System.out: android.zlib.version=1.2.8 > 05-12 09:10:06.971 8921 8921 I System.out: user.language=en > 05-12 09:10:06.971 8921 8921 I System.out: java.vm.version=2.1.0 > 05-12 09:10:06.971 8921 8921 I System.out: com.sun.javafx.isEmbedded=true > 05-12 09:10:06.971 8921 8921 I System.out: prism.glDepthSize=16 > 05-12 09:10:06.971 8921 8921 I System.out: path.separator=: > 05-12 09:10:06.971 8921 8921 I System.out: java.runtime.name=Android > Runtime > 05-12 09:10:06.971 8921 8921 I System.out: java.specification.version=0.9 > 05-12 09:10:06.971 8921 8921 I System.out: user.dir=/ > 05-12 09:10:06.971 8921 8921 I System.out: prism.maxTextureSize=2048 > 05-12 09:10:06.971 8921 8921 I System.out: > java.vm.specification.vendor=The Android Project > 05-12 09:10:06.971 8921 8921 I System.out: java.vm.name=Dalvik > 05-12 09:10:06.971 8921 8921 I System.out: monocle.platform=Android > 05-12 09:10:06.971 8921 8921 I System.out: log.lens=FINEST > 05-12 09:10:06.971 8921 8921 I System.out: > java.vm.specification.version=0.9 > 05-12 09:10:06.971 8921 8921 I System.out: user.home= > 05-12 09:10:06.971 8921 8921 I System.out: java.specification.name=Dalvik > Core Library > 05-12 09:10:06.971 8921 8921 I System.out: file.separator=/ > 05-12 09:10:06.971 8921 8921 I System.out: > java.library.path=/vendor/lib:/system/lib > 05-12 09:10:06.971 8921 8921 I System.out: user.variant= > 05-12 09:10:06.971 8921 8921 I System.out: os.version=3.14.29 > 05-12 09:10:06.971 8921 8921 I System.out: > java.boot.class.path=/system/framework/core-libart.jar:/sy... > 05-12 09:10:06.971 8921 8921 I System.out: DALVIK.prism.verbose=true > 05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.name=Dalvik > Virtual Machine Specification > 05-12 09:10:06.971 8921 8921 I System.out: javafx.platform=android > 05-12 09:10:06.971 8921 8921 I System.out: glass.lens=eglfb > 05-12 09:10:06.971 8921 8921 I System.out: os.name=Linux > 05-12 09:10:06.971 8921 8921 I System.out: user.region=US > 05-12 09:10:06.971 8921 8921 I System.out: java.class.path=. > 05-12 09:10:06.971 8921 8921 I System.out: > android.icu.impl.ICUBinary.dataPath=/data/misc/zoneinfo/current/icu:/syst... > 05-12 09:10:06.971 8921 8921 I System.out: prism.verbose=true > 05-12 09:10:06.971 8921 8921 I System.out: prism.vsync=false > 05-12 09:10:06.971 8921 8921 I System.out: java.specification.vendor=The > Android Project > 05-12 09:10:06.971 8921 8921 I System.out: java.vm.vendor=The Android > Project > 05-12 09:10:06.971 8921 8921 I System.out: prism.allowhidpi=false > 05-12 09:10:06.972 8921 8921 I System.out: java.vendor=The Android Project > 05-12 09:10:06.972 8921 8921 I System.out: http.agent=Dalvik/2.1.0 (Linux; > U; Android 6.0.1... > 05-12 09:10:06.972 8921 8921 I System.out: android.icu.cldr.version=27.0.1 > 05-12 09:10:06.972 8921 8921 I System.out: > android.openssl.version=BoringSSL > 05-12 09:10:06.972 8921 8921 I System.out: java.home=/system > 05-12 09:10:06.972 8921 8921 I System.out: java.vm.vendor.url= > http://www.android.com/ > 05-12 09:10:06.972 8921 8921 I System.out: java.class.version=50.0 > 05-12 09:10:06.972 8921 8921 V DalvikLauncher: Launch JavaFX application > on DALVIK vm. > 05-12 09:10:06.976 8921 8921 V DalvikLauncher: We have JavaFX on our > current (base) classpath, registered exit listener > 05-12 09:10:06.978 8921 8921 V DalvikLauncher: application class: [class > org.javafxports.helloworld.HelloAndroid] > 05-12 09:10:06.978 8921 8921 V DalvikLauncher: preloader class: [null] > 05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx application class: > [class javafx.application.Application] > 05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx launcher class: > [class com.sun.javafx.application.LauncherImpl] > 05-12 09:10:06.978 8921 8921 V DalvikLauncher: launch application method: > [public static void > com.sun.javafx.application.LauncherImpl.launchApplication(java.lang.Class,java.lang.Class,java.lang.String[])] > 05-12 09:10:06.979 8921 8921 V FXEntity: Called Surface changed [1280, > 696], format 4 > 05-12 09:10:06.979 8921 8921 V FXActivity native: [JVDBG] SURFACE created > native android window at 0xf4a94608, surface = 0xffda7370 > 05-12 09:10:06.980 8921 8921 V FXEntity: Called Surface redraw needed > 05-12 09:10:06.989 8921 8921 V FXEntity: Called Surface redraw needed > 05-12 09:10:07.018 4053 4075 I ActivityManager: Displayed > org.javafxports.helloworld/javafxports.android.FXActivity: +461ms > 05-12 09:10:07.020 8921 8938 I System.out: Prism pipeline init order: es2 > 05-12 09:10:07.020 8921 8938 I System.out: Using native-based Pisces > rasterizer > 05-12 09:10:07.020 8921 8938 I System.out: Using dirty region optimizations > 05-12 09:10:07.020 8921 8938 I System.out: Using system sized mask for > primitives > 05-12 09:10:07.021 8921 8938 I System.out: Not forcing power of 2 sizes > for textures > 05-12 09:10:07.021 8921 8938 I System.out: Using hardware CLAMP_TO_ZERO > mode > 05-12 09:10:07.021 8921 8938 I System.out: Not opting in for HiDPI pixel > scaling > 05-12 09:10:07.026 8921 8939 I System.out: Prism pipeline name = > com.sun.prism.es2.ES2Pipeline > 05-12 09:10:07.029 8921 8939 I System.out: Loading ES2 native library ... > prism_es2_monocle > 05-12 09:10:07.039 8921 8939 I System.out: succeeded. > 05-12 09:10:07.040 8921 8939 I System.out: GLFactory using > com.sun.prism.es2.MonocleGLFactory > 05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libGLESv2.so > 05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712dd04 > 05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libEGL.so > 05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712d9c4 > 05-12 09:10:07.053 8921 8939 I GLASS : Binding to libactivity.so > 05-12 09:10:07.054 8921 8939 I GLASS : GetNativeWindow = 0xf4ad86dc, > getDensitiy = 0xf4ad86ec > 05-12 09:10:07.054 8921 8935 V FXEntity: notify_glassHasStarted called in > FXActivity. register device now. > 05-12 09:10:07.072 8921 8939 E libEGL : eglMakeCurrent:800 error 3009 > (EGL_BAD_MATCH) > 05-12 09:10:07.076 8921 8939 I System.out: (X) Got class = class > com.sun.prism.es2.ES2Pipeline > 05-12 09:10:07.077 8921 8939 I System.out: Initialized prism pipeline: > com.sun.prism.es2.ES2Pipeline > 05-12 09:10:07.083 8921 8943 I DENSITY : GETDENSITY, answer = 1.000000 > 05-12 09:10:07.097 8921 8939 I System.out: Maximum supported texture size: > 4096 > 05-12 09:10:07.097 8921 8939 I System.out: Maximum texture size clamped to > 2048 > 05-12 09:10:07.097 8921 8939 I System.out: Non power of two texture > support = true > 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of vertex > attributes = 16 > 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform > vertex components = 1024 > 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform > fragment components = 1024 > 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of varying > components = 48 > 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units > usable in a vertex shader = 0 > 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units > usable in a fragment shader = 8 > 05-12 09:10:07.098 8921 8939 I System.out: Graphics Vendor: ARM > 05-12 09:10:07.098 8921 8939 I System.out: Renderer: Mali-450 MP > 05-12 09:10:07.098 8921 8939 I System.out: Version: OpenGL ES 2.0 > 05-12 09:10:07.104 8921 8935 I System.out: register device done > 05-12 09:10:07.107 8921 8943 W System.err: vsync: false vpipe: true > 05-12 09:10:07.107 8921 8943 I System.out: [MON] Create device > 05-12 09:10:07.109 8921 8943 I System.out: [MON] Create device done, add > done > 05-12 09:10:07.257 8921 8943 W System.err: Loading FontFactory > com.sun.javafx.font.freetype.FTFactory > 05-12 09:10:07.258 8921 8943 W System.err: Subpixel: enabled > 05-12 09:10:07.272 8921 8943 W System.err: Freetype2 Loaded (version > 2.10.0) > 05-12 09:10:07.272 8921 8943 W System.err: LCD support Enabled > 05-12 09:10:07.302 8921 8943 W art : Before Android 4.1, method void > com.sun.javafx.scene.transform.TransformUtils$ImmutableTransform.ensureCanTransform2DPoint() > would have incorrectly overridden the package-private method in > javafx.scene.transform.Transform > 05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double > javafx.scene.text.TextFlow.computeChildPrefAreaHeight(javafx.scene.Node, > javafx.geometry.Insets) would have incorrectly overridden the > package-private method in javafx.scene.layout.Region > 05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double > javafx.scene.text.TextFlow.computeChildPrefAreaWidth(javafx.scene.Node, > javafx.geometry.Insets) would have incorrectly overridden the > package-private method in javafx.scene.layout.Region > 05-12 09:10:08.001 8921 8939 I System.out: max rectangle texture cell size > = 62 > 05-12 09:10:08.019 8921 8939 I System.out: wrap rectangle texture = 2 x 2 > 05-12 09:10:08.024 8921 8939 I System.out: ES2ResourceFactory: Prism - > createStockShader: AlphaTexture_Color.frag > 05-12 09:10:08.287 8921 8939 E javafx : Program link log: L0010 Uniform > 'color' differ on precision > 05-12 09:10:08.287 8921 8939 W System.err: java.lang.RuntimeException: > Error creating shader program > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:158) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:190) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.prism.es2.ES2Context.getPhongShader(ES2Context.java:122) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.prism.es2.ES2Context.renderMeshView(ES2Context.java:451) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.prism.es2.ES2MeshView.render(ES2MeshView.java:119) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGShape3D.renderMeshView(NGShape3D.java:179) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGShape3D.renderContent(NGShape3D.java:201) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:330) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > 05-12 09:10:08.288 8921 8939 W System.err: at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423) > 05-12 09:10:08.288 8921 8939 W System.err: at > java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > 05-12 09:10:08.288 8921 8939 W System.err: at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113) > 05-12 09:10:08.288 8921 8939 W System.err: at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588) > 05-12 09:10:08.288 8921 8939 W System.err: at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > 05-12 09:10:08.288 8921 8939 W System.err: at > java.lang.Thread.run(Thread.java:818) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Mon Aug 12 10:02:39 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 12 Aug 2024 10:02:39 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> Message-ID: On Fri, 9 Aug 2024 08:13:16 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > GlassViewDelegate: Correctly set origin and offset in dragImage > > - Centering to dragImage was removed - origin is now top-left of dragImage > - Offset direction was swapped modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1049: > 1047: if (image != nil) > 1048: { > 1049: // select the center of the image as the drag origin The old comment about RT-17629 (https://bugs.openjdk.org/browse/JDK-8091965) does not apply anymore: after this PR, the offset, which comes from the Java layer, does adjust the drag image origin. So I believe we can remove the whole comment as well (and possibly close RT-17629). modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1068: > 1066: > 1067: dragPoint.x -= offset.x; > 1068: dragPoint.y -= offset.y; This works fine now, _if_ the offset values are smaller than the imageHalf X,Y values, which doesn't make sense anymore: - If you drag from {0,0} (top-left), it works from that position - But if you drag from {imageW, imageH} (bottom-right), the offset is clamped to the image centre, which it is not expected. So now we need to change the above lines to clamp the offset between 0,0 and imageW,H (though Windows doesn't clamp the offset at all). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713448689 PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713460897 From lkostyra at openjdk.org Mon Aug 12 12:16:36 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 12 Aug 2024 12:16:36 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> Message-ID: On Mon, 12 Aug 2024 09:54:19 GMT, Jose Pereda wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> GlassViewDelegate: Correctly set origin and offset in dragImage >> >> - Centering to dragImage was removed - origin is now top-left of dragImage >> - Offset direction was swapped > > modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1068: > >> 1066: >> 1067: dragPoint.x -= offset.x; >> 1068: dragPoint.y -= offset.y; > > This works fine now, _if_ the offset values are smaller than the imageHalf X,Y values, which doesn't make sense anymore: > > - If you drag from {0,0} (top-left), it works from that position > - But if you drag from {imageW, imageH} (bottom-right), the offset is clamped to the image centre, which it is not expected. > > So now we need to change the above lines to clamp the offset between 0,0 and imageW,H (though Windows doesn't clamp the offset at all). Out of curiosity I removed offset clamping (macOS snaps the drag image regardless) and technically it still works, but when you cancel the drag the image snaps back to the offset position. With high enough (or negative) values drag image can animate back even outside the application bounds, which makes little sense and looks weird. I'll clamp it between 0,0 and imageW,H as you mentioned. I also didn't find a way to disable above drag image "snapping". However, if it makes sense to clamp it on macOS, maybe it would also make sense to introduce similar limits to offsets on other platforms (probably as a separate issue)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713643394 From jpereda at openjdk.org Mon Aug 12 12:42:38 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 12 Aug 2024 12:42:38 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> Message-ID: On Mon, 12 Aug 2024 12:14:26 GMT, Lukasz Kostyra wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1068: >> >>> 1066: >>> 1067: dragPoint.x -= offset.x; >>> 1068: dragPoint.y -= offset.y; >> >> This works fine now, _if_ the offset values are smaller than the imageHalf X,Y values, which doesn't make sense anymore: >> >> - If you drag from {0,0} (top-left), it works from that position >> - But if you drag from {imageW, imageH} (bottom-right), the offset is clamped to the image centre, which it is not expected. >> >> So now we need to change the above lines to clamp the offset between 0,0 and imageW,H (though Windows doesn't clamp the offset at all). > > Out of curiosity I removed offset clamping (macOS snaps the drag image regardless) and technically it still works, but when you cancel the drag the image snaps back to the offset position. With high enough (or negative) values drag image can animate back even outside the application bounds, which makes little sense and looks weird. I'll clamp it between 0,0 and imageW,H as you mentioned. > > I also didn't find a way to disable above drag image "snapping". However, if it makes sense to clamp it on macOS, maybe it would also make sense to introduce similar limits to offsets on other platforms (probably as a separate issue)? Right, there is a built-in native animation from the offset point to the mouse cursor (in and out). When the drag event is cancelled, the image returns to the offset location with this animation. We still want that, so I wouldn't remove the animation (if we could), but of course, with the original position of the source, no far away from it, so it makes sense to clamp between the image bounds. And doing the same (clamping) for Windows would be a separate issue, indeed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713684798 From kcr at openjdk.org Mon Aug 12 12:52:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 12:52:37 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove deprecated file @jaybhaskar Can you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2283900603 From lkostyra at openjdk.org Mon Aug 12 12:58:25 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 12 Aug 2024 12:58:25 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v3] In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: > When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. > > This change fixes this mistake. Now drag image should be properly offset. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Adjust clamping values, remove old TODO ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1532/files - new: https://git.openjdk.org/jfx/pull/1532/files/c922de84..41cd6755 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=01-02 Stats: 14 lines in 1 file changed: 4 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1532.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1532/head:pull/1532 PR: https://git.openjdk.org/jfx/pull/1532 From kcr at openjdk.org Mon Aug 12 14:37:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 14:37:11 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set Message-ID: 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ (Enterprise|Professional|Community)\VC\Auxiliary\Build 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. 5. Removed the following unused variables: DEVENVCMD DXSDK_DIR VS_VER 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). I left some debug print statements in, and will remove them in a follow-on commit. I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. ------------- Commit messages: - Remove obsolete check for VS_VER in jfxmedia Makefile - Remove illegal char from 'REM' comment - Print deprecation warning if VS150COMNTOOLS is used - Add MSVCDIR back in - Add debug prints - 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set Changes: https://git.openjdk.org/jfx/pull/1534/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289174 Stats: 191 lines in 5 files changed: 60 ins; 79 del; 52 mod Patch: https://git.openjdk.org/jfx/pull/1534.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1534/head:pull/1534 PR: https://git.openjdk.org/jfx/pull/1534 From kcr at openjdk.org Mon Aug 12 14:37:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 14:37:11 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 14:21:14 GMT, Kevin Rushforth wrote: > 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: > > C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ > (Enterprise|Professional|Community)\VC\Auxiliary\Build > > 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. > 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. > 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. > 5. Removed the following unused variables: > > DEVENVCMD > DXSDK_DIR > VS_VER > > 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). > 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). > 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). > > > I left some debug print statements in, and will remove them in a follow-on commit. > > I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. Reviewers: @prrace and either @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284151235 From angorya at openjdk.org Mon Aug 12 14:45:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 14:45:47 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v25] In-Reply-To: References: Message-ID: On Sat, 10 Aug 2024 17:59:52 GMT, Michael Strau? wrote: > I strongly suggest to do this as part of [JDK-8338121](https://bugs.openjdk.org/browse/JDK-8338121) +1. I am fine with splitting the work in two parts. My only suggestion is to valign the table cells to top instead of center. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2284177222 From jbhaskar at openjdk.org Mon Aug 12 15:28:36 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 12 Aug 2024 15:28:36 GMT Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove deprecated file +looks good to me ------------- Marked as reviewed by jbhaskar (Committer). PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2233379048 From kcr at openjdk.org Mon Aug 12 15:37:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 15:37:10 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: Message-ID: > 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: > > C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ > (Enterprise|Professional|Community)\VC\Auxiliary\Build > > 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. > 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. > 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. > 5. Removed the following unused variables: > > DEVENVCMD > DXSDK_DIR > VS_VER > > 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). > 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). > 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). > > > I left some debug print statements in, and will remove them in a follow-on commit. > > I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Revert "Add debug prints" This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1534/files - new: https://git.openjdk.org/jfx/pull/1534/files/99f3804c..b6972b36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=00-01 Stats: 28 lines in 2 files changed: 0 ins; 28 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1534.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1534/head:pull/1534 PR: https://git.openjdk.org/jfx/pull/1534 From kcr at openjdk.org Mon Aug 12 15:40:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 15:40:41 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: Message-ID: <5kO75QWUB85XSr3iPJipIL5MtnfQuGEmkJGEBHKlwPM=.3ddebd12-4a06-46a7-87de-fc9f66ba0565@github.com> On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Add debug prints" > > This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486. > I left some debug print statements in, and will remove them in a follow-on commit. I removed these with the last commit. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284307863 From jpereda at openjdk.org Mon Aug 12 16:10:40 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 12 Aug 2024 16:10:40 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v3] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: On Mon, 12 Aug 2024 12:58:25 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Adjust clamping values, remove old TODO Looking good, I still have two minor comments modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1049: > 1047: if (image != nil) > 1048: { > 1049: // select the center of the image as the drag origin There are two consecutive `if (image != nil)` blocks, so you can remove the 4 lines above this one. ------------- PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2233475851 PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714048165 From jpereda at openjdk.org Mon Aug 12 16:10:40 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 12 Aug 2024 16:10:40 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> Message-ID: On Mon, 12 Aug 2024 12:39:52 GMT, Jose Pereda wrote: >> Out of curiosity I removed offset clamping (macOS snaps the drag image regardless) and technically it still works, but when you cancel the drag the image snaps back to the offset position. With high enough (or negative) values drag image can animate back even outside the application bounds, which makes little sense and looks weird. I'll clamp it between 0,0 and imageW,H as you mentioned. >> >> I also didn't find a way to disable above drag image "snapping". However, if it makes sense to clamp it on macOS, maybe it would also make sense to introduce similar limits to offsets on other platforms (probably as a separate issue)? > > Right, there is a built-in native animation from the offset point to the mouse cursor (in and out). > > When the drag event is cancelled, the image returns to the offset location with this animation. We still want that, so I wouldn't remove the animation (if we could), but of course, with the original position of the source, no far away from it, so it makes sense to clamp between the image bounds. > > And doing the same (clamping) for Windows would be a separate issue, indeed. By the way, this is how you can disable the cancel animation: diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m index 50a79cabf6..373537f24e 100644 --- a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m +++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m @@ -40,6 +40,7 @@ - (NSDragOperation)draggingSession:(NSDraggingSession *)session sourceOperationMaskForDraggingContext:(NSDraggingContext)context { + session.animatesToStartingPositionsOnCancelOrFail = NO; // The Command key masks out every operation other than NSDragOperationGeneric. We want // internal Move events to get through this filtering so we copy the Move bit into the // Generic bit and treat Generic as a synonym for Move. I'm still in favour of this native animation, as opposed to the Windows case that doesn't have it. This can be a separated issue as well (unifying the animation in all platforms). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714046402 From angorya at openjdk.org Mon Aug 12 16:24:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 16:24:36 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> Message-ID: <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com> On Mon, 12 Aug 2024 16:02:32 GMT, Jose Pereda wrote: >> Right, there is a built-in native animation from the offset point to the mouse cursor (in and out). >> >> When the drag event is cancelled, the image returns to the offset location with this animation. We still want that, so I wouldn't remove the animation (if we could), but of course, with the original position of the source, no far away from it, so it makes sense to clamp between the image bounds. >> >> And doing the same (clamping) for Windows would be a separate issue, indeed. > > By the way, this is how you can disable the cancel animation: > > > diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m > index 50a79cabf6..373537f24e 100644 > --- a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m > +++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m > @@ -40,6 +40,7 @@ > > - (NSDragOperation)draggingSession:(NSDraggingSession *)session sourceOperationMaskForDraggingContext:(NSDraggingContext)context > { > + session.animatesToStartingPositionsOnCancelOrFail = NO; > // The Command key masks out every operation other than NSDragOperationGeneric. We want > // internal Move events to get through this filtering so we copy the Move bit into the > // Generic bit and treat Generic as a synonym for Move. > > > I'm still in favour of this native animation, as opposed to the Windows case that doesn't have it. This can be a separated issue as well (unifying the animation in all platforms). I wanted to chime in, thought it might be unrelated: In the context of a docking framework, it is impossible to disable the cancel animation. We should have a way to disable it. The use case is when the user drags and drops a tab/pane outside of the dockable windows. In this case a new window should appear at the drop location, without the drag image animated back to the start position. Another thing that is impossible is to control the drag image: sometimes one needs a scaled icon, sometimes one wants the full content. These two issues basically prevent implementing a docking framework via DnD, one needs to use other solution, for example https://github.com/andy-goryachev/FxDock ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714071087 From nlisker at openjdk.org Mon Aug 12 17:04:38 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 12 Aug 2024 17:04:38 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid [v2] In-Reply-To: References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: On Sat, 10 Aug 2024 11:53:00 GMT, John Hendrikx wrote: >>> This is not the case. The sorting is still correct. Claiming that the sorting is invalid because a newly added item was not placed in a specific location relative to other equal items is a bit of misrepresentation. >>> >>> So, if this PR wants to move forward, I think we first need to decide if we want to guarantee a specific behavior when inserting new but equal elements. >> >> The issue isn?t just with adding new elements. It also affects the `TableView` that populated with items from a `SortedList`, The `SortedList`'s comparator is bound to the `TableView`'s comparator. >> When the table is sorted by two columns and the second sort is removed, the table should revert to sorting by just the first column. However, currently, removing the second column from the sort order doesn't change the items order. >> >> For example: >> ![image](https://github.com/user-attachments/assets/9ed8b2ea-9879-4dc9-a285-4d03be2d2691) >> >> 1. The initial order is [0, 1, 2, 3] (index column). >> 2. Sort by `Col1`, the order will be: [1, 0, 2, 3]. >> 3. Add a second sort (Shift + Click) on `Col2`, the order will be: [1, 2, 3, 0]. >> 4. Shift + Click again on `Col2` to sort in descending order: [1, 0, 3, 2]. >> 5. Shift + Click again on `Col2` to remove the sort from `Col2`. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2. >> >>
          >> Code >> >> >> import javafx.application.Application; >> import javafx.beans.property.ReadOnlyObjectWrapper; >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import javafx.collections.transformation.SortedList; >> import javafx.scene.Scene; >> import javafx.scene.control.TableColumn; >> import javafx.scene.control.TableView; >> import javafx.stage.Stage; >> >> public class Main extends Application { >> >> @Override >> public void start(Stage primaryStage) { >> primaryStage.setScene(new Scene(createTableView())); >> primaryStage.show(); >> } >> >> private TableView createTableView() { >> TableView tableView = new TableView<>(); >> >> TableColumn indexColumn = new TableColumn<>("#"); >> indexColumn.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().index())); >> indexColumn.setSortable(false); >> >> TableColumn column1 = new TableColumn<>("Col1"); >> column1.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue... > >> Shift + Click again on Col2 to remove the sort from Col2. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2. > > Why is that the expected order? It is "a" possible, but valid order. When only sorting on `Col1` then in my opinion [1, 0, 2, 3], [1, 0, 3, 2], [1, 2, 0, 3], etc.. are all valid sort orders. > > If we want to distinguish between equal elements to give them a fixed sub-ordering (and the inverse one I suppose when the sort is descending) then what should the distinguishing factor be? Its position in the underlying unsorted list? The time it was added to the underlying list? They need not be the same. Using the position in the underlying list could be quite random if the source of the list doesn't guarantee a fixed position (from an unsorted database query for example). > > What if the underlying list is another sorted list or a filtered list, can we even rely on the indices those provide? @hjohn I was confused as well, but the [`TableView` docs](https://openjfx.io/javadoc/22/javafx.controls/javafx/scene/control/TableView.html#sorting-heading) say: > Starting with JavaFX 8.0 (and the introduction of [SortedList](https://openjfx.io/javadoc/22/javafx.base/javafx/collections/transformation/SortedList.html)), it is now possible to have the collection return to the unsorted state when there are no columns as part of the TableView [sort order](https://openjfx.io/javadoc/22/javafx.controls/javafx/scene/control/TableView.html#getSortOrder()). To do this, you must create a SortedList instance, and bind its [comparator](https://openjfx.io/javadoc/22/javafx.base/javafx/collections/transformation/SortedList.html#comparatorProperty()) property to the TableView [comparator](https://openjfx.io/javadoc/22/javafx.controls/javafx/scene/control/TableView.html#comparatorProperty()) property So I think that the confusion stems from the fuzzy guarantee that removing the column-based sorting will return the table to *the* unsorted state before that sorting (and not to *a* unsorted state). That might mean that `TableView` will have to maintain the initial sorting somewhere. Or... it's a bad documentation :) I still don't see how this is a bug in `SortedList`. It could be a bug in `TableView`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2284512503 From lkostyra at openjdk.org Mon Aug 12 17:13:51 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 12 Aug 2024 17:13:51 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> > When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. > > This change fixes this mistake. Now drag image should be properly offset. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Merge two if image != nil statements together Those were unnecessarily split ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1532/files - new: https://git.openjdk.org/jfx/pull/1532/files/41cd6755..f6d065ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1532.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1532/head:pull/1532 PR: https://git.openjdk.org/jfx/pull/1532 From jpereda at openjdk.org Mon Aug 12 17:24:40 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 12 Aug 2024 17:24:40 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com> Message-ID: On Mon, 12 Aug 2024 16:22:17 GMT, Andy Goryachev wrote: >> By the way, this is how you can disable the cancel animation: >> >> >> diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m >> index 50a79cabf6..373537f24e 100644 >> --- a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m >> +++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m >> @@ -40,6 +40,7 @@ >> >> - (NSDragOperation)draggingSession:(NSDraggingSession *)session sourceOperationMaskForDraggingContext:(NSDraggingContext)context >> { >> + session.animatesToStartingPositionsOnCancelOrFail = NO; >> // The Command key masks out every operation other than NSDragOperationGeneric. We want >> // internal Move events to get through this filtering so we copy the Move bit into the >> // Generic bit and treat Generic as a synonym for Move. >> >> >> I'm still in favour of this native animation, as opposed to the Windows case that doesn't have it. This can be a separated issue as well (unifying the animation in all platforms). > > I wanted to chime in, thought it might be unrelated: > > In the context of a docking framework, it is impossible to disable the cancel animation. We should have a way to disable it. The use case is when the user drags and drops a tab/pane outside of the dockable windows. In this case a new window should appear at the drop location, without the drag image animated back to the start position. > > Another thing that is impossible is to control the drag image: sometimes one needs a scaled icon, sometimes one wants the full content. > > These two issues basically prevent implementing a docking framework via DnD, one needs to use other solution, for example > https://github.com/andy-goryachev/FxDock I'm not sure if I follow, but about the cancel animation, do you mean that is not possible to disable it on macOS? Have you tested `session.animatesToStartingPositionsOnCancelOrFail`? As for the image, `DragBoard::setDragView` allows you setting any image that you need for the drag gesture, or am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714139069 From angorya at openjdk.org Mon Aug 12 17:30:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 17:30:36 GMT Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com> <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com> Message-ID: On Mon, 12 Aug 2024 17:21:58 GMT, Jose Pereda wrote: >> I wanted to chime in, thought it might be unrelated: >> >> In the context of a docking framework, it is impossible to disable the cancel animation. We should have a way to disable it. The use case is when the user drags and drops a tab/pane outside of the dockable windows. In this case a new window should appear at the drop location, without the drag image animated back to the start position. >> >> Another thing that is impossible is to control the drag image: sometimes one needs a scaled icon, sometimes one wants the full content. >> >> These two issues basically prevent implementing a docking framework via DnD, one needs to use other solution, for example >> https://github.com/andy-goryachev/FxDock > > I'm not sure if I follow, but about the cancel animation, do you mean that is not possible to disable it on macOS? Have you tested `session.animatesToStartingPositionsOnCancelOrFail`? > As for the image, `DragBoard::setDragView` allows you setting any image that you need for the drag gesture, or am I missing something? it's been a while - java8 time frame - back then I was unable to find a way to disable animation on cancel. as for image - I was setting large image and fx tried to scale it to be smaller, I was unable to force it to show the unscaled full size image. also, why does the drag image look fuzzy on mac retina? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714146005 From lkostyra at openjdk.org Mon Aug 12 17:34:41 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 12 Aug 2024 17:34:41 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: Message-ID: <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com> On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Add debug prints" > > This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486. buildSrc/genVSproperties.bat line 52: > 50: for %%a in (2022, 2019, 2017) do ( > 51: set year=%%a > 52: for %%b in (Enterprise, Professional, Community) do ( Quick two cents from me on this part - Microsoft also offers a free CLI-only version of Visual Studio called "Build Tools for Visual Studio" - https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022 Those install in a separate "BuildTools" directory (so ex. `C:\Program Files\Microsoft Visual Studio\2022\BuildTools...`). Internally the directory structure is the same and all the scripts we need are also there, so it seems like this should work. I think we could also add BuildTools as an option here? I can check on my machine if it builds as part of this review. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714151393 From lkostyra at openjdk.org Mon Aug 12 17:36:43 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 12 Aug 2024 17:36:43 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split Also I noticed the PR title does not match the JBS issue title - missed the macOS tag while copying. Will update it to match. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284567585 From kcr at openjdk.org Mon Aug 12 18:07:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 18:07:36 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com> References: <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com> Message-ID: On Mon, 12 Aug 2024 17:32:10 GMT, Lukasz Kostyra wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Add debug prints" >> >> This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486. > > buildSrc/genVSproperties.bat line 52: > >> 50: for %%a in (2022, 2019, 2017) do ( >> 51: set year=%%a >> 52: for %%b in (Enterprise, Professional, Community) do ( > > Quick two cents from me on this part - Microsoft also offers a free CLI-only version of Visual Studio called "Build Tools for Visual Studio" - https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022 > > Those install in a separate "BuildTools" directory (so ex. `C:\Program Files\Microsoft Visual Studio\2022\BuildTools...`). Internally the directory structure is the same and all the scripts we need are also there, so it seems like this should work. I think we could also add BuildTools as an option here? I can check on my machine if it builds as part of this review. Thanks, that would be helpful. Let me know what you find. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714186379 From nlisker at openjdk.org Mon Aug 12 19:21:35 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 12 Aug 2024 19:21:35 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Add debug prints" > > This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486. The wiki page for building OpenJFX will also need an update. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284741466 From kcr at openjdk.org Mon Aug 12 19:50:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 19:50:37 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: Message-ID: <6m1ntAfN41A1g1mHqzYzTow9C-ys9xIKwV6z1UYm23A=.5bae6aee-ab99-4b79-9870-02dfc80aa158@github.com> On Mon, 12 Aug 2024 19:18:40 GMT, Nir Lisker wrote: > The wiki page for building OpenJFX will also need an update. Yes. I plan to (I meant to list that in the Description, but forgot to add it). Thanks for the reminder. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284787751 From prr at openjdk.org Mon Aug 12 20:27:37 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 12 Aug 2024 20:27:37 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: <6m1ntAfN41A1g1mHqzYzTow9C-ys9xIKwV6z1UYm23A=.5bae6aee-ab99-4b79-9870-02dfc80aa158@github.com> References: <6m1ntAfN41A1g1mHqzYzTow9C-ys9xIKwV6z1UYm23A=.5bae6aee-ab99-4b79-9870-02dfc80aa158@github.com> Message-ID: On Mon, 12 Aug 2024 19:48:11 GMT, Kevin Rushforth wrote: > > The wiki page for building OpenJFX will also need an update. > > Yes. I plan to (I meant to list that in the Description, but forgot to add it). Thanks for the reminder. Yes indeed, Kevin and I discussed that at some length. What is there today is useless anyway. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284844571 From prr at openjdk.org Mon Aug 12 20:44:39 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 12 Aug 2024 20:44:39 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Add debug prints" > > This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486. buildSrc/genVSproperties.bat line 27: > 25: > 26: REM Windows bat file that runs vcvars64.bat for Visual Studio > 27: REM and echos out a property file with the values of the environment nit : I think it is usually spelt echoes. buildSrc/genVSproperties.bat line 55: > 53: set edition=%%b > 54: for %%c in ("Program Files", "Program Files (x86)") do ( > 55: set ProgramFiles=%%~c What does the ~ do here ? buildSrc/win.gradle line 93: > 91: defineProperty("WINDOWS_VS_LIB", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;" + "$WINDOWS_SDK_DIR/lib;") > 92: defineProperty("WINDOWS_VS_LIBPATH", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;") > 93: def parfaitPath = IS_COMPILE_PARFAIT ? System.getenv().get("PARFAIT_PATH") + ";" : ""; Did you mean to remove parfaitPath ? buildSrc/win.gradle line 113: > 111: IS_DEBUG_NATIVE ? ["/MDd", "/Od", "/Zi", "/DDEBUG"] : ["/O2", "/MD", "/DNDEBUG"] > 112: > 113: // Serialize access to PDB file for debug builds if on VS2013 or later The "if on VS2013 or later" part of the comment is obsolete. buildSrc/win.gradle line 141: > 139: > 140: // Remove C++ static linking if not on VS2010 > 141: ccFlags -= ["/D_STATIC_CPPLIB", "/D_DISABLE_DEPRECATE_STATIC_CPPLIB"] The "if not on VS2010" part of the comment is obsolete. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714334014 PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714339338 PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714344403 PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714342671 PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714343779 From angorya at openjdk.org Mon Aug 12 20:51:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 20:51:37 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split FYI, I've added Drag and Drop page to the Monkey Tester for testing various options: https://github.com/andy-goryachev-oracle/MonkeyTest ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284881877 From angorya at openjdk.org Mon Aug 12 20:57:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 20:57:36 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split To clarify my earlier comments: 1. my complaints are related, but outside of the scope for this PR 2. the Dragboard class allows for setting of drag view image, but it always tries to resize it to some arbitrary size - increase the size if the image is too small, scale down if it is too large. There is no way to customize that (but should be!) 3. there is no public API to control drop cancellation behavior. At the minimum, there should be a way to disable the scuttling behavior. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284890339 From angorya at openjdk.org Mon Aug 12 21:02:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 21:02:41 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split Question: how should we handle the negative offsets? The way javadoc is currently phrased, "offsetX x position of the cursor **over** the image" implies that the offset is clamped to be inside of the (scaled) image. If so, the behavior appears to be correct even in the presence of infinities and NaNs (the latter produces 0 offset). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284896632 From angorya at openjdk.org Mon Aug 12 21:12:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 21:12:36 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split Another issue - out of scope for this PR - is the DRAG_DONE event missing any coordinates, regardless of whether it was dropped over the accepting target or non-accepting target or no target. I think this was another reason I could not implement the docking framework via DnD. {event=DRAG_DONE, screenX=0.0, screenY=0.0, sceneX=0.0, sceneY=0.0} ------------- PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284911706 From kcr at openjdk.org Mon Aug 12 21:31:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 21:31:49 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v3] In-Reply-To: References: Message-ID: > 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: > > C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ > (Enterprise|Professional|Community)\VC\Auxiliary\Build > > 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. > 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. > 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. > 5. Removed the following unused variables: > > DEVENVCMD > DXSDK_DIR > VS_VER > > 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). > 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). > 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). > > > I left some debug print statements in, and will remove them in a follow-on commit. > > I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1534/files - new: https://git.openjdk.org/jfx/pull/1534/files/b6972b36..4bd166ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1534.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1534/head:pull/1534 PR: https://git.openjdk.org/jfx/pull/1534 From kcr at openjdk.org Mon Aug 12 21:31:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 21:31:49 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: Message-ID: <1DQuapCS3wwDNWPnidhB0lrKWdvHqL077Ve9IxxlF6k=.8522bca7-cd16-4067-967a-e14c343d9f31@github.com> On Mon, 12 Aug 2024 20:31:37 GMT, Phil Race wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Add debug prints" >> >> This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486. > > buildSrc/genVSproperties.bat line 27: > >> 25: >> 26: REM Windows bat file that runs vcvars64.bat for Visual Studio >> 27: REM and echos out a property file with the values of the environment > > nit : I think it is usually spelt echoes. This was preexisting, but since I touched this line (to remove white space), I'll fix it. > buildSrc/genVSproperties.bat line 55: > >> 53: set edition=%%b >> 54: for %%c in ("Program Files", "Program Files (x86)") do ( >> 55: set ProgramFiles=%%~c > > What does the ~ do here ? It strips the quotes. > buildSrc/win.gradle line 113: > >> 111: IS_DEBUG_NATIVE ? ["/MDd", "/Od", "/Zi", "/DDEBUG"] : ["/O2", "/MD", "/DNDEBUG"] >> 112: >> 113: // Serialize access to PDB file for debug builds if on VS2013 or later > > The "if on VS2013 or later" part of the comment is obsolete. I'll remove it. > buildSrc/win.gradle line 141: > >> 139: >> 140: // Remove C++ static linking if not on VS2010 >> 141: ccFlags -= ["/D_STATIC_CPPLIB", "/D_DISABLE_DEPRECATE_STATIC_CPPLIB"] > > The "if not on VS2010" part of the comment is obsolete. I'll remove it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714379348 PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714379591 PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714384323 PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714384853 From kcr at openjdk.org Mon Aug 12 21:31:50 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 21:31:50 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v3] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 20:41:13 GMT, Phil Race wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > buildSrc/win.gradle line 93: > >> 91: defineProperty("WINDOWS_VS_LIB", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;" + "$WINDOWS_SDK_DIR/lib;") >> 92: defineProperty("WINDOWS_VS_LIBPATH", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;") >> 93: def parfaitPath = IS_COMPILE_PARFAIT ? System.getenv().get("PARFAIT_PATH") + ";" : ""; > > Did you mean to remove parfaitPath ? Yes, it was intentional. Once I removed the (unused) default for `WINDOWS_VS_PATH`, that local variable was no longer referenced. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714383497 From prr at openjdk.org Mon Aug 12 21:36:37 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 12 Aug 2024 21:36:37 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v3] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2234058329 From angorya at openjdk.org Mon Aug 12 22:03:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 22:03:39 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1053: > 1051: float imageH = [image size].height; > 1052: > 1053: if (offset.x < 0.0f) { I am puzzled a bit: a NaN input seem to produce NaN offsets, yet the testing shows that it behaves as if 0 offsets (possibly in the native code)? Should the ifs be restructured so as not to pass NaN downstream? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714411657 From kcr at openjdk.org Mon Aug 12 22:50:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 22:50:54 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split Looks good to me. Unifying the behavior on Windows and Linux can be done in the follow-up bug [JDK-8338204](https://bugs.openjdk.org/browse/JDK-8338204). If needed, additional follow-up issues can be filed. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2234132296 From kcr at openjdk.org Mon Aug 12 22:50:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 22:50:55 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 21:58:51 GMT, Andy Goryachev wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Merge two if image != nil statements together >> >> Those were unnecessarily split > > modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1053: > >> 1051: float imageH = [image size].height; >> 1052: >> 1053: if (offset.x < 0.0f) { > > I am puzzled a bit: a NaN input seem to produce NaN offsets, yet the testing shows that it behaves as if 0 offsets (possibly in the native code)? > > Should the ifs be restructured so as not to pass NaN downstream? That seems out of scope for this PR. We typically don't do any special processing to deal with NaN unless there is a problem. If needed, maybe it could be done as part of the follow-up bug [JDK-8338204](https://bugs.openjdk.org/browse/JDK-8338204). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714438854 From kcr at openjdk.org Mon Aug 12 22:53:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 22:53:52 GMT Subject: RFR: 8336938: Update libFFI to 3.4.6 In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 00:26:13 GMT, Alexander Matveev wrote: > - libFFI updated to 3.4.6. > - No additional changes are done. > - Tested on Windows, macOS and Linux with all supported formats. @tiainen Do you want to be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2285031562 From angorya at openjdk.org Mon Aug 12 23:09:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 23:09:56 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2234162494 From angorya at openjdk.org Mon Aug 12 23:09:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Aug 2024 23:09:57 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 22:38:32 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1053: >> >>> 1051: float imageH = [image size].height; >>> 1052: >>> 1053: if (offset.x < 0.0f) { >> >> I am puzzled a bit: a NaN input seem to produce NaN offsets, yet the testing shows that it behaves as if 0 offsets (possibly in the native code)? >> >> Should the ifs be restructured so as not to pass NaN downstream? > > That seems out of scope for this PR. We typically don't do any special processing to deal with NaN unless there is a problem. If needed, maybe it could be done as part of the follow-up bug [JDK-8338204](https://bugs.openjdk.org/browse/JDK-8338204). Sounds good, especially since it seems to treat NaNs as 0's. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714458124 From kcr at openjdk.org Mon Aug 12 23:18:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Aug 2024 23:18:53 GMT Subject: RFR: 8336938: Update libFFI to 3.4.6 In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 00:26:13 GMT, Alexander Matveev wrote: > - libFFI updated to 3.4.6. > - No additional changes are done. > - Tested on Windows, macOS and Linux with all supported formats. I see one minor difference between the upstream and your PR in a commented out line of code in `sysv_intel.S`. I don't know whether it is significant (I guess not, as long as it compiles with the current inline comment style). diff -u -w -r ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S ./src/x86/sysv_intel.S --- ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S 2024-08-12 15:59:14.597741100 -0700 +++ ./src/x86/sysv_intel.S 2024-08-12 16:05:42.708534300 -0700 @@ -102,7 +102,7 @@ mov ecx, [12+ebp] /* load return type code */ mov [ebp+8], ebx /* preserve %ebx */ L(UW2): - // cfi_rel_offset(%ebx, 8) + /* cfi_rel_offset(%ebx, 8) */ and ecx, X86_RET_TYPE_MASK lea ebx, [L(store_table) + ecx * 8] ------------- PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2285054088 From jpereda at openjdk.org Mon Aug 12 23:41:54 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 12 Aug 2024 23:41:54 GMT Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v4] In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com> Message-ID: On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra wrote: >> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. >> >> This change fixes this mistake. Now drag image should be properly offset. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Merge two if image != nil statements together > > Those were unnecessarily split Looks good ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2234191527 From almatvee at openjdk.org Tue Aug 13 01:05:51 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 Aug 2024 01:05:51 GMT Subject: RFR: 8336938: Update libFFI to 3.4.6 In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 23:15:58 GMT, Kevin Rushforth wrote: > I see one minor difference between the upstream and your PR in a commented out line of code in `sysv_intel.S`. I don't know whether it is significant (I guess not, as long as it compiles with the current inline comment style). > > ``` > diff -u -w -r ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S ./src/x86/sysv_intel.S > --- ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S 2024-08-12 15:59:14.597741100 -0700 > +++ ./src/x86/sysv_intel.S 2024-08-12 16:05:42.708534300 -0700 > @@ -102,7 +102,7 @@ > mov ecx, [12+ebp] /* load return type code */ > mov [ebp+8], ebx /* preserve %ebx */ > L(UW2): > - // cfi_rel_offset(%ebx, 8) > + /* cfi_rel_offset(%ebx, 8) */ > > and ecx, X86_RET_TYPE_MASK > lea ebx, [L(store_table) + ecx * 8] > ``` Yes, it compiles fine. It was changed by libFFI itself in 3.4.6. I think to be inline with rest of comments in this file. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2285153581 From lkostyra at openjdk.org Tue Aug 13 06:30:58 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 13 Aug 2024 06:30:58 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: References: <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com> Message-ID: <3ELosjv6Xqh7GRy6eU9nhZ9G4BjZJ6fIwDHza1JiMMQ=.696a4555-fff2-46f9-b3dd-a0a0981afa02@github.com> On Mon, 12 Aug 2024 18:04:47 GMT, Kevin Rushforth wrote: >> buildSrc/genVSproperties.bat line 52: >> >>> 50: for %%a in (2022, 2019, 2017) do ( >>> 51: set year=%%a >>> 52: for %%b in (Enterprise, Professional, Community) do ( >> >> Quick two cents from me on this part - Microsoft also offers a free CLI-only version of Visual Studio called "Build Tools for Visual Studio" - https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022 >> >> Those install in a separate "BuildTools" directory (so ex. `C:\Program Files\Microsoft Visual Studio\2022\BuildTools...`). Internally the directory structure is the same and all the scripts we need are also there, so it seems like this should work. I think we could also add BuildTools as an option here? I can check on my machine if it builds as part of this review. > > Thanks, that would be helpful. Let me know what you find. I checked on a Win 11 system where Build Tools 2022 are installed in default directory (no other Visual Studio edition) and the build failed with "Cannot locate Visual Studio compilers" message. Adding `BuildTools` as an option to this loop fixed it and JFX built properly (checked without Media and Webkit). Alternatively, setting `VSCOMMONTOOLS` also helps, but I think we can easily add `BuildTools` as an option here. As a side-note - building without this PR on the same system also failed so it doesn't necessarily introduce a regression, but I think it would be a worthy addition regardless. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714733992 From lkostyra at openjdk.org Tue Aug 13 06:34:57 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 13 Aug 2024 06:34:57 GMT Subject: Integrated: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com> Message-ID: <5JXB5AKz4i9YpaLuTtJZE0WSYmvhw2Tvv7xT_7vsLfE=.6f262d9b-e49b-41fa-a872-ee00a524be9f@github.com> On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra wrote: > When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS. > > This change fixes this mistake. Now drag image should be properly offset. This pull request has now been integrated. Changeset: 00c74ebf Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/00c74ebf96cbe24b833cb51d2ee533e69396c846 Stats: 24 lines in 1 file changed: 7 ins; 10 del; 7 mod 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image Reviewed-by: jpereda, kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1532 From nlisker at openjdk.org Tue Aug 13 11:53:59 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 13 Aug 2024 11:53:59 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90: > 88: private final int specificity; > 89: > 90: @SuppressWarnings("removal") What is this removal warning suppression? I know it was there before these changes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715163301 From nlisker at openjdk.org Tue Aug 13 11:56:54 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 13 Aug 2024 11:56:54 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug I see a lot of aversion from for-each loops in favor of indexed loops in the classes this PR touches. While I don't suggest to change it here, any idea why? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286067091 From jhendrikx at openjdk.org Tue Aug 13 12:02:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Aug 2024 12:02:59 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 11:54:16 GMT, Nir Lisker wrote: > I see a lot of aversion from for-each loops in favor of indexed loops in the classes this PR touches. While I don't suggest to change it here, any idea why? It's just the style the original code was written with. There is no reason to write the binary load/save code like this (as IO will be a far greater bottleneck). There are/were other parts (in `Match` and the selector subtypes) however that are performance sensitive, so perhaps the entire classes were just written in a similar style "just in case". ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286078330 From jhendrikx at openjdk.org Tue Aug 13 12:07:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Aug 2024 12:07:58 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 12:05:18 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90: >> >>> 88: private final int specificity; >>> 89: >>> 90: @SuppressWarnings("removal") >> >> What is this removal warning suppression? I know it was there before these changes. > > `SimpleSelector` was deprecated for removal (from the public javafx.css package). Now that it is moved to the internal package, the deprecation on that was also removed. The `SuppressWarnings` is therefore no longer needed here as the deprecation is no longer present on the now internal `SimpleSelector` type. The diff seems to show I did not remove that line, but it should no longer be needed. I'll check. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715180851 From jhendrikx at openjdk.org Tue Aug 13 12:07:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Aug 2024 12:07:58 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 11:51:39 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bug > > modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90: > >> 88: private final int specificity; >> 89: >> 90: @SuppressWarnings("removal") > > What is this removal warning suppression? I know it was there before these changes. `SimpleSelector` was deprecated for removal (from the public javafx.css package). Now that it is moved to the internal package, the deprecation on that was also removed. The `SuppressWarnings` is therefore no longer needed here as the deprecation is no longer present on the now internal `SimpleSelector` type. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715180348 From jhendrikx at openjdk.org Tue Aug 13 12:18:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Aug 2024 12:18:12 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 22:31:57 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bug > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/CompoundSelector.java line 75: > >> 73: /** >> 74: * The relationships between the selectors >> 75: * @return Immutable List<Combinator> > > minor: would {@code List} be a better choice here, if it works? Fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715189665 From jhendrikx at openjdk.org Tue Aug 13 12:18:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Aug 2024 12:18:12 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v8] In-Reply-To: References: Message-ID: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Fix javadoc - Remove unnecessary suppress warnings ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1333/files - new: https://git.openjdk.org/jfx/pull/1333/files/39c94408..875c1a88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From kcr at openjdk.org Tue Aug 13 12:34:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Aug 2024 12:34:52 GMT Subject: RFR: 8336938: Update libFFI to 3.4.6 In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 01:03:32 GMT, Alexander Matveev wrote: > Yes, it compiles fine. It was changed by libFFI itself in 3.4.6. I think to be inline with rest of comments in this file. What I meant was that you missed making that change when you updated the file. The old line with the inline comment style is still in our copy of the file. So it no longer matches the upstream libffi 3.4.6. It seems best to apply that part of the patch so that we will match the upstream version of the file. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2286144930 From nlisker at openjdk.org Tue Aug 13 14:13:59 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 13 Aug 2024 14:13:59 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 22:47:28 GMT, Andy Goryachev wrote: > oops, yes, you did, my mistake. the master progressed since then, got me confused. > > I got a bunch of errors again after switching: > > ``` > Description Resource Type Path Location > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3024 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3214 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3267 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3282 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3607 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3651 > ``` I got these too, as well as many The method createShader(String, InputStream, Map, Map, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap, HashMap, int, boolean, boolean) I haven't worked on this repo for 3 weeks, what changed? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286360227 From jhendrikx at openjdk.org Tue Aug 13 14:20:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Aug 2024 14:20:58 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 14:10:52 GMT, Nir Lisker wrote: > > oops, yes, you did, my mistake. the master progressed since then, got me confused. > > I got a bunch of errors again after switching: > > ``` > > Description Resource Type Path Location > > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3024 > > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3214 > > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3267 > > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3282 > > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3607 > > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3651 > > ``` > > I got these too, as well as many > > ``` > The method createShader(String, InputStream, Map, Map, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap, HashMap, int, boolean, boolean) > ``` > > I haven't worked on this repo for 3 weeks, what changed? The ones mentioned by Andy I also see, and are just a difference in opinion between Javac and ECJ, or perhaps a bug in the incremental compilation that Eclipse does (as they usually only appear when it does an incremental compile, not a full one). When those occur, I just select them and remove them from the errors list. The others I haven't seen before, and I'm not seeing them now. I did a search for `createShader` but didn't see anything unusual. I'm not aware of any special changes in the last 3 weeks. I did a fresh import recently, and nothing strange popped up. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286377890 From kcr at openjdk.org Tue Aug 13 14:42:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Aug 2024 14:42:59 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 14:18:39 GMT, John Hendrikx wrote: > ``` > The method createShader(String, InputStream, Map, Map, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap, HashMap, int, boolean, boolean) > ``` > > I haven't worked on this repo for 3 weeks, what changed? You need to do a clean build. This method was changed by [JDK-8336624](https://bugs.openjdk.org/browse/JDK-8336624) / PR #1530 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286427951 From nlisker at openjdk.org Tue Aug 13 15:28:56 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 13 Aug 2024 15:28:56 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v3] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Continuing from https://github.com/openjdk/jfx/pull/1333#issuecomment-2286427951, I updated my VS and did a clean build on `master` and got > java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.33.31629/bin/Hostx64/x64/cl.exe'' After applying this patch, my clean build was successful (up to the webkit part). I then removed the `VS150COMNTOOLS` env var and tried another clean build and it worked as well. Tested on Windows 10. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2235891455 From almatvee at openjdk.org Tue Aug 13 19:04:09 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 Aug 2024 19:04:09 GMT Subject: RFR: 8336938: Update libFFI to 3.4.6 [v2] In-Reply-To: References: Message-ID: <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com> > - libFFI updated to 3.4.6. > - No additional changes are done. > - Tested on Windows, macOS and Linux with all supported formats. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8336938: Update libFFI to 3.4.6 [v2] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1531/files - new: https://git.openjdk.org/jfx/pull/1531/files/e51e5c71..c4a9d5b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1531&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1531&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1531.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1531/head:pull/1531 PR: https://git.openjdk.org/jfx/pull/1531 From kcr at openjdk.org Tue Aug 13 19:09:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Aug 2024 19:09:54 GMT Subject: RFR: 8336938: Update libFFI to 3.4.6 [v2] In-Reply-To: <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com> References: <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com> Message-ID: On Tue, 13 Aug 2024 19:04:09 GMT, Alexander Matveev wrote: >> - libFFI updated to 3.4.6. >> - No additional changes are done. >> - Tested on Windows, macOS and Linux with all supported formats. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8336938: Update libFFI to 3.4.6 [v2] Code changes look good. Testing looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1531#pullrequestreview-2236361557 From mhanl at openjdk.org Tue Aug 13 19:26:56 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 13 Aug 2024 19:26:56 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v3] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Changes look good and also worked for me. Removed the `VS150COMNTOOLS` variable and rebuild the project. EDIT: Tested on Windows 11. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2236391549 From angorya at openjdk.org Tue Aug 13 21:06:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Aug 2024 21:06:57 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v4] In-Reply-To: References: Message-ID: On Sat, 10 Aug 2024 16:21:11 GMT, Markus Mack wrote: >> This PR is a fix for another IOOBE that I discovered while working on #1476. >> >> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. >> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. >> >> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. >> >> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. >> >> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. >> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. > > Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - test "negative" style class in BarChartTest tests > - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series > - fix "negative" style class when series is changed > - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java > - BarChart: Fix adding non-empty series > - BarChart: Add styleClass "negative" for added data thank you for making the changes! looks good now. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1488#pullrequestreview-2236574603 From angorya at openjdk.org Tue Aug 13 21:20:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Aug 2024 21:20:55 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v8] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 12:18:12 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Fix javadoc > - Remove unnecessary suppress warnings Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2236600499 From angorya at openjdk.org Tue Aug 13 21:35:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Aug 2024 21:35:11 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed [v2] In-Reply-To: References: Message-ID: > Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. > > This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. > > The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. Andy Goryachev 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 10 additional commits since the last revision: - avoid csr - Merge remote-tracking branch 'origin/master' into ag.consume - only if consumed - only when consumed - propagate - cleanup - simpler - event helper - copy for test - propagate consume action ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1523/files - new: https://git.openjdk.org/jfx/pull/1523/files/551ed976..48022d6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1523&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1523&range=00-01 Stats: 1379 lines in 29 files changed: 1135 ins; 90 del; 154 mod Patch: https://git.openjdk.org/jfx/pull/1523.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1523/head:pull/1523 PR: https://git.openjdk.org/jfx/pull/1523 From angorya at openjdk.org Tue Aug 13 21:42:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Aug 2024 21:42:56 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed [v2] In-Reply-To: References: Message-ID: <9dThcWI8O458E7q99q_V2LCf2DAIubiD0ypNkSLKUNw=.4e67118b-e815-4c93-9dc5-ac29f79c53f5@github.com> On Tue, 13 Aug 2024 21:35:11 GMT, Andy Goryachev wrote: >> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. >> >> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. >> >> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. > > Andy Goryachev 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 10 additional commits since the last revision: > > - avoid csr > - Merge remote-tracking branch 'origin/master' into ag.consume > - only if consumed > - only when consumed > - propagate > - cleanup > - simpler > - event helper > - copy for test > - propagate consume action Removed 'final' keyword from existing public APIs. The changes are limited to TextFieldBehavior and SpinnerSkin. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2287183307 From angorya at openjdk.org Tue Aug 13 21:42:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Aug 2024 21:42:56 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 20:16:29 GMT, Martin Fox wrote: > An EventDispatcher that creates a new event without linking it to the original will break this PR. But that's a consequence you're creating. You can't say the developer is making a choice about event linking when the very notion is new with this PR. Actually, this statement is not correct: the consumed flag will be propagated, but only if `propagateConsume` was set by the helper, which is being done in a very specific case. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2287186541 From angorya at openjdk.org Tue Aug 13 21:54:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Aug 2024 21:54:02 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec Could we get this reviewed please? Perhaps @lukostyra or @beldenfox ? Also, there was a comment from @andzsinszan > TextFieldTableCell -> a bit buggy has it been looked at? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2287200158 From kcr at openjdk.org Wed Aug 14 02:21:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Aug 2024 02:21:30 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v4] In-Reply-To: References: Message-ID: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com> > 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: > > C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ > (Enterprise|Professional|Community)\VC\Auxiliary\Build > > 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. > 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. > 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. > 5. Removed the following unused variables: > > DEVENVCMD > DXSDK_DIR > VS_VER > > 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). > 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). > 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). > > > I left some debug print statements in, and will remove them in a follow-on commit. > > I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Look for BuildTools if other VS editions not found ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1534/files - new: https://git.openjdk.org/jfx/pull/1534/files/4bd166ea..6cd3f239 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1534.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1534/head:pull/1534 PR: https://git.openjdk.org/jfx/pull/1534 From kcr at openjdk.org Wed Aug 14 02:21:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Aug 2024 02:21:30 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v2] In-Reply-To: <3ELosjv6Xqh7GRy6eU9nhZ9G4BjZJ6fIwDHza1JiMMQ=.696a4555-fff2-46f9-b3dd-a0a0981afa02@github.com> References: <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com> <3ELosjv6Xqh7GRy6eU9nhZ9G4BjZJ6fIwDHza1JiMMQ=.696a4555-fff2-46f9-b3dd-a0a0981afa02@github.com> Message-ID: On Tue, 13 Aug 2024 06:27:51 GMT, Lukasz Kostyra wrote: >> Thanks, that would be helpful. Let me know what you find. > > I checked on a Win 11 system where Build Tools 2022 are installed in default directory (no other Visual Studio edition) and the build failed with "Cannot locate Visual Studio compilers" message. Adding `BuildTools` as an option to this loop fixed it and JFX built properly (checked without Media and Webkit). Alternatively, setting `VSCOMMONTOOLS` also helps, but I think we can easily add `BuildTools` as an option here. > > As a side-note - building without this PR on the same system also failed so it doesn't necessarily introduce a regression, but I think it would be a worthy addition regardless. I decided to go ahead and add this. Can you test and review it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1716227825 From azvegint at openjdk.org Wed Aug 14 06:27:19 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 14 Aug 2024 06:27:19 GMT Subject: RFR: 8337827: [XWayland] Skip failing tests on Wayland Message-ID: This changeset introduces the `Util.isOnWayland()` method and skips failing tests on Wayland. After that, all tests run on Wayland without failures. ------------- Commit messages: - add javadoc - 8337827: [XWayland] Skip failing tests on Wayland Changes: https://git.openjdk.org/jfx/pull/1536/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1536&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337827 Stats: 31 lines in 4 files changed: 25 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1536.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1536/head:pull/1536 PR: https://git.openjdk.org/jfx/pull/1536 From lkostyra at openjdk.org Wed Aug 14 08:28:59 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 14 Aug 2024 08:28:59 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v4] In-Reply-To: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com> References: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com> Message-ID: On Wed, 14 Aug 2024 02:21:30 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Look for BuildTools if other VS editions not found Looks good. Tested a clean build on two Win 11 machines (one with VS 2022 Pro, one with VS 2022 Build Tools) and everything built with no issues. ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2237487481 From duke at openjdk.org Wed Aug 14 10:41:57 2024 From: duke at openjdk.org (Dirk Lemmermann) Date: Wed, 14 Aug 2024 10:41:57 GMT Subject: RFR: 8337656 iOS WebView Position In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 11:40:06 GMT, Florian Kirmaier wrote: > Fixing WebView on iOS > (I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.) > > @johanvos > If this looks reasonable to you, can you provide a test build for @dlemmermann ? > Then he can test it with his JFX-Central iOS version. The proper positioning of the WebView is the last thing missing for us to go for a release. Would be great to know whether we can use the WebView for displaying YouTube videos or not. Any support in this area would be much appreciated. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1526#issuecomment-2288414826 From nlisker at openjdk.org Wed Aug 14 11:11:01 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 14 Aug 2024 11:11:01 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v4] In-Reply-To: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com> References: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com> Message-ID: <14zBPDcoJXuCNTCeJOjqly3LMI_vulye9I77fgt4OQk=.ed76334b-9235-464f-94fc-de81501ca5a9@github.com> On Wed, 14 Aug 2024 02:21:30 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Look for BuildTools if other VS editions not found Re-approving ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2237844252 From nlisker at gmail.com Wed Aug 14 12:03:35 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 14 Aug 2024 15:03:35 +0300 Subject: RichTextArea: API Review In-Reply-To: References: Message-ID: My questions are similar to the ones in the previous discussion, but now I can be more specific. I see a list of "building blocks" in https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically, two types of building blocks additions are important as I see it: rich text-specific ones like document models and a way to add decorations/colors etc., and the split of controls in general into skin/input/behavior (on which there has been a long discussion). My questions are: 1. If these are provided to the user, how difficult is it for them to compose a RTA? JavaFX doesn't provide some somewhat-common controls that you see in various other libraries with the reasoning that the library should give the user the ability to create their own controls (which is not so easy right now). Is RTA an exception, like ColorPicker and DatePicker? 2. Can these building blocks be used to enhance existing controls? For example, to help with TextArea's performance with long texts, or allow rich text-like features in other controls, like the squiggly red line under the text in a TextField? 3. As also mentioned in the proposal, there are already 3rd party RTAs - RichTextFX and Gluon's. Does the proposed RTA offer more than these (besides the ease of use by being in JavaFX)? Do the building blocks of these offer advantages that the proposed building blocks don't? An abstract test that can be done is to see if these controls can be "retrofitted" with the proposed new building blocks (no need to actually rewrite the code). If not, it could hint to an incompatibility or a limit of the proposal that makes it less appealing. Thanks, Nir On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev wrote: > Dear fellow developers: > > > > Thank you for the early feedback on the RichTextArea proposal [0]. > > > > We are moving to the next phase by submitting the public pull request [1]. > The main goal is to include the new control in an incubating module [8], > hopefully in jfx24, as a means of putting non-final API in the hands of > developers while the API and implementation progress towards either > finalization or removal in a future release. > > > > For your convenience, two test applications are provided - > *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new > controls with a number of different models. In addition to these two > testers, please check out a simple standalone rich text editor application, > *RichEditorDemoApp*, > > > > We would encourage anyone - the javafx developers, and especially the > application developers, to take a look at the public API [3]. It's > probably less important at this stage to do a deep code review of the > implementation, but we would certainly appreciate and welcome your code > review comments. > > > > Thank you in advance, > > -andy > > > > > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > > [1] Pull request: https://github.com/openjdk/jfx/pull/1524 > > [2] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > > [3] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [4] CSS Reference: > https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > > [5] Behavior doc: > https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > > [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [7] Previous (now obsolete) draft pull request: > https://github.com/openjdk/jfx/pull/1374 > > [8] Incubator module JEP: > https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Wed Aug 14 13:34:57 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 14 Aug 2024 13:34:57 GMT Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set [v4] In-Reply-To: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com> References: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com> Message-ID: On Wed, 14 Aug 2024 02:21:30 GMT, Kevin Rushforth wrote: >> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: >> >> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ >> (Enterprise|Professional|Community)\VC\Auxiliary\Build >> >> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. >> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. >> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. >> 5. Removed the following unused variables: >> >> DEVENVCMD >> DXSDK_DIR >> VS_VER >> >> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). >> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). >> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). >> >> >> I left some debug print statements in, and will remove them in a follow-on commit. >> >> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Look for BuildTools if other VS editions not found Marked as reviewed by mhanl (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2238184522 From quizynox at gmail.com Wed Aug 14 13:35:42 2024 From: quizynox at gmail.com (quizynox) Date: Wed, 14 Aug 2024 17:35:42 +0400 Subject: RichTextArea: API Review In-Reply-To: References: Message-ID: <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com> Hello, > As also mentioned in the proposal, there are already 3rd party RTAs - > RichTextFX and Gluon's. Does the proposed RTA offer more than these > (besides the ease of use by being in JavaFX)? Do the building blocks > of these offer advantages that the proposed building blocks don't? An > abstract test that can be done is to see if these controls can be > "retrofitted" with the proposed new building blocks (no need to > actually rewrite the code). If not, it could hint to an > incompatibility or a limit of the proposal that makes it less appealing. - Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for commercial projects (even internal non-profit projects). It can't be an alternative, because of this alone. - RichTextFX depends on several long-unmaintained libraries, namely ReactFX. There is nothing that can be done from the OpenJFX side, as it would require rewriting RichTextFX from scratch. I don't think anyone expects OpenJFX to provide something as complex as CodeMirror. However, having a basic rich text control with reasonable extension points would already be a significant improvement. On 14/08/2024 16.03, Nir Lisker wrote: > My questions are similar to the ones in the previous?discussion,?but > now I can be more specific. > > I see a list of "building blocks" in > https://bugs.openjdk.org/browse/JDK-8300569, which I like. > Specifically, two types of building blocks additions are important as > I see it: rich text-specific ones like document models and a way to > add decorations/colors etc., and the split of controls in general into > skin/input/behavior (on which there has been a long discussion). My > questions are: > > 1. If these are provided to the user, how difficult is it for them to > compose a RTA? JavaFX doesn't provide some somewhat-common controls > that you see in various other libraries with the reasoning that the > library should give the user the ability to create their own controls > (which is not so easy right now). Is RTA an exception,?like > ColorPicker and DatePicker? > 2. Can these building blocks be used to enhance existing controls? For > example, to help with TextArea's performance with long texts, or allow > rich text-like features in other controls, like the squiggly red line > under the text in a TextField? > 3. As also mentioned in the proposal, there are already 3rd party RTAs > - RichTextFX and Gluon's. Does the proposed RTA offer more than these > (besides the ease of use by being in JavaFX)? Do the building blocks > of these offer advantages that the proposed building blocks don't? An > abstract test that can be done is to see if these controls can be > "retrofitted" with the proposed new building blocks (no need to > actually rewrite the code). If not, it could hint to an > incompatibility or a limit of the proposal that makes it less appealing. > > Thanks, > Nir > > > On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev > wrote: > > Dear fellow developers: > > Thank you for the early feedback on the RichTextArea proposal [0]. > > We are moving to the next phase by submitting the public pull > request [1].The main goal is to include the new control in an > incubating module [8], hopefully in jfx24, as a means of putting > non-final API in the hands of developers while the API and > implementation progress towards either finalization or removal in > a future release. > > For your convenience, two test applications are provided - > *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the > new controls with a number of different models.In addition to > these two testers, please check out a simple standalone rich text > editor application, *RichEditorDemoApp*, > > We would encourage anyone - the javafx developers, and especially > the application developers, to take a look at the public API > [3].It's probably less important at this stage to do a deep code > review of the implementation, but we would certainly appreciate > and welcome your code review comments. > > Thank you in advance, > > -andy > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > > [1] Pull request: https://github.com/openjdk/jfx/pull/1524 > > [2] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > > [3] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [4] CSS Reference: > https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > > [5] Behavior doc: > https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > > [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > > [7] Previous (now obsolete) draft pull request: > https://github.com/openjdk/jfx/pull/1374 > > [8] Incubator module JEP: > https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Aug 14 14:45:16 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 14 Aug 2024 17:45:16 +0300 Subject: RichTextArea: API Review In-Reply-To: <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com> References: <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com> Message-ID: > > - Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for > commercial projects > Didn't know. That's a good point. > - RichTextFX depends on several long-unmaintained libraries, namely > ReactFX. > ReactFX is mostly finished. I have been using it for years, there are only a few bugs there that I have hit. Some of the features there were even imported to JavaFX. Otherwise, I don't know about the 3rd party libraries situation there. having a basic rich text control with reasonable extension points would > already be a significant improvement. > Having a lot of things in JavaFX will be a significant improvement. The question we're discussing is, is this worth the time compared to other things that could have a bigger impact. The developer resources are very limited. As someone who doesn't need this level of rich text support, I would personally like to see time invested elsewhere, but as a maintainer I acknowledge that others do want this, so I don't mind supporting it. Tray icon support is one of the most requested features (which I also don't require personally), maybe that's a better time investment, I don't know. On Wed, Aug 14, 2024 at 4:35?PM quizynox wrote: > Hello, > > As also mentioned in the proposal, there are already 3rd party RTAs - > RichTextFX and Gluon's. Does the proposed RTA offer more than these > (besides the ease of use by being in JavaFX)? Do the building blocks of > these offer advantages that the proposed building blocks don't? An abstract > test that can be done is to see if these controls can be "retrofitted" with > the proposed new building blocks (no need to actually rewrite the code). If > not, it could hint to an incompatibility or a limit of the proposal that > makes it less appealing. > > - Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for > commercial projects (even internal non-profit projects). It can't be an > alternative, because of this alone. > - RichTextFX depends on several long-unmaintained libraries, namely > ReactFX. There is nothing that can be done from the OpenJFX side, as it > would require rewriting RichTextFX from scratch. > > I don't think anyone expects OpenJFX to provide something as complex as > CodeMirror. However, having a basic rich text control with reasonable > extension points would already be a significant improvement. > On 14/08/2024 16.03, Nir Lisker wrote: > > My questions are similar to the ones in the previous discussion, but now I > can be more specific. > > I see a list of "building blocks" in > https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically, > two types of building blocks additions are important as I see it: rich > text-specific ones like document models and a way to add decorations/colors > etc., and the split of controls in general into skin/input/behavior (on > which there has been a long discussion). My questions are: > > 1. If these are provided to the user, how difficult is it for them to > compose a RTA? JavaFX doesn't provide some somewhat-common controls that > you see in various other libraries with the reasoning that the library > should give the user the ability to create their own controls (which is not > so easy right now). Is RTA an exception, like ColorPicker and DatePicker? > 2. Can these building blocks be used to enhance existing controls? For > example, to help with TextArea's performance with long texts, or allow rich > text-like features in other controls, like the squiggly red line under the > text in a TextField? > 3. As also mentioned in the proposal, there are already 3rd party RTAs - > RichTextFX and Gluon's. Does the proposed RTA offer more than these > (besides the ease of use by being in JavaFX)? Do the building blocks of > these offer advantages that the proposed building blocks don't? An abstract > test that can be done is to see if these controls can be "retrofitted" with > the proposed new building blocks (no need to actually rewrite the code). If > not, it could hint to an incompatibility or a limit of the proposal that > makes it less appealing. > > Thanks, > Nir > > > On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev > wrote: > >> Dear fellow developers: >> >> >> >> Thank you for the early feedback on the RichTextArea proposal [0]. >> >> >> >> We are moving to the next phase by submitting the public pull request [1]. >> The main goal is to include the new control in an incubating module [8], >> hopefully in jfx24, as a means of putting non-final API in the hands of >> developers while the API and implementation progress towards either >> finalization or removal in a future release. >> >> >> >> For your convenience, two test applications are provided - >> *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new >> controls with a number of different models. In addition to these two >> testers, please check out a simple standalone rich text editor application, >> *RichEditorDemoApp*, >> >> >> >> We would encourage anyone - the javafx developers, and especially the >> application developers, to take a look at the public API [3]. It's >> probably less important at this stage to do a deep code review of the >> implementation, but we would certainly appreciate and welcome your code >> review comments. >> >> >> >> Thank you in advance, >> >> -andy >> >> >> >> >> >> [0] Proposal: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> >> [1] Pull request: https://github.com/openjdk/jfx/pull/1524 >> >> [2] Discussion points: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> >> [3] API specification (javadoc): >> https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> >> [4] CSS Reference: >> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> >> [5] Behavior doc: >> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> >> [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> >> [7] Previous (now obsolete) draft pull request: >> https://github.com/openjdk/jfx/pull/1374 >> >> [8] Incubator module JEP: >> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlichten at openjdk.org Wed Aug 14 14:47:01 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 14 Aug 2024 14:47:01 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev wrote: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/SyntaxDecorator.java line 37: > 35: /** > 36: * Creates a {@link RichParagraph} from the paragraph plain text. > 37: * The text string is guaranteed to contain neither newline nor carriage return symbols. Comment seems unclear to me. Which text string ? There is no String parameter here, only a CodeTextModel with a paragraph index... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717071557 From hmeda at openjdk.org Wed Aug 14 14:50:55 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 14 Aug 2024 14:50:55 GMT Subject: Integrated: 8336941 : Update libxslt to 1.1.42 In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 06:36:22 GMT, Hima Bindu Meda wrote: > Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen This pull request has now been integrated. Changeset: dc8f607e Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/dc8f607e4ce95e348bb812a1c942e4321c00f0f8 Stats: 478 lines in 19 files changed: 111 ins; 316 del; 51 mod 8336941: Update libxslt to 1.1.42 Reviewed-by: kcr, jbhaskar ------------- PR: https://git.openjdk.org/jfx/pull/1527 From rlichten at openjdk.org Wed Aug 14 14:51:56 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 14 Aug 2024 14:51:56 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev wrote: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/BasicTextModel.java line 198: > 196: */ > 197: public static class InMemoryContent implements Content { > 198: private final ArrayList paragraphs = new ArrayList<>(); Since paragraphs may be inserted anywhere, I would guess that using a LinkedList should be more efficient here. Otherwise, when adding a line break somewhere in the middle of a long text, a lot of array members must be copied. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717082870 From rlichten at openjdk.org Wed Aug 14 14:57:54 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 14 Aug 2024 14:57:54 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: <-WhEo5SNaDtEPHLJd_1ErFogQeAJ-sbJ1kxiPliYbDk=.1fac7bc2-fb5f-4d59-a35c-b352cfad1549@github.com> On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev wrote: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 tests/manual/RichTextAreaDemo/src/com/oracle/demo/richtext/codearea/DemoSyntaxDecorator.java line 54: > 52: > 53: @Override > 54: public RichParagraph createRichParagraph(CodeTextModel model, int index) { When implementing "real" syntax highlighting, the style of a paragraph will depend on the style of it's predecessors (e.g. multiline strings or multiline comments)... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717093140 From r.lichtenberger at gmail.com Wed Aug 14 14:59:04 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Wed, 14 Aug 2024 16:59:04 +0200 Subject: RichTextArea: API Review In-Reply-To: References: Message-ID: Am 02.08.24 um 21:41 schrieb Andy Goryachev: > > Dear fellow developers: > > Thank you for the early feedback on the RichTextArea proposal [0]. > > We are moving to the next phase by submitting the public pull request > [1].The main goal is to include the new control in an incubating > module [8], hopefully in jfx24, as a means of putting non-final API in > the hands of developers while the API and implementation progress > towards either finalization or removal in a future release. > > For your convenience, two test applications are provided - > *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new > controls with a number of different models.In addition to these two > testers, please check out a simple standalone rich text editor > application, *RichEditorDemoApp*, > > We would encourage anyone - the javafx developers, and especially the > application developers, to take a look at the public API [3].It's > probably less important at this stage to do a deep code review of the > implementation, but we would certainly appreciate and welcome your > code review comments. > Just taken a very cursory look over the pull request (leaving a few thoughts) and I like the API very much. I would indeed try to get rid of RichTextFX in our application, if RTA becomes available. Thanks for the effort, Robert > Thank you in advance, > > -andy > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > > [1] Pull request: https://github.com/openjdk/jfx/pull/1524 > > [2] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > > [3] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [4] CSS Reference: > https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > > [5] Behavior doc: > https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > > [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > > [7] Previous (now obsolete) draft pull request: > https://github.com/openjdk/jfx/pull/1374 > > [8] Incubator module JEP: > https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Aug 14 15:02:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Aug 2024 15:02:58 GMT Subject: Integrated: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 14:21:14 GMT, Kevin Rushforth wrote: > 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations: > > C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\ > (Enterprise|Professional|Community)\VC\Auxiliary\Build > > 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more. > 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment. > 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically. > 5. Removed the following unused variables: > > DEVENVCMD > DXSDK_DIR > VS_VER > > 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast). > 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed). > 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin). > > > I left some debug print statements in, and will remove them in a follow-on commit. > > I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit. This pull request has now been integrated. Changeset: a8f78505 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/a8f7850503043f616703fdfc8d0a26a00f47b7c8 Stats: 165 lines in 5 files changed: 32 ins; 79 del; 54 mod 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set Reviewed-by: nlisker, mhanl, lkostyra, prr ------------- PR: https://git.openjdk.org/jfx/pull/1534 From mfox at openjdk.org Wed Aug 14 15:13:57 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 14 Aug 2024 15:13:57 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 21:40:46 GMT, Andy Goryachev wrote: > Actually, this statement is not correct: the consumed flag will be propagated, but only if `propagateConsume` was set by the helper, which is being done in a very specific case. If a perfectly legal, properly written dispatcher in the chain creates a new event without using `copyFor` the `propagateConsume` link will be broken and this PR will not work correctly. That's solely because this PR is trying to create a new way of communicating whether an event is consumed or not instead of using the existing mechanism. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289078999 From mfox at openjdk.org Wed Aug 14 15:16:04 2024 From: mfox a