From mstrauss at openjdk.org Sat Jul 1 22:30:06 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 1 Jul 2023 22:30:06 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments Message-ID: DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: ... String data = uri.substring(dataSeparator + 1); Charset charset = Charset.defaultCharset(); ... URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. ------------- Commit messages: - Don't use URLDecoder in DataURI - Failing test Changes: https://git.openjdk.org/jfx/pull/1165/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1165&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311216 Stats: 105 lines in 2 files changed: 93 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1165.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1165/head:pull/1165 PR: https://git.openjdk.org/jfx/pull/1165 From kpk at openjdk.org Sun Jul 2 09:57:00 2023 From: kpk at openjdk.org (Karthik P K) Date: Sun, 2 Jul 2023 09:57:00 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 17:21:59 GMT, Andy Goryachev wrote: > Do you mean MouseVent.getX()? The x coordinate reported by `MouseEvent.getPickResult().getIntersectedPoint()` method. I can reproduce this issue in MonkeyTester as well. When I checked the `Point2D` object sent to `Text::hitTest()` method, it is different when RichText is displayed in multiple lines like how it is shown in the above screenshot and when it is displayed in single line as shown below. image In both the cases cursor is hovered just over the right side of caret line. The x coordinate value reported is given below. Single line - x: 102 Multi line - x: 1 Because of this issue, the character index calculated for the same character changes. However I agree that bug is present in the character index calculation like you mentioned above. I'll work on fixing that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1616556353 From jhendrikx at openjdk.org Sun Jul 2 11:46:19 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 2 Jul 2023 11:46:19 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add newline at end of ConditionalBinding file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/1f40a4b2..ca69e2c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Sun Jul 2 12:56:03 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 2 Jul 2023 12:56:03 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Fri, 23 Jun 2023 15:45:21 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments I only reviewed this partially. My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. The `ResizeHelper` is short-lived, and created/recreated many times during a resize operation. I'm not even sure why it is being instantiated at all (it literally is created and discarded in a single method). The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). I'd expect: 1. User starts a resize 2. All sizes and positions are stored -- this may be a good time to create something like the `ResizeHelper`. This `ResizeHelper` should never modify the initial sizes, as they're needed for each new calculation until the drag ends. 3. User drags the cursor all over the place 4. Depending on where the cursor is + the initial stored values, a new set of column sizes is calculated and displayed; the algorithm should not have "memory" effects of non-final column sizes of positions where the cursor was before 5. When the drag ends, the final position is exactly what would have happened if the drag was a single instant move, in other words, moving the cursor from `0 -> 100` should be the same as if it was moved from `0 -> -10 -> 90 -> 200 -> 100` I haven't checked completely how the column resizing works, but I don't see how this could possible be a good algorithm currently. So I'm left wondering what value this change then brings as I think these changes would more than likely all be discarded once the UX is implemented correctly. A direct JUnit test on this complicated code that verifies all the edge cases would be something I'd like to see added as a minimum, but looking at the code, I don't see this being a good algorithm at all... modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 58: > 56: ConstrainedColumnResize.ResizeMode mode) { > 57: this.rf = rf; > 58: this.snap = (rf.getTableControl().isSnapToPixel() ? rf.getTableControl() : null); Obtaining the `Region` here is a bit hacky, this may be out of scope, but I would say `snap` should be a boolean, and the `snapXXX` helper methods in this class should call `ScaledMath`. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 77: > 75: double cmin = snapCeil(c.getMinWidth()); // always honor min width! > 76: double cmax = snapFloor(c.getMaxWidth()); // TableColumnBase.doSetWidth() clamps to (min,max) range > 77: min[i] = cmin; Looking at `doSetWidth` I see that it clamps using unsnapped values, so the column can still be given an unsnapped size. When scale is 1.0, and the column for example has its min/max width set to 20.1 and 20.9, then snapCeil is 21 and snapFloor is 20 (so maximum is less than minimum, which may already be a bit dubious). When `doSetWidth` is called it will be clamped, resulting in `20.1` or `20.9`. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 125: > 123: private void distribute(double delta, double[] desired) { > 124: double threshold = snapRound(SMALL_DELTA); > 125: if (Math.abs(delta) > threshold) { The threshold is pretty arbitrary, I don't think it benefits from snap rounding here. I'd be more inclined to eliminate the difference between these two functions; I would expect that if a user drags a column resizer for 100 pixels, that it should make no difference whether that was a slow drag or a fast one, and the end visuals and column sizes should be exactly the same regardless. ------------- PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-1509558936 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1249477980 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1249466719 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1249493706 From ebresie at gmail.com Sun Jul 2 16:21:33 2023 From: ebresie at gmail.com (Eric Bresie) Date: Sun, 2 Jul 2023 11:21:33 -0500 Subject: Problem with OpenJFX on Windows/Cygwin/SDKMAN Environment Message-ID: Hope this is the right place to ask this question...If there was some IRC, Slack, or some other form of chat I would direct it there... I am trying to build openjfx from master per https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX Using 1. Cygwin in Windows 11 environment with specified add ons setup. 2. Visual Studio 2022 Community in use, setting the VS150COMNTOOLS to subfolder under this 1. Is this acceptable or should a different variable be used here? 2. Does ./vcvarsall.bat need to be called to set applicable VisualStudio variables, etc.)? 3. I'm using SDKMAN to manage my JDKs in the Cygwin environment. Attempting the basic sh gradlew tasks command I'm getting Build file 'C:\git\jfx\jfx\build.gradle' line: 693 * What went wrong: A problem occurred evaluating root project 'jfx'. > Missing or incorrect path to 'java': '\home\\.sdkman\candidates\java\current\bin\java.exe'. Perhaps bad JDK_HOME? /home/ /.sdkman/candidates/java/current In the build.gradle, the above issue occurs here // Make sure JDK_HOME/bin/java exists if (!file(JAVA).exists()) throw new Exception("Missing or incorrect path to 'java': '$JAVA'. Perhaps bad JDK_HOME? $JDK_HOME") My environment variables are set like: $ echo $JAVA_HOME /home//.sdkman/candidates/java/current $ echo $JDK_HOME /home/ /.sdkman/candidates/java/current In the bin of the above there is the following which appears to have "java.exe" so not sure why this is happening. ~/.sdkman/candidates/java/current/bin $ ls -l java* -rwxrwxr-x 1 146824 Apr 18 17:39 java.dll -rwxrwxr-x 1 50056 Apr 18 17:39 java.exe -rwxrwxr-x 1 287624 Apr 18 17:39 javaaccessbridge.dll -rwxrwxr-x 1 23944 Apr 18 17:39 javac.exe -rwxrwxr-x 1 23944 Apr 18 17:39 javadoc.exe -rwxrwxr-x 1 179080 Apr 18 17:39 javajpeg.dll -rwxrwxr-x 1 23944 Apr 18 17:39 javap.exe -rwxrwxr-x 1 50056 Apr 18 17:39 javaw.exe Not sure if this is due to the way sdkman creates a symbolic link from "current" to given candidate or if there is some "pathing differences" (i.e. Windows C:\\someplace" vs /c/someplace, etc.) issue. Has anyone had similar issues and/or know how to get around this? Eric Bresie ebresie at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Sun Jul 2 16:49:11 2023 From: john at status6.com (John Neffenger) Date: Sun, 2 Jul 2023 09:49:11 -0700 Subject: Problem with OpenJFX on Windows/Cygwin/SDKMAN Environment In-Reply-To: References: Message-ID: <2b399422-ec3d-b1a5-76c1-27891f3645dd@status6.com> On 7/2/23 9:21 AM, Eric Bresie wrote: > * What went wrong: > A problem occurred evaluating root project 'jfx'. > > Missing or incorrect path to 'java': > '\home\\.sdkman\candidates\java\current\bin\java.exe'. > Perhaps bad JDK_HOME? /home/ ? /.sdkman/candidates/java/current You might need to use the cygpath command to set those environment variables. I finally got builds working well on Windows with the following script for setting up the environment variables in Cygwin: ------------------------------------------------------------------------ #!/bin/bash # Sets up the environment for building JavaFX # Path must include 'C:\Windows\System32' syspath=/usr/sbin:/usr/bin:/sbin:/bin:/cygdrive/c/Windows/System32 # Visual Studio Build Tools 2022 export VS150COMNTOOLS="C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\VC\\Auxiliary\\Build" cmake=$HOME/opt/cmake-3.26.4-windows-x86_64 jdk=$HOME/opt/jdk-19.0.2 ant=$HOME/opt/apache-ant-1.10.13 CMAKE_HOME=$(cygpath -m "$cmake") JAVA_HOME=$(cygpath -m "$jdk") ANT_HOME=$(cygpath -m "$ant") SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) export CMAKE_HOME export JAVA_HOME export ANT_HOME export SOURCE_DATE_EPOCH # JDK_HOME and PATH are required by the build export JDK_HOME="$JAVA_HOME" export PATH=$ant/bin:$jdk/bin:$cmake/bin:$syspath ------------------------------------------------------------------------ See my repository at jgneff/jfxbuild for the scripts I use to run the builds. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebresie at gmail.com Sun Jul 2 17:23:03 2023 From: ebresie at gmail.com (Eric Bresie) Date: Sun, 2 Jul 2023 12:23:03 -0500 Subject: Problem with OpenJFX on Windows/Cygwin/SDKMAN Environment In-Reply-To: <2b399422-ec3d-b1a5-76c1-27891f3645dd@status6.com> References: <2b399422-ec3d-b1a5-76c1-27891f3645dd@status6.com> Message-ID: Probably a question I should have asked up front and may have missed it someplace, but what is the version of JDK required for jfx from master? I'm using JDK 17 at the moment. Is that still okay? Will give that a try... Before I got this email response I was poking around some... I ran "sh gradlew --debug tasks" and noticed there appeared to be two variations of paths showing up (see below). I could be wrong, but the first looks like it might be okay in cygwin but the subsequent ones don't look quite right to me (i.e., assume using cygwin it might treat the "\home\.." as a "corrupt" path with the "\" escaping portions of the path). 2023-07-02T11:59:29.490-0500 [INFO] [org.gradle.api.Project] *Converting > path '/home//.sdkman/candidates/java/current' via cygpath to > /home/* > */.sdkman/candidates/java/current*2023-07-02T11:59:29.490-0500 [INFO] > [org.gradle.api.Project] Converting path > '/home//.sdkman/candidates/java/current/bin/java' via cygpath to > *\home\\.sdkman\candidates\java\current\bin\java* > 2023-07-02T11:59:29.490-0500 [INFO] [org.gradle.api.Project] Converting > path '/home//.sdkman/candidates/java/current/bin/javac' via > cygpath to \home\\.sdkman\candidates\java\current\bin\javac > 2023-07-02T11:59:29.490-0500 [INFO] [org.gradle.api.Project] Converting > path '/home//.sdkman/candidates/java/current/bin/javadoc' via > cygpath to \home\\.sdkman\candidates\java\current\bin\javadoc > 2023-07-02T11:59:29.490-0500 [INFO] [org.gradle.api.Project] Converting > path '/home//.sdkman/candidates/java/current/bin/jmod' via > cygpath to \home\\.sdkman\candidates\java\current\bin\jmod > 2023-07-02T11:59:29.491-0500 [INFO] [org.gradle.api.Project] Converting > path 'null/jmods' via cygpath to null/jmods Not sure if it's related but in the build.gradle file, I noticed the below "cygpath helper methods" defined. Does the build.gradle not truely use the actual "cygpath" and instead just tries to mirror the behavior within? Is it possible the build.gradle cygpath related conversions are a little off around the highlighted places and/or need the "-m" (mixed) type of logic included? /** > > * Converts cygwin style paths to windows style paths, but with a forward > slash. > * This method is safe to call from any platform, and will only do work if > * called on Windows (in all other cases it simply returns the supplied > path. > * > * @param path the path to convert > * @return the path converted to windows style, if on windows, otherwise it > * is the supplied path. > */ > String cygpath(String path) { > if (!IS_WINDOWS) return path; > if (path == null || "".equals(path)) return path; > * String ret = path.replaceAll('\\\\', '/')* > logger.info("Converting path '$path' via cygpath to "+ret) > return ret > } > /** > * Converts cygwin file paths for java executables to windows style > * executable paths by changing forward slashes to back slashes and > * adding the '.exe' extension. > * This method is safe to call from any platform, and will only do work if > * called on Windows (in all other cases it simply returns the supplied > path). > * > * @param path the path to convert > * @return the path converted to windows style, if on windows, otherwise it > * is the supplied path. > */ > String cygpathExe(String path) { > if (!IS_WINDOWS) return path; > if (path == null || "".equals(path)) return path; > *String ret = path.replaceAll('/', '\\\\')* > logger.info("Converting path '$path' via cygpath to "+ret) > return ret + ".exe" > } > > Eric Bresie ebresie at gmail.com On Sun, Jul 2, 2023 at 11:50?AM John Neffenger wrote: > On 7/2/23 9:21 AM, Eric Bresie wrote: > > * What went wrong: > A problem occurred evaluating root project 'jfx'. > > Missing or incorrect path to 'java': > '\home\\.sdkman\candidates\java\current\bin\java.exe'. Perhaps > bad JDK_HOME? /home/ /.sdkman/candidates/java/current > > You might need to use the cygpath command to set those environment > variables. I finally got builds working well on Windows with the following > script > for > setting up the environment variables in Cygwin: > ------------------------------ > > #!/bin/bash > # Sets up the environment for building JavaFX > > # Path must include 'C:\Windows\System32' > syspath=/usr/sbin:/usr/bin:/sbin:/bin:/cygdrive/c/Windows/System32 > > # Visual Studio Build Tools 2022 > export VS150COMNTOOLS="C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\VC\\Auxiliary\\Build" > > cmake=$HOME/opt/cmake-3.26.4-windows-x86_64 > jdk=$HOME/opt/jdk-19.0.2 > ant=$HOME/opt/apache-ant-1.10.13 > > CMAKE_HOME=$(cygpath -m "$cmake") > JAVA_HOME=$(cygpath -m "$jdk") > ANT_HOME=$(cygpath -m "$ant") > SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > > export CMAKE_HOME > export JAVA_HOME > export ANT_HOME > export SOURCE_DATE_EPOCH > > # JDK_HOME and PATH are required by the build > export JDK_HOME="$JAVA_HOME" > export PATH=$ant/bin:$jdk/bin:$cmake/bin:$syspath > > ------------------------------ > > See my repository at jgneff/jfxbuild > for the scripts I use to > run the builds. > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Sun Jul 2 22:37:09 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 2 Jul 2023 22:37:09 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v7] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 17:31:42 GMT, Michael Strau? wrote: >>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed). >>> >>> Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all. We might even want to look into other frameworks like Swing. Maybe there are people internally at Oracle who can give valuable input here too? >> >> I think extracting the common code out of HBox and VBox would be good, as they're basically doing the same thing in a different axis. The code could then be unit tested directly (ie. given a set of min/max/pref sizes, a target size and a "snapper", calculate optimal sizes). Something like this: >> >> double[] distribute(double space, double[] minWidths, double[] maxWidths, Snapper snapper); >> >> The minWidths/maxWidths would be min + pref or pref + max depending on the situation, but this function wouldn't care. The `Snapper` here would be aware of the scale, and would be a dummy implementation that does nothing when snapping is disabled. >> >> This purposely does not handle spacing between children, as you can calculate that before hand and adjust `space` to the actual space available for children, simplifying the code. >> >> Disclaimer: I used to create my own layout manager (see: [smartlayout](https://github.com/hjohn/hs.ui.smartlayout/blob/master/src/main/java/hs/smartlayout/LayoutRequirements.java)) that took into account min/max and weight of each child, and even groups of children (a restriction over two or more children at once) -- weight would affect resizing, allowing you to make layouts where children took space according to some ratio (1:2:3 for example). This functionality I called a `SpaceDistributor` which was purposely given a neutral name as it could be used for both horizontal or vertical calculations. When including weight, the calculations could get so complex that I had multiple implementations and an exhaustive search implementation (which was used by unit tests to verify the optimized implementations). This was before scaling became an issue though, so this code did not take snapping values to pixels into account. > > Thank you very much @hjohn for your extensive review. Before addressing your comments, I'd like to get some clarification (ideally also from @kevinrushforth), because I am a bit confused by the discussion so far. > > This PR is a very narrow patch that fixes an obvious bug in `HBox` and `VBox`. It's narrow in that it doesn't change the present algorithm, it merely corrects some of its flaws. There is a little bit of refactoring, but that's only done where it helps readers to better understand the algorithm. > > However, the discussion seems to center around the idea of large-scale refactoring, even across multiple components, including open tickets like [8299753](https://bugs.openjdk.org/browse/JDK-8299753). That's not something I can do as part of this PR, and if large-scale refactoring is the way we choose to go forward, I'd rather not spend more of my time on this particular PR. There needs to be a realistic chance that this PR will be accepted for integration basically as it is. > > If we want to expand the scope of this work, this PR should be closed and the discussion should be continued on the mailing list. > PR #1111 is likely to be the eventual solution for the general problem of handling layout when snap-to-pixel is set (as it is by default). So the question I have, primarily for @mstr2 and @hjohn, is: Is this PR a reasonable step along the path to where we want to go? Or will it need to be reworked or reverted if and when we get to PR #1111 ? > > If it's the former, it might make sense to revive this PR and take it forward. Otherwise, it should probably be closed in favor of continuing work on PR #1111 It could perhaps be a reasonable step, although most of the effort would become wasted if we also move #1111 forward. I'd expect a good JUnit test though to prove that it works correctly. It's also possible that the integration of #1118 already solved some of the problems (but I'm sure it did not solve all of them), and so this PR and #1111 may have become less important. ------------- PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1616885353 From kpk at openjdk.org Mon Jul 3 09:07:09 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 3 Jul 2023 09:07:09 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v4] In-Reply-To: References: Message-ID: On Sun, 2 Jul 2023 09:53:58 GMT, Karthik P K wrote: > However I agree that bug is present in the character index calculation like you mentioned above. I'll work on fixing that. Correction: The character index calculation looks to be correct when x coordinate passed to it is correct. One more case I observed, if we further reduce the width of TextFlow pane by moving the splitter as shown in screenshot below, the x coordinate value reported is correct again. image If cursor is hovered just after the caret line, x value reported is 1 which is correct. Character index calculated in this case is also correct. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1617676237 From jpereda at openjdk.org Mon Jul 3 10:07:07 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 3 Jul 2023 10:07:07 GMT Subject: RFR: 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers Message-ID: This PR fixes the regression introduced with [JDK-8087673](https://bugs.openjdk.org/browse/JDK-8087673) by only modifying the header's width if it is the last visible column. Two tests that fail before the proposed patch and pass after it have been also included. ------------- Commit messages: - update license header - Only modify header's width if it is the last visible column, and include tests Changes: https://git.openjdk.org/jfx/pull/1166/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1166&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311127 Stats: 101 lines in 3 files changed: 99 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1166.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1166/head:pull/1166 PR: https://git.openjdk.org/jfx/pull/1166 From mstrauss at openjdk.org Mon Jul 3 14:42:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 3 Jul 2023 14:42:19 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v7] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strau? wrote: >> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. >> >> The following program shows the problem for HBox: >> >> Region r1 = new Region(); >> Region r2 = new Region(); >> Region r3 = new Region(); >> Region r4 = new Region(); >> Region r5 = new Region(); >> Region r6 = new Region(); >> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r1.setPrefWidth(25.3); >> r2.setPrefWidth(25.3); >> r3.setPrefWidth(25.4); >> r4.setPrefWidth(25.3); >> r5.setPrefWidth(25.3); >> r6.setPrefWidth(25.4); >> r1.setMaxHeight(30); >> r2.setMaxHeight(30); >> r3.setMaxHeight(30); >> r4.setMaxHeight(30); >> r5.setMaxHeight(30); >> r6.setMaxHeight(30); >> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); >> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); >> hbox1.setPrefHeight(40); >> >> r1 = new Region(); >> r2 = new Region(); >> r3 = new Region(); >> r4 = new Region(); >> r5 = new Region(); >> r6 = new Region(); >> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r1.setPrefWidth(25.3); >> r2.setPrefWidth(25.3); >> r3.setPrefWidth(25.4); >> r4.setPrefWidth(25.3); >> r5.setPrefWidth(25.3); >> r6.setPrefWidth(25.4); >> r1.setMaxHeight(30); >> r2.setMaxHeight(30); >> r3.setMaxHeight(30); >> r4.setMaxHeight(30); >> r5.setMaxHeight(30); >> r6.setMaxHeight(30); >> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); >> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null,... > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - changes per review > - Merge branch 'master' into fixes/box-snap-to-pixel > > # Conflicts: > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java > - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel > - revert snappedSum > - don't call snappedSum in hot loop > - Improved code documentation > - Merge branch 'master' into fixes/box-snap-to-pixel > - changed some method names, make test config a local class > - added documentation, improved method names > - Merge branch 'master' into fixes/box-snap-to-pixel > - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a I've tested #1111, which solves the problem that this PR addresses. I've also tested #1118, which is not sufficient to fix the problem (child widths can still exceed container width). Since the implementation is quite different, I think we should close this PR, and move #1111 forward. > It's also possible that the integration of https://github.com/openjdk/jfx/pull/1118 already solved some of the problems (but I'm sure it did not solve all of them), and so this PR and https://github.com/openjdk/jfx/pull/1111 may have become less important. The main problem is still present with #1118, so a solution for that has not become less important. ------------- PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1618481215 From psadhukhan at openjdk.org Mon Jul 3 16:17:17 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Jul 2023 16:17:17 GMT Subject: RFR: 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices Message-ID: If the scaleFactors used for the current device are not 1.0, a JXFPanel will send a resize event with 0x0 dimensions to the JavaFX scene which can have undesirable effects, which is because the resize pixel buffer is created even for initial size of 9x0 width,height. Fix is to make sure to prevent resizing the pixel buffer for initial width/height of 0. ------------- Commit messages: - 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices Changes: https://git.openjdk.org/jfx/pull/1168/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8231865 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1168.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1168/head:pull/1168 PR: https://git.openjdk.org/jfx/pull/1168 From psadhukhan at openjdk.org Tue Jul 4 06:01:15 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Jul 2023 06:01:15 GMT Subject: RFR: 8090267: JFXPanel Input Problem Message-ID: When Japanse (IME on) is inputted to the TextFIeld, which is on JFXPanel, small window for inputting appears on top-left side of screen ![image](https://github.com/openjdk/jfx/assets/43534309/65833d59-528e-4087-9992-9f86b8b8c47f) For swing-interop case, WmImeStartComposition starts composition in native ImmSetCompositionWindow window as "m_useNativeCompWindow" below is true for FX https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3957 m_useNativeCompWindow is true because during sun.awt.im.InputContext#focusGained() calls activateInputMethod which calls WInputMethod.activate() which calls haveActiveClient() which checks for clientComponent.getInputMethodRequests(). Now, in JFXPanel, getInputMethodRequests() returns null as setEmbeddedScene() is not called yet. Since getInputMethodRequests() returns null, haveActiveClient() is false which calls enableNativeIME() with 1 [thereby native composition window is enabled] https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java#L316 Proposed fix is to ensure there is an active client "initially" so that enableNativeIME() is called with 0 and no native compostion window is shown. getInputMethodRequests() is called in setEmbeddedScene() so as to make sure getInputMethodRequest() is initialised to correct "InputMethodSupport.InputMethodRequestsAdapter.fxRequests" object and not NULL. AFter fix ![image](https://github.com/openjdk/jfx/assets/43534309/ec3d8343-9295-4950-885b-f9983b9b017a) ------------- Commit messages: - 8090267: JFXPanel Input Problem Changes: https://git.openjdk.org/jfx/pull/1169/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1169&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8090267 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1169.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1169/head:pull/1169 PR: https://git.openjdk.org/jfx/pull/1169 From duke at openjdk.org Tue Jul 4 14:05:10 2023 From: duke at openjdk.org (duke) Date: Tue, 4 Jul 2023 14:05:10 GMT Subject: Withdrawn: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 10:37:40 GMT, Florian Kirmaier wrote: > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/622 From psadhukhan at openjdk.org Wed Jul 5 03:19:22 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 5 Jul 2023 03:19:22 GMT Subject: RFR: 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held Message-ID: If an EventHandler or EventFilter for a mouse button is attached to a scene within a JFXPanel and the **primary mouse button** is held, any mouse button click will create an event such that event.getButton().name() wrongly returns PRIMARY, even if the secondary or middle button was clicked. This is because `SwingEvents.mouseButtonToEmbedMouseButton()` overwrites the button name after checking the modifier value. For mouse click with primary button `mouseButtonToEmbedMouseButton` is first called with `BUTTON1 `and modifier `BUTTON1_DOWN_MASK `(ie 1024) and then when secondary button(ie right button is clicked) `mouseButtonToEmbedMouseButton` is called with `BUTTON3 `and modifier `BUTTON3_DOWN_MASK | BUTTON1_DOWN_MASK` (ie 5120) and when secondary button is released, `mouseButtonToEmbedMouseButton` is again called with `BUTTON3 `but with modifier `BUTTON1_DOWN_MASK `(1024) resulting in button being declared PRIMARY. Fix is to make sure not to overwrite button name if a button name is already assigned. ------------- Commit messages: - 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held - 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held Changes: https://git.openjdk.org/jfx/pull/1170/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8242419 Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1170.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1170/head:pull/1170 PR: https://git.openjdk.org/jfx/pull/1170 From fkirmaier at openjdk.org Wed Jul 5 16:31:12 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 5 Jul 2023 16:31:12 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v9] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 12:18:49 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - JDK-8273485 > Fixing issue caused by wrong merge. > - Merge remote-tracking branch 'origin/master' into JDK-8273485_swing-deadlock > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m > - JDK-8273485 > Added check for null when calling initScreens > - JDK-8273485 > Fixing toggle fullscreen! > - JDK-8273485 > removed the toggle fullscreen before closing - to avoid the beep and improve the user experience > - JDK-8273485 > Fixed Beep sound when closing a fullscreen window > - JDK-8273485 > small cleanup of the changes. > - JDK-8273485 > Removed the enter/leave nested event loop logic, for mac fullscreen > - JDK-8273485 > Added unit-test > - JDK-8273485 > Fixing deadlock when switching to fullscreen, when also swing is used. I guess there is no way to reopen pull requests, except creating new ones? ------------- PR Comment: https://git.openjdk.org/jfx/pull/622#issuecomment-1622100608 From angorya at openjdk.org Wed Jul 5 16:51:07 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 16:51:07 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Sun, 2 Jul 2023 12:53:05 GMT, John Hendrikx wrote: > My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. please elaborate, or point to a specific problem. It is entirely possible that a better algorithm might exist, but it might be out of scope *at the moment*, as this is a follow-up for a specific issue. > The `ResizeHelper` is short-lived, and created/recreated many times during a resize operation. I'm not even sure why it is being instantiated at all (it literally is created and discarded in a single method). convenience - it does have some data, and it's easier to keep code along with the data. > The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). This is not my experience. Specifically, the difference in behavior between small changes (when the users resizes the columns slowly and we get small deltas of 1 pixel) and large changes (e.g. when initially resizing the table, or the user moves the mouse quickly) are significant. For example, I tried to use your SpaceDistributor from #1111 and it suffered from the same problem as bypassing the small delta path (by setting SMALL_DELTA=0) - when the user resizes the columns slowly, the same column gets the pixel and grows wider than the rest. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622127738 From angorya at openjdk.org Wed Jul 5 16:58:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 16:58:10 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Sun, 2 Jul 2023 12:11:56 GMT, John Hendrikx wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 58: > >> 56: ConstrainedColumnResize.ResizeMode mode) { >> 57: this.rf = rf; >> 58: this.snap = (rf.getTableControl().isSnapToPixel() ? rf.getTableControl() : null); > > Obtaining the `Region` here is a bit hacky, this may be out of scope, but I would say `snap` should be a boolean, and the `snapXXX` helper methods in this class should call `ScaledMath`. Here i would disagree. I specifically do not want to replicate the snap code in the Region, since the Region publishes its snapping API. If there is a change in the snapping APIs in the Region, that change would need to be replicated again here, which I think is a bad idea. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 77: > >> 75: double cmin = snapCeil(c.getMinWidth()); // always honor min width! >> 76: double cmax = snapFloor(c.getMaxWidth()); // TableColumnBase.doSetWidth() clamps to (min,max) range >> 77: min[i] = cmin; > > Looking at `doSetWidth` I see that it clamps using unsnapped values, so the column can still be given an unsnapped size. When scale is 1.0, and the column for example has its min/max width set to 20.1 and 20.9, then snapCeil is 21 and snapFloor is 20 (so maximum is less than minimum, which may already be a bit dubious). When `doSetWidth` is called it will be clamped, resulting in `20.1` or `20.9`. For some reason, I've decided to leave that as is, but since you pointed it out, I think it ought to be fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1253385294 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1253382973 From angorya at openjdk.org Wed Jul 5 17:01:05 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 17:01:05 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <-YkpWiwD9vre9JjctMdZLhre2qi1c1mUra48H8-2Xqk=.042b05ea-3208-40a5-9172-1a6fc78046f0@github.com> On Sun, 2 Jul 2023 12:40:17 GMT, John Hendrikx wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 125: > >> 123: private void distribute(double delta, double[] desired) { >> 124: double threshold = snapRound(SMALL_DELTA); >> 125: if (Math.abs(delta) > threshold) { > > The threshold is pretty arbitrary, I don't think it benefits from snap rounding here. I'd be more inclined to eliminate the difference between these two functions; I would expect that if a user drags a column resizer for 100 pixels, that it should make no difference whether that was a slow drag or a fast one, and the end visuals and column sizes should be exactly the same regardless. theoretically, may be. I could not achieve it with the algorithm that distributes space for large deltas, as it breaks down with small deltas, see my previous comment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1253390837 From angorya at openjdk.org Wed Jul 5 19:23:17 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 19:23:17 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v3] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <_8wJ-sSuu89rAQZZwU_Dd7lToSNYEqCXC0AICZY0NRM=.1acc35cc-ef6d-4822-b223-a467766e44b5@github.com> > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/8eab7970..2e06578e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=01-02 Stats: 62 lines in 5 files changed: 56 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From angorya at openjdk.org Wed Jul 5 19:30:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 19:30:21 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v4] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). 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 ten additional commits since the last revision: - whitespace - Merge remote-tracking branch 'origin/master' into 8299753.resize - review comments - review comments - whitespace - removed obsolete tester - Merge remote-tracking branch 'origin/master' into 8299753.resize - cleanup - new algorithm ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/2e06578e..908203cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=02-03 Stats: 6565 lines in 125 files changed: 3405 ins; 2951 del; 209 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From angorya at openjdk.org Wed Jul 5 19:31:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 19:31:02 GMT Subject: RFR: 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 03:07:01 GMT, Prasanta Sadhukhan wrote: > If an EventHandler or EventFilter for a mouse button is attached to a scene within a JFXPanel and the **primary mouse button** is held, any mouse button click will create an event such that event.getButton().name() wrongly returns PRIMARY, even if the secondary or middle button was clicked. > This is because `SwingEvents.mouseButtonToEmbedMouseButton()` overwrites the button name after checking the modifier value. > For mouse click with primary button `mouseButtonToEmbedMouseButton` is first called with `BUTTON1 `and modifier `BUTTON1_DOWN_MASK `(ie 1024) and then when secondary button(ie right button is clicked) `mouseButtonToEmbedMouseButton` is called with `BUTTON3 `and modifier `BUTTON3_DOWN_MASK | BUTTON1_DOWN_MASK` (ie 5120) > and when secondary button is released, `mouseButtonToEmbedMouseButton` is again called with `BUTTON3 `but with modifier `BUTTON1_DOWN_MASK `(1024) resulting in button being declared PRIMARY. > > Fix is to make sure not to overwrite button name if a button name is already assigned. modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingEvents.java line 84: > 82: } > 83: // Fix for RT-15457: we should report mouse buttons for mouse drags > 84: if (abstractButton == AbstractEvents.MOUSEEVENT_NONE_BUTTON) { minor: the placement of the old comment suggests that it applies to like 84 (this change). Perhaps the comment should be moved down to the line 85. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1170#discussion_r1253538089 From jhendrikx at openjdk.org Wed Jul 5 19:50:01 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 5 Jul 2023 19:50:01 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v4] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <4yn2YCJ9SfeT2yNz9pkjM-0Tww09pHrlq6IYnGasuLE=.a1fc92bc-06b2-4b2b-be35-ac1ad7ab4a4a@github.com> On Wed, 5 Jul 2023 19:30:21 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). > > 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 ten additional commits since the last revision: > > - whitespace > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - review comments > - review comments > - whitespace > - removed obsolete tester > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - cleanup > - new algorithm > > My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. > > please elaborate, or point to a specific problem. It is entirely possible that a better algorithm might exist, but it might be out of scope _at the moment_, as this is a follow-up for a specific issue. It's hard to point to a specific problem when most of the algorithm used would be unnecessary if it used the initial conditions + current resize position as its basis for calculating the column sizes. My problem with this implementation is that it takes what is fundamentally a very simple algorithm (columns have sizes X,Y,Z and Y is resized 10 pixels larger, what should the layout be?) and turns it into a frame rate dependent, mouse movement dependent delta calculation. The initial conditions are discarded, and so a single drag resize of 10 pixels is NOT the same as a drag resize that captured several individual steps (1 + 2 + 3 + 4 pixels), while it really should be... On top of that, if indeed the algorithm is flawed, as I think it is, then there is no way to really fix it apart from some cosmetic changes. This then would be a lot of wasted effort. As I noted, there is no JUnit test for this code as of yet, and for such a complicated algorithm to be verified to be correct, I think it would need one to pass review. If we're willing to forego that, then I suppose a casual fix is in the cards, but I can't really see whether or not it would be correct (within its fundamental limitations) without extensive manual testing. > > The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). > > This is not my experience. Specifically, the difference in behavior between small changes (when the users resizes the columns slowly and we get small deltas of 1 pixel) and large changes (e.g. when initially resizing the table, or the user moves the mouse quickly) are significant. Yes, it would be needed with this algorithm as it is dependent on mouse cursor speed and frame rate as it has no idea of what the initial positions were and how it arrived at the current state. > For example, I tried to use your SpaceDistributor from #1111 and it suffered from the same problem as bypassing the small delta path (by setting SMALL_DELTA=0) - when the user resizes the columns slowly, the same column gets the pixel and grows wider than the rest. It would not be sufficient to just replace `ResizeHelper` with something that uses the space distributor as the information it needs would still be lost. When writing algorithms that resize a UI, using the current size of the elements in your UI + a resize amount will never result in a consistent looking resize. It always must be based on their size constraints (which can be min/pref/max based for controls that can't be individually resized) or the actual sizes when the action started (for splitters or columns). Once the action is finished, only then do the new sizes become the initial sizes for the next action -- not at every mouse event or frame that elapses. `HBox` for example doesn't use its **current** sizes to calculate its "new" size -- it always goes back to the basic min/pref/max sizes, then looks at the space available and computes new sizes based on only that information. If it used the current sizes as its base, you would notice that in certain scenario's the final sizes (if you slowly vs quickly resized a window) would not necessarily always be the same for the same available width -- that's exactly what I think is happening with the column sizes; it's not deterministic and can't be because it lacks the information to do so and hence has to resort to `SMALL_DELTA` tricks to differentiate between "fast" and "slow" resizes. Relying on such things (which can vary with mouse hardware, current framerate, CPU/GPU load, amount of visible `Node`s) makes for an inconsistent resize experience, even when the column was resized by the exact same amount of pixels when the resize ends. This can I think be fixed relatively easily; all it really would take is to track when the drag starts, store the sizes, use these sizes to calculate new sizes each time, and when the drag ends, discard the stored sizes. The `ResizeHelper` would then only need a single much simpler method that takes an array of sizes, the resizing mode, the space available and which column was resized and by how much -- or if you want, you can associate the `ResizeHelper` with the drag resize start, and use the same helper while the resize is in progress. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622392841 From angorya at openjdk.org Wed Jul 5 20:08:03 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 20:08:03 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v4] In-Reply-To: <4yn2YCJ9SfeT2yNz9pkjM-0Tww09pHrlq6IYnGasuLE=.a1fc92bc-06b2-4b2b-be35-ac1ad7ab4a4a@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> <4yn2YCJ9SfeT2yNz9pkjM-0Tww09pHrlq6IYnGasuLE=.a1fc92bc-06b2-4b2b-be35-ac1ad7ab4a4a@github.com> Message-ID: <43lNqWlX7r-y1QWSSDHUjCfY3wHSk9uwM8kG2aKI_Do=.148cf6ba-ba66-4f65-a937-5470aef738bf@github.com> On Wed, 5 Jul 2023 19:45:39 GMT, John Hendrikx wrote: >> 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 ten additional commits since the last revision: >> >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - review comments >> - review comments >> - whitespace >> - removed obsolete tester >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - cleanup >> - new algorithm > >> > My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. >> >> please elaborate, or point to a specific problem. It is entirely possible that a better algorithm might exist, but it might be out of scope _at the moment_, as this is a follow-up for a specific issue. > > It's hard to point to a specific problem when most of the algorithm used would be unnecessary if it used the initial conditions + current resize position as its basis for calculating the column sizes. My problem with this implementation is that it takes what is fundamentally a very simple algorithm (columns have sizes X,Y,Z and Y is resized 10 pixels larger, what should the layout be?) and turns it into a frame rate dependent, mouse movement dependent delta calculation. The initial conditions are discarded, and so a single drag resize of 10 pixels is NOT the same as a drag resize that captured several individual steps (1 + 2 + 3 + 4 pixels), while it really should be... > > On top of that, if indeed the algorithm is flawed, as I think it is, then there is no way to really fix it apart from some cosmetic changes. This then would be a lot of wasted effort. As I noted, there is no JUnit test for this code as of yet, and for such a complicated algorithm to be verified to be correct, I think it would need one to pass review. If we're willing to forego that, then I suppose a casual fix is in the cards, but I can't really see whether or not it would be correct (within its fundamental limitations) without extensive manual testing. > >> > The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). >> >> This is not my experience. Specifically, the difference in behavior between small changes (when the users resizes the columns slowly and we get small deltas of 1 pixel) and large changes (e.g. when initially resizing the table, or the user moves the mouse quickly) are significant. > > Yes, it would be needed with this algorithm as it is dependent on mouse cursor speed and frame rate as it has no idea of what the initial positions were and how it arrived... Thank you for a detailed write up, @hjohn . One thing to note: the new code is a modification of the earlier work on constrained column resize policies, that logic is unaffected. The only difference is to recognize the fact that in an over-constrained situation sone constraints must be relaxed, and that eliminates multiple passes. Another consideration is that we are not re-writing Tree/TableView skin column resizing code. The fact that the current public APIs do not provide us with the initial condition and instead invoke the policy resize methods giving small deltas is a limitation this PR is not going to address. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622420462 From angorya at openjdk.org Wed Jul 5 20:40:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 20:40:04 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v4] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <0H2UuQQapuIvPTJww95dZSABt3l_9BpEjB8KX2tw-y8=.8e8d5003-798f-47e7-b9ec-c136bd0dca81@github.com> On Wed, 5 Jul 2023 20:31:09 GMT, Michael Strau? wrote: >> 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 ten additional commits since the last revision: >> >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - review comments >> - review comments >> - whitespace >> - removed obsolete tester >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - cleanup >> - new algorithm > > I agree with John that a layout algorithm that uses incremental calculations will always be flawed in principle. The correct approach is to store the initial configuration, and then for each configuration change, go back to the initial configuration and recompute the layout solution. > > Now, we might still accept a bugfix for a flawed algorithm. But JDK-8299753 is an enhancement, not a bugfix. I'm not sure what to make of this: it's obviously a flawed approach, and basing an enhancement on a flawed approach means that someone would have to come back to this issue in the future and solve it correctly. > > I don't think that the issue at hand is so severe that it's a forced move to integrate this interim solution. I respectfully disagree, @mstr2 . This fix is not an interim solution - unlike any theoretical considerations of "flawed approach", in practice this code does work as expected with integer and fractional scales, and, given our situation, it's highly unlikely that any alternative solutions will ever be considered, especially those that would affect existing public APIs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622464854 From mstrauss at openjdk.org Wed Jul 5 20:55:08 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 5 Jul 2023 20:55:08 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - Remove unused code > - Ensure Match doesn't allow modification > - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy > - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 modules/javafx.graphics/src/main/java/com/sun/javafx/css/ImmutablePseudoClassSetsCache.java line 50: > 48: * @throws NullPointerException when {@code pseudoClasses} is {@code null} or contains {@code null}s > 49: */ > 50: public static Set of(Set pseudoClasses) { Usually, a static `of` method returns an instance of the declaring class. Maybe a name like `immutableSetOf` would be better. modules/javafx.graphics/src/main/java/com/sun/javafx/css/ImmutablePseudoClassSetsCache.java line 57: > 55: } > 56: > 57: Set copy = Set.copyOf(pseudoClasses); The set that is returned from this method will probably be passed into the method over and over again. Every time, `CACHE.get(...)` will call `pseudoClasses.hashCode()`, which in turn iterates over all elements to compute the hash code. Have you considered precomputing the hash code of the set, so that this repeated recalculation is not required? While this might seem like a micro-optimization, we are potentially dealing with a method that is called very often. Here is an alternative implementation for an immutable set that precomputes and stores its hash code: final class ImmutableSet extends AbstractSet { private final T[] elements; private final int hashCode; @SuppressWarnings("unchecked") ImmutableSet(Set elements) { this.elements = (T[])elements.toArray(); this.hashCode = elements.hashCode(); } @Override public Object[] toArray() { return elements.clone(); } @Override public Iterator iterator() { return new Iterator<>() { int index; @Override public boolean hasNext() { return index < elements.length; } @Override public T next() { try { return elements[index++]; } catch (ArrayIndexOutOfBoundsException ignored) { throw new NoSuchElementException(); } } }; } @Override public int size() { return elements.length; } @Override public int hashCode() { return hashCode; } } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1253628919 PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1253634604 From mhanl at openjdk.org Wed Jul 5 21:00:06 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 5 Jul 2023 21:00:06 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 20:52:28 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate >> - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Fix another edge case in BitSet equals >> >> When arrays are not the same size, but there are no set bits in the ones >> the other set doesn't have, two bit sets can still be considered equal >> - Take element type into account for BitSet.equals() >> - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray >> >> - Removed faulty toArray implementations in PseudoClassState and >> StyleClassSet >> - Added test that verifies equals/hashCode for PseudoClassState respect >> Set contract now >> - Made getBits package private so it can't be inherited >> - Remove unused code >> - Ensure Match doesn't allow modification >> - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy >> - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/ImmutablePseudoClassSetsCache.java line 57: > >> 55: } >> 56: >> 57: Set copy = Set.copyOf(pseudoClasses); > > The set that is returned from this method will probably be passed into the method over and over again. Every time, `CACHE.get(...)` will call `pseudoClasses.hashCode()`, which in turn iterates over all elements to compute the hash code. Have you considered precomputing the hash code of the set, so that this repeated recalculation is not required? While this might seem like a micro-optimization, we are potentially dealing with a method that is called very often. > > Here is an alternative implementation for an immutable set that precomputes and stores its hash code: > > final class ImmutableSet extends AbstractSet { > private final T[] elements; > private final int hashCode; > > @SuppressWarnings("unchecked") > ImmutableSet(Set elements) { > this.elements = (T[])elements.toArray(); > this.hashCode = elements.hashCode(); > } > > @Override > public Object[] toArray() { > return elements.clone(); > } > > @Override > public Iterator iterator() { > return new Iterator<>() { > int index; > > @Override > public boolean hasNext() { > return index < elements.length; > } > > @Override > public T next() { > try { > return elements[index++]; > } catch (ArrayIndexOutOfBoundsException ignored) { > throw new NoSuchElementException(); > } > } > }; > } > > @Override > public int size() { > return elements.length; > } > > @Override > public int hashCode() { > return hashCode; > } > } we can even consider to calculate it lazily, if we want to take this approach ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1253638535 From angorya at openjdk.org Wed Jul 5 21:16:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jul 2023 21:16:59 GMT Subject: RFR: 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers In-Reply-To: References: Message-ID: <-aa_5n1j0E01_nmK_xKyt9ZP89LDGUg8iE3s6VYhM9w=.e0bf5141-4fc3-400f-ba5d-38eb7ff26583@github.com> On Mon, 3 Jul 2023 10:01:51 GMT, Jose Pereda wrote: > This PR fixes the regression introduced with [JDK-8087673](https://bugs.openjdk.org/browse/JDK-8087673) by only modifying the header's width if it is the last visible column. > > Two tests that fail before the proposed patch and pass after it have been also included. looks good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1166#pullrequestreview-1515380896 From jhendrikx at openjdk.org Wed Jul 5 22:17:06 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 5 Jul 2023 22:17:06 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 20:56:51 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/ImmutablePseudoClassSetsCache.java line 57: >> >>> 55: } >>> 56: >>> 57: Set copy = Set.copyOf(pseudoClasses); >> >> The set that is returned from this method will probably be passed into the method over and over again. Every time, `CACHE.get(...)` will call `pseudoClasses.hashCode()`, which in turn iterates over all elements to compute the hash code. Have you considered precomputing the hash code of the set, so that this repeated recalculation is not required? While this might seem like a micro-optimization, we are potentially dealing with a method that is called very often. >> >> Here is an alternative implementation for an immutable set that precomputes and stores its hash code: >> >> final class ImmutableSet extends AbstractSet { >> private final T[] elements; >> private final int hashCode; >> >> @SuppressWarnings("unchecked") >> ImmutableSet(Set elements) { >> this.elements = (T[])elements.toArray(); >> this.hashCode = elements.hashCode(); >> } >> >> @Override >> public Object[] toArray() { >> return elements.clone(); >> } >> >> @Override >> public Iterator iterator() { >> return new Iterator<>() { >> int index; >> >> @Override >> public boolean hasNext() { >> return index < elements.length; >> } >> >> @Override >> public T next() { >> try { >> return elements[index++]; >> } catch (ArrayIndexOutOfBoundsException ignored) { >> throw new NoSuchElementException(); >> } >> } >> }; >> } >> >> @Override >> public int size() { >> return elements.length; >> } >> >> @Override >> public int hashCode() { >> return hashCode; >> } >> } > > we can even consider to calculate it lazily, if we want to take this approach These sets are still created on demand, just as often as before, the main change is that there will no longer be thousands of exact duplicate sets in memory that can't be shared because they are modifiable. The passed in sets will in 99% of the cases be newly allocated sets outside of our control, allocated just nanoseconds before. The hash code therefore will still need to be computed in almost all cases. These are then compared with the keys in the map, which already have a pre-computed hash code (courtesy of `HashMap`). It would be exceedingly rare (and probably a mistake) to pass in a set that you got from the cache. If you use the cache, you know you have an immutable version, and so can share it freely. Methods that expose these again should be documented that the set is already immutable (see `Match#getPseudoClasses` for example). Aside from loading new style sheets, the code that will be doing the most calls to `ImmutablePseudoClassSetsCache#of` is in the `CssStyleHelper`: PseudoClassState pseudoClassState = new PseudoClassState(); pseudoClassState.addAll(parent.pseudoClassStates); pseudoClassState.retainAll(parent.styleHelper.triggerStates); retainedStates[count++] = ImmutablePseudoClassSetsCache.of(pseudoClassState); As you can see, it constructs a new mutable set, and converts it to an immutable one. We can't avoid its hash code calculation. Also, the returned immutable set is currently a highly optimized implementation from `ImmutableCollections` (although they don't cache the hash code). They for example have memory storage requirements similar to an array, but still offer `O(1)` contains checks thanks to an open addressing hashing scheme that uses probing. Even that barely matters though as most of these sets will contain only a couple of elements (most of them 1, some of them 2, and extremely rarely 3 or more). Still, we'd be trading one optimization for another and a new maintenance burden. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1253708005 From jhendrikx at openjdk.org Wed Jul 5 22:22:07 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 5 Jul 2023 22:22:07 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 20:47:20 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate >> - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Fix another edge case in BitSet equals >> >> When arrays are not the same size, but there are no set bits in the ones >> the other set doesn't have, two bit sets can still be considered equal >> - Take element type into account for BitSet.equals() >> - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray >> >> - Removed faulty toArray implementations in PseudoClassState and >> StyleClassSet >> - Added test that verifies equals/hashCode for PseudoClassState respect >> Set contract now >> - Made getBits package private so it can't be inherited >> - Remove unused code >> - Ensure Match doesn't allow modification >> - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy >> - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/ImmutablePseudoClassSetsCache.java line 50: > >> 48: * @throws NullPointerException when {@code pseudoClasses} is {@code null} or contains {@code null}s >> 49: */ >> 50: public static Set of(Set pseudoClasses) { > > Usually, a static `of` method returns an instance of the declaring class. Maybe a name like `immutableSetOf` would be better. Yeah, you have a point. Or maybe just `get` or `lookup`. With sets it always feels a bit weird as the key is also the value :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1253710540 From mstrauss at openjdk.org Thu Jul 6 00:26:05 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 6 Jul 2023 00:26:05 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v4] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Wed, 5 Jul 2023 20:31:09 GMT, Michael Strau? wrote: >> 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 ten additional commits since the last revision: >> >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - review comments >> - review comments >> - whitespace >> - removed obsolete tester >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - cleanup >> - new algorithm > > I agree with John that a layout algorithm that uses incremental calculations will always be flawed in principle. The correct approach is to store the initial configuration, and then for each configuration change, go back to the initial configuration and recompute the layout solution. > > Now, we might still accept a bugfix for a flawed algorithm. But JDK-8299753 is an enhancement, not a bugfix. I'm not sure what to make of this: it's obviously a flawed approach, and basing an enhancement on a flawed approach means that someone would have to come back to this issue in the future and solve it correctly. > > I don't think that the issue at hand is so severe that it's a forced move to integrate this interim solution. > I respectfully disagree, @mstr2 . > > This fix is not an interim solution - unlike any theoretical considerations of "flawed approach", in practice this code does work as expected with integer and fractional scales, and, given our situation, it's highly unlikely that any alternative solutions will ever be considered, especially those that would affect existing public APIs. It isn't just a theoretical issue. The proposed patch fails to keep the divider precisely at the cursor location, depending on frame rate and mouse movement speed. This is how the behavior manifests on my machine: https://github.com/openjdk/jfx/assets/43553916/79cf04be-bd18-4cfe-9c34-912978ee96ee ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622726851 From mstrauss at openjdk.org Thu Jul 6 00:38:07 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 6 Jul 2023 00:38:07 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 22:14:38 GMT, John Hendrikx wrote: >> we can even consider to calculate it lazily, if we want to take this approach > > These sets are still created on demand, just as often as before, the main change is that there will no longer be thousands of exact duplicate sets in memory that can't be shared because they are modifiable. The passed in sets will in 99% of the cases be newly allocated sets outside of our control, allocated just nanoseconds before. The hash code therefore will still need to be computed in almost all cases. These are then compared with the keys in the map, which already have a pre-computed hash code (courtesy of `HashMap`). > > It would be exceedingly rare (and probably a mistake) to pass in a set that you got from the cache. If you use the cache, you know you have an immutable version, and so can share it freely. Methods that expose these again should be documented that the set is already immutable (see `Match#getPseudoClasses` for example). Aside from loading new style sheets, the code that will be doing the most calls to `ImmutablePseudoClassSetsCache#of` is in the `CssStyleHelper`: > > PseudoClassState pseudoClassState = new PseudoClassState(); > > pseudoClassState.addAll(parent.pseudoClassStates); > pseudoClassState.retainAll(parent.styleHelper.triggerStates); > > retainedStates[count++] = ImmutablePseudoClassSetsCache.of(pseudoClassState); > > As you can see, it constructs a new mutable set, and converts it to an immutable one. We can't avoid its hash code calculation. > > Also, the returned immutable set is currently a highly optimized implementation from `ImmutableCollections` (although they don't cache the hash code). They for example have memory storage requirements similar to an array, but still offer `O(1)` contains checks thanks to an open addressing hashing scheme that uses probing. Even that barely matters though as most of these sets will contain only a couple of elements (most of them 1, some of them 2, and extremely rarely 3 or more). Still, we'd be trading one optimization for another and a new maintenance burden. I see. If the cached sets are not passed into the cache again, it doesn't seem to be all that useful to precompute the hash. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1253789078 From psadhukhan at openjdk.org Thu Jul 6 03:21:19 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 6 Jul 2023 03:21:19 GMT Subject: RFR: 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 19:28:37 GMT, Andy Goryachev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment > > modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingEvents.java line 84: > >> 82: } >> 83: // Fix for RT-15457: we should report mouse buttons for mouse drags >> 84: if (abstractButton == AbstractEvents.MOUSEEVENT_NONE_BUTTON) { > > minor: the placement of the old comment suggests that it applies to like 84 (this change). Perhaps the comment should be moved down to the line 85. ok..done.. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1170#discussion_r1253875203 From psadhukhan at openjdk.org Thu Jul 6 03:21:19 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 6 Jul 2023 03:21:19 GMT Subject: RFR: 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held [v2] In-Reply-To: References: Message-ID: > If an EventHandler or EventFilter for a mouse button is attached to a scene within a JFXPanel and the **primary mouse button** is held, any mouse button click will create an event such that event.getButton().name() wrongly returns PRIMARY, even if the secondary or middle button was clicked. > This is because `SwingEvents.mouseButtonToEmbedMouseButton()` overwrites the button name after checking the modifier value. > For mouse click with primary button `mouseButtonToEmbedMouseButton` is first called with `BUTTON1 `and modifier `BUTTON1_DOWN_MASK `(ie 1024) and then when secondary button(ie right button is clicked) `mouseButtonToEmbedMouseButton` is called with `BUTTON3 `and modifier `BUTTON3_DOWN_MASK | BUTTON1_DOWN_MASK` (ie 5120) > and when secondary button is released, `mouseButtonToEmbedMouseButton` is again called with `BUTTON3 `but with modifier `BUTTON1_DOWN_MASK `(1024) resulting in button being declared PRIMARY. > > Fix is to make sure not to overwrite button name if a button name is already assigned. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1170/files - new: https://git.openjdk.org/jfx/pull/1170/files/f44b7496..f10c3299 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1170&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1170&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1170.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1170/head:pull/1170 PR: https://git.openjdk.org/jfx/pull/1170 From sven.reimers at gmail.com Thu Jul 6 07:50:29 2023 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 6 Jul 2023 10:50:29 +0300 Subject: State of JavaFX Notebook Message-ID: Hi all, Greetings from JCrete, we are having a discussion about Java, Jupyter and JShell which reminded me of the demo of JavaFX Notebook. Can anyone give a short update? Maybe I missed some good news? Thx Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Thu Jul 6 13:17:22 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 6 Jul 2023 13:17:22 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated Message-ID: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. Fix is made to update scales to EmbeddedWindow ------------- Commit messages: - 8274932: Render scales in EmbeddedWindow are not properly updated Changes: https://git.openjdk.org/jfx/pull/1171/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8274932 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From angorya at openjdk.org Thu Jul 6 16:10:07 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Jul 2023 16:10:07 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v4] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <2y6CsiR4R_zKOCJPZIj3y_Os_y9G2ZAnyvDqdaTjgQk=.bc697eae-d52b-4724-9fb6-2a2c027d36ae@github.com> On Thu, 6 Jul 2023 00:23:09 GMT, Michael Strau? wrote: >> I agree with John that a layout algorithm that uses incremental calculations will always be flawed in principle. The correct approach is to store the initial configuration, and then for each configuration change, go back to the initial configuration and recompute the layout solution. >> >> Now, we might still accept a bugfix for a flawed algorithm. But JDK-8299753 is an enhancement, not a bugfix. I'm not sure what to make of this: it's obviously a flawed approach, and basing an enhancement on a flawed approach means that someone would have to come back to this issue in the future and solve it correctly. >> >> I don't think that the issue at hand is so severe that it's a forced move to integrate this interim solution. > >> I respectfully disagree, @mstr2 . >> >> This fix is not an interim solution - unlike any theoretical considerations of "flawed approach", in practice this code does work as expected with integer and fractional scales, and, given our situation, it's highly unlikely that any alternative solutions will ever be considered, especially those that would affect existing public APIs. > > It isn't just a theoretical issue. The proposed patch fails to keep the divider precisely at the cursor location, depending on frame rate and mouse movement speed. This is how the behavior manifests on my machine: > > https://github.com/openjdk/jfx/assets/43553916/79cf04be-bd18-4cfe-9c34-912978ee96ee Thank you for the video, @mstr2 This is an intrinsic problem with the Tree/TableView - you can observe it even with the UNCONSTRAINED_RESIZE_POLICY. You both are right in that it's impossible to fix this without remembering the initial MOUSE_PRESSED position. I wonder if it's possible to fix it without making API changes. However, fixing this is out of scope for this PR. This PR deals with correctly handling of fractional scale (within the constraints of the current resize policy API) and cursor decoupling even when moving very slowly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1623937662 From duke at openjdk.org Thu Jul 6 17:56:09 2023 From: duke at openjdk.org (duke) Date: Thu, 6 Jul 2023 17:56:09 GMT Subject: Withdrawn: JDK-8306490: Fix raw type warnings in graphics In-Reply-To: References: Message-ID: <-qZLXfINBXIbiVs24duH5w65yYe9Ml2aH7lZVoyFBnA=.3bbc4fcd-9f4f-4b99-91ab-a836256703a5@github.com> On Tue, 18 Apr 2023 16:17:52 GMT, John Hendrikx wrote: > Focused only on raw type problems, and removing casts that were no longer needed because of the changes. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1095 From kpk at openjdk.org Fri Jul 7 05:31:17 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 7 Jul 2023 05:31:17 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree Message-ID: In `TreeTableRowSkin`, graphic was not updated along with tree item update. Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. ------------- Commit messages: - Fix TreeTableView graphic property issue Changes: https://git.openjdk.org/jfx/pull/1172/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1172&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285700 Stats: 32 lines in 2 files changed: 31 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1172.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1172/head:pull/1172 PR: https://git.openjdk.org/jfx/pull/1172 From jpereda at openjdk.org Fri Jul 7 12:46:04 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 7 Jul 2023 12:46:04 GMT Subject: Integrated: 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 10:01:51 GMT, Jose Pereda wrote: > This PR fixes the regression introduced with [JDK-8087673](https://bugs.openjdk.org/browse/JDK-8087673) by only modifying the header's width if it is the last visible column. > > Two tests that fail before the proposed patch and pass after it have been also included. This pull request has now been integrated. Changeset: 5aad0406 Author: Jose Pereda URL: https://git.openjdk.org/jfx/commit/5aad0406e5ab18d9da56e8adb4c013b93be1ba3d Stats: 101 lines in 3 files changed: 99 ins; 0 del; 2 mod 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1166 From jhendrikx at openjdk.org Fri Jul 7 13:15:08 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 7 Jul 2023 13:15:08 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Thu, 13 Apr 2023 15:58:32 GMT, Nir Lisker wrote: >> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. >> >> # Behavior >> >> |Listener...|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| >> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| >> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| >> >> ## Nested notifications: >> >> | |ExpressionHelper|ListenerManager| >> |---|---|---| >> |Type|Depth first (call stack increases for each nested level)|(same)| >> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| >> |Vetoing Possible?|No|Yes| >> |Old Value correctness|Only for listeners called before listeners making nested changes|Always| >> >> # Performance >> >> |Listener|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Addition|Array based, append in empty slot, resize as needed|(same)| >> |Removal|Array based, shift array, resize as needed|(same)| >> |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| >> |Removal during notification|As above|Entry is `null`ed| >> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| >> |Notifying Invalidation Listeners|1 ns each|(same)| >> |Notifying Change Listeners|1 ns each (*)|2-3 ns each| >> >> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values >> >> # Memory Use >> >> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. >> >> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| >> |---|---|---|---| >> |No Listeners|none|none|none| >> |Single InvalidationListener|16 bytes overhead|none|none| >> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| >> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| >> >> # About nested changes >> >> Nested changes are simply changes that are made to a property that is currently in the process of notif... > > John and I discussed this off-list. I will write a short review of this change. > > ### Behavior > The solution implements has the following behaviors, which are compared to the current (partially-flawed) ones: > * Listeners are invoked in the order they were registered, with invalidation listeners being invoked before change listeners. This is also the current behavior. The behavior of invoking all listeners according to the order of registrations will be investigated. > * Listeners that are removed during event propagation will be removed immediately, and will not receive the event (if they hadn't already). This differs from the current behavior of removing the listeners only after the event finished (buggy implementation). > * Listeners that are added during event propagation will be effectively added after the event finishes, and will not receive the event during which they were added. This is also the current behavior (buggy implementation). The behavior of adding the listeners immediately, as is done with removal, will be investigated. > * Nested events are invoked "depth-first", meaning that the parent event propagation is halted until the nested event finishes (see below). This differs from the current behavior that takes the "breadth-first" approach - each event finishes before the nested one starts (buggy implementation). > * Nested events are only handled by listeners who received the parent event already so that they can react to the new change. Listeners that did not receive the parent event will only get a single (updated) event so that they don't react to irrelevant values. This allows vetoing, This differs from the current behavior that sends all events to all listeners (buggy implementation). > > ### Examples > Suppose 5 change listeners are registered when an event starts. > **Removal during an event** > > L1 gets the event > L2 gets the event and removes L4 > L3 gets the event and removes L2 (L2 already got the event) > L4 does not get the event (removed by L2) > L5 gets the event > final listeners: L1, L3, L5 > > **Addition during an event** > > L1 gets the event > L2 gets the event and adds L6 > L3-L5 get the event > L6 does not get the event (added by L2) > final listeners: L1 - L6 > > **Nested event** (value change during an event) > > The observable value changes from 0 to 1 > L1 gets 0->1 > L2 gets 0->1 > L3 gets 0->1 and sets the value to 2 (vetoing) > L1-L3 get 1->2 (nested event - listeners can react to the new change) > L4-L5 get 0->2 (parent event continues with the updated value) > > **Recurs... @nlisker I think I addressed all the issues, do you think it can move forward? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1625396623 From angorya at openjdk.org Fri Jul 7 15:55:06 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 15:55:06 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 05:25:34 GMT, Karthik P K wrote: > In `TreeTableRowSkin`, graphic was not updated along with tree item update. > > Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. > > Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. tested using the modified MonkeyTester, works with the fix and fails in the master branch. good job! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1172#pullrequestreview-1519204601 From angorya at openjdk.org Fri Jul 7 16:11:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 16:11:02 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 6 Jul 2023 13:10:44 GMT, Prasanta Sadhukhan wrote: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow @prsadhuk could you update to the latest master branch? I am getting build errors... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625634277 From angorya at openjdk.org Fri Jul 7 16:24:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 16:24:01 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 6 Jul 2023 13:10:44 GMT, Prasanta Sadhukhan wrote: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Testing on Mac with 2 monitors (primary scale=2, secondary scale=1), running the Main class from the ticket. 1. getting exception: Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 at javafx.graphics/com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:293) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:475) at javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:475) at javafx.base/com.sun.javafx.collections.VetoableListDecorator.setAll(VetoableListDecorator.java:116) at javafx.base/com.sun.javafx.collections.VetoableListDecorator.setAll(VetoableListDecorator.java:110) at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.updateChildren(LabeledSkinBase.java:282) at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.lambda$11(LabeledSkinBase.java:219) at javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$1(LambdaMultiplePropertyChangeListenerHandler.java:88) at javafx.base/javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86) at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.base/javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104) at javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:1) at javafx.base/javafx.beans.property.StringProperty.setValue(StringProperty.java:71) at javafx.controls/javafx.scene.control.Labeled.setText(Labeled.java:147) at andy_test/goryachev.apps.EmbeddedFrameBug.updateText(EmbeddedFrameBug.java:86) at andy_test/goryachev.apps.EmbeddedFrameBug.lambda$3(EmbeddedFrameBug.java:69) at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.base/javafx.beans.property.DoublePropertyBase.fireValueChangedEvent(DoublePropertyBase.java:107) at javafx.base/javafx.beans.property.DoublePropertyBase.markInvalid(DoublePropertyBase.java:114) at javafx.base/javafx.beans.property.DoublePropertyBase.set(DoublePropertyBase.java:148) at javafx.graphics/javafx.stage.Window.setRenderScaleX(Window.java:494) at javafx.swing/javafx.embed.swing.JFXPanel.updateComponentSize(JFXPanel.java:640) at javafx.swing/javafx.embed.swing.JFXPanel.addNotify(JFXPanel.java:945) at java.desktop/java.awt.Container.addNotify(Container.java:2804) at java.desktop/javax.swing.JComponent.addNotify(JComponent.java:4846) at java.desktop/java.awt.Container.addNotify(Container.java:2804) at java.desktop/javax.swing.JComponent.addNotify(JComponent.java:4846) at java.desktop/java.awt.Container.addNotify(Container.java:2804) at java.desktop/javax.swing.JComponent.addNotify(JComponent.java:4846) at java.desktop/javax.swing.JRootPane.addNotify(JRootPane.java:721) at java.desktop/java.awt.Container.addNotify(Container.java:2804) at java.desktop/java.awt.Window.addNotify(Window.java:791) at java.desktop/java.awt.Frame.addNotify(Frame.java:495) at java.desktop/java.awt.Window.show(Window.java:1053) at java.desktop/java.awt.Component.show(Component.java:1728) at java.desktop/java.awt.Component.setVisible(Component.java:1675) at java.desktop/java.awt.Window.setVisible(Window.java:1036) at andy_test/goryachev.apps.EmbeddedFrameBug.setFrameVisible(EmbeddedFrameBug.java:51) at andy_test/goryachev.apps.EmbeddedFrameBug.lambda$1(EmbeddedFrameBug.java:45) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) 2. on primary retina monitor, the UI looks good: Screenshot 2023-07-07 at 09 18 05 on the secondary, not so good: ![Screenshot 2023-07-07 at 09 18 01](https://github.com/openjdk/jfx/assets/107069028/abed1cbe-b426-476c-82c5-39f223cde31b) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625650927 From angorya at openjdk.org Fri Jul 7 16:28:03 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 16:28:03 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <5EEN1zva5rD-Y5eaHYeOhVM0y7GiPWg9xN9LtkNkgNQ=.f1b4a74b-ae81-4c02-838d-e536646ba344@github.com> On Thu, 6 Jul 2023 13:10:44 GMT, Prasanta Sadhukhan wrote: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Appearance without the fix on the secondary is almost identical: Screenshot 2023-07-07 at 09 23 48 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625656133 From psadhukhan at openjdk.org Fri Jul 7 16:46:03 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 16:46:03 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 6 Jul 2023 13:10:44 GMT, Prasanta Sadhukhan wrote: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow > Testing on Mac with 2 monitors (primary scale=2, secondary scale=1), running the Main class from the ticket. > > 1. getting exception: > > ``` > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 > at javafx.graphics/com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:293) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:475) > at javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:475) > at javafx.base/com.sun.javafx.collections.VetoableListDecorator.setAll(VetoableListDecorator.java:116) > at javafx.base/com.sun.javafx.collections.VetoableListDecorator.setAll(VetoableListDecorator.java:110) > at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.updateChildren(LabeledSkinBase.java:282) > at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.lambda$11(LabeledSkinBase.java:219) > at javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$1(LambdaMultiplePropertyChangeListenerHandler.java:88) > at javafx.base/javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86) > at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192) > at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at javafx.base/javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104) > at javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111) > at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) > at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:1) > at javafx.base/javafx.beans.property.StringProperty.setValue(StringProperty.java:71) > at javafx.controls/javafx.scene.control.Labeled.setText(Labeled.java:147) > at andy_test/goryachev.apps.EmbeddedFrameBug.updateText(EmbeddedFrameBug.java:86) > at andy_test/goryachev.apps.EmbeddedFrameBug.lambda$3(EmbeddedFrameBug.java:69) > at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192) > at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at javafx.base/javafx.beans.property.DoublePropertyBase.fireValueChangedEvent(DoublePropertyBase.java:107) > at javafx.base/javafx.beans.property.DoublePropertyBase.markInvalid(DoublePropertyBase.java:114) > at javafx.base/javafx.beans.property.DoublePropertyBase.set(DoublePropertyBase.java:148) > at javafx.graphics/javafx.stage.Window.setRenderScaleX(Window.java:494) > at javafx.swing/javafx.embed.swing.JFXPanel.updateComponentSize(JFXPanel.java:640) > at javafx.swing/javafx.embed.swing.JFXPanel.addNotify(JFXPanel.java:945) > at java.desktop/java.awt.Container.addNotify(Container.java:2804) > at java.desktop/javax.swing.JComponent.addNotify(JComponent.java:4846) > at java.desktop/java.awt.Container.addNotify(Container.java:2804) > at java.desktop/javax.swing.JComponent.addNotify(JComponent.java:4846) > at java.desktop/java.awt.Container.addNotify(Container.java:2804) > at java.desktop/javax.swing.JComponent.addNotify(JComponent.java:4846) > at java.desktop/javax.swing.JRootPane.addNotify(JRootPane.java:721) > at java.desktop/java.awt.Container.addNotify(Container.java:2804) > at java.desktop/java.awt.Window.addNotify(Window.java:791) > at java.desktop/java.awt.Frame.addNotify(Frame.java:495) > at java.desktop/java.awt.Window.show(Window.java:1053) > at java.desktop/java.awt.Component.show(Component.java:1728) > at java.desktop/java.awt.Component.setVisible(Component.java:1675) > at java.desktop/java.awt.Window.setVisible(Window.java:1036) > at andy_test/goryachev.apps.EmbeddedFrameBug.setFrameVisible(EmbeddedFrameBug.java:51) > at andy_test/goryachev.apps.EmbeddedFrameBug.lambda$1(EmbeddedFrameBug.java:45) > at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) > at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) > at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) > at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) > ``` > > 2. on primary retina monitor, the UI looks good: > > Screenshot 2023-07-07 at 09 18 05 > on the secondary, not so good: > > ![Screenshot 2023-07-07 at 09 18 01](https://user-images.githubusercontent.com/107069028/251800216-abed1cbe-b426-476c-82c5-39f223cde31b.png) That is tracked on different bugid https://bugs.openjdk.org/browse/JDK-8222209 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625672987 From psadhukhan at openjdk.org Fri Jul 7 16:46:04 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 16:46:04 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Fri, 7 Jul 2023 16:41:09 GMT, Prasanta Sadhukhan wrote: > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 > at javafx.graphics/com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:293) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:475) > at javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:475) > at javafx.base/com.sun.javafx.collections.VetoableListDecorator.setAll(VetoableListDecorator.jav You need to run with this change private static void initAndShowGUI() throws Exception { JFrame frame = new JFrame("Swing and JavaFX"); final JFXPanel fxPanel = new JFXPanel(); frame.add(fxPanel); frame.setSize(300, 200); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); if (!SET_FRAME_VISIBLE_LATE) { setFrameVisible(frame); } Platform.runLater(() -> { try { initFX(fxPanel, frame); } catch (Exception e) {} }); if (SET_FRAME_VISIBLE_LATE) { setFrameVisible(frame); } } private static void initFX(JFXPanel fxPanel, JFrame frame) throws Exception { // This method is invoked on the JavaFX thread Scene scene = createScene(); fxPanel.setScene(scene); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625674962 From psadhukhan at openjdk.org Fri Jul 7 16:49:01 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 16:49:01 GMT Subject: RFR: 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 03:21:19 GMT, Prasanta Sadhukhan wrote: >> If an EventHandler or EventFilter for a mouse button is attached to a scene within a JFXPanel and the **primary mouse button** is held, any mouse button click will create an event such that event.getButton().name() wrongly returns PRIMARY, even if the secondary or middle button was clicked. >> This is because `SwingEvents.mouseButtonToEmbedMouseButton()` overwrites the button name after checking the modifier value. >> For mouse click with primary button `mouseButtonToEmbedMouseButton` is first called with `BUTTON1 `and modifier `BUTTON1_DOWN_MASK `(ie 1024) and then when secondary button(ie right button is clicked) `mouseButtonToEmbedMouseButton` is called with `BUTTON3 `and modifier `BUTTON3_DOWN_MASK | BUTTON1_DOWN_MASK` (ie 5120) >> and when secondary button is released, `mouseButtonToEmbedMouseButton` is again called with `BUTTON3 `but with modifier `BUTTON1_DOWN_MASK `(1024) resulting in button being declared PRIMARY. >> >> Fix is to make sure not to overwrite button name if a button name is already assigned. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment Any further comments on this @andy-goryachev-oracle ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1170#issuecomment-1625678437 From angorya at openjdk.org Fri Jul 7 16:56:05 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 16:56:05 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <-N3gehqqi4hNGy8yEbvmxTMo3C3WewTaJZgJRfijds8=.85616c32-4731-4de3-b876-9db016ee7e4d@github.com> On Fri, 7 Jul 2023 16:42:58 GMT, Prasanta Sadhukhan wrote: > You need to run with this change Does not help. I think the problem is that FX stage is being manipulated from the EDT, see the comment in JFXPanel:607 and the FX stage access on JFXPanel:640. You probably need to wrap the following code in Platform.runLater(), though I can't tell if sendResizeEventToFX(); should be in the EDT or FX app thread: if (stage != null) { stage.setRenderScaleX(scaleFactorX); stage.setRenderScaleY(scaleFactorY); } sendResizeEventToFX(); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625685563 From angorya at openjdk.org Fri Jul 7 17:08:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 17:08:02 GMT Subject: RFR: 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 03:21:19 GMT, Prasanta Sadhukhan wrote: >> If an EventHandler or EventFilter for a mouse button is attached to a scene within a JFXPanel and the **primary mouse button** is held, any mouse button click will create an event such that event.getButton().name() wrongly returns PRIMARY, even if the secondary or middle button was clicked. >> This is because `SwingEvents.mouseButtonToEmbedMouseButton()` overwrites the button name after checking the modifier value. >> For mouse click with primary button `mouseButtonToEmbedMouseButton` is first called with `BUTTON1 `and modifier `BUTTON1_DOWN_MASK `(ie 1024) and then when secondary button(ie right button is clicked) `mouseButtonToEmbedMouseButton` is called with `BUTTON3 `and modifier `BUTTON3_DOWN_MASK | BUTTON1_DOWN_MASK` (ie 5120) >> and when secondary button is released, `mouseButtonToEmbedMouseButton` is again called with `BUTTON3 `but with modifier `BUTTON1_DOWN_MASK `(1024) resulting in button being declared PRIMARY. >> >> Fix is to make sure not to overwrite button name if a button name is already assigned. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment modified the code test thusly: scene.addEventHandler(MouseEvent.MOUSE_CLICKED, event -> System.out.println("Button clicked: " + event.getButton().name())); scene.addEventHandler(MouseEvent.MOUSE_PRESSED, event -> System.out.println("Button pressed: " + event.getButton().name())); scene.addEventHandler(MouseEvent.MOUSE_RELEASED, event -> System.out.println("Button released: " + event.getButton().name())); tested with the fix (works as expected) and without the fix (fails as expected). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1170#pullrequestreview-1519316404 From psadhukhan at openjdk.org Fri Jul 7 17:13:24 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 17:13:24 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v2] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Set stage scale in FX thread - Set stage scale in FX thread ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1171/files - new: https://git.openjdk.org/jfx/pull/1171/files/14610e82..24d9272d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From angorya at openjdk.org Fri Jul 7 17:13:24 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 17:13:24 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v2] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Fri, 7 Jul 2023 17:07:57 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Set stage scale in FX thread > - Set stage scale in FX thread modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 644: > 642: stage.setRenderScaleY(scaleFactorY); > 643: } > 644: }); [question] could there be race condition between sendResizeEventToFX() and stage.setRenderScale() since we now have two different threads operating? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1171#discussion_r1256148933 From psadhukhan at openjdk.org Fri Jul 7 17:18:12 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 17:18:12 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v2] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Fri, 7 Jul 2023 17:07:55 GMT, Andy Goryachev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Set stage scale in FX thread >> - Set stage scale in FX thread > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 644: > >> 642: stage.setRenderScaleY(scaleFactorY); >> 643: } >> 644: }); > > [question] > could there be race condition between sendResizeEventToFX() and stage.setRenderScale() since we now have two different threads operating? I dont think so as we have similar call on FX thread in setScene() without any race issue... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1171#discussion_r1256156012 From psadhukhan at openjdk.org Fri Jul 7 17:18:10 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 17:18:10 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v3] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Set stage scale in FX thread ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1171/files - new: https://git.openjdk.org/jfx/pull/1171/files/24d9272d..3689422d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From angorya at openjdk.org Fri Jul 7 17:49:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 17:49:01 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v3] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <0lFyxH2XxBa8LiMkKR6CcOXalsktoPzwPEgSpJlJVwY=.136f79b7-e9a3-4edc-ae25-90d3d606b52e@github.com> On Fri, 7 Jul 2023 17:18:10 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Set stage scale in FX thread 1. please merge the master branch 2. to avoid [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) condition, I am launching separate windows on all monitors. What I see is that the label text on the secondary monitor is not as smooth (see earlier screenshots), the image appears as a solid black block. Is this expected? 3. one interesting thing I noticed is that the master branch launches two windows and it shows O100% on both (even though the primary scale=2, secondary=1). The fixed branch shows O200% on both (again, that appears to be incorrect). Here is the code: package goryachev.bugs; import java.awt.GraphicsConfiguration; import java.awt.GraphicsDevice; import java.awt.GraphicsEnvironment; import java.awt.Rectangle; import javax.swing.JFrame; import javax.swing.SwingUtilities; import javafx.application.Platform; import javafx.embed.swing.JFXPanel; import javafx.geometry.Insets; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.layout.Background; import javafx.scene.layout.BackgroundFill; import javafx.scene.layout.CornerRadii; import javafx.scene.layout.HBox; import javafx.scene.layout.Region; import javafx.scene.layout.VBox; import javafx.scene.paint.Color; public class EmbeddedFrameBug { private static final boolean SET_FRAME_VISIBLE_LATE = true; private static void initAndShowGUI() //throws Exception { for (GraphicsDevice d: GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices()) { GraphicsConfiguration c = d.getDefaultConfiguration(); Rectangle r = c.getBounds(); JFrame frame = new JFrame("Swing and JavaFX"); final JFXPanel fxPanel = new JFXPanel(); frame.add(fxPanel); frame.setSize(300, 200); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setLocation((int)r.getCenterX(), (int)r.getCenterY()); if (!SET_FRAME_VISIBLE_LATE) { setFrameVisible(frame); } Platform.runLater(() -> { try { initFX(fxPanel, frame); } catch (Exception e) { e.printStackTrace(); } }); if (SET_FRAME_VISIBLE_LATE) { setFrameVisible(frame); } } } private static void initFX(JFXPanel fxPanel, JFrame frame) throws Exception { // This method is invoked on the JavaFX thread Scene scene = createScene(); fxPanel.setScene(scene); } private static void setFrameVisible(JFrame frame) { frame.setVisible(true); } private static Scene createScene() { VBox root = new VBox(); root.setPadding(new Insets(5)); Scene scene = new Scene(root); HBox hBox = new HBox(); hBox.setPrefSize(30, 30); hBox.setMaxWidth(Region.USE_PREF_SIZE); hBox.setBackground(new Background(new BackgroundFill(Color.BLACK, CornerRadii.EMPTY, Insets.EMPTY))); Label label = new Label(); scene.windowProperty().addListener((ob, oldWindow, newWindow) -> { newWindow.renderScaleXProperty().addListener((obs, oldValue, newValue) -> updateText(label, newValue)); updateText(label, newWindow.getRenderScaleX()); }); root.getChildren().addAll(hBox, label); return (scene); } private static void updateText(Label label, Number scaleX) { if (scaleX == null) { label.setText("Unknown scale x"); } else { label.setText("O" + String.format("%.0f%%", scaleX.doubleValue() * 100)); } } public static void main(String[] args) { SwingUtilities.invokeLater(EmbeddedFrameBug::initAndShowGUI); } } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625740460 From psadhukhan at openjdk.org Fri Jul 7 17:56:01 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jul 2023 17:56:01 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v3] In-Reply-To: <0lFyxH2XxBa8LiMkKR6CcOXalsktoPzwPEgSpJlJVwY=.136f79b7-e9a3-4edc-ae25-90d3d606b52e@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> <0lFyxH2XxBa8LiMkKR6CcOXalsktoPzwPEgSpJlJVwY=.136f79b7-e9a3-4edc-ae25-90d3d606b52e@github.com> Message-ID: <4jlWSGRgbvW5NW69p6aHKm37zNJtvqJGQCj_K9y-avk=.1c1d3a6e-1023-4772-a76f-07ffe46d7d3c@github.com> On Fri, 7 Jul 2023 17:46:18 GMT, Andy Goryachev wrote: > 1. please merge the master branch > > 2. to avoid [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) condition, I am launching separate windows on all monitors. What I see is that the label text on the secondary monitor is not as smooth (see earlier screenshots), the image appears as a solid black block. Is this expected? > > 3. one interesting thing I noticed is that the master branch launches two windows and it shows O100% on both (even though the primary scale=2, secondary=1). The fixed branch shows O200% on both (again, that appears to be incorrect). > 2. It is expected as can be seen in JBS " filled rectangular box shows only black pixels" 3. Yes, it should show 200% with this current fix. For JDK-8222209, I have a fix for getting different scales on different monitors so that it will show 200% on primary and 100% in secondary but it does not solve the label blurriness on secondary monitor, so could not raise a PR still. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625752860 From angorya at openjdk.org Fri Jul 7 18:51:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 18:51:59 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v3] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <9X-xHZoluXfHN9dKbaB1uBwCyrL97Y3nD-ScuRPXuVw=.556d02f2-ca20-4d92-929e-3f3573f5022f@github.com> On Fri, 7 Jul 2023 17:18:10 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Set stage scale in FX thread are you saying that it should show 200% even for the window that gets shown on the secondary (scale=1)? even though the test code does listen to the changes on the right scene instance scene.windowProperty().addListener((ob, oldWindow, newWindow) -> { newWindow.renderScaleXProperty().addListener((obs, oldValue, newValue) -> updateText(label, newValue)); updateText(label, newWindow.getRenderScaleX()); }); ? also, the poorly rendered text with the fix - does it mean this PR needs more work? here is the comparison between the master and the fix, using the window that appears on the secondary: ![Screenshot 2023-07-07 at 11 43 49](https://github.com/openjdk/jfx/assets/107069028/8db3f763-810c-4b46-9928-3b0fd3fd78ad) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1625882313 From angorya at openjdk.org Fri Jul 7 19:07:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 19:07:01 GMT Subject: RFR: 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 16:11:16 GMT, Prasanta Sadhukhan wrote: > If the scaleFactors used for the current device are not 1.0, a JXFPanel will send a resize event with 0x0 dimensions to the JavaFX scene which can have undesirable effects, which is because the resize pixel buffer is created even for initial size of 9x0 width,height. > Fix is to make sure to prevent resizing the pixel buffer for initial width/height of 0. modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 631: > 629: if (oldWidth == 0 && oldHeight == 0 && pWidth == 0 && pHeight == 0) { > 630: return; > 631: } this change fixes the issue with the provided test code. a few comments: 1. if I wrap textArea with a BorderPane, I never get width=0 (master branch) 2. would it make sense to add a check to line 611: if((pWidth == 0) && (pHeight == 0))? 3. lines 617, 618 subtract border insets, would that risk making pWidth/pHeight negative (considering code on lines 613, 614)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1168#discussion_r1256330975 From angorya at openjdk.org Fri Jul 7 19:21:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 19:21:01 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments In-Reply-To: References: Message-ID: <0L6Up21bIam1EoMCzlaphesIrRegkOPwPyyEcnPr2P0=.6b8bd8c7-3ca9-4e0c-aa42-6f7cfa8309be@github.com> On Sat, 1 Jul 2023 22:24:09 GMT, Michael Strau? wrote: > DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: > > > ... > String data = uri.substring(dataSeparator + 1); > Charset charset = Charset.defaultCharset(); > ... > URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) > > > This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. > > This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. > > **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 115: > 113: nameValuePairs, > 114: base64, > 115: base64 ? Base64.getDecoder().decode(data) : decodePercentEncoding(data)); I wonder if this is all necessary. The data is supposed to be url-encoded, so it's essentially ASCII, no? passing default charset to getBytes() is not right, it probably should be URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(StandardCharsets.US_ASCII)); or am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1256342382 From angorya at openjdk.org Fri Jul 7 19:21:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 19:21:02 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments In-Reply-To: <0L6Up21bIam1EoMCzlaphesIrRegkOPwPyyEcnPr2P0=.6b8bd8c7-3ca9-4e0c-aa42-6f7cfa8309be@github.com> References: <0L6Up21bIam1EoMCzlaphesIrRegkOPwPyyEcnPr2P0=.6b8bd8c7-3ca9-4e0c-aa42-6f7cfa8309be@github.com> Message-ID: On Fri, 7 Jul 2023 19:16:20 GMT, Andy Goryachev wrote: >> DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: >> >> >> ... >> String data = uri.substring(dataSeparator + 1); >> Charset charset = Charset.defaultCharset(); >> ... >> URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) >> >> >> This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. >> >> This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. >> >> **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. > > modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 115: > >> 113: nameValuePairs, >> 114: base64, >> 115: base64 ? Base64.getDecoder().decode(data) : decodePercentEncoding(data)); > > I wonder if this is all necessary. The data is supposed to be url-encoded, so it's essentially ASCII, no? > > passing default charset to getBytes() is not right, it probably should be > > URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(StandardCharsets.US_ASCII)); > > or am I missing something? >From https://datatracker.ietf.org/doc/html/rfc3986#page-11 Therefore, the Berners-Lee, et al. Standards Track [Page 11] [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) URI Generic Syntax January 2005 integer values used by the ABNF must be mapped back to their corresponding characters via US-ASCII in order to complete the syntax rules. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1256344029 From duke at openjdk.org Fri Jul 7 19:44:11 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 7 Jul 2023 19:44:11 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v9] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 12:18:49 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - JDK-8273485 > Fixing issue caused by wrong merge. > - Merge remote-tracking branch 'origin/master' into JDK-8273485_swing-deadlock > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m > - JDK-8273485 > Added check for null when calling initScreens > - JDK-8273485 > Fixing toggle fullscreen! > - JDK-8273485 > removed the toggle fullscreen before closing - to avoid the beep and improve the user experience > - JDK-8273485 > Fixed Beep sound when closing a fullscreen window > - JDK-8273485 > small cleanup of the changes. > - JDK-8273485 > Removed the enter/leave nested event loop logic, for mac fullscreen > - JDK-8273485 > Added unit-test > - JDK-8273485 > Fixing deadlock when switching to fullscreen, when also swing is used. I took a look at this since I'm trying to better understand the Mac fullscreen code (there's a bunch of cruft I would like to remove). The stack trace in the original bug report confused me. In `WindowStage.setScene` the window be should taken out of fullscreen mode before setScene acquires the renderLock and sets the view to null. Exiting fullscreen is failing because at this point in the close process the stage is hidden and you can't change the fullscreen state of a stage while it's hidden (see `WindowStage.applyFullScreen`). I think it's a bug in the core Java code that you can hide a fullscreen window without having it automatically exit fullscreen. Hiding a fullscreen window doesn't even work on the Mac since the OS just ignores the `orderOut:` call. As an experiment I tweaked the Mac code to exit fullscreen when the window is hidden using exactly the same code as in _setView and it avoided the deadlock state reported in the original bug. I haven't done a full test run with the changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/622#issuecomment-1625983080 From angorya at openjdk.org Fri Jul 7 19:51:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 19:51:12 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v9] In-Reply-To: References: Message-ID: <7wUawBMx6XFv0JSxoGR78cnkmRQvFsPEeLaH1v-7fmg=.bf311eaa-f0db-4b42-872b-bb6fd234bf0b@github.com> On Fri, 7 Jul 2023 19:40:59 GMT, Martin Fox wrote: > As an experiment I tweaked the Mac code to exit fullscreen when the window is hidden using exactly the same code as in _setView and it avoided the deadlock state reported in the original bug. +1 ------------- PR Comment: https://git.openjdk.org/jfx/pull/622#issuecomment-1625989518 From mstrauss at openjdk.org Fri Jul 7 20:25:59 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 7 Jul 2023 20:25:59 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments In-Reply-To: References: <0L6Up21bIam1EoMCzlaphesIrRegkOPwPyyEcnPr2P0=.6b8bd8c7-3ca9-4e0c-aa42-6f7cfa8309be@github.com> Message-ID: On Fri, 7 Jul 2023 19:17:59 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/util/DataURI.java line 115: >> >>> 113: nameValuePairs, >>> 114: base64, >>> 115: base64 ? Base64.getDecoder().decode(data) : decodePercentEncoding(data)); >> >> I wonder if this is all necessary. The data is supposed to be url-encoded, so it's essentially ASCII, no? >> >> passing default charset to getBytes() is not right, it probably should be >> >> URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(StandardCharsets.US_ASCII)); >> >> or am I missing something? > > From https://datatracker.ietf.org/doc/html/rfc3986#page-11 > > > Therefore, the > > > > > > Berners-Lee, et al. Standards Track [Page 11] > > [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) URI Generic Syntax January 2005 > > > integer values used by the ABNF must be mapped back to their > corresponding characters via US-ASCII in order to complete the syntax > rules. > I wonder if this is all necessary. The data is supposed to be url-encoded, so it's essentially ASCII, no? > > passing default charset to getBytes() is not right, it probably should be > > URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(StandardCharsets.US_ASCII)); > > or am I missing something? The payload of a data URI is just a sequence of bytes, not characters. Only when the numeric value of a byte, assuming ASCII encoding, is a *safe URL character*, it is left as-is; otherwise percent-encoding is used to encode the byte value. The [specification](https://datatracker.ietf.org/doc/html/rfc2397) points out: Without ";base64", the data (as a sequence of octets) is represented using ASCII encoding for octets inside the range of safe URL characters and using the standard %xx hex encoding of URLs for octets outside that range. Decoding the payload back to a byte array is done by simply converting each assumed ASCII character to its numeric value, and decoding percent-encoded bytes to their hex value. Note that the assumed ASCII encoding only refers to the URL, but not to the payload. The payload is not a string, and it doesn't contain characters; it's a sequence of bytes. `URLDecoder` is not a general-purpose class to decode a percent-encoded sequence of bytes. It's specifically meant to take a HTML forms string and decode it into a string with some defined charset, using additional rules that don't generally apply to percent-encoded byte sequences. For example, a space character is encoded as `+` (that's where the kind-of-hacky `data.replace("+", "%2B")` comes from). Using `URLDecoder` kind of works (if we use a sufficiently rich charset for both `URLDecoder.decode` and `String.getBytes`), but only by accident. While it accepts almost any percent-encoded data, the Javadoc for `URLDecoder` says: There are two possible ways in which this decoder could deal with illegal strings. It could either leave illegal characters alone or it could throw an IllegalArgumentException. Which approach the decoder takes is left to the implementation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1256426290 From angorya at openjdk.org Fri Jul 7 20:50:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 20:50:59 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments In-Reply-To: References: <0L6Up21bIam1EoMCzlaphesIrRegkOPwPyyEcnPr2P0=.6b8bd8c7-3ca9-4e0c-aa42-6f7cfa8309be@github.com> Message-ID: On Fri, 7 Jul 2023 20:23:17 GMT, Michael Strau? wrote: >> From https://datatracker.ietf.org/doc/html/rfc3986#page-11 >> >> >> Therefore, the >> >> >> >> >> >> Berners-Lee, et al. Standards Track [Page 11] >> >> [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) URI Generic Syntax January 2005 >> >> >> integer values used by the ABNF must be mapped back to their >> corresponding characters via US-ASCII in order to complete the syntax >> rules. > >> I wonder if this is all necessary. The data is supposed to be url-encoded, so it's essentially ASCII, no? >> >> passing default charset to getBytes() is not right, it probably should be >> >> URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(StandardCharsets.US_ASCII)); >> >> or am I missing something? > > The payload of a data URI is just a sequence of bytes, not characters. Only when the numeric value of a byte, assuming ASCII encoding, is a *safe URL character*, it is left as-is; otherwise percent-encoding is used to encode the byte value. The [specification](https://datatracker.ietf.org/doc/html/rfc2397) points out: > > Without ";base64", the data (as a sequence of octets) is represented using > ASCII encoding for octets inside the range of safe URL characters and using > the standard %xx hex encoding of URLs for octets outside that range. > > > Decoding the payload back to a byte array is done by simply converting each assumed ASCII character to its numeric value, and decoding percent-encoded bytes to their hex value. Note that the assumed ASCII encoding only refers to the URL, but not to the payload. The payload is not a string, and it doesn't contain characters; it's a sequence of bytes. > > `URLDecoder` is not a general-purpose class to decode a percent-encoded sequence of bytes. It's specifically meant to take a HTML forms string and decode it into a string with some defined charset, using additional rules that don't generally apply to percent-encoded byte sequences. For example, a space character is encoded as `+` (that's where the kind-of-hacky `data.replace("+", "%2B")` comes from). > > Using `URLDecoder` kind of works (if we use a sufficiently rich charset for both `URLDecoder.decode` and `String.getBytes`), but only by accident. While it accepts almost any percent-encoded data, the Javadoc for `URLDecoder` says: > > There are two possible ways in which this decoder could deal with illegal strings. > It could either leave illegal characters alone or it could throw an IllegalArgumentException. > Which approach the decoder takes is left to the implementation. thank you for clarifications! your approach does make sense. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1256454118 From angorya at openjdk.org Fri Jul 7 20:51:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Jul 2023 20:51:02 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments In-Reply-To: References: Message-ID: <-4GuFGUTCOkuSrgaRWB8_bQTveDiVkc4Qr-_U13nNGc=.0fa84d30-df81-4a10-bd11-e046c13cc78d@github.com> On Sat, 1 Jul 2023 22:24:09 GMT, Michael Strau? wrote: > DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: > > > ... > String data = uri.substring(dataSeparator + 1); > Charset charset = Charset.defaultCharset(); > ... > URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) > > > This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. > > This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. > > **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. modules/javafx.graphics/src/test/java/test/com/sun/javafx/util/DataURITest.java line 183: > 181: // We use URLEncoder here to escape the emoji character using percent-encoding. > 182: // When DataURI parses its payload, it automatically converts percent-encoded characters back to octets. > 183: String input = URLEncoder.encode("?", StandardCharsets.UTF_8); would it make sense to try several different strings that include +, \n, \t, data:, charset:, %, empty string, &, _, %zz? modules/javafx.graphics/src/test/java/test/com/sun/javafx/util/DataURITest.java line 203: > 201: > 202: ex = assertThrows(IllegalArgumentException.class, () -> DataURI.tryParse("data:,%0")); > 203: assertTrue(ex.getMessage().startsWith("Incomplete")); "%", "", null ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1256453599 PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1256455821 From mhanl at openjdk.org Sat Jul 8 10:17:58 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 8 Jul 2023 10:17:58 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 05:25:34 GMT, Karthik P K wrote: > In `TreeTableRowSkin`, graphic was not updated along with tree item update. > > Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. > > Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. Is it possible to write a Unit test as well? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1627059129 From mstrauss at openjdk.org Sat Jul 8 23:38:05 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 8 Jul 2023 23:38:05 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments [v2] In-Reply-To: References: Message-ID: > DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: > > > ... > String data = uri.substring(dataSeparator + 1); > Charset charset = Charset.defaultCharset(); > ... > URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) > > > This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. > > This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. > > **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added more tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1165/files - new: https://git.openjdk.org/jfx/pull/1165/files/9065941c..e13dfe43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1165&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1165&range=00-01 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1165.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1165/head:pull/1165 PR: https://git.openjdk.org/jfx/pull/1165 From mstrauss at openjdk.org Sat Jul 8 23:38:06 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 8 Jul 2023 23:38:06 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments [v2] In-Reply-To: <-4GuFGUTCOkuSrgaRWB8_bQTveDiVkc4Qr-_U13nNGc=.0fa84d30-df81-4a10-bd11-e046c13cc78d@github.com> References: <-4GuFGUTCOkuSrgaRWB8_bQTveDiVkc4Qr-_U13nNGc=.0fa84d30-df81-4a10-bd11-e046c13cc78d@github.com> Message-ID: On Fri, 7 Jul 2023 20:45:59 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> added more tests > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/util/DataURITest.java line 183: > >> 181: // We use URLEncoder here to escape the emoji character using percent-encoding. >> 182: // When DataURI parses its payload, it automatically converts percent-encoded characters back to octets. >> 183: String input = URLEncoder.encode("?", StandardCharsets.UTF_8); > > would it make sense to try several different strings that include +, \n, \t, data:, charset:, %, empty string, &, _, %zz? Most of these cases should already be covered by existing tests (`testMissingDataSeparatorIsInvalid`, `testParametersListWithoutKeyValuePairsIsInvalid`, `testLeadingOrTrailingWhitespaceIsAcceptable`). > modules/javafx.graphics/src/test/java/test/com/sun/javafx/util/DataURITest.java line 203: > >> 201: >> 202: ex = assertThrows(IllegalArgumentException.class, () -> DataURI.tryParse("data:,%0")); >> 203: assertTrue(ex.getMessage().startsWith("Incomplete")); > > "%", "", null ? I've added tests for these inputs. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1257386139 PR Review Comment: https://git.openjdk.org/jfx/pull/1165#discussion_r1257385872 From jvos at openjdk.org Sun Jul 9 08:02:02 2023 From: jvos at openjdk.org (Johan Vos) Date: Sun, 9 Jul 2023 08:02:02 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Sat, 8 Jul 2023 10:15:47 GMT, Marius Hanl wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Is it possible to write a Unit test as well? +1 on @Maran23 to add a unit test. For these kinds of changes, I think it is important to have a performance check as well (e.g. count the number of invocations to updateItem etc). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1627640393 From jvos at openjdk.org Sun Jul 9 08:50:08 2023 From: jvos at openjdk.org (Johan Vos) Date: Sun, 9 Jul 2023 08:50:08 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: <0lA8dgL4uhIpq83cH53hvMgpk8J1zf0Q8umEzfUhXdM=.28c265a6-8e2d-49f0-a5be-ceba81a4c977@github.com> On Sun, 2 Jul 2023 11:46:19 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add newline at end of ConditionalBinding file I believe this is a valuable addition that will take away one of the major pain points for developers (having to keep a reference to the passed lambda, as explained in the JBS issue). I did read the comments and discussion, and it seems everything is addressed. I don't have naming preferences, so I'm fine with the suggested ones. I looked at the code and ran the tests, all good. I don't see performance implications in existing code, and I didn't spot potential performance issues using the subscription-based approach. I believe this change will lead to questions about "best patterns" from developers. I don't think we need lots of discussion about this in the code/javadoc, although some components in the OpenJFX codebase do so. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1069#issuecomment-1627651103 From tsayao at openjdk.org Sun Jul 9 17:47:58 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 9 Jul 2023 17:47:58 GMT Subject: RFR: 8251240: Menus inaccessible on Linux with i3 wm Message-ID: The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. Te fix replaces the usage of the function for already known extents value calculation. ------------- Commit messages: - Merge branch 'master' into fix_menu_i3_wm - Fix menu position on i3 wm Changes: https://git.openjdk.org/jfx/pull/1173/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8251240 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1173.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1173/head:pull/1173 PR: https://git.openjdk.org/jfx/pull/1173 From jpereda at openjdk.org Sun Jul 9 19:20:08 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 9 Jul 2023 19:20:08 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 2 Jul 2023 11:46:19 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add newline at end of ConditionalBinding file modules/javafx.base/src/main/java/javafx/beans/Observable.java line 110: > 108: default Subscription subscribe(Runnable subscriber) { > 109: Objects.requireNonNull(subscriber, "subscriber cannot be null"); > 110: InvalidationListener listener = obs -> subscriber.run(); InvalidationListeners are widely used in this pattern: javaFXProperty.addListener(new InvalidationListener() { @Override public void invalidated(Observable observable) { if (value.get() != null) { // do something javaFXProperty.removeListener(this); } } }); Does subscribe/unsubscribe allows something like this? modules/javafx.base/src/main/java/javafx/beans/Observable.java line 110: > 108: default Subscription subscribe(Runnable subscriber) { > 109: Objects.requireNonNull(subscriber, "subscriber cannot be null"); > 110: InvalidationListener listener = obs -> subscriber.run(); In the `subscribe` implementations, Invalidation/ChangeListeners are added as local variables. Have you run any test to check that they don't end up being gc'ed, because no strong references being held? And also related to this, how would you add a WeakInvalidation/WeakChangeListener? Maybe, that's up to the developer, overriding the default implementation of `subscribe`? modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 77: > 75: */ > 76: default Subscription and(Subscription other) { > 77: Objects.requireNonNull(other, "other cannot be null"); As per javadoc, this equivalent to `Subscription.combine(this, other)`, so then, couldn't you just call it instead of doing a different implementation? modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 345: > 343: ChangeListener listener = (obs, old, current) -> subscriber.accept(current); > 344: > 345: subscriber.accept(getValue()); // eagerly send current value What is the reason of this logic being done only for the Consumer and not for the BiConsumer (or the Runnable for that matter)? modules/javafx.base/src/test/java/test/javafx/beans/ObservableSubscriptionsTest.java line 57: > 55: value.set("B"); > 56: > 57: assertEquals(1, calls.get()); I'd add a comment here about: this works as long as `value` doesn't get validated again, i.e with a call to `value.get()`. (Imagine that someone is running tests and wants to add a printout of `value`...) modules/javafx.base/src/test/java/test/javafx/beans/ObservableSubscriptionsTest.java line 58: > 56: > 57: assertEquals(1, calls.get()); > 58: } Maybe you could also extend this test to show how `unsubscribe` works modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueSubscriptionsTest.java line 97: > 95: > 96: assertNull(lastCall.get()); > 97: } Can you add a test where you subscribe using a Runnable (therefore adding an InvalidationListener) and with a Consumer o BiConsumer (adding a ChangeListener)? Also unsubscribing them separately. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257526387 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257526612 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257529022 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257521581 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257521933 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257522153 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257523574 From mstrauss at openjdk.org Sun Jul 9 19:37:07 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 9 Jul 2023 19:37:07 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 18:07:33 GMT, Jose Pereda wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add newline at end of ConditionalBinding file > > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 345: > >> 343: ChangeListener listener = (obs, old, current) -> subscriber.accept(current); >> 344: >> 345: subscriber.accept(getValue()); // eagerly send current value > > What is the reason of this logic being done only for the Consumer and not for the BiConsumer (or the Runnable for that matter)? There doesn't seem to be a way to do the same for the other overloads: * The `Runnable` overload is specified to be invoked _when the value becomes invalid_, which isn't happening when a subscription is added. Eagerly invoking the runnable without a valid->invalid transition does not conform to the specification of an invalidation listener. * The `BiConsumer` overload accepts two values: the old value and the new value. But we don't know the old value, we only know the current value. Using the current value as both old and new value does not conform to the specification of a change listener. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257531578 From jpereda at openjdk.org Sun Jul 9 20:08:57 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 9 Jul 2023 20:08:57 GMT Subject: RFR: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 17:43:05 GMT, Thiago Milczarek Sayao wrote: > The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. > > Te fix replaces the usage of the function for already known extents value calculation. Looks good to me! Tested on Ubuntu and Ubuntu with i3 window manager. Passes on the latter after this patch, and fails before it. ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1173#pullrequestreview-1520952236 From mstrauss at openjdk.org Sun Jul 9 20:14:04 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 9 Jul 2023 20:14:04 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: <5bcAnpoDU_i1tDcSfDFJ9BCiGdtrkB8ksWbIP-o3gqY=.cad9a29c-c42a-49a8-9a89-75b2075484a2@github.com> On Sun, 2 Jul 2023 11:46:19 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add newline at end of ConditionalBinding file modules/javafx.base/src/main/java/javafx/beans/Observable.java line 99: > 97: /** > 98: * Creates a {@link Subscription} on this value which calls the given > 99: * {@code runnable} whenever it becomes invalid. I think the documentation for these new methods should go into more detail and clearly explain the semantics. These are fundamental concepts, and I think it's a good idea to err on the side of over-explaining. Here's a suggestion: Creates a {@code Subscription} for invalidation events of this {@code Observable}.

The specified {@code runnable} will be invoked when the {@code Observable} transitions to the invalid state. This happens when the observed value is changed, usually by calling the {@link ObservableValue#setValue} method. Note that the specified {@code runnable} will not be invoked for subsequent value changes unless the {@code Observable} has transitioned to the valid state again, usually by invoking the {@link ObservableValue#getValue} method.

An {@code Observable} is automatically validated on every change when a {@link ChangeListener} or a {@link Consumer} or {@link BiConsumer} subscription is added. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257535676 From jhendrikx at openjdk.org Sun Jul 9 20:28:01 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 9 Jul 2023 20:28:01 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: <10x6cdi03UjgPPhjT3kiLLdkJKciLvEwKcJj79vkHXI=.0f6407cf-220e-4986-8a9c-76624e03b672@github.com> On Sun, 9 Jul 2023 19:34:23 GMT, Michael Strau? wrote: >> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 345: >> >>> 343: ChangeListener listener = (obs, old, current) -> subscriber.accept(current); >>> 344: >>> 345: subscriber.accept(getValue()); // eagerly send current value >> >> What is the reason of this logic being done only for the Consumer and not for the BiConsumer (or the Runnable for that matter)? > > There doesn't seem to be a way to do the same for the other overloads: > * The `Runnable` overload is specified to be invoked _when the value becomes invalid_, which isn't happening when a subscription is added. Eagerly invoking the runnable without a valid->invalid transition does not conform to the specification of an invalidation listener. > * The `BiConsumer` overload accepts two values: the old value and the new value. But we don't know the old value, we only know the current value. Using the current value as both old and new value does not conform to the specification of a change listener. The reasoning is that this would be the most logical and convenient way for these subscriptions to work. I think mstr2 said it well, but I'll run them down as well: Invalidation subscribers are called when the property actually becomes invalid; since it may currently be valid, calling the subscriber immediately would send the wrong signal. A case could be made to call the subscriber immediately if it is currently invalid, but I think whatever we choose here, it should work the same way as the current `addListener(InvalidationListener)` -- I'm pretty sure this one doesn't call the listener immediately when the property is currently invalid (this is something of a gotcha as well for beginning users of `InvalidationListener`s). Change subscribers require the old value; this is only temporarily available when there's an actual change in the property. Old values are not cached, and can't be cached as this may prevent garbage collection of whatever the old value references. The value listeners are a new breed, and specifically set up for convenient use. They're also the only ones that can send a sensible initial value, and since I'm pretty sure that's almost always what you'd want, this is the default for this type of subscription. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257536996 From jhendrikx at openjdk.org Sun Jul 9 20:40:08 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 9 Jul 2023 20:40:08 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 18:48:16 GMT, Jose Pereda wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add newline at end of ConditionalBinding file > > modules/javafx.base/src/main/java/javafx/beans/Observable.java line 110: > >> 108: default Subscription subscribe(Runnable subscriber) { >> 109: Objects.requireNonNull(subscriber, "subscriber cannot be null"); >> 110: InvalidationListener listener = obs -> subscriber.run(); > > InvalidationListeners are widely used in this pattern: > > > javaFXProperty.addListener(new InvalidationListener() { > @Override > public void invalidated(Observable observable) { > if (value.get() != null) { > // do something > javaFXProperty.removeListener(this); > } > } > }); > > > Does subscribe/unsubscribe allows something like this? The new `subscribe` methods don't support this usage, but they're also not intended to replace the old methods. Cases like the one you show above, but also cases where a single listener is registered on many properties still are best handled using the `addListener`/`removeListener` methods. I consider them more advanced usage which you are more likely to encounter in the internals of JavaFX or libraries. I don't see this pattern that often though, but I know it exists as removing listeners during notification is something that `ExpressionHelper` specifically needs to deal with (also see https://github.com/openjdk/jfx/pull/1081 where I'm advocating for a better `ExpressionHelper` that provides correct old values when dealing with nested notifications and listener list changes). I suppose you could still do this in a hacky way: private Subscription subscription; { subscription = property.subscribe(() -> { if (condition) { this.subscription.unsubscribe(); } }); } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257538675 From jhendrikx at openjdk.org Sun Jul 9 20:59:01 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 9 Jul 2023 20:59:01 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 18:50:34 GMT, Jose Pereda wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add newline at end of ConditionalBinding file > > modules/javafx.base/src/main/java/javafx/beans/Observable.java line 110: > >> 108: default Subscription subscribe(Runnable subscriber) { >> 109: Objects.requireNonNull(subscriber, "subscriber cannot be null"); >> 110: InvalidationListener listener = obs -> subscriber.run(); > > In the `subscribe` implementations, Invalidation/ChangeListeners are added as local variables. Have you run any test to check that they don't end up being gc'ed, because no strong references being held? > > And also related to this, how would you add a WeakInvalidation/WeakChangeListener? Maybe, that's up to the developer, overriding the default implementation of `subscribe`? There is no need, the returned `Subscription` is implemented using a lambda that captures the listener (as it needs it to call `removeListener`). As long as you have the `Subscription` referenced, it can't get GC'd. If you let the `Subscription` get GC'd, then you'd lose your means to unsubscribe the listener, just like if you lost the reference to the listener itself, you would never be able to remove it anymore. Weak listeners I would not recommend to use in new code if you can avoid it. They're unpredictable as to when they're removed exactly, and can still receive notifications when your application may be in a state where you don't expect them anymore. The `Subscription` interface is in fact intended to make management of listeners easier so you can rely less on weak listeners. One pattern I can really recommend to use is to automatically disable listeners when the UI they belong with becomes invisible, for example: private Subscription subscription = Subscription.EMPTY; node.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .subscribe(visible -> { if (visible) { subscription = Subscription.combine( // create subscriptions (to external resources) here as we just became visible! ); } else { // we became invisible, remove listeners (from external resources) to remove hard references that // may keep the UI referenced; the other branch will restore them if the UI becomes visible again subscription.unsubscribe(); // unsubscribes everything in one go } }); Or you can use `ObservableValue#when` to do something similar, not requiring subscriptions. I suspect it may also prove a useful pattern for `Skin`s that have a specific lifecycle. They can register listeners (and combine in a single subscription) in their constructor / initializer, and remove them all in their `dispose` method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257540910 From jhendrikx at openjdk.org Sun Jul 9 21:20:05 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 9 Jul 2023 21:20:05 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 19:12:24 GMT, Jose Pereda wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add newline at end of ConditionalBinding file > > modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 77: > >> 75: */ >> 76: default Subscription and(Subscription other) { >> 77: Objects.requireNonNull(other, "other cannot be null"); > > As per javadoc, this equivalent to `Subscription.combine(this, other)`, so then, couldn't you just call it instead of doing a different implementation? I didn't quite see your point immediately, I thought you meant we don't need this method, but you meant why not do: default Subscription and(Subscription other) { return Subscription.combine(this, other); } I agree this would work, and I don't mind it either way, but calling `combine` does incur a bit more overhead (when called with only a list of 2). The reason I think `and` is a bit more efficient this way is that I think two variable captures vs a `List` with 2 elements will be slightly more efficient. Not that I thought about it that long when implementing it, I just wanted to avoid creating the varargs array, and then the `List` if it isn't strictly needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257543221 From jhendrikx at openjdk.org Sun Jul 9 21:23:05 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 9 Jul 2023 21:23:05 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: <5bcAnpoDU_i1tDcSfDFJ9BCiGdtrkB8ksWbIP-o3gqY=.cad9a29c-c42a-49a8-9a89-75b2075484a2@github.com> References: <5bcAnpoDU_i1tDcSfDFJ9BCiGdtrkB8ksWbIP-o3gqY=.cad9a29c-c42a-49a8-9a89-75b2075484a2@github.com> Message-ID: On Sun, 9 Jul 2023 20:11:06 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add newline at end of ConditionalBinding file > > modules/javafx.base/src/main/java/javafx/beans/Observable.java line 99: > >> 97: /** >> 98: * Creates a {@link Subscription} on this value which calls the given >> 99: * {@code runnable} whenever it becomes invalid. > > I think the documentation for these new methods should go into more detail and clearly explain the semantics. These are fundamental concepts, and I think it's a good idea to err on the side of over-explaining. Here's a suggestion: > > > Creates a {@code Subscription} for invalidation events of this {@code Observable}. >

> The specified {@code runnable} will be invoked when the {@code Observable} transitions to the > invalid state. This happens when the observed value is changed, usually by calling > the {@link ObservableValue#setValue} method. Note that the specified {@code runnable} will not > be invoked for subsequent value changes unless the {@code Observable} has transitioned to the > valid state again, usually by invoking the {@link ObservableValue#getValue} method. >

> An {@code Observable} is automatically validated on every change when a {@link ChangeListener} > or a {@link Consumer} or {@link BiConsumer} subscription is added. Sure, that's a good suggestion, I may have been overly brief to avoid repeating what is known for invalidation listeners, but as this method does not mention invalidation listeners (and only uses them internally for now) a full explanation would be good to add. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257543571 From jhendrikx at openjdk.org Sun Jul 9 21:27:05 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 9 Jul 2023 21:27:05 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 18:10:05 GMT, Jose Pereda wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add newline at end of ConditionalBinding file > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableSubscriptionsTest.java line 57: > >> 55: value.set("B"); >> 56: >> 57: assertEquals(1, calls.get()); > > I'd add a comment here about: this works as long as `value` doesn't get validated again, i.e with a call to `value.get()`. (Imagine that someone is running tests and wants to add a printout of `value`...) Yeah, the invalidation mechanism is sometimes tricky to test as observing the property will alter the results :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257544069 From mstrauss at openjdk.org Sun Jul 9 21:32:01 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 9 Jul 2023 21:32:01 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: <5bcAnpoDU_i1tDcSfDFJ9BCiGdtrkB8ksWbIP-o3gqY=.cad9a29c-c42a-49a8-9a89-75b2075484a2@github.com> Message-ID: On Sun, 9 Jul 2023 21:20:02 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/Observable.java line 99: >> >>> 97: /** >>> 98: * Creates a {@link Subscription} on this value which calls the given >>> 99: * {@code runnable} whenever it becomes invalid. >> >> I think the documentation for these new methods should go into more detail and clearly explain the semantics. These are fundamental concepts, and I think it's a good idea to err on the side of over-explaining. Here's a suggestion: >> >> >> Creates a {@code Subscription} for invalidation events of this {@code Observable}. >>

>> The specified {@code runnable} will be invoked when the {@code Observable} transitions to the >> invalid state. This happens when the observed value is changed, usually by calling >> the {@link ObservableValue#setValue} method. Note that the specified {@code runnable} will not >> be invoked for subsequent value changes unless the {@code Observable} has transitioned to the >> valid state again, usually by invoking the {@link ObservableValue#getValue} method. >>

>> An {@code Observable} is automatically validated on every change when a {@link ChangeListener} >> or a {@link Consumer} or {@link BiConsumer} subscription is added. > > Sure, that's a good suggestion, I may have been overly brief to avoid repeating what is known for invalidation listeners, but as this method does not mention invalidation listeners (and only uses them internally for now) a full explanation would be good to add. Another option would be to refer to the documentation for `InvalidationListener` or `Observable.addListener(InvalidationListener)`, both of which could be improved a bit in a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257544619 From jpereda at openjdk.org Sun Jul 9 22:59:59 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 9 Jul 2023 22:59:59 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: <10x6cdi03UjgPPhjT3kiLLdkJKciLvEwKcJj79vkHXI=.0f6407cf-220e-4986-8a9c-76624e03b672@github.com> References: <10x6cdi03UjgPPhjT3kiLLdkJKciLvEwKcJj79vkHXI=.0f6407cf-220e-4986-8a9c-76624e03b672@github.com> Message-ID: On Sun, 9 Jul 2023 20:24:09 GMT, John Hendrikx wrote: >> There doesn't seem to be a way to do the same for the other overloads: >> * The `Runnable` overload is specified to be invoked _when the value becomes invalid_, which isn't happening when a subscription is added. Eagerly invoking the runnable without a valid->invalid transition does not conform to the specification of an invalidation listener. >> * The `BiConsumer` overload accepts two values: the old value and the new value. But we don't know the old value, we only know the current value. Using the current value as both old and new value does not conform to the specification of a change listener. > > The reasoning is that this would be the most logical and convenient way for these subscriptions to work. I think mstr2 said it well, but I'll run them down as well: > > Invalidation subscribers are called when the property actually becomes invalid; since it may currently be valid, calling the subscriber immediately would send the wrong signal. A case could be made to call the subscriber immediately if it is currently invalid, but I think whatever we choose here, it should work the same way as the current `addListener(InvalidationListener)` -- I'm pretty sure this one doesn't call the listener immediately when the property is currently invalid (this is something of a gotcha as well for beginning users of `InvalidationListener`s). > > Change subscribers require the old value; this is only temporarily available when there's an actual change in the property. Old values are not cached, and can't be cached as this may prevent garbage collection of whatever the old value references. > > The value listeners are a new breed, and specifically set up for convenient use. They're also the only ones that can send a sensible initial value, and since I'm pretty sure that's almost always what you'd want, this is the default for this type of subscription. Okay, that makes sense for the InvalidationListener. However, for the ChangeListener, as I see it, this PR gives two options, over the same listener: you can care only about the newValue, or you can care about both oldValue and newValue, both from the observableValue. These are then passed to the consumer/biConsumer that defines the ChangeListener, but I don't see any reason why this consumer/biconsumer needs to get initialized with any value at all, does it? Only bindings apply the initial value: when you bind two properties (unidirectionally), one property will get any future values of the other, starting from the initial value. But I don't see that happening to changeListeners: when you add a changeListener to a property, I don't see the action being invoked with the current value of the property at that moment, only when the property does change from the current value. In fact, if you run this test: private final StringProperty value = new SimpleStringProperty("Initial"); @Test void subscribeConsumerShouldCallSubscriberImmediatelyAndAfterEachChange() { value.addListener((obs, ov, nv) -> System.out.println("changeListener, nv: " + nv)); value.subscribe(nv -> System.out.println("consumer, nv = " + nv)); value.subscribe((ov, nv) -> System.out.println("biconsumer, nv = " + nv)); value.set("A"); } you'll get: consumer, nv = Initial changeListener, nv: A consumer, nv = A biconsumer, nv = A It feels wrong to see the first printout to me. My point is that I don't see why we need to call the consumer at all before there is any actual change in the property. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257562515 From jpereda at openjdk.org Sun Jul 9 23:09:00 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 9 Jul 2023 23:09:00 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 20:56:06 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/Observable.java line 110: >> >>> 108: default Subscription subscribe(Runnable subscriber) { >>> 109: Objects.requireNonNull(subscriber, "subscriber cannot be null"); >>> 110: InvalidationListener listener = obs -> subscriber.run(); >> >> In the `subscribe` implementations, Invalidation/ChangeListeners are added as local variables. Have you run any test to check that they don't end up being gc'ed, because no strong references being held? >> >> And also related to this, how would you add a WeakInvalidation/WeakChangeListener? Maybe, that's up to the developer, overriding the default implementation of `subscribe`? > > There is no need, the returned `Subscription` is implemented using a lambda that captures the listener (as it needs it to call `removeListener`). As long as you have the `Subscription` referenced, it can't get GC'd. If you let the `Subscription` get GC'd, then you'd lose your means to unsubscribe the listener, just like if you lost the reference to the listener itself, you would never be able to remove it anymore. > > Weak listeners I would not recommend to use in new code if you can avoid it. They're unpredictable as to when they're removed exactly, and can still receive notifications when your application may be in a state where you don't expect them anymore. > > The `Subscription` interface is in fact intended to make management of listeners easier so you can rely less on weak listeners. One pattern I can really recommend to use is to automatically disable listeners when the UI they belong with becomes invisible, for example: > > private Subscription subscription = Subscription.EMPTY; > > node.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .subscribe(visible -> { > if (visible) { > subscription = Subscription.combine( > // create subscriptions (to external resources) here as we just became visible! > ); > } > else { > // we became invisible, remove listeners (from external resources) to remove hard references that > // may keep the UI referenced; the other branch will restore them if the UI becomes visible again > subscription.unsubscribe(); // unsubscribes everything in one go > } > }); > > Or you can use `ObservableValue#when` to do something similar, not requiring subscriptions. > > I suspect it may also prove a useful pattern for `Skin`s that have a specific lifecycle. They can register listeners (and combine in a single subscription) in their constructor / initializer, and remove them all in their `dispose` method. That looks good, but it is also a point for the pattern I described earlier: `node.sceneProperty()` (and also `node.skinProperty()`, since you mentioned it too), are two very good examples of properties that often return null values, so your pattern will need to include at list a filter to make sure scene is not null, but it would be great if it could use something like a `when` there: node.sceneProperty().when(node.getScene() != null).flatMap... (pretty much like this hidden gem in com.sun.javafx.scene.control.skin.Utils::executeOnceWhenPropertyIsNonNull) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257563777 From jpereda at openjdk.org Sun Jul 9 23:16:03 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 9 Jul 2023 23:16:03 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 20:56:06 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/Observable.java line 110: >> >>> 108: default Subscription subscribe(Runnable subscriber) { >>> 109: Objects.requireNonNull(subscriber, "subscriber cannot be null"); >>> 110: InvalidationListener listener = obs -> subscriber.run(); >> >> In the `subscribe` implementations, Invalidation/ChangeListeners are added as local variables. Have you run any test to check that they don't end up being gc'ed, because no strong references being held? >> >> And also related to this, how would you add a WeakInvalidation/WeakChangeListener? Maybe, that's up to the developer, overriding the default implementation of `subscribe`? > > There is no need, the returned `Subscription` is implemented using a lambda that captures the listener (as it needs it to call `removeListener`). As long as you have the `Subscription` referenced, it can't get GC'd. If you let the `Subscription` get GC'd, then you'd lose your means to unsubscribe the listener, just like if you lost the reference to the listener itself, you would never be able to remove it anymore. > > Weak listeners I would not recommend to use in new code if you can avoid it. They're unpredictable as to when they're removed exactly, and can still receive notifications when your application may be in a state where you don't expect them anymore. > > The `Subscription` interface is in fact intended to make management of listeners easier so you can rely less on weak listeners. One pattern I can really recommend to use is to automatically disable listeners when the UI they belong with becomes invisible, for example: > > private Subscription subscription = Subscription.EMPTY; > > node.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .subscribe(visible -> { > if (visible) { > subscription = Subscription.combine( > // create subscriptions (to external resources) here as we just became visible! > ); > } > else { > // we became invisible, remove listeners (from external resources) to remove hard references that > // may keep the UI referenced; the other branch will restore them if the UI becomes visible again > subscription.unsubscribe(); // unsubscribes everything in one go > } > }); > > Or you can use `ObservableValue#when` to do something similar, not requiring subscriptions. > > I suspect it may also prove a useful pattern for `Skin`s that have a specific lifecycle. They can register listeners (and combine in a single subscription) in their constructor / initializer, and remove them all in their `dispose` method. Yes, `flatMap` or `when` are great for those cases, so the pattern with the new `subscribe` proposal seems quite useful. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257564709 From jhendrikx at openjdk.org Sun Jul 9 23:24:03 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 9 Jul 2023 23:24:03 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 23:13:20 GMT, Jose Pereda wrote: >> There is no need, the returned `Subscription` is implemented using a lambda that captures the listener (as it needs it to call `removeListener`). As long as you have the `Subscription` referenced, it can't get GC'd. If you let the `Subscription` get GC'd, then you'd lose your means to unsubscribe the listener, just like if you lost the reference to the listener itself, you would never be able to remove it anymore. >> >> Weak listeners I would not recommend to use in new code if you can avoid it. They're unpredictable as to when they're removed exactly, and can still receive notifications when your application may be in a state where you don't expect them anymore. >> >> The `Subscription` interface is in fact intended to make management of listeners easier so you can rely less on weak listeners. One pattern I can really recommend to use is to automatically disable listeners when the UI they belong with becomes invisible, for example: >> >> private Subscription subscription = Subscription.EMPTY; >> >> node.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .subscribe(visible -> { >> if (visible) { >> subscription = Subscription.combine( >> // create subscriptions (to external resources) here as we just became visible! >> ); >> } >> else { >> // we became invisible, remove listeners (from external resources) to remove hard references that >> // may keep the UI referenced; the other branch will restore them if the UI becomes visible again >> subscription.unsubscribe(); // unsubscribes everything in one go >> } >> }); >> >> Or you can use `ObservableValue#when` to do something similar, not requiring subscriptions. >> >> I suspect it may also prove a useful pattern for `Skin`s that have a specific lifecycle. They can register listeners (and combine in a single subscription) in their constructor / initializer, and remove them all in their `dispose` method. > > Yes, `flatMap` or `when` are great for those cases, so the pattern with the new `subscribe` proposal seems quite useful. I missed the `orElse(false)` in the example above, which deals with scene being `null`. Full example should be: private Subscription subscription = Subscription.EMPTY; node.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false) .subscribe(visible -> { if (visible) { subscription = Subscription.combine( // create subscriptions (to external resources) here as we just became visible! ); } else { // we became invisible, remove listeners (from external resources) to remove hard references that // may keep the UI referenced; the other branch will restore them if the UI becomes visible again subscription.unsubscribe(); // unsubscribes everything in one go } }); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257565724 From jhendrikx at openjdk.org Mon Jul 10 00:20:09 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 10 Jul 2023 00:20:09 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: <10x6cdi03UjgPPhjT3kiLLdkJKciLvEwKcJj79vkHXI=.0f6407cf-220e-4986-8a9c-76624e03b672@github.com> Message-ID: On Sun, 9 Jul 2023 22:56:23 GMT, Jose Pereda wrote: >> The reasoning is that this would be the most logical and convenient way for these subscriptions to work. I think mstr2 said it well, but I'll run them down as well: >> >> Invalidation subscribers are called when the property actually becomes invalid; since it may currently be valid, calling the subscriber immediately would send the wrong signal. A case could be made to call the subscriber immediately if it is currently invalid, but I think whatever we choose here, it should work the same way as the current `addListener(InvalidationListener)` -- I'm pretty sure this one doesn't call the listener immediately when the property is currently invalid (this is something of a gotcha as well for beginning users of `InvalidationListener`s). >> >> Change subscribers require the old value; this is only temporarily available when there's an actual change in the property. Old values are not cached, and can't be cached as this may prevent garbage collection of whatever the old value references. >> >> The value listeners are a new breed, and specifically set up for convenient use. They're also the only ones that can send a sensible initial value, and since I'm pretty sure that's almost always what you'd want, this is the default for this type of subscription. > > Okay, that makes sense for the InvalidationListener. > > However, for the ChangeListener, as I see it, this PR gives two options, over the same listener: you can care only about the newValue, or you can care about both oldValue and newValue, both from the observableValue. These are then passed to the consumer/biConsumer that defines the ChangeListener, but I don't see any reason why this consumer/biconsumer needs to get initialized with any value at all, does it? > > Only bindings apply the initial value: when you bind two properties (unidirectionally), one property will get any future values of the other, starting from the initial value. But I don't see that happening to changeListeners: when you add a changeListener to a property, I don't see the action being invoked with the current value of the property at that moment, only when the property does change from the current value. > > In fact, if you run this test: > > > private final StringProperty value = new SimpleStringProperty("Initial"); > > @Test > void subscribeConsumerShouldCallSubscriberImmediatelyAndAfterEachChange() { > value.addListener((obs, ov, nv) -> System.out.println("changeListener, nv: " + nv)); > value.subscribe(nv -> System.out.println("consumer, nv = " + nv)); > value.subscribe((ov, nv) -> System.out.println("biconsumer, nv = " + nv)); > value.set("A"); > } > > > you'll get: > > > consumer, nv = Initial > changeListener, nv: A > consumer, nv = A > biconsumer, nv = A > > > It feels wrong to see the first printout to me. > > My point is that I don't see why we need to call the consumer at all before there is any actual change in the property. I think it would be better to see value listeners as the listener alternative to what `bind` offers, except not limited to properties. The main purpose of these subscriptions is to keep things in sync, not so much to know when something changed. When you can use `bind` that would be ideal, but not all properties can be bound, and not everything you may want to keep in sync is a property. `SelectionModel` is a good example; its properties can't be bound, but it does have methods to modify the selection: myModelSelection.subscribe(selectionModel::select); // sync right away thanks to initial call The same goes for other state that you may want to sync, like the example I gave in another reply: node.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false) .subscribe(this::subscribeOrUnsubscribeDependingOnVisibility); It's much nicer if this gets called immediately, to avoid having to duplicate this code to register the initial subscribers (and this code may need to check the visibility first still... was this UI part added to an existing visible UI? Then register immediately, if it wasn't then do nothing and let the subscriber above handle it... ) I think calling subscribers immediately when it is possible and makes sense to do so should be the default. For change subscribers it makes no sense as there is no change to report; for invalidation subscribers, you could again make the case that it may be good to call them immediately if the property isn't currently valid, if it weren't for the fact that `ExpressionHelper` will make a property always valid when you register an `InvalidationListener` (undocumented) -- and since it will always be valid immediately after subscription, there is no need to do that initial call. (The `ExpressionHelper` making the property valid when a listener gets added may even have been a quick hack, as it will unnecessarily make something valid, which may result in **all** invalidation listeners getting called down the line, while the intention maybe was to only call the newly registered one if the property was currently invalid... too late to change this now though without breaking lots of code.) So I realize this may seem inconsistent, but each subscriber type IMHO can stand on its own and can have a different purpose and different semantics, and I think that in the case of a value subscriber, there is a lot more benefit from calling the subscriber immediately than the other way around. Alternatively, you can always use a change subscriber if that initial call is not what you want. There is some precedent as well, ReactFX, which inspired some of these enhancements, also has/had this mechanism, and they made the same choice for value type subscriptions. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257575641 From psadhukhan at openjdk.org Mon Jul 10 06:26:02 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 06:26:02 GMT Subject: Integrated: 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held In-Reply-To: References: Message-ID: <1SingMrqTSJWcHoXHXW2X-vEgq6w0brVi0S07vL45BU=.a124e300-73a5-4a58-b4c3-6005f96420a0@github.com> On Wed, 5 Jul 2023 03:07:01 GMT, Prasanta Sadhukhan wrote: > If an EventHandler or EventFilter for a mouse button is attached to a scene within a JFXPanel and the **primary mouse button** is held, any mouse button click will create an event such that event.getButton().name() wrongly returns PRIMARY, even if the secondary or middle button was clicked. > This is because `SwingEvents.mouseButtonToEmbedMouseButton()` overwrites the button name after checking the modifier value. > For mouse click with primary button `mouseButtonToEmbedMouseButton` is first called with `BUTTON1 `and modifier `BUTTON1_DOWN_MASK `(ie 1024) and then when secondary button(ie right button is clicked) `mouseButtonToEmbedMouseButton` is called with `BUTTON3 `and modifier `BUTTON3_DOWN_MASK | BUTTON1_DOWN_MASK` (ie 5120) > and when secondary button is released, `mouseButtonToEmbedMouseButton` is again called with `BUTTON3 `but with modifier `BUTTON1_DOWN_MASK `(1024) resulting in button being declared PRIMARY. > > Fix is to make sure not to overwrite button name if a button name is already assigned. This pull request has now been integrated. Changeset: 8635f81f Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jfx/commit/8635f81fc2451a206c018ad024fc1553a53d659f Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod 8242419: JFXPanel: MouseEvent always reports that Primary button changed state if held Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1170 From psadhukhan at openjdk.org Mon Jul 10 06:52:11 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 06:52:11 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v4] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix to get correct scale in secondary monitor ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1171/files - new: https://git.openjdk.org/jfx/pull/1171/files/3689422d..6bfb624c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=02-03 Stats: 16 lines in 1 file changed: 3 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From psadhukhan at openjdk.org Mon Jul 10 06:52:15 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 06:52:15 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v3] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Fri, 7 Jul 2023 17:18:10 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Set stage scale in FX thread > are you saying that it should show 200% even for the window that gets shown on the secondary (scale=1)? even though the test code does listen to the changes on the right scene instance > > ``` > scene.windowProperty().addListener((ob, oldWindow, newWindow) -> { > newWindow.renderScaleXProperty().addListener((obs, oldValue, newValue) -> updateText(label, newValue)); > updateText(label, newWindow.getRenderScaleX()); > }); > ``` > > ? > > also, the poorly rendered text with the fix - does it mean this PR needs more work? > > here is the comparison between the master and the fix, using the window that appears on the secondary: > > ![Screenshot 2023-07-07 at 11 43 49](https://user-images.githubusercontent.com/107069028/251831932-8db3f763-810c-4b46-9928-3b0fd3fd78ad.png) Fix to get correct scale in secondary monitor...Poorly rendered text on secondary is tracked in JDK-8222209 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1628341775 From psadhukhan at openjdk.org Mon Jul 10 06:54:49 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 06:54:49 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v5] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8274932 - Fix to get correct scale in secondary monitor - Set stage scale in FX thread - Set stage scale in FX thread - Set stage scale in FX thread - 8274932: Render scales in EmbeddedWindow are not properly updated ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1171/files - new: https://git.openjdk.org/jfx/pull/1171/files/6bfb624c..c2c23fc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=03-04 Stats: 70526 lines in 1267 files changed: 30933 ins; 13657 del; 25936 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From psadhukhan at openjdk.org Mon Jul 10 07:26:10 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 07:26:10 GMT Subject: RFR: 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices [v2] In-Reply-To: References: Message-ID: > If the scaleFactors used for the current device are not 1.0, a JXFPanel will send a resize event with 0x0 dimensions to the JavaFX scene which can have undesirable effects, which is because the resize pixel buffer is created even for initial size of 9x0 width,height. > Fix is to make sure to prevent resizing the pixel buffer for initial width/height of 0. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Make pWidth/pHeight 0 after border insets if it's negative ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1168/files - new: https://git.openjdk.org/jfx/pull/1168/files/d8ba8797..4e61ece2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1168&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1168&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1168.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1168/head:pull/1168 PR: https://git.openjdk.org/jfx/pull/1168 From psadhukhan at openjdk.org Mon Jul 10 07:29:01 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 07:29:01 GMT Subject: RFR: 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices [v2] In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 19:04:42 GMT, Andy Goryachev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Make pWidth/pHeight 0 after border insets if it's negative > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 631: > >> 629: if (oldWidth == 0 && oldHeight == 0 && pWidth == 0 && pHeight == 0) { >> 630: return; >> 631: } > > this change fixes the issue with the provided test code. > > a few comments: > 1. if I wrap textArea with a BorderPane, I never get width=0 (master branch) > 2. would it make sense to add a check to line 611: if((pWidth == 0) && (pHeight == 0))? > 3. lines 617, 618 subtract border insets, would that risk making pWidth/pHeight negative (considering code on lines 613, 614)? I guess l618, 619 in PR takes care of pt 2,3 concern.. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1168#discussion_r1257834019 From jpereda at openjdk.org Mon Jul 10 08:04:03 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 10 Jul 2023 08:04:03 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: <10x6cdi03UjgPPhjT3kiLLdkJKciLvEwKcJj79vkHXI=.0f6407cf-220e-4986-8a9c-76624e03b672@github.com> Message-ID: On Mon, 10 Jul 2023 00:17:44 GMT, John Hendrikx wrote: >> Okay, that makes sense for the InvalidationListener. >> >> However, for the ChangeListener, as I see it, this PR gives two options, over the same listener: you can care only about the newValue, or you can care about both oldValue and newValue, both from the observableValue. These are then passed to the consumer/biConsumer that defines the ChangeListener, but I don't see any reason why this consumer/biconsumer needs to get initialized with any value at all, does it? >> >> Only bindings apply the initial value: when you bind two properties (unidirectionally), one property will get any future values of the other, starting from the initial value. But I don't see that happening to changeListeners: when you add a changeListener to a property, I don't see the action being invoked with the current value of the property at that moment, only when the property does change from the current value. >> >> In fact, if you run this test: >> >> >> private final StringProperty value = new SimpleStringProperty("Initial"); >> >> @Test >> void subscribeConsumerShouldCallSubscriberImmediatelyAndAfterEachChange() { >> value.addListener((obs, ov, nv) -> System.out.println("changeListener, nv: " + nv)); >> value.subscribe(nv -> System.out.println("consumer, nv = " + nv)); >> value.subscribe((ov, nv) -> System.out.println("biconsumer, nv = " + nv)); >> value.set("A"); >> } >> >> >> you'll get: >> >> >> consumer, nv = Initial >> changeListener, nv: A >> consumer, nv = A >> biconsumer, nv = A >> >> >> It feels wrong to see the first printout to me. >> >> My point is that I don't see why we need to call the consumer at all before there is any actual change in the property. > > I think it would be better to see value listeners as the listener alternative to what `bind` offers, except not limited to properties. The main purpose of these subscriptions is to keep things in sync, not so much to know when something changed. When you can use `bind` that would be ideal, but not all properties can be bound, and not everything you may want to keep in sync is a property. `SelectionModel` is a good example; its properties can't be bound, but it does have methods to modify the selection: > > myModelSelection.subscribe(selectionModel::select); // sync right away thanks to initial call > > The same goes for other state that you may want to sync, like the example I gave in another reply: > > > node.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .subscribe(this::subscribeOrUnsubscribeDependingOnVisibility); > > It's much nicer if this gets called immediately, to avoid having to duplicate this code to register the initial subscribers (and this code may need to check the visibility first still... was this UI part added to an existing visible UI? Then register immediately, if it wasn't then do nothing and let the subscriber above handle it... ) > > I think calling subscribers immediately when it is possible and makes sense to do so should be the default. For change subscribers it makes no sense as there is no change to report; for invalidation subscribers, you could again make the case that it may be good to call them immediately if the property isn't currently valid, if it weren't for the fact that `ExpressionHelper` will make a property always valid when you register an `InvalidationListener` (undocumented) -- and since it will always be valid immediately after subscription, there is no need to do that initial call. (The `ExpressionHelper` making the property valid when a listener gets added may even have been a quick hack, as it will unnecessarily make something valid, which may result in **all** invalidation listeners getting called down the line, while the intention maybe was to only call the newly registered one if the property was currently invalid... too late to change this now though without breaking lots of code.) > > So I realize this may seem inconsistent, but each subscriber type IMHO can stand on its own and can have a different purpose and different semantics, and I think that in the case of a value subscriber, there is a lot more benefit from calling the subscriber immediately than th... Thanks for the clarifications. If I get it right, you talk about `invalidation subscriber` for `subscribe(Runnable)` API, `value subscriber` for `subscribe(Consumer)` API and `change subscriber` for `subscribe(BiConsumer)` API, and that's fine, but for a developer that approaches this new API, there is no indication of that (API naming, javadoc), so that's why I'm a little bit concerned about this different in behaviour of the value vs change subscribers. As commented before, probably the javadoc for the three `subscribe` methods should be extended a little bit more with a mention of the listener involved, and with a small sample. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257872604 From jvos at openjdk.org Mon Jul 10 08:09:01 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 10 Jul 2023 08:09:01 GMT Subject: RFR: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: References: Message-ID: <8LM_2ZgwqQXoEryOxLjSbYUf2-tCECiTDrRk8Eh3zZ8=.247221d9-5efb-439f-aeee-6c0be8e5ede7@github.com> On Sun, 9 Jul 2023 17:43:05 GMT, Thiago Milczarek Sayao wrote: > The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. > > Te fix replaces the usage of the function for already known extents value calculation. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1016: > 1014: if (frame_type == TITLED) { > 1015: GdkRectangle rect; > 1016: gdk_window_get_frame_extents(gdk_window, &rect); Looking at potential regression: in case of a TITLED frame, before this patch you would use `get_frame_extents` and now you will use `get_origin` in all cases. Are there scenario's where this might lead to regression, or is there a way to test this? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1173#discussion_r1257878275 From jhendrikx at openjdk.org Mon Jul 10 08:19:07 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 10 Jul 2023 08:19:07 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: <10x6cdi03UjgPPhjT3kiLLdkJKciLvEwKcJj79vkHXI=.0f6407cf-220e-4986-8a9c-76624e03b672@github.com> Message-ID: On Mon, 10 Jul 2023 08:01:46 GMT, Jose Pereda wrote: >> I think it would be better to see value listeners as the listener alternative to what `bind` offers, except not limited to properties. The main purpose of these subscriptions is to keep things in sync, not so much to know when something changed. When you can use `bind` that would be ideal, but not all properties can be bound, and not everything you may want to keep in sync is a property. `SelectionModel` is a good example; its properties can't be bound, but it does have methods to modify the selection: >> >> myModelSelection.subscribe(selectionModel::select); // sync right away thanks to initial call >> >> The same goes for other state that you may want to sync, like the example I gave in another reply: >> >> >> node.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .subscribe(this::subscribeOrUnsubscribeDependingOnVisibility); >> >> It's much nicer if this gets called immediately, to avoid having to duplicate this code to register the initial subscribers (and this code may need to check the visibility first still... was this UI part added to an existing visible UI? Then register immediately, if it wasn't then do nothing and let the subscriber above handle it... ) >> >> I think calling subscribers immediately when it is possible and makes sense to do so should be the default. For change subscribers it makes no sense as there is no change to report; for invalidation subscribers, you could again make the case that it may be good to call them immediately if the property isn't currently valid, if it weren't for the fact that `ExpressionHelper` will make a property always valid when you register an `InvalidationListener` (undocumented) -- and since it will always be valid immediately after subscription, there is no need to do that initial call. (The `ExpressionHelper` making the property valid when a listener gets added may even have been a quick hack, as it will unnecessarily make something valid, which may result in **all** invalidation listeners getting called down the line, while the intention maybe was to only call the newly registered one if the property was currently invalid... too late to change this now though without breaking lots of code. ) >> >> So I realize this may seem inconsistent, but each subscriber type IMHO can stand on its own and can have a different purpose and different semantics, and I think that in the case of a value subscriber, there is a lot more benefit from callin... > > Thanks for the clarifications. > If I get it right, you talk about `invalidation subscriber` for `subscribe(Runnable)` API, `value subscriber` for `subscribe(Consumer)` API and `change subscriber` for `subscribe(BiConsumer)` API, and that's fine, but for a developer that approaches this new API, there is no indication of that (API naming, javadoc), so that's why I'm a little bit concerned about this different in behaviour of the value vs change subscribers. > > As commented before, probably the javadoc for the three `subscribe` methods should be extended a little bit more with a mention of the listener involved, and with a small sample. Yes, it's true they map like that: Runnable -> invalidations, Consumer -> values, BiConsumer -> changes. I will extend the docs as this indeed is a bit unclear now (the methods were called "invalidations", "values" and "changes" before). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257889214 From tsayao at openjdk.org Mon Jul 10 09:04:07 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 10 Jul 2023 09:04:07 GMT Subject: RFR: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: <8LM_2ZgwqQXoEryOxLjSbYUf2-tCECiTDrRk8Eh3zZ8=.247221d9-5efb-439f-aeee-6c0be8e5ede7@github.com> References: <8LM_2ZgwqQXoEryOxLjSbYUf2-tCECiTDrRk8Eh3zZ8=.247221d9-5efb-439f-aeee-6c0be8e5ede7@github.com> Message-ID: On Mon, 10 Jul 2023 08:06:34 GMT, Johan Vos wrote: >> The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. >> >> Te fix replaces the usage of the function for already known extents value calculation. > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1016: > >> 1014: if (frame_type == TITLED) { >> 1015: GdkRectangle rect; >> 1016: gdk_window_get_frame_extents(gdk_window, &rect); > > Looking at potential regression: in case of a TITLED frame, before this patch you would use `get_frame_extents` and now you will use `get_origin` in all cases. Are there scenario's where this might lead to regression, or is there a way to test this? `geometry.x` and `y` should point to the top left corner of the window including decorations (on JavaFX logic), then the view position will have the decoration size as x and y. `gdk_window_get_frame_extents` returns the top left position with frame extents (decorations) - all other Gdk/Gtk functions will return position without decorations (because on X11 they are drawn on client side). Somehow `gdk_window_get_frame_extents` is broken on i3-wm, but we already have the frame extents values. I just replaced it by getting normal origins (does not include decorations) and if the frame is TITLED, subtract the frame extents to have the window position accounting decorations. To test this I: - [ ] Run the bug example with UNDECORATED window on i3 and mutter (the default gnome wm); - [ ] Run the bug example with DECORATED window on i3 and mutter (the default gnome wm); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1173#discussion_r1257946494 From angorya at openjdk.org Mon Jul 10 16:11:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Jul 2023 16:11:12 GMT Subject: RFR: 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 07:26:10 GMT, Prasanta Sadhukhan wrote: >> If the scaleFactors used for the current device are not 1.0, a JXFPanel will send a resize event with 0x0 dimensions to the JavaFX scene which can have undesirable effects, which is because the resize pixel buffer is created even for initial size of 9x0 width,height. >> Fix is to make sure to prevent resizing the pixel buffer for initial width/height of 0. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Make pWidth/pHeight 0 after border insets if it's negative looks good now, thanks! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1168#pullrequestreview-1522427717 From angorya at openjdk.org Mon Jul 10 16:22:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Jul 2023 16:22:14 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v5] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Mon, 10 Jul 2023 06:54:49 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8274932 > - Fix to get correct scale in secondary monitor > - Set stage scale in FX thread > - Set stage scale in FX thread > - Set stage scale in FX thread > - 8274932: Render scales in EmbeddedWindow are not properly updated getting the scales right on both monitors now (macOS) the image is rendered with no gaps. LGTM ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1171#pullrequestreview-1522452579 From angorya at openjdk.org Mon Jul 10 16:27:16 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Jul 2023 16:27:16 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments [v2] In-Reply-To: References: Message-ID: On Sat, 8 Jul 2023 23:38:05 GMT, Michael Strau? wrote: >> DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: >> >> >> ... >> String data = uri.substring(dataSeparator + 1); >> Charset charset = Charset.defaultCharset(); >> ... >> URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) >> >> >> This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. >> >> This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. >> >> **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added more tests +1 for added tests, thank you. LGTM ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1165#pullrequestreview-1522481262 From psadhukhan at openjdk.org Mon Jul 10 16:29:13 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jul 2023 16:29:13 GMT Subject: Integrated: 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 16:11:16 GMT, Prasanta Sadhukhan wrote: > If the scaleFactors used for the current device are not 1.0, a JXFPanel will send a resize event with 0x0 dimensions to the JavaFX scene which can have undesirable effects, which is because the resize pixel buffer is created even for initial size of 9x0 width,height. > Fix is to make sure to prevent resizing the pixel buffer for initial width/height of 0. This pull request has now been integrated. Changeset: 8fef6a33 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jfx/commit/8fef6a3315efed579a431d580aae143da236e7b2 Stats: 11 lines in 1 file changed: 7 ins; 4 del; 0 mod 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1168 From kcr at openjdk.org Mon Jul 10 16:36:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Jul 2023 16:36:14 GMT Subject: RFR: 8311216: DataURI can lose information in some charset environments [v2] In-Reply-To: References: Message-ID: <19V4LNsrLq9rssq79CU4OmXL63mBlpap_5OQBrm0AqE=.fbf3a304-8de0-4fee-8107-e4a7f313b8da@github.com> On Sat, 8 Jul 2023 23:38:05 GMT, Michael Strau? wrote: >> DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: >> >> >> ... >> String data = uri.substring(dataSeparator + 1); >> Charset charset = Charset.defaultCharset(); >> ... >> URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) >> >> >> This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. >> >> This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. >> >> **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added more tests This one could use a second pair of eyes on it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1165#issuecomment-1629319587 From kcr at openjdk.org Mon Jul 10 16:43:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Jul 2023 16:43:19 GMT Subject: RFR: 8231865: JFXPanel sends resize event with size 0x0 on HiDPI devices [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 07:26:10 GMT, Prasanta Sadhukhan wrote: >> If the scaleFactors used for the current device are not 1.0, a JXFPanel will send a resize event with 0x0 dimensions to the JavaFX scene which can have undesirable effects, which is because the resize pixel buffer is created even for initial size of 9x0 width,height. >> Fix is to make sure to prevent resizing the pixel buffer for initial width/height of 0. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Make pWidth/pHeight 0 after border insets if it's negative Ideally, a regression test -- either automated (if feasible) or manual -- would have been included with this fix. Is it worth a follow-on bug to add such a test? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1168#issuecomment-1629332242 From angorya at openjdk.org Mon Jul 10 16:44:11 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Jul 2023 16:44:11 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v3] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 17:34:23 GMT, Martin Fox wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/input/KeyEvent.java line 388: >> >>> 386: * The hardware key code which is private to the implementation. >>> 387: */ >>> 388: private int hardwareCode; >> >> Does it need to be private? Events are public, and I think it should be possible to make your own events that act exactly like an event created by the system, which would preclude hidden variables. > > At this point I don't have a strong opinion on whether this field is private or not. Originally I wanted it to be private because I thought of it as "whatever magic value makes KeyCharacterCombinations work" and was concerned we might want to tweak that over time. That's less of a concern now that I've prototyped the implementation on three different platforms. > > This is largely a policy issue that's above my pay grade. This is an intrinsically platform-specific bit of information we would be exposing to developers. Are we going to create side effects when KeyEvents are synthesized? See, for instance, EmbeddedScene:366 or FXVKSkin:860 (and possibly other places)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1258582546 From kcr at openjdk.org Mon Jul 10 18:02:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Jul 2023 18:02:07 GMT Subject: RFR: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 07:26:39 GMT, Florian Kirmaier wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> small changes based on code review > > I've tested it on Mac. > > On Windows, many people will test it soon, because the fix is now integrated into a development version of a JavaFX Application, with a lot of Testers / Developers. So if something breaks, we should know it very soon. > But I don't expect any issues. > > For Linux, I currently don't have a device available to test it. > I could create a TestVM, to just Test it, but I don't really see how this breaks only on Linux. @FlorianKirmaier This is ready for you to `/integrate` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1152#issuecomment-1629447401 From kizune at openjdk.org Mon Jul 10 20:45:31 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 10 Jul 2023 20:45:31 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice Message-ID: To avoid confusion on the os x dynamic linker side i renamed native classes from ButtonAccessibility to JFXButtonAccessibility. I will use JFX prefix down the line to avoid any confusion when running with the latest JDK that also migrated to the new a11y API. ------------- Commit messages: - 8311806: Class ButtonAccessibility is implemented twice Changes: https://git.openjdk.org/jfx/pull/1174/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1174&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311806 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1174.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1174/head:pull/1174 PR: https://git.openjdk.org/jfx/pull/1174 From david.smith at dms489.com Mon Jul 10 23:05:27 2023 From: david.smith at dms489.com (dms489) Date: Mon, 10 Jul 2023 19:05:27 -0400 Subject: Installing JRE for Netbeans development Message-ID: Can somebody please point me to the procedure for installing the JRE used for developing Netbeans projects? -- David Smith david.smith at dms489.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebresie at gmail.com Tue Jul 11 02:44:03 2023 From: ebresie at gmail.com (Eric Bresie) Date: Mon, 10 Jul 2023 21:44:03 -0500 Subject: Installing JRE for Netbeans development In-Reply-To: References: Message-ID: Can pull down recent version of Netbeans here: https://netbeans.apache.org/download/nb18/index.html The community installers have a jre version packaged with it. Within Netbeans in the Tools?Java Platform area, it?s possible to download any of recent JDK/JRE releases which can be installed as part of it. For more recent Netbeans versions, it requires JDK 11 or newer. Hope that helps. On Mon, Jul 10, 2023 at 6:06 PM dms489 wrote: > Can somebody please point me to the procedure for installing the JRE used > for developing Netbeans projects? > -- > David Smith > david.smith at dms489.com > -- Eric Bresie ebresie at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fkirmaier at openjdk.org Tue Jul 11 07:35:22 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 11 Jul 2023 07:35:22 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v9] In-Reply-To: References: Message-ID: <7PyHAznvwDnSrdtINdcsmGFuzllS0X88Faa3BVWOeOg=.2008b607-ed14-49e7-9071-1bfde2750b4b@github.com> On Mon, 18 Jul 2022 12:18:49 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - JDK-8273485 > Fixing issue caused by wrong merge. > - Merge remote-tracking branch 'origin/master' into JDK-8273485_swing-deadlock > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m > - JDK-8273485 > Added check for null when calling initScreens > - JDK-8273485 > Fixing toggle fullscreen! > - JDK-8273485 > removed the toggle fullscreen before closing - to avoid the beep and improve the user experience > - JDK-8273485 > Fixed Beep sound when closing a fullscreen window > - JDK-8273485 > small cleanup of the changes. > - JDK-8273485 > Removed the enter/leave nested event loop logic, for mac fullscreen > - JDK-8273485 > Added unit-test > - JDK-8273485 > Fixing deadlock when switching to fullscreen, when also swing is used. It's nice to see there are other ways to fix the problem. The approach of this PR had the big advantage of highly reducing the complexity. Nested Event Loops are highly cursed - and removing one of them probably solves complicated issues at once. We had so many issues with nested event loops - and in my opinion - they should even be removed entirely in the long run. ------------- PR Comment: https://git.openjdk.org/jfx/pull/622#issuecomment-1630300293 From psadhukhan at openjdk.org Tue Jul 11 07:58:07 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 11 Jul 2023 07:58:07 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' of https://git.openjdk.org/jfx into JDK-8274932 - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8274932 - Fix to get correct scale in secondary monitor - Set stage scale in FX thread - Set stage scale in FX thread - Set stage scale in FX thread - 8274932: Render scales in EmbeddedWindow are not properly updated ------------- Changes: https://git.openjdk.org/jfx/pull/1171/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=05 Stats: 28 lines in 1 file changed: 15 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From fkirmaier at openjdk.org Tue Jul 11 10:53:16 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 11 Jul 2023 10:53:16 GMT Subject: Integrated: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change In-Reply-To: References: Message-ID: <3QItE6CKUZy6mLkn8GBDeoT1xUdJ1W9b4wufdY0ByeE=.3ada3137-c7fb-47c7-bf67-a31440c68c44@github.com> On Tue, 13 Jun 2023 13:52:46 GMT, Florian Kirmaier wrote: > Fixing JDK-8309935 and providing a test for it. This pull request has now been integrated. Changeset: a91b34d1 Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/a91b34d1245efcfd68bac7cffc84d57f39aff06f Stats: 116 lines in 2 files changed: 115 ins; 0 del; 1 mod 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1152 From kcr at openjdk.org Tue Jul 11 11:02:31 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jul 2023 11:02:31 GMT Subject: RFR: 8311844: Change JavaFX release version to 22 Message-ID: Bump the version number of JavaFX to 22. I will integrate this to master as part of forking the jfx21 stabilization branch, which is scheduled for Thursday, July 13, 2023 at 16:00 UTC. ------------- Commit messages: - 8311844: Change JavaFX release version to 22 Changes: https://git.openjdk.org/jfx/pull/1175/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1175&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311844 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1175.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1175/head:pull/1175 PR: https://git.openjdk.org/jfx/pull/1175 From kpk at openjdk.org Tue Jul 11 12:41:07 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 11 Jul 2023 12:41:07 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Sat, 8 Jul 2023 10:15:47 GMT, Marius Hanl wrote: > Is it possible to write a Unit test as well? I tried to write unit test but since it should be checked if the graphic is cleared while collapsing the tree and added back while expanding, I couldn't find out a way to do this. I tried to use `VirtualFlowTestUtils.assertGraphicIsVisible()` method similar to how it is used in `TreeTableViewTest` to do the same but it did not help in this case. Please let me know if you have any suggestions. > For these kinds of changes, I think it is important to have a performance check as well (e.g. count the number of invocations to updateItem etc). I have checked my changes using the program given in [JDK-8143266](https://bugs.openjdk.org/browse/JDK-8143266). I did not find performance degradation as a result of my changes. Do you suggest writing separate test for this? Please let me know your suggestion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1630750269 From kcr at openjdk.org Tue Jul 11 12:48:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jul 2023 12:48:13 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v9] In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 16:27:52 GMT, Florian Kirmaier wrote: > I guess there is no way to reopen pull requests, except creating new ones? There is, using the Skara `/open` command. In this case, I think the approach suggested by @beldenfox might be preferable. ------------- PR Comment: https://git.openjdk.org/jfx/pull/622#issuecomment-1630761864 From fastegal at openjdk.org Tue Jul 11 14:08:11 2023 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 11 Jul 2023 14:08:11 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 12:38:39 GMT, Karthik P K wrote: > > Is it possible to write a Unit test as well? > > I tried to write unit test but since it should be checked if the graphic is cleared while collapsing the tree and added back while expanding, I couldn't find out a way to do this. I would try to test the state of the graphic of the concrete item - keep track of it on setup and before showing the treetable - after showing, it should/not be part of the visible hierarchy (as appropriate) after expanding/collapsing. When it should be visible also verify that it is at the expected location. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1630896955 From angorya at openjdk.org Tue Jul 11 15:18:19 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Jul 2023 15:18:19 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Tue, 11 Jul 2023 07:58:07 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into JDK-8274932 > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8274932 > - Fix to get correct scale in secondary monitor > - Set stage scale in FX thread > - Set stage scale in FX thread > - Set stage scale in FX thread > - 8274932: Render scales in EmbeddedWindow are not properly updated Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1171#pullrequestreview-1524527206 From arapte at openjdk.org Tue Jul 11 15:53:09 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 11 Jul 2023 15:53:09 GMT Subject: RFR: 8311844: Change JavaFX release version to 22 In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 10:56:25 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 22. I will integrate this to master as part of forking the jfx21 stabilization branch, which is scheduled for Thursday, July 13, 2023 at 16:00 UTC. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1175#pullrequestreview-1524600839 From duke at openjdk.org Tue Jul 11 16:27:22 2023 From: duke at openjdk.org (Martin Fox) Date: Tue, 11 Jul 2023 16:27:22 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v9] In-Reply-To: <7PyHAznvwDnSrdtINdcsmGFuzllS0X88Faa3BVWOeOg=.2008b607-ed14-49e7-9071-1bfde2750b4b@github.com> References: <7PyHAznvwDnSrdtINdcsmGFuzllS0X88Faa3BVWOeOg=.2008b607-ed14-49e7-9071-1bfde2750b4b@github.com> Message-ID: On Tue, 11 Jul 2023 07:31:58 GMT, Florian Kirmaier wrote: > The approach of this PR had the big advantage of highly reducing the complexity. Nested event loops are complicated and I agree we should ditch them when we can. But in this case Apple saddled us and themselves with complexity by making fullscreen transitions asynchronous. I did a quick Google search and had no problem finding problems. The Electron folks discovered that if you call toggleFullscreen during the fullscreen transition you get "weird behavior (incl. phantom windows)" and I was able to reproduce this. Who knows what other strangeness can happen. Anything we do to make toggleFullscreen behave more synchronously reduces our exposure to Apple bugs (and synchronous behavior is what JavaFX expects) so I think we'll just have to grit our teeth and deal with the nested event loops. ------------- PR Comment: https://git.openjdk.org/jfx/pull/622#issuecomment-1631127635 From jvos at openjdk.org Tue Jul 11 19:04:07 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 11 Jul 2023 19:04:07 GMT Subject: RFR: 8311844: Change JavaFX release version to 22 In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 10:56:25 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 22. I will integrate this to master as part of forking the jfx21 stabilization branch, which is scheduled for Thursday, July 13, 2023 at 16:00 UTC. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1175#pullrequestreview-1524987402 From michaelstrau2 at gmail.com Tue Jul 11 19:52:34 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 11 Jul 2023 21:52:34 +0200 Subject: CSS Transitions Message-ID: I've previously proposed to add implicit CSS transitions to JavaFX. Compared to the previous proposal, this new and refined proposal is a "minimally invasive" version that requires almost no new API. The previous proposal did get some reactions on GitHub, and I hope that this new proposal can attract enough support within the OpenJFX community to move it forward: Goals ----- Support CSS Transitions [1] in JavaFX. Non-Goals --------- It is not a goal to * change the semantics of explicit transitions and animations of the `javafx.animation` framework * provide a programmatic API for implicit transitions (i.e. implicit tansitions can only be defined in stylesheets) * support CSS Animations [2] Motivation ---------- CSS Transitions [1] is a universally supported web standard that allows developers to specify how a CSS property changes its value smoothly from one value to another. Here's how an implicit transition is defined in a stylesheet: .button { transition-property: -fx-opacity; transition-duration: 1s; } CSS Transitions makes it easy to define animated transitions and create rich and fluid user experiences. CSS Transitions also nicely complements control skins: while skins define the structure and semantics of a control, implicit transitions define its dynamic appearance. Alternatives ------------ Applications that want to offer animated user experiences can use the existing `javafx.animation` framework. Animated controls can be created by subclassing existing skins and hooking into different kinds of input events and property change events to trigger animations. However, this is very cumbersome compared to using CSS Transitions. Description ----------- The `transition` pseudo-property is added to styleable nodes. It is special and distinct from all other CSS properties for three reasons: 1. There is no API to access this property in Java code. 2. It is not returned from `Node.getClassCssMetaData`. 3. It is guaranteed to be applied before all other properties. When a property value is changed by the CSS subsystem, we look whether a transition has been specified for the given property. If it has, the value change is animated over time. This works for all primitive property types, as well as object properties with `javafx.animation.Interpolatable` values. Note that in order for this to work, we must apply the `transition` pseudo-property before all other properties, as otherwise the CSS subsystem might not know that a transition was specified for a given property by the time the property value is changed. It is important to note that an implicit transition is only started when the property value is changed by the CSS subsystem, but not when it is changed programmatically by calling Property.setValue(T) or via a binding. This maximizes compatibility with code that assumes that programmatic value changes happen instantly. Applications don't need to keep track of running transitions, as they are automatically cancelled when their associated control is removed from the scene graph, becomes invisible, or is eligible for garbage collection. TransitionEvent --------------- The new event `javafx.css.TransitionEvent` signals the creation, beginning, completion and cancellation of implicit CSS transitions [3]. Applications can use this event to react to running transitions, for example by allowing a running transition to complete before reconfiguring the user interface or switching to a new page. Easing Functions ---------------- CSS Transitions specifies the `transition-timing-function` sub-property to define easing functions (see CSS Easing Functions [4]). Here is a list of all easing functions available in CSS Easing Functions: * linear * ease, ease-in, ease-out, ease-in-out, cubic-bezier(x1, y1, x2, y2) * step-start, step-end, steps(intervals, step-position) Easing functions are implemented using `javafx.animation.Interpolator` in JavaFX. While it may seem straightforward to re-use existing interpolator implementations like `Interpolator.EASE_IN`, `Interpolator.EASE_OUT`, etc., the definitions of those interpolators don't match the definitions of CSS Easing Functions. In order to maximize compatibility with CSS Transitions, implicit transitions use the CSS definitions, not the SMIL 3.0 definitions of the existing interpolator implementations. Note that step-wise interpolators are only available for CSS Transitions, they are not exposed as new public API in the `javafx.animation` framework. The reason for this is that step-wise interpolators accept negative input values and can produce different results depending on their `step-position` parameter (for details on that, see "2.3.1. Output of a step easing function" [5]). Since the `javafx.animation` framework does not provide negative input values to interpolators, step-wise interpolators don't work with explicit transitions and animations. This could be a future enhancement. Future enhancements ------------------- * In a follow-up enhancement, `Insets`, `Background`, `BackgroundFill`, and `CornerRadii` will implement the `Interpolatable` interface to allow more types to be implicitly animated. * CSS Animations [2] might also be implemented, which is another CSS-based animation framework. * An API to programmatically define CSS transitions might be added. Not doing this right away allows the implementation to move around a bit (which it might do if we choose to also do CSS Animations). * Expose step-wise interpolators as public API in the `javafx.animation` framework. [1] https://www.w3.org/TR/css-transitions-1/ [2] https://www.w3.org/TR/css-animations-1/ [3] https://www.w3.org/TR/css-transitions-1/#transition-events [4] https://www.w3.org/TR/css-easing-1/ [5] https://www.w3.org/TR/css-easing-1/#step-easing-algo From kcr at openjdk.org Tue Jul 11 20:15:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jul 2023 20:15:11 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: <4vGNtIhtb9EOw7HfvHSetiuEadZCsZiXmzF6KS0Hs38=.38e2f13e-f748-4767-9c27-e037cc25c4ff@github.com> On Mon, 10 Jul 2023 20:39:34 GMT, Alexander Zuev wrote: > To avoid confusion on the os x dynamic linker side i renamed native classes from ButtonAccessibility to JFXButtonAccessibility. I will use JFX prefix down the line to avoid any confusion when running with the latest JDK that also migrated to the new a11y API. The fix looks fine and should avoid the problem of name collision. It seems unfortunate that the namespace is global, especially in this case, since the symbols are not needed outside of libglass.dylib. Is there a way to hide the symbols so that they are not exported? If not, then adopting the pattern you chose is OK. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1174#issuecomment-1631448738 From jhendrikx at openjdk.org Tue Jul 11 20:55:35 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 20:55:35 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v8] In-Reply-To: References: Message-ID: <-5n6At6CR9rsdzQk8JuZAX4smAl756g6LKvvM7E1hqs=.6ebdc8de-68da-4c1d-be7c-99b7ac2cf3e7@github.com> > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Change documentation for subscriber methods to be similar to listener methods ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/ca69e2c3..c297afbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=06-07 Stats: 54 lines in 2 files changed: 34 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Tue Jul 11 20:55:38 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 20:55:38 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: <5bcAnpoDU_i1tDcSfDFJ9BCiGdtrkB8ksWbIP-o3gqY=.cad9a29c-c42a-49a8-9a89-75b2075484a2@github.com> Message-ID: On Sun, 9 Jul 2023 21:29:18 GMT, Michael Strau? wrote: >> Sure, that's a good suggestion, I may have been overly brief to avoid repeating what is known for invalidation listeners, but as this method does not mention invalidation listeners (and only uses them internally for now) a full explanation would be good to add. > > Another option would be to refer to the documentation for `InvalidationListener` or `Observable.addListener(InvalidationListener)`, both of which could be improved a bit in a separate PR. @mstr2 I updated the docs a bit, although I did not add your suggestion. I looked at the full class, and I think the class docs for `Observable` already describes how invalidations work. The docs for `addListener` don't repeat this either: * Implementations of this class should strive to generate as few events as * possible to avoid wasting too much time in event handlers. Implementations in * this library mark themselves as invalid when the first invalidation event * occurs. They do not generate anymore invalidation events until their value is * recomputed and valid again. What I did do is add some more description similar to what the `addListener` methods have. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1260267388 From jhendrikx at openjdk.org Tue Jul 11 21:04:42 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 21:04:42 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v9] In-Reply-To: References: Message-ID: <8myT8CTAXHJpo9HscuaxYA0ugC7RrlM5juIoS7-bqho=.6795a542-826e-44b3-98f5-c0574d12bf87@github.com> > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Extend tests to test unsubscribe ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/c297afbe..525c7841 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=07-08 Stats: 32 lines in 2 files changed: 26 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Tue Jul 11 21:04:46 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 21:04:46 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Wed, 14 Jun 2023 19:35:19 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Move Subscription method for invalidations to Observable >> >> - moved Subscription class to the Observable package > > I reviewed the proposal in the JBS enhancement and the proposed API in this PR. I think this would be a useful addition to JavaFX. I left a few questions and comments. @kevinrushforth I changed the docs a bit, if there's agreement on the new changes I can still update the CSR I hope. Otherwise, as it doesn't change semantics, I suppose this could be done separately as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1069#issuecomment-1631501049 From jhendrikx at openjdk.org Tue Jul 11 21:04:48 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 21:04:48 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v7] In-Reply-To: References: <10x6cdi03UjgPPhjT3kiLLdkJKciLvEwKcJj79vkHXI=.0f6407cf-220e-4986-8a9c-76624e03b672@github.com> Message-ID: <8yeurWEn2g5WvHDQZpgBm6W8gn3_a_hnzvATWGTJV9s=.53e01475-ef3a-4622-9e86-096cc1ad6b73@github.com> On Mon, 10 Jul 2023 08:15:54 GMT, John Hendrikx wrote: >> Thanks for the clarifications. >> If I get it right, you talk about `invalidation subscriber` for `subscribe(Runnable)` API, `value subscriber` for `subscribe(Consumer)` API and `change subscriber` for `subscribe(BiConsumer)` API, and that's fine, but for a developer that approaches this new API, there is no indication of that (API naming, javadoc), so that's why I'm a little bit concerned about this different in behaviour of the value vs change subscribers. >> >> As commented before, probably the javadoc for the three `subscribe` methods should be extended a little bit more with a mention of the listener involved, and with a small sample. > > Yes, it's true they map like that: Runnable -> invalidations, Consumer -> values, BiConsumer -> changes. I will extend the docs as this indeed is a bit unclear now (the methods were called "invalidations", "values" and "changes" before). I've updated the docs, and also renamed the parameters from `subscriber` to `xxxSubscriber` so it is more clear even without reading the docs. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1260273704 From john.hendrikx at gmail.com Tue Jul 11 21:27:49 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 11 Jul 2023 23:27:49 +0200 Subject: CSS Transitions In-Reply-To: References: Message-ID: Just a few questions inline: On 11/07/2023 21:52, Michael Strau? wrote: > Easing Functions > ---------------- > CSS Transitions specifies the `transition-timing-function` > sub-property to define easing functions (see CSS Easing Functions > [4]). Here is a list of all easing functions available in CSS Easing > Functions: > > * linear > * ease, ease-in, ease-out, ease-in-out, cubic-bezier(x1, y1, x2, y2) > * step-start, step-end, steps(intervals, step-position) > > Easing functions are implemented using `javafx.animation.Interpolator` > in JavaFX. While it may seem straightforward to re-use existing > interpolator implementations like `Interpolator.EASE_IN`, > `Interpolator.EASE_OUT`, etc., the definitions of those interpolators > don't match the definitions of CSS Easing Functions. In order to > maximize compatibility with CSS Transitions, implicit transitions use > the CSS definitions, not the SMIL 3.0 definitions of the existing > interpolator implementations. Should this also provide fx-ease-in (etc) if you want to be compatible with other FX animations instead of CSS ones (which have little meaning in FX apps) ? > Note that step-wise interpolators are only available for CSS > Transitions, they are not exposed as new public API in the > `javafx.animation` framework. The reason for this is that step-wise > interpolators accept negative input values and can produce different > results depending on their `step-position` parameter (for details on > that, see "2.3.1. Output of a step easing function" [5]). I would think that an Interpolator still has a defined begin and end state, regardless if it is step based or a smooth transition. Perhaps I'm misunderstanding something here about the step based transitions, but I don't see why the fraction value running from 0 to 1 would be incompatible with step based transitions.? The following interpolator would create 10 discrete steps: ??? new Interpolator() { ??????? @Override ??????? protected double curve(double t) { ??????????? return Math.floor(t * 10) / 10; ?? // 10 steps ??????? } ??? }; Add some parameters, and make adjustments for the various CSS jump types, whether ceil/floor should be used, etc, and I think it could implement the CSS step variants as well. --John From kcr at openjdk.org Tue Jul 11 22:16:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jul 2023 22:16:11 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Wed, 14 Jun 2023 19:35:19 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Move Subscription method for invalidations to Observable >> >> - moved Subscription class to the Observable package > > I reviewed the proposal in the JBS enhancement and the proposed API in this PR. I think this would be a useful addition to JavaFX. I left a few questions and comments. > @kevinrushforth I changed the docs a bit, if there's agreement on the new changes I can still update the CSR I hope. Otherwise, as it doesn't change semantics, I suppose this could be done separately as well. The doc changes, including the change to the argument names, looks good to me. Go ahead and update the CSR accordingly, and I'll "Review" it. Any other clarifying doc changes can be done subsequent to this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1069#issuecomment-1631577149 From kcr at openjdk.org Tue Jul 11 22:26:15 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jul 2023 22:26:15 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v9] In-Reply-To: <8myT8CTAXHJpo9HscuaxYA0ugC7RrlM5juIoS7-bqho=.6795a542-826e-44b3-98f5-c0574d12bf87@github.com> References: <8myT8CTAXHJpo9HscuaxYA0ugC7RrlM5juIoS7-bqho=.6795a542-826e-44b3-98f5-c0574d12bf87@github.com> Message-ID: On Tue, 11 Jul 2023 21:04:42 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Extend tests to test unsubscribe I note one more javadoc change needed (a missing `@since` tag). modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 33: > 31: /** > 32: * A subscription encapsulates how to cancel it without having > 33: * to keep track of how it was created. This needs an `@since 21` javadoc tag here. ------------- PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1525234547 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1260342187 From john.hendrikx at gmail.com Tue Jul 11 22:50:56 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Jul 2023 00:50:56 +0200 Subject: ListView with ImageViews for cells very bugged? Message-ID: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> I tend to avoid ListView, because for some reason it seems to just never do what I want unless used for its mundane rows of text use case.? I so far always just implemented my own skin for ListView that deals with displays that have many images that need to scroll smoothly, but... Recently, I've again attempted to use ListView, this time for showing (so far) fixed size ImageViews with images exactly 512x512 pixels in size: The cell factory looks like this, which I think is a correct implementation: ????? listView.setCellFactory(lv -> { ??????? return new ListCell<>() { ????????? protected void updateItem(ImageHandle imageHandle, boolean empty) { ??????????? if(empty) { ????????????? setGraphic(null); ??????????? } ??????????? else { ????????????? try { ??????????????? setGraphic(new ImageView(new Image(new ByteArrayInputStream(imageHandle.getImageData())))); ????????????? } ????????????? catch(IOException e) { ??????????????? e.printStackTrace(); ????????????? } ??????????? } ????????? } ??????? }; ????? }); Now, this is with JavaFX 21-ea-24 (but also happens on 19).? I spotted the following IMHO bugs: 1) When the ImageView is so large that a single row is only partially visible, the scrollbar is incorrect (it shows a full bar, even if half of a row is displayed). 2) The vertical scrollbar doesn't respond to a click in the non-thumb area at all (you'd expect to make it scroll a page up or down that way) 3) When jerkily resizing the window, I can sometimes have a vertical + horizontal scrollbar when there's a full row visible + anywhere from 0 to 10 extra empty pixels (probably the potential height of a horizontal scrollbar) with the vertical scroll bar still visible.? The algorithm to hide the scrollbar apparently is not deterministic and depends on mouse movement speed. 4) When a row is less than half visible, scrolling the window down to another ImageView will jump the view and hide the first cell that should still be visible for the bottom 0-49% of its height. 5) It's possible to get the vertical scroll bar in such a state that it doesn't respond to the mouse any more at all, even by dragging the thumb.? Some keyboard action and mouse scrolling sometimes restores it to relatively normal functioning. 6) Mouse wheel scrolling acts weird.? With one large cell visible and two rows available, scrolling only **down** on the mouse wheel will scroll down, then jump back up, and scroll down again... it's impossible to scroll all the way down to get to a point where it stops scrolling as it keeps jumping back. This is with ImageView's.? I suppose they're known to have problems... but then I switched to a Region, which contain an ImageView with proper min/pref/max implementations.? This improved the situation somewhat.? The scrollbar was much more reliable, but I still saw almost all of the above issues, but somewhat more reliable than before.? Still rows would disappear when (for the most part) invisible, those and the jumps of the view are just totally unacceptable. I'm not quite sure what to make of this, it seems the control is not meant for arbitrary graphics. --John package org.int4.sdui.ui; import hs.mediasystem.util.image.ImageHandle; import hs.mediasystem.util.javafx.control.Containers; import java.io.ByteArrayInputStream; import java.io.IOException; import java.util.Base64; import java.util.List; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListCell; import javafx.scene.control.ListView; import javafx.scene.control.TextArea; import javafx.scene.image.Image; import javafx.scene.image.ImageView; import javafx.scene.layout.HBox; import javafx.scene.layout.Priority; import javafx.stage.Stage; import kong.unirest.core.Unirest; public class Main { ? public static void main(String[] args) { ??? Application.launch(UI.class, args); ? } ? public static class UI extends Application { ??? @Override ??? public void start(Stage primaryStage) { ????? TextArea prompt = new TextArea("a flower on Mars"); ????? Button button = new Button("Submit"); ????? ListView listView = new ListView<>(); ????? listView.setCellFactory(lv -> { ??????? return new ListCell<>() { ????????? protected void updateItem(ImageHandle imageHandle, boolean empty) { ??????????? if(empty) { ????????????? setGraphic(null); ??????????? } ??????????? else { ????????????? try { ??????????????? setGraphic(new ImageView(new Image(new ByteArrayInputStream(imageHandle.getImageData())))); ????????????? } ????????????? catch(IOException e) { ??????????????? e.printStackTrace(); ????????????? } ??????????? } ????????? } ??????? }; ????? }); ????? button.setOnAction(e -> { ??????? Txt2ImgResponse response = textToImage(prompt.getText()); ??????? for(String image : response.images) { ????????? listView.getItems().add(new InMemoryImageHandle(Base64.getDecoder().decode(image))); ??????? } ????? }); ????? HBox hbox = Containers.hbox(Containers.vbox(prompt, button), listView); ????? HBox.setHgrow(listView, Priority.ALWAYS); ????? Scene scene = new Scene(hbox); ????? primaryStage.setScene(scene); ????? primaryStage.show(); ??? } ??? private Txt2ImgResponse textToImage(String prompt) { ????? return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") ??????? .body(new Txt2Img(prompt, 5)) ??????? .contentType("application/json") ??????? .asObject(Txt2ImgResponse.class) ??????? .getBody(); ??? } ? } ? static class InMemoryImageHandle implements ImageHandle { ??? private final byte[] data; ??? public InMemoryImageHandle(byte[] data) { ????? this.data = data; ??? } ??? @Override ??? public byte[] getImageData() { ????? return data; ??? } ??? @Override ??? public String getKey() { ????? return null; ??? } ??? @Override ??? public boolean isFastSource() { ????? return true; ??? } ? } ? record Txt2Img(String prompt, int steps) {} ? record Txt2ImgResponse(List images) {} } From kevin.rushforth at oracle.com Tue Jul 11 22:58:35 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Jul 2023 15:58:35 -0700 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> Message-ID: <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> What you have should work, but will create redundant images and ImageView ojbects. The recommendation is to create the nodes (ImageView in this case) in the constructor of the cell factory and call setGraphic with either null or that factory's node. Having said that, I doubt that this is related to the visual problems you are seeing. Maybe Ajit or Andy have some ideas. -- Kevin On 7/11/2023 3:50 PM, John Hendrikx wrote: > I tend to avoid ListView, because for some reason it seems to just > never do what I want unless used for its mundane rows of text use > case. I so far always just implemented my own skin for ListView that > deals with displays that have many images that need to scroll > smoothly, but... > > Recently, I've again attempted to use ListView, this time for showing > (so far) fixed size ImageViews with images exactly 512x512 pixels in > size: > > The cell factory looks like this, which I think is a correct > implementation: > > ????? listView.setCellFactory(lv -> { > ??????? return new ListCell<>() { > ????????? protected void updateItem(ImageHandle imageHandle, boolean > empty) { > ??????????? if(empty) { > ????????????? setGraphic(null); > ??????????? } > ??????????? else { > ????????????? try { > ??????????????? setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > ????????????? } > ????????????? catch(IOException e) { > ??????????????? e.printStackTrace(); > ????????????? } > ??????????? } > ????????? } > ??????? }; > ????? }); > > Now, this is with JavaFX 21-ea-24 (but also happens on 19).? I spotted > the following IMHO bugs: > > 1) When the ImageView is so large that a single row is only partially > visible, the scrollbar is incorrect (it shows a full bar, even if half > of a row is displayed). > > 2) The vertical scrollbar doesn't respond to a click in the non-thumb > area at all (you'd expect to make it scroll a page up or down that way) > > 3) When jerkily resizing the window, I can sometimes have a vertical + > horizontal scrollbar when there's a full row visible + anywhere from 0 > to 10 extra empty pixels (probably the potential height of a > horizontal scrollbar) with the vertical scroll bar still visible.? The > algorithm to hide the scrollbar apparently is not deterministic and > depends on mouse movement speed. > > 4) When a row is less than half visible, scrolling the window down to > another ImageView will jump the view and hide the first cell that > should still be visible for the bottom 0-49% of its height. > > 5) It's possible to get the vertical scroll bar in such a state that > it doesn't respond to the mouse any more at all, even by dragging the > thumb.? Some keyboard action and mouse scrolling sometimes restores it > to relatively normal functioning. > > 6) Mouse wheel scrolling acts weird.? With one large cell visible and > two rows available, scrolling only **down** on the mouse wheel will > scroll down, then jump back up, and scroll down again... it's > impossible to scroll all the way down to get to a point where it stops > scrolling as it keeps jumping back. > > This is with ImageView's.? I suppose they're known to have problems... > but then I switched to a Region, which contain an ImageView with > proper min/pref/max implementations.? This improved the situation > somewhat.? The scrollbar was much more reliable, but I still saw > almost all of the above issues, but somewhat more reliable than > before.? Still rows would disappear when (for the most part) > invisible, those and the jumps of the view are just totally unacceptable. > > I'm not quite sure what to make of this, it seems the control is not > meant for arbitrary graphics. > > --John > > > > package org.int4.sdui.ui; > > import hs.mediasystem.util.image.ImageHandle; > import hs.mediasystem.util.javafx.control.Containers; > > import java.io.ByteArrayInputStream; > import java.io.IOException; > import java.util.Base64; > import java.util.List; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListCell; > import javafx.scene.control.ListView; > import javafx.scene.control.TextArea; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.HBox; > import javafx.scene.layout.Priority; > import javafx.stage.Stage; > > import kong.unirest.core.Unirest; > > public class Main { > > ? public static void main(String[] args) { > ??? Application.launch(UI.class, args); > ? } > > ? public static class UI extends Application { > > ??? @Override > ??? public void start(Stage primaryStage) { > ????? TextArea prompt = new TextArea("a flower on Mars"); > ????? Button button = new Button("Submit"); > ????? ListView listView = new ListView<>(); > > ????? listView.setCellFactory(lv -> { > ??????? return new ListCell<>() { > ????????? protected void updateItem(ImageHandle imageHandle, boolean > empty) { > ??????????? if(empty) { > ????????????? setGraphic(null); > ??????????? } > ??????????? else { > ????????????? try { > ??????????????? setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > ????????????? } > ????????????? catch(IOException e) { > ??????????????? e.printStackTrace(); > ????????????? } > ??????????? } > ????????? } > ??????? }; > ????? }); > > ????? button.setOnAction(e -> { > ??????? Txt2ImgResponse response = textToImage(prompt.getText()); > > ??????? for(String image : response.images) { > ????????? listView.getItems().add(new > InMemoryImageHandle(Base64.getDecoder().decode(image))); > ??????? } > ????? }); > > ????? HBox hbox = Containers.hbox(Containers.vbox(prompt, button), > listView); > > ????? HBox.setHgrow(listView, Priority.ALWAYS); > > ????? Scene scene = new Scene(hbox); > > ????? primaryStage.setScene(scene); > ????? primaryStage.show(); > ??? } > > ??? private Txt2ImgResponse textToImage(String prompt) { > ????? return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > ??????? .body(new Txt2Img(prompt, 5)) > ??????? .contentType("application/json") > ??????? .asObject(Txt2ImgResponse.class) > ??????? .getBody(); > ??? } > ? } > > ? static class InMemoryImageHandle implements ImageHandle { > ??? private final byte[] data; > > ??? public InMemoryImageHandle(byte[] data) { > ????? this.data = data; > ??? } > > ??? @Override > ??? public byte[] getImageData() { > ????? return data; > ??? } > > ??? @Override > ??? public String getKey() { > ????? return null; > ??? } > > ??? @Override > ??? public boolean isFastSource() { > ????? return true; > ??? } > ? } > > ? record Txt2Img(String prompt, int steps) {} > ? record Txt2ImgResponse(List images) {} > } > > > From jhendrikx at openjdk.org Tue Jul 11 23:05:21 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 23:05:21 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v10] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add since tag to Subscription ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/525c7841..3e65572d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=08-09 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Tue Jul 11 23:12:20 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 23:12:20 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v11] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix case on since tag ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/3e65572d..0a5e2c72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From kcr at openjdk.org Tue Jul 11 23:12:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jul 2023 23:12:20 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v10] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 23:05:21 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since tag to Subscription modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 35: > 33: * to keep track of how it was created. > 34: * > 35: * @Since 21 Needs to be lower-case `s` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1260369855 From jhendrikx at openjdk.org Tue Jul 11 23:14:10 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 23:14:10 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v10] In-Reply-To: References: Message-ID: <1_X_TMKPXnDx60T4kYfMvNrFR--8412vBqCNuVZwhgQ=.0128030f-d900-4a73-a2f9-5477708e8f3a@github.com> On Tue, 11 Jul 2023 23:07:33 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add since tag to Subscription > > modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 35: > >> 33: * to keep track of how it was created. >> 34: * >> 35: * @Since 21 > > Needs to be lower-case `s` Yes, sorry, I noticed when updating the CSR that I added it wrong. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1260372822 From andy.goryachev at oracle.com Tue Jul 11 23:17:37 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 11 Jul 2023 23:17:37 +0000 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> Message-ID: I'll need to replicate this scenario to be able to say anything definitive. Just by looking at the cell factory code though, I suspect there might be some async processing around new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); which might cause the issue. Could you try pre-loading images? -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, July 11, 2023 at 15:58 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? What you have should work, but will create redundant images and ImageView ojbects. The recommendation is to create the nodes (ImageView in this case) in the constructor of the cell factory and call setGraphic with either null or that factory's node. Having said that, I doubt that this is related to the visual problems you are seeing. Maybe Ajit or Andy have some ideas. -- Kevin On 7/11/2023 3:50 PM, John Hendrikx wrote: > I tend to avoid ListView, because for some reason it seems to just > never do what I want unless used for its mundane rows of text use > case. I so far always just implemented my own skin for ListView that > deals with displays that have many images that need to scroll > smoothly, but... > > Recently, I've again attempted to use ListView, this time for showing > (so far) fixed size ImageViews with images exactly 512x512 pixels in > size: > > The cell factory looks like this, which I think is a correct > implementation: > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > Now, this is with JavaFX 21-ea-24 (but also happens on 19). I spotted > the following IMHO bugs: > > 1) When the ImageView is so large that a single row is only partially > visible, the scrollbar is incorrect (it shows a full bar, even if half > of a row is displayed). > > 2) The vertical scrollbar doesn't respond to a click in the non-thumb > area at all (you'd expect to make it scroll a page up or down that way) > > 3) When jerkily resizing the window, I can sometimes have a vertical + > horizontal scrollbar when there's a full row visible + anywhere from 0 > to 10 extra empty pixels (probably the potential height of a > horizontal scrollbar) with the vertical scroll bar still visible. The > algorithm to hide the scrollbar apparently is not deterministic and > depends on mouse movement speed. > > 4) When a row is less than half visible, scrolling the window down to > another ImageView will jump the view and hide the first cell that > should still be visible for the bottom 0-49% of its height. > > 5) It's possible to get the vertical scroll bar in such a state that > it doesn't respond to the mouse any more at all, even by dragging the > thumb. Some keyboard action and mouse scrolling sometimes restores it > to relatively normal functioning. > > 6) Mouse wheel scrolling acts weird. With one large cell visible and > two rows available, scrolling only **down** on the mouse wheel will > scroll down, then jump back up, and scroll down again... it's > impossible to scroll all the way down to get to a point where it stops > scrolling as it keeps jumping back. > > This is with ImageView's. I suppose they're known to have problems... > but then I switched to a Region, which contain an ImageView with > proper min/pref/max implementations. This improved the situation > somewhat. The scrollbar was much more reliable, but I still saw > almost all of the above issues, but somewhat more reliable than > before. Still rows would disappear when (for the most part) > invisible, those and the jumps of the view are just totally unacceptable. > > I'm not quite sure what to make of this, it seems the control is not > meant for arbitrary graphics. > > --John > > > > package org.int4.sdui.ui; > > import hs.mediasystem.util.image.ImageHandle; > import hs.mediasystem.util.javafx.control.Containers; > > import java.io.ByteArrayInputStream; > import java.io.IOException; > import java.util.Base64; > import java.util.List; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListCell; > import javafx.scene.control.ListView; > import javafx.scene.control.TextArea; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.HBox; > import javafx.scene.layout.Priority; > import javafx.stage.Stage; > > import kong.unirest.core.Unirest; > > public class Main { > > public static void main(String[] args) { > Application.launch(UI.class, args); > } > > public static class UI extends Application { > > @Override > public void start(Stage primaryStage) { > TextArea prompt = new TextArea("a flower on Mars"); > Button button = new Button("Submit"); > ListView listView = new ListView<>(); > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > button.setOnAction(e -> { > Txt2ImgResponse response = textToImage(prompt.getText()); > > for(String image : response.images) { > listView.getItems().add(new > InMemoryImageHandle(Base64.getDecoder().decode(image))); > } > }); > > HBox hbox = Containers.hbox(Containers.vbox(prompt, button), > listView); > > HBox.setHgrow(listView, Priority.ALWAYS); > > Scene scene = new Scene(hbox); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > private Txt2ImgResponse textToImage(String prompt) { > return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > .body(new Txt2Img(prompt, 5)) > .contentType("application/json") > .asObject(Txt2ImgResponse.class) > .getBody(); > } > } > > static class InMemoryImageHandle implements ImageHandle { > private final byte[] data; > > public InMemoryImageHandle(byte[] data) { > this.data = data; > } > > @Override > public byte[] getImageData() { > return data; > } > > @Override > public String getKey() { > return null; > } > > @Override > public boolean isFastSource() { > return true; > } > } > > record Txt2Img(String prompt, int steps) {} > record Txt2ImgResponse(List images) {} > } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Tue Jul 11 23:19:21 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 11 Jul 2023 23:19:21 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v12] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix subscriber -> valueSubscriber ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/0a5e2c72..170ca454 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From john.hendrikx at gmail.com Tue Jul 11 23:22:15 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Jul 2023 01:22:15 +0200 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> Message-ID: <108385a0-22f0-21cb-f5b9-ff490e827c07@gmail.com> It's not the most efficient code for sure, as so far its bare bones seeing if the app works at all.? I already updated it a bit, adding the ImageView as a field of the cell factory, but it made little difference.? I'll work up a full example tomorrow with pre-loaded images and everything (and without my util helpers) so others can try. --John On 12/07/2023 00:58, Kevin Rushforth wrote: > What you have should work, but will create redundant images and > ImageView ojbects. The recommendation is to create the nodes > (ImageView in this case) in the constructor of the cell factory and > call setGraphic with either null or that factory's node. > > Having said that, I doubt that this is related to the visual problems > you are seeing. Maybe Ajit or Andy have some ideas. > > -- Kevin > > > On 7/11/2023 3:50 PM, John Hendrikx wrote: >> I tend to avoid ListView, because for some reason it seems to just >> never do what I want unless used for its mundane rows of text use >> case. I so far always just implemented my own skin for ListView that >> deals with displays that have many images that need to scroll >> smoothly, but... >> >> Recently, I've again attempted to use ListView, this time for showing >> (so far) fixed size ImageViews with images exactly 512x512 pixels in >> size: >> >> The cell factory looks like this, which I think is a correct >> implementation: >> >> ????? listView.setCellFactory(lv -> { >> ??????? return new ListCell<>() { >> ????????? protected void updateItem(ImageHandle imageHandle, boolean >> empty) { >> ??????????? if(empty) { >> ????????????? setGraphic(null); >> ??????????? } >> ??????????? else { >> ????????????? try { >> ??????????????? setGraphic(new ImageView(new Image(new >> ByteArrayInputStream(imageHandle.getImageData())))); >> ????????????? } >> ????????????? catch(IOException e) { >> ??????????????? e.printStackTrace(); >> ????????????? } >> ??????????? } >> ????????? } >> ??????? }; >> ????? }); >> >> Now, this is with JavaFX 21-ea-24 (but also happens on 19).? I >> spotted the following IMHO bugs: >> >> 1) When the ImageView is so large that a single row is only partially >> visible, the scrollbar is incorrect (it shows a full bar, even if >> half of a row is displayed). >> >> 2) The vertical scrollbar doesn't respond to a click in the non-thumb >> area at all (you'd expect to make it scroll a page up or down that way) >> >> 3) When jerkily resizing the window, I can sometimes have a vertical >> + horizontal scrollbar when there's a full row visible + anywhere >> from 0 to 10 extra empty pixels (probably the potential height of a >> horizontal scrollbar) with the vertical scroll bar still visible.? >> The algorithm to hide the scrollbar apparently is not deterministic >> and depends on mouse movement speed. >> >> 4) When a row is less than half visible, scrolling the window down to >> another ImageView will jump the view and hide the first cell that >> should still be visible for the bottom 0-49% of its height. >> >> 5) It's possible to get the vertical scroll bar in such a state that >> it doesn't respond to the mouse any more at all, even by dragging the >> thumb.? Some keyboard action and mouse scrolling sometimes restores >> it to relatively normal functioning. >> >> 6) Mouse wheel scrolling acts weird.? With one large cell visible and >> two rows available, scrolling only **down** on the mouse wheel will >> scroll down, then jump back up, and scroll down again... it's >> impossible to scroll all the way down to get to a point where it >> stops scrolling as it keeps jumping back. >> >> This is with ImageView's.? I suppose they're known to have >> problems... but then I switched to a Region, which contain an >> ImageView with proper min/pref/max implementations.? This improved >> the situation somewhat.? The scrollbar was much more reliable, but I >> still saw almost all of the above issues, but somewhat more reliable >> than before.? Still rows would disappear when (for the most part) >> invisible, those and the jumps of the view are just totally >> unacceptable. >> >> I'm not quite sure what to make of this, it seems the control is not >> meant for arbitrary graphics. >> >> --John >> >> >> >> package org.int4.sdui.ui; >> >> import hs.mediasystem.util.image.ImageHandle; >> import hs.mediasystem.util.javafx.control.Containers; >> >> import java.io.ByteArrayInputStream; >> import java.io.IOException; >> import java.util.Base64; >> import java.util.List; >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.ListCell; >> import javafx.scene.control.ListView; >> import javafx.scene.control.TextArea; >> import javafx.scene.image.Image; >> import javafx.scene.image.ImageView; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.Priority; >> import javafx.stage.Stage; >> >> import kong.unirest.core.Unirest; >> >> public class Main { >> >> ? public static void main(String[] args) { >> ??? Application.launch(UI.class, args); >> ? } >> >> ? public static class UI extends Application { >> >> ??? @Override >> ??? public void start(Stage primaryStage) { >> ????? TextArea prompt = new TextArea("a flower on Mars"); >> ????? Button button = new Button("Submit"); >> ????? ListView listView = new ListView<>(); >> >> ????? listView.setCellFactory(lv -> { >> ??????? return new ListCell<>() { >> ????????? protected void updateItem(ImageHandle imageHandle, boolean >> empty) { >> ??????????? if(empty) { >> ????????????? setGraphic(null); >> ??????????? } >> ??????????? else { >> ????????????? try { >> ??????????????? setGraphic(new ImageView(new Image(new >> ByteArrayInputStream(imageHandle.getImageData())))); >> ????????????? } >> ????????????? catch(IOException e) { >> ??????????????? e.printStackTrace(); >> ????????????? } >> ??????????? } >> ????????? } >> ??????? }; >> ????? }); >> >> ????? button.setOnAction(e -> { >> ??????? Txt2ImgResponse response = textToImage(prompt.getText()); >> >> ??????? for(String image : response.images) { >> ????????? listView.getItems().add(new >> InMemoryImageHandle(Base64.getDecoder().decode(image))); >> ??????? } >> ????? }); >> >> ????? HBox hbox = Containers.hbox(Containers.vbox(prompt, button), >> listView); >> >> ????? HBox.setHgrow(listView, Priority.ALWAYS); >> >> ????? Scene scene = new Scene(hbox); >> >> ????? primaryStage.setScene(scene); >> ????? primaryStage.show(); >> ??? } >> >> ??? private Txt2ImgResponse textToImage(String prompt) { >> ????? return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") >> ??????? .body(new Txt2Img(prompt, 5)) >> ??????? .contentType("application/json") >> ??????? .asObject(Txt2ImgResponse.class) >> ??????? .getBody(); >> ??? } >> ? } >> >> ? static class InMemoryImageHandle implements ImageHandle { >> ??? private final byte[] data; >> >> ??? public InMemoryImageHandle(byte[] data) { >> ????? this.data = data; >> ??? } >> >> ??? @Override >> ??? public byte[] getImageData() { >> ????? return data; >> ??? } >> >> ??? @Override >> ??? public String getKey() { >> ????? return null; >> ??? } >> >> ??? @Override >> ??? public boolean isFastSource() { >> ????? return true; >> ??? } >> ? } >> >> ? record Txt2Img(String prompt, int steps) {} >> ? record Txt2ImgResponse(List images) {} >> } >> >> >> > From john.hendrikx at gmail.com Tue Jul 11 23:33:33 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Jul 2023 01:33:33 +0200 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> Message-ID: <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> I said I'd do it tomorrow, but here is a full example anyway with pre-loaded images, and without external dependencies: package org.int4.sdui.ui; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListCell; import javafx.scene.control.ListView; import javafx.scene.control.TextArea; import javafx.scene.image.Image; import javafx.scene.image.ImageView; import javafx.scene.layout.HBox; import javafx.scene.layout.Priority; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class Main2 { ? public static void main(String[] args) { ??? Application.launch(UI.class, args); ? } ? public static class UI extends Application { ??? @Override ??? public void start(Stage primaryStage) throws InterruptedException { ????? Image image1 = new Image("https://picsum.photos/512/512"); ????? Image image2 = new Image("https://picsum.photos/512/512"); ????? TextArea prompt = new TextArea("a flower on Mars"); ????? Button button = new Button("Submit"); ????? ListView listView = new ListView<>(); ????? while(image1.isBackgroundLoading() || image2.isBackgroundLoading()) { ??????? Thread.sleep(100); ????? } ????? listView.getItems().addAll(image1, image2); ????? listView.setCellFactory(lv -> { ??????? final ImageView imageView = new ImageView(); ??????? return new ListCell<>() { ????????? protected void updateItem(Image image, boolean empty) { ??????????? if(empty) { ????????????? setGraphic(null); ??????????? } ??????????? else { ????????????? imageView.setImage(image); ????????????? setGraphic(imageView); ??????????? } ????????? } ??????? }; ????? }); ????? HBox hbox = new HBox() {{ ??????? getChildren().addAll( ????????? new VBox() {{ ??????????? getChildren().addAll(prompt, button); ????????? }}, ????????? listView ??????? ); ????? }}; ????? HBox.setHgrow(listView, Priority.ALWAYS); ????? Scene scene = new Scene(hbox); ????? primaryStage.setScene(scene); ????? primaryStage.show(); ??? } ? } } --John On 12/07/2023 01:17, Andy Goryachev wrote: > > I'll need to replicate this scenario to be able to say anything > definitive. > > Just by looking at the cell factory code though, I suspect there might > be some async processing around > > new ImageView(new Image(new > > ByteArrayInputStream(imageHandle.getImageData())))); > > which might cause the issue. > > Could you try pre-loading images? > > -andy > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Tuesday, July 11, 2023 at 15:58 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: ListView with ImageViews for cells very bugged? > > What you have should work, but will create redundant images and > ImageView ojbects. The recommendation is to create the nodes (ImageView > in this case) in the constructor of the cell factory and call setGraphic > with either null or that factory's node. > > Having said that, I doubt that this is related to the visual problems > you are seeing. Maybe Ajit or Andy have some ideas. > > -- Kevin > > > On 7/11/2023 3:50 PM, John Hendrikx wrote: > > I tend to avoid ListView, because for some reason it seems to just > > never do what I want unless used for its mundane rows of text use > > case. I so far always just implemented my own skin for ListView that > > deals with displays that have many images that need to scroll > > smoothly, but... > > > > Recently, I've again attempted to use ListView, this time for showing > > (so far) fixed size ImageViews with images exactly 512x512 pixels in > > size: > > > > The cell factory looks like this, which I think is a correct > > implementation: > > > > ????? listView.setCellFactory(lv -> { > > ??????? return new ListCell<>() { > > ????????? protected void updateItem(ImageHandle imageHandle, boolean > > empty) { > > ??????????? if(empty) { > > ????????????? setGraphic(null); > > ??????????? } > > ??????????? else { > > ????????????? try { > > ??????????????? setGraphic(new ImageView(new Image(new > > ByteArrayInputStream(imageHandle.getImageData())))); > > ????????????? } > > ????????????? catch(IOException e) { > > ??????????????? e.printStackTrace(); > > ????????????? } > > ??????????? } > > ????????? } > > ??????? }; > > ????? }); > > > > Now, this is with JavaFX 21-ea-24 (but also happens on 19).? I spotted > > the following IMHO bugs: > > > > 1) When the ImageView is so large that a single row is only partially > > visible, the scrollbar is incorrect (it shows a full bar, even if half > > of a row is displayed). > > > > 2) The vertical scrollbar doesn't respond to a click in the non-thumb > > area at all (you'd expect to make it scroll a page up or down that way) > > > > 3) When jerkily resizing the window, I can sometimes have a vertical + > > horizontal scrollbar when there's a full row visible + anywhere from 0 > > to 10 extra empty pixels (probably the potential height of a > > horizontal scrollbar) with the vertical scroll bar still visible.? The > > algorithm to hide the scrollbar apparently is not deterministic and > > depends on mouse movement speed. > > > > 4) When a row is less than half visible, scrolling the window down to > > another ImageView will jump the view and hide the first cell that > > should still be visible for the bottom 0-49% of its height. > > > > 5) It's possible to get the vertical scroll bar in such a state that > > it doesn't respond to the mouse any more at all, even by dragging the > > thumb.? Some keyboard action and mouse scrolling sometimes restores it > > to relatively normal functioning. > > > > 6) Mouse wheel scrolling acts weird.? With one large cell visible and > > two rows available, scrolling only **down** on the mouse wheel will > > scroll down, then jump back up, and scroll down again... it's > > impossible to scroll all the way down to get to a point where it stops > > scrolling as it keeps jumping back. > > > > This is with ImageView's.? I suppose they're known to have problems... > > but then I switched to a Region, which contain an ImageView with > > proper min/pref/max implementations.? This improved the situation > > somewhat.? The scrollbar was much more reliable, but I still saw > > almost all of the above issues, but somewhat more reliable than > > before.? Still rows would disappear when (for the most part) > > invisible, those and the jumps of the view are just totally > unacceptable. > > > > I'm not quite sure what to make of this, it seems the control is not > > meant for arbitrary graphics. > > > > --John > > > > > > > > package org.int4.sdui.ui; > > > > import hs.mediasystem.util.image.ImageHandle; > > import hs.mediasystem.util.javafx.control.Containers; > > > > import java.io.ByteArrayInputStream; > > import java.io.IOException; > > import java.util.Base64; > > import java.util.List; > > > > import javafx.application.Application; > > import javafx.scene.Scene; > > import javafx.scene.control.Button; > > import javafx.scene.control.ListCell; > > import javafx.scene.control.ListView; > > import javafx.scene.control.TextArea; > > import javafx.scene.image.Image; > > import javafx.scene.image.ImageView; > > import javafx.scene.layout.HBox; > > import javafx.scene.layout.Priority; > > import javafx.stage.Stage; > > > > import kong.unirest.core.Unirest; > > > > public class Main { > > > > ? public static void main(String[] args) { > > ??? Application.launch(UI.class, args); > > ? } > > > > ? public static class UI extends Application { > > > > ??? @Override > > ??? public void start(Stage primaryStage) { > > ????? TextArea prompt = new TextArea("a flower on Mars"); > > ????? Button button = new Button("Submit"); > > ????? ListView listView = new ListView<>(); > > > > ????? listView.setCellFactory(lv -> { > > ??????? return new ListCell<>() { > > ????????? protected void updateItem(ImageHandle imageHandle, boolean > > empty) { > > ??????????? if(empty) { > > ????????????? setGraphic(null); > > ??????????? } > > ??????????? else { > > ????????????? try { > > ??????????????? setGraphic(new ImageView(new Image(new > > ByteArrayInputStream(imageHandle.getImageData())))); > > ????????????? } > > ????????????? catch(IOException e) { > > ??????????????? e.printStackTrace(); > > ????????????? } > > ??????????? } > > ????????? } > > ??????? }; > > ????? }); > > > > ????? button.setOnAction(e -> { > > ??????? Txt2ImgResponse response = textToImage(prompt.getText()); > > > > ??????? for(String image : response.images) { > > ????????? listView.getItems().add(new > > InMemoryImageHandle(Base64.getDecoder().decode(image))); > > ??????? } > > ????? }); > > > > ????? HBox hbox = Containers.hbox(Containers.vbox(prompt, button), > > listView); > > > > ????? HBox.setHgrow(listView, Priority.ALWAYS); > > > > ????? Scene scene = new Scene(hbox); > > > > ????? primaryStage.setScene(scene); > > ????? primaryStage.show(); > > ??? } > > > > ??? private Txt2ImgResponse textToImage(String prompt) { > > ????? return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > > ??????? .body(new Txt2Img(prompt, 5)) > > ??????? .contentType("application/json") > > ??????? .asObject(Txt2ImgResponse.class) > > ??????? .getBody(); > > ??? } > > ? } > > > > ? static class InMemoryImageHandle implements ImageHandle { > > ??? private final byte[] data; > > > > ??? public InMemoryImageHandle(byte[] data) { > > ????? this.data = data; > > ??? } > > > > ??? @Override > > ??? public byte[] getImageData() { > > ????? return data; > > ??? } > > > > ??? @Override > > ??? public String getKey() { > > ????? return null; > > ??? } > > > > ??? @Override > > ??? public boolean isFastSource() { > > ????? return true; > > ??? } > > ? } > > > > ? record Txt2Img(String prompt, int steps) {} > > ? record Txt2ImgResponse(List images) {} > > } > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 11 23:48:32 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 11 Jul 2023 23:48:32 +0000 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> Message-ID: Thank you for the code sample, John! Had to replace loading from https:// to a local file://, but I do see some of the issues you've mentioned (on macOS): 2), 5), and 6). There is also a new issue: 7) when the top of the cell is outside of the view area, the image is not shown at all (but the cell is sized correctly). All this is indeed weird. Looks like the time is right to create a bug, unless it's this one: JDK-8090254 [ListView] page up/down navigation doesn't work, when items are large (again!) -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, July 11, 2023 at 16:34 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? I said I'd do it tomorrow, but here is a full example anyway with pre-loaded images, and without external dependencies: package org.int4.sdui.ui; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListCell; import javafx.scene.control.ListView; import javafx.scene.control.TextArea; import javafx.scene.image.Image; import javafx.scene.image.ImageView; import javafx.scene.layout.HBox; import javafx.scene.layout.Priority; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class Main2 { public static void main(String[] args) { Application.launch(UI.class, args); } public static class UI extends Application { @Override public void start(Stage primaryStage) throws InterruptedException { Image image1 = new Image("https://picsum.photos/512/512"); Image image2 = new Image("https://picsum.photos/512/512"); TextArea prompt = new TextArea("a flower on Mars"); Button button = new Button("Submit"); ListView listView = new ListView<>(); while(image1.isBackgroundLoading() || image2.isBackgroundLoading()) { Thread.sleep(100); } listView.getItems().addAll(image1, image2); listView.setCellFactory(lv -> { final ImageView imageView = new ImageView(); return new ListCell<>() { protected void updateItem(Image image, boolean empty) { if(empty) { setGraphic(null); } else { imageView.setImage(image); setGraphic(imageView); } } }; }); HBox hbox = new HBox() {{ getChildren().addAll( new VBox() {{ getChildren().addAll(prompt, button); }}, listView ); }}; HBox.setHgrow(listView, Priority.ALWAYS); Scene scene = new Scene(hbox); primaryStage.setScene(scene); primaryStage.show(); } } } --John On 12/07/2023 01:17, Andy Goryachev wrote: I'll need to replicate this scenario to be able to say anything definitive. Just by looking at the cell factory code though, I suspect there might be some async processing around new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); which might cause the issue. Could you try pre-loading images? -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, July 11, 2023 at 15:58 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? What you have should work, but will create redundant images and ImageView ojbects. The recommendation is to create the nodes (ImageView in this case) in the constructor of the cell factory and call setGraphic with either null or that factory's node. Having said that, I doubt that this is related to the visual problems you are seeing. Maybe Ajit or Andy have some ideas. -- Kevin On 7/11/2023 3:50 PM, John Hendrikx wrote: > I tend to avoid ListView, because for some reason it seems to just > never do what I want unless used for its mundane rows of text use > case. I so far always just implemented my own skin for ListView that > deals with displays that have many images that need to scroll > smoothly, but... > > Recently, I've again attempted to use ListView, this time for showing > (so far) fixed size ImageViews with images exactly 512x512 pixels in > size: > > The cell factory looks like this, which I think is a correct > implementation: > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > Now, this is with JavaFX 21-ea-24 (but also happens on 19). I spotted > the following IMHO bugs: > > 1) When the ImageView is so large that a single row is only partially > visible, the scrollbar is incorrect (it shows a full bar, even if half > of a row is displayed). > > 2) The vertical scrollbar doesn't respond to a click in the non-thumb > area at all (you'd expect to make it scroll a page up or down that way) > > 3) When jerkily resizing the window, I can sometimes have a vertical + > horizontal scrollbar when there's a full row visible + anywhere from 0 > to 10 extra empty pixels (probably the potential height of a > horizontal scrollbar) with the vertical scroll bar still visible. The > algorithm to hide the scrollbar apparently is not deterministic and > depends on mouse movement speed. > > 4) When a row is less than half visible, scrolling the window down to > another ImageView will jump the view and hide the first cell that > should still be visible for the bottom 0-49% of its height. > > 5) It's possible to get the vertical scroll bar in such a state that > it doesn't respond to the mouse any more at all, even by dragging the > thumb. Some keyboard action and mouse scrolling sometimes restores it > to relatively normal functioning. > > 6) Mouse wheel scrolling acts weird. With one large cell visible and > two rows available, scrolling only **down** on the mouse wheel will > scroll down, then jump back up, and scroll down again... it's > impossible to scroll all the way down to get to a point where it stops > scrolling as it keeps jumping back. > > This is with ImageView's. I suppose they're known to have problems... > but then I switched to a Region, which contain an ImageView with > proper min/pref/max implementations. This improved the situation > somewhat. The scrollbar was much more reliable, but I still saw > almost all of the above issues, but somewhat more reliable than > before. Still rows would disappear when (for the most part) > invisible, those and the jumps of the view are just totally unacceptable. > > I'm not quite sure what to make of this, it seems the control is not > meant for arbitrary graphics. > > --John > > > > package org.int4.sdui.ui; > > import hs.mediasystem.util.image.ImageHandle; > import hs.mediasystem.util.javafx.control.Containers; > > import java.io.ByteArrayInputStream; > import java.io.IOException; > import java.util.Base64; > import java.util.List; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListCell; > import javafx.scene.control.ListView; > import javafx.scene.control.TextArea; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.HBox; > import javafx.scene.layout.Priority; > import javafx.stage.Stage; > > import kong.unirest.core.Unirest; > > public class Main { > > public static void main(String[] args) { > Application.launch(UI.class, args); > } > > public static class UI extends Application { > > @Override > public void start(Stage primaryStage) { > TextArea prompt = new TextArea("a flower on Mars"); > Button button = new Button("Submit"); > ListView listView = new ListView<>(); > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > button.setOnAction(e -> { > Txt2ImgResponse response = textToImage(prompt.getText()); > > for(String image : response.images) { > listView.getItems().add(new > InMemoryImageHandle(Base64.getDecoder().decode(image))); > } > }); > > HBox hbox = Containers.hbox(Containers.vbox(prompt, button), > listView); > > HBox.setHgrow(listView, Priority.ALWAYS); > > Scene scene = new Scene(hbox); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > private Txt2ImgResponse textToImage(String prompt) { > return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > .body(new Txt2Img(prompt, 5)) > .contentType("application/json") > .asObject(Txt2ImgResponse.class) > .getBody(); > } > } > > static class InMemoryImageHandle implements ImageHandle { > private final byte[] data; > > public InMemoryImageHandle(byte[] data) { > this.data = data; > } > > @Override > public byte[] getImageData() { > return data; > } > > @Override > public String getKey() { > return null; > } > > @Override > public boolean isFastSource() { > return true; > } > } > > record Txt2Img(String prompt, int steps) {} > record Txt2ImgResponse(List images) {} > } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Wed Jul 12 01:13:06 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 12 Jul 2023 03:13:06 +0200 Subject: CSS Transitions In-Reply-To: References: Message-ID: My comments inline: On Tue, Jul 11, 2023 at 11:28?PM John Hendrikx wrote: > > Should this also provide fx-ease-in (etc) if you want to be compatible > with other FX animations instead of CSS ones (which have little meaning > in FX apps) ? Yes, I think that's a good idea. > > Note that step-wise interpolators are only available for CSS > > Transitions, they are not exposed as new public API in the > > `javafx.animation` framework. The reason for this is that step-wise > > interpolators accept negative input values and can produce different > > results depending on their `step-position` parameter (for details on > > that, see "2.3.1. Output of a step easing function" [5]). > > I would think that an Interpolator still has a defined begin and end > state, regardless if it is step based or a smooth transition. Perhaps > I'm misunderstanding something here about the step based transitions, > but I don't see why the fraction value running from 0 to 1 would be > incompatible with step based transitions. The following interpolator > would create 10 discrete steps: > > new Interpolator() { > @Override > protected double curve(double t) { > return Math.floor(t * 10) / 10; // 10 steps > } > }; > > Add some parameters, and make adjustments for the various CSS jump > types, whether ceil/floor should be used, etc, and I think it could > implement the CSS step variants as well. I think you're right. In general, the distinction is relevant when we are in the delay phase before the active phase and the animated value is back-filled into the delay phase. However, a closer reading of the specification reveals that a CSS transition is not back-filling (which I thought it was). The specification states: "If the current time is at or before the start time of the transition (that is, during the delay phase of the transition), the current value is a specified style that will compute to the start value of the transition." https://www.w3.org/TR/css-transitions-1/#application The start value of the transition is the value of the property before it was affected by the transition. In other words, the transition does not back-fill the first value of the active phase into the delay phase. If we end up implementing CSS Animations, or if we enhance JavaFX animations to support different fill modes, we would need to change the specification of interpolators to accept negative values, or add a side channel to pass in the "before-active" information. From ajit.ghaisas at oracle.com Wed Jul 12 09:26:58 2023 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 12 Jul 2023 09:26:58 +0000 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> Message-ID: <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Hi John, This looks like a user code issue and not a JavaFX bug. Most of the vertical scrollbar issues that you have mentioned get fixed by adding a call to "super.updateItem(image, empty);" as a first call in the cell factory method "protected void updateItem(Image image, boolean empty)? I am seeing an exception when I scroll fully down and then scroll up by clicking empty area on the vertical scrollbar. This looks like a separate issue though. Regards, Ajit On 12-Jul-2023, at 5:18 AM, Andy Goryachev wrote: Thank you for the code sample, John! Had to replace loading from https:// to a local file://, but I do see some of the issues you've mentioned (on macOS): 2), 5), and 6). There is also a new issue: 7) when the top of the cell is outside of the view area, the image is not shown at all (but the cell is sized correctly). All this is indeed weird. Looks like the time is right to create a bug, unless it's this one: JDK-8090254 [ListView] page up/down navigation doesn't work, when items are large (again!) -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, July 11, 2023 at 16:34 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? I said I'd do it tomorrow, but here is a full example anyway with pre-loaded images, and without external dependencies: package org.int4.sdui.ui; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListCell; import javafx.scene.control.ListView; import javafx.scene.control.TextArea; import javafx.scene.image.Image; import javafx.scene.image.ImageView; import javafx.scene.layout.HBox; import javafx.scene.layout.Priority; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class Main2 { public static void main(String[] args) { Application.launch(UI.class, args); } public static class UI extends Application { @Override public void start(Stage primaryStage) throws InterruptedException { Image image1 = new Image("https://picsum.photos/512/512"); Image image2 = new Image("https://picsum.photos/512/512"); TextArea prompt = new TextArea("a flower on Mars"); Button button = new Button("Submit"); ListView listView = new ListView<>(); while(image1.isBackgroundLoading() || image2.isBackgroundLoading()) { Thread.sleep(100); } listView.getItems().addAll(image1, image2); listView.setCellFactory(lv -> { final ImageView imageView = new ImageView(); return new ListCell<>() { protected void updateItem(Image image, boolean empty) { if(empty) { setGraphic(null); } else { imageView.setImage(image); setGraphic(imageView); } } }; }); HBox hbox = new HBox() {{ getChildren().addAll( new VBox() {{ getChildren().addAll(prompt, button); }}, listView ); }}; HBox.setHgrow(listView, Priority.ALWAYS); Scene scene = new Scene(hbox); primaryStage.setScene(scene); primaryStage.show(); } } } --John On 12/07/2023 01:17, Andy Goryachev wrote: I'll need to replicate this scenario to be able to say anything definitive. Just by looking at the cell factory code though, I suspect there might be some async processing around new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); which might cause the issue. Could you try pre-loading images? -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, July 11, 2023 at 15:58 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? What you have should work, but will create redundant images and ImageView ojbects. The recommendation is to create the nodes (ImageView in this case) in the constructor of the cell factory and call setGraphic with either null or that factory's node. Having said that, I doubt that this is related to the visual problems you are seeing. Maybe Ajit or Andy have some ideas. -- Kevin On 7/11/2023 3:50 PM, John Hendrikx wrote: > I tend to avoid ListView, because for some reason it seems to just > never do what I want unless used for its mundane rows of text use > case. I so far always just implemented my own skin for ListView that > deals with displays that have many images that need to scroll > smoothly, but... > > Recently, I've again attempted to use ListView, this time for showing > (so far) fixed size ImageViews with images exactly 512x512 pixels in > size: > > The cell factory looks like this, which I think is a correct > implementation: > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > Now, this is with JavaFX 21-ea-24 (but also happens on 19). I spotted > the following IMHO bugs: > > 1) When the ImageView is so large that a single row is only partially > visible, the scrollbar is incorrect (it shows a full bar, even if half > of a row is displayed). > > 2) The vertical scrollbar doesn't respond to a click in the non-thumb > area at all (you'd expect to make it scroll a page up or down that way) > > 3) When jerkily resizing the window, I can sometimes have a vertical + > horizontal scrollbar when there's a full row visible + anywhere from 0 > to 10 extra empty pixels (probably the potential height of a > horizontal scrollbar) with the vertical scroll bar still visible. The > algorithm to hide the scrollbar apparently is not deterministic and > depends on mouse movement speed. > > 4) When a row is less than half visible, scrolling the window down to > another ImageView will jump the view and hide the first cell that > should still be visible for the bottom 0-49% of its height. > > 5) It's possible to get the vertical scroll bar in such a state that > it doesn't respond to the mouse any more at all, even by dragging the > thumb. Some keyboard action and mouse scrolling sometimes restores it > to relatively normal functioning. > > 6) Mouse wheel scrolling acts weird. With one large cell visible and > two rows available, scrolling only **down** on the mouse wheel will > scroll down, then jump back up, and scroll down again... it's > impossible to scroll all the way down to get to a point where it stops > scrolling as it keeps jumping back. > > This is with ImageView's. I suppose they're known to have problems... > but then I switched to a Region, which contain an ImageView with > proper min/pref/max implementations. This improved the situation > somewhat. The scrollbar was much more reliable, but I still saw > almost all of the above issues, but somewhat more reliable than > before. Still rows would disappear when (for the most part) > invisible, those and the jumps of the view are just totally unacceptable. > > I'm not quite sure what to make of this, it seems the control is not > meant for arbitrary graphics. > > --John > > > > package org.int4.sdui.ui; > > import hs.mediasystem.util.image.ImageHandle; > import hs.mediasystem.util.javafx.control.Containers; > > import java.io.ByteArrayInputStream; > import java.io.IOException; > import java.util.Base64; > import java.util.List; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListCell; > import javafx.scene.control.ListView; > import javafx.scene.control.TextArea; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.HBox; > import javafx.scene.layout.Priority; > import javafx.stage.Stage; > > import kong.unirest.core.Unirest; > > public class Main { > > public static void main(String[] args) { > Application.launch(UI.class, args); > } > > public static class UI extends Application { > > @Override > public void start(Stage primaryStage) { > TextArea prompt = new TextArea("a flower on Mars"); > Button button = new Button("Submit"); > ListView listView = new ListView<>(); > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > button.setOnAction(e -> { > Txt2ImgResponse response = textToImage(prompt.getText()); > > for(String image : response.images) { > listView.getItems().add(new > InMemoryImageHandle(Base64.getDecoder().decode(image))); > } > }); > > HBox hbox = Containers.hbox(Containers.vbox(prompt, button), > listView); > > HBox.setHgrow(listView, Priority.ALWAYS); > > Scene scene = new Scene(hbox); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > private Txt2ImgResponse textToImage(String prompt) { > return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > .body(new Txt2Img(prompt, 5)) > .contentType("application/json") > .asObject(Txt2ImgResponse.class) > .getBody(); > } > } > > static class InMemoryImageHandle implements ImageHandle { > private final byte[] data; > > public InMemoryImageHandle(byte[] data) { > this.data = data; > } > > @Override > public byte[] getImageData() { > return data; > } > > @Override > public String getKey() { > return null; > } > > @Override > public boolean isFastSource() { > return true; > } > } > > record Txt2Img(String prompt, int steps) {} > record Txt2ImgResponse(List images) {} > } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Wed Jul 12 13:31:28 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 12 Jul 2023 13:31:28 GMT Subject: RFR: 8310582: Update copyright header for files modified in 2023 Message-ID: <3sj90GhBO-T4w3VVp0y_Md1t-p20fktD8i-UBPmGmhg=.b721d179-2638-4f57-a6e1-6e438d7bec68@github.com> Updating last modified year in copyright header of the files that were modified during year 2023. ------------- Commit messages: - 8310582: Update copyright header for files modified in 2023 Changes: https://git.openjdk.org/jfx/pull/1176/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1176&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310582 Stats: 328 lines in 328 files changed: 0 ins; 0 del; 328 mod Patch: https://git.openjdk.org/jfx/pull/1176.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1176/head:pull/1176 PR: https://git.openjdk.org/jfx/pull/1176 From kcr at openjdk.org Wed Jul 12 13:54:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Jul 2023 13:54:10 GMT Subject: RFR: 8310582: Update copyright header for files modified in 2023 In-Reply-To: <3sj90GhBO-T4w3VVp0y_Md1t-p20fktD8i-UBPmGmhg=.b721d179-2638-4f57-a6e1-6e438d7bec68@github.com> References: <3sj90GhBO-T4w3VVp0y_Md1t-p20fktD8i-UBPmGmhg=.b721d179-2638-4f57-a6e1-6e438d7bec68@github.com> Message-ID: On Wed, 12 Jul 2023 13:24:16 GMT, Ambarish Rapte wrote: > Updating last modified year in copyright header of the files that were modified during year 2023. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1176#pullrequestreview-1526415853 From andy.goryachev at oracle.com Wed Jul 12 14:50:43 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 12 Jul 2023 14:50:43 +0000 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: Ajit is right - perhaps javadoc for updateItem() should explicitly mention this? Also, perhaps https://bugs.openjdk.org/browse/JDK-8090254 should be closed - we recently updated javadoc to read Warning: Nodes should not be inserted directly into the items list (this is a different issue altogether) -andy From: Ajit Ghaisas Date: Wednesday, July 12, 2023 at 02:26 To: John Hendrikx Cc: openjfx-dev at openjdk.org , Andy Goryachev Subject: Re: ListView with ImageViews for cells very bugged? Hi John, This looks like a user code issue and not a JavaFX bug. Most of the vertical scrollbar issues that you have mentioned get fixed by adding a call to "super.updateItem(image, empty);" as a first call in the cell factory method "protected void updateItem(Image image, boolean empty)? I am seeing an exception when I scroll fully down and then scroll up by clicking empty area on the vertical scrollbar. This looks like a separate issue though. Regards, Ajit On 12-Jul-2023, at 5:18 AM, Andy Goryachev wrote: Thank you for the code sample, John! Had to replace loading from https:// to a local file://, but I do see some of the issues you've mentioned (on macOS): 2), 5), and 6). There is also a new issue: 7) when the top of the cell is outside of the view area, the image is not shown at all (but the cell is sized correctly). All this is indeed weird. Looks like the time is right to create a bug, unless it's this one: JDK-8090254 [ListView] page up/down navigation doesn't work, when items are large (again!) -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, July 11, 2023 at 16:34 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? I said I'd do it tomorrow, but here is a full example anyway with pre-loaded images, and without external dependencies: package org.int4.sdui.ui; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListCell; import javafx.scene.control.ListView; import javafx.scene.control.TextArea; import javafx.scene.image.Image; import javafx.scene.image.ImageView; import javafx.scene.layout.HBox; import javafx.scene.layout.Priority; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class Main2 { public static void main(String[] args) { Application.launch(UI.class, args); } public static class UI extends Application { @Override public void start(Stage primaryStage) throws InterruptedException { Image image1 = new Image("https://picsum.photos/512/512"); Image image2 = new Image("https://picsum.photos/512/512"); TextArea prompt = new TextArea("a flower on Mars"); Button button = new Button("Submit"); ListView listView = new ListView<>(); while(image1.isBackgroundLoading() || image2.isBackgroundLoading()) { Thread.sleep(100); } listView.getItems().addAll(image1, image2); listView.setCellFactory(lv -> { final ImageView imageView = new ImageView(); return new ListCell<>() { protected void updateItem(Image image, boolean empty) { if(empty) { setGraphic(null); } else { imageView.setImage(image); setGraphic(imageView); } } }; }); HBox hbox = new HBox() {{ getChildren().addAll( new VBox() {{ getChildren().addAll(prompt, button); }}, listView ); }}; HBox.setHgrow(listView, Priority.ALWAYS); Scene scene = new Scene(hbox); primaryStage.setScene(scene); primaryStage.show(); } } } --John On 12/07/2023 01:17, Andy Goryachev wrote: I'll need to replicate this scenario to be able to say anything definitive. Just by looking at the cell factory code though, I suspect there might be some async processing around new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); which might cause the issue. Could you try pre-loading images? -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, July 11, 2023 at 15:58 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? What you have should work, but will create redundant images and ImageView ojbects. The recommendation is to create the nodes (ImageView in this case) in the constructor of the cell factory and call setGraphic with either null or that factory's node. Having said that, I doubt that this is related to the visual problems you are seeing. Maybe Ajit or Andy have some ideas. -- Kevin On 7/11/2023 3:50 PM, John Hendrikx wrote: > I tend to avoid ListView, because for some reason it seems to just > never do what I want unless used for its mundane rows of text use > case. I so far always just implemented my own skin for ListView that > deals with displays that have many images that need to scroll > smoothly, but... > > Recently, I've again attempted to use ListView, this time for showing > (so far) fixed size ImageViews with images exactly 512x512 pixels in > size: > > The cell factory looks like this, which I think is a correct > implementation: > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > Now, this is with JavaFX 21-ea-24 (but also happens on 19). I spotted > the following IMHO bugs: > > 1) When the ImageView is so large that a single row is only partially > visible, the scrollbar is incorrect (it shows a full bar, even if half > of a row is displayed). > > 2) The vertical scrollbar doesn't respond to a click in the non-thumb > area at all (you'd expect to make it scroll a page up or down that way) > > 3) When jerkily resizing the window, I can sometimes have a vertical + > horizontal scrollbar when there's a full row visible + anywhere from 0 > to 10 extra empty pixels (probably the potential height of a > horizontal scrollbar) with the vertical scroll bar still visible. The > algorithm to hide the scrollbar apparently is not deterministic and > depends on mouse movement speed. > > 4) When a row is less than half visible, scrolling the window down to > another ImageView will jump the view and hide the first cell that > should still be visible for the bottom 0-49% of its height. > > 5) It's possible to get the vertical scroll bar in such a state that > it doesn't respond to the mouse any more at all, even by dragging the > thumb. Some keyboard action and mouse scrolling sometimes restores it > to relatively normal functioning. > > 6) Mouse wheel scrolling acts weird. With one large cell visible and > two rows available, scrolling only **down** on the mouse wheel will > scroll down, then jump back up, and scroll down again... it's > impossible to scroll all the way down to get to a point where it stops > scrolling as it keeps jumping back. > > This is with ImageView's. I suppose they're known to have problems... > but then I switched to a Region, which contain an ImageView with > proper min/pref/max implementations. This improved the situation > somewhat. The scrollbar was much more reliable, but I still saw > almost all of the above issues, but somewhat more reliable than > before. Still rows would disappear when (for the most part) > invisible, those and the jumps of the view are just totally unacceptable. > > I'm not quite sure what to make of this, it seems the control is not > meant for arbitrary graphics. > > --John > > > > package org.int4.sdui.ui; > > import hs.mediasystem.util.image.ImageHandle; > import hs.mediasystem.util.javafx.control.Containers; > > import java.io.ByteArrayInputStream; > import java.io.IOException; > import java.util.Base64; > import java.util.List; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListCell; > import javafx.scene.control.ListView; > import javafx.scene.control.TextArea; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.HBox; > import javafx.scene.layout.Priority; > import javafx.stage.Stage; > > import kong.unirest.core.Unirest; > > public class Main { > > public static void main(String[] args) { > Application.launch(UI.class, args); > } > > public static class UI extends Application { > > @Override > public void start(Stage primaryStage) { > TextArea prompt = new TextArea("a flower on Mars"); > Button button = new Button("Submit"); > ListView listView = new ListView<>(); > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > button.setOnAction(e -> { > Txt2ImgResponse response = textToImage(prompt.getText()); > > for(String image : response.images) { > listView.getItems().add(new > InMemoryImageHandle(Base64.getDecoder().decode(image))); > } > }); > > HBox hbox = Containers.hbox(Containers.vbox(prompt, button), > listView); > > HBox.setHgrow(listView, Priority.ALWAYS); > > Scene scene = new Scene(hbox); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > private Txt2ImgResponse textToImage(String prompt) { > return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > .body(new Txt2Img(prompt, 5)) > .contentType("application/json") > .asObject(Txt2ImgResponse.class) > .getBody(); > } > } > > static class InMemoryImageHandle implements ImageHandle { > private final byte[] data; > > public InMemoryImageHandle(byte[] data) { > this.data = data; > } > > @Override > public byte[] getImageData() { > return data; > } > > @Override > public String getKey() { > return null; > } > > @Override > public boolean isFastSource() { > return true; > } > } > > record Txt2Img(String prompt, int steps) {} > record Txt2ImgResponse(List images) {} > } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Jul 12 14:57:10 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 12 Jul 2023 07:57:10 -0700 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: The updateItem docs [1] already say this. I had missed that the test program didn't do this, so thanks to Ajit for pointing it out. And yes, https://bugs.openjdk.org/browse/JDK-8090254 should be closed as not an issue with a reference to the doc bug that clarified this. -- Kevin [1] https://download.java.net/java/early_access/javafx21/docs/api/javafx.controls/javafx/scene/control/Cell.html#updateItem(T,boolean) On 7/12/2023 7:50 AM, Andy Goryachev wrote: > > Ajit is right - perhaps javadoc for updateItem() should explicitly > mention this? > > Also, perhaps https://bugs.openjdk.org/browse/JDK-8090254 should be > closed - we recently updated javadoc to read > > > Warning: Nodes should not be inserted directly into the items list > > (this is a different issue altogether) > > -andy > > *From: *Ajit Ghaisas > *Date: *Wednesday, July 12, 2023 at 02:26 > *To: *John Hendrikx > *Cc: *openjfx-dev at openjdk.org , Andy > Goryachev > *Subject: *Re: ListView with ImageViews for cells very bugged? > > Hi John, > > ?This looks like a user code issue and not a JavaFX bug. > > ?Most of the vertical scrollbar issues that you have mentioned get > fixed by adding a call to "super.updateItem(image, empty);" as a first > call in the cell factory method "protected void updateItem(Image > image, boolean empty)? > > I am seeing an exception when I scroll fully down and then scroll up > by clicking empty area on the vertical scrollbar. This looks like a > separate issue though. > > Regards, > > Ajit > > > > On 12-Jul-2023, at 5:18 AM, Andy Goryachev > wrote: > > Thank you for the code sample, John! > > Had to replace loading from https:// to a local file://, but I do > see some of the issues you've mentioned (on macOS): > > 2), 5), and 6). > > There is also a new issue: > > 7) when the top of the cell is outside of the view area, the image > is not shown at all (but the cell is sized correctly). > > All this is indeed weird. Looks like the time is right to create a > bug, unless it's this one: > > JDK-8090254 > > > > [ListView] page up/down navigation doesn't work, when items are > large (again!) > > -andy > > *From:*openjfx-dev on behalf of > John Hendrikx > *Date:*Tuesday, July 11, 2023 at 16:34 > *To:*openjfx-dev at openjdk.org > *Subject:*Re: ListView with ImageViews for cells very bugged? > > I said I'd do it tomorrow, but here is a full example anyway with > pre-loaded images, and without external dependencies: > > package org.int4.sdui.ui; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListCell; > import javafx.scene.control.ListView; > import javafx.scene.control.TextArea; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.HBox; > import javafx.scene.layout.Priority; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class Main2 { > > ? public static void main(String[] args) { > ??? Application.launch(UI.class, args); > ? } > > ? public static class UI extends Application { > > ??? @Override > ??? public void start(Stage primaryStage) throws > InterruptedException { > ????? Image image1 = new Image("https://picsum.photos/512/512" > ); > ????? Image image2 = new Image("https://picsum.photos/512/512" > ); > > ????? TextArea prompt = new TextArea("a flower on Mars"); > ????? Button button = new Button("Submit"); > ????? ListView listView = new ListView<>(); > > ????? while(image1.isBackgroundLoading() || > image2.isBackgroundLoading()) { > ??????? Thread.sleep(100); > ????? } > > ????? listView.getItems().addAll(image1, image2); > ????? listView.setCellFactory(lv -> { > ??????? final ImageView imageView = new ImageView(); > > ??????? return new ListCell<>() { > ????????? protected void updateItem(Image image, boolean empty) { > ??????????? if(empty) { > ????????????? setGraphic(null); > ??????????? } > ??????????? else { > ????????????? imageView.setImage(image); > ????????????? setGraphic(imageView); > ??????????? } > ????????? } > ??????? }; > ????? }); > > ????? HBox hbox = new HBox() {{ > ??????? getChildren().addAll( > ????????? new VBox() {{ > ??????????? getChildren().addAll(prompt, button); > ????????? }}, > ????????? listView > ??????? ); > ????? }}; > > ????? HBox.setHgrow(listView, Priority.ALWAYS); > > ????? Scene scene = new Scene(hbox); > > ????? primaryStage.setScene(scene); > ????? primaryStage.show(); > ??? } > ? } > } > > > > > > --John > > On 12/07/2023 01:17, Andy Goryachev wrote: > > I'll need to replicate this scenario to be able to say > anything definitive. > > Just by looking at the cell factory code though, I suspect > there might be some async processing around > > new ImageView(new Image(new > > ByteArrayInputStream(imageHandle.getImageData())))); > > which might cause the issue. > > Could you try pre-loading images? > > -andy > > *From:*openjfx-dev > on behalf of Kevin > Rushforth > > *Date:*Tuesday, July 11, 2023 at 15:58 > *To:*openjfx-dev at openjdk.org > > *Subject:*Re: ListView with ImageViews for cells very bugged? > > What you have should work, but will create redundant images and > ImageView ojbects. The recommendation is to create the nodes > (ImageView > in this case) in the constructor of the cell factory and call > setGraphic > with either null or that factory's node. > > Having said that, I doubt that this is related to the visual > problems > you are seeing. Maybe Ajit or Andy have some ideas. > > -- Kevin > > > On 7/11/2023 3:50 PM, John Hendrikx wrote: > > I tend to avoid ListView, because for some reason it seems > to just > > never do what I want unless used for its mundane rows of > text use > > case. I so far always just implemented my own skin for > ListView that > > deals with displays that have many images that need to scroll > > smoothly, but... > > > > Recently, I've again attempted to use ListView, this time > for showing > > (so far) fixed size ImageViews with images exactly 512x512 > pixels in > > size: > > > > The cell factory looks like this, which I think is a correct > > implementation: > > > > listView.setCellFactory(lv -> { > > ??????? return new ListCell<>() { > > ????????? protected void updateItem(ImageHandle imageHandle, > boolean > > empty) { > > ??????????? if(empty) { > > ????????????? setGraphic(null); > > ??????????? } > > ??????????? else { > > ????????????? try { > > ??????????????? setGraphic(new ImageView(new Image(new > > ByteArrayInputStream(imageHandle.getImageData())))); > > ????????????? } > > ????????????? catch(IOException e) { > > e.printStackTrace(); > > ????????????? } > > ??????????? } > > ????????? } > > ??????? }; > > ????? }); > > > > Now, this is with JavaFX 21-ea-24 (but also happens on 19). > I spotted > > the following IMHO bugs: > > > > 1) When the ImageView is so large that a single row is only > partially > > visible, the scrollbar is incorrect (it shows a full bar, > even if half > > of a row is displayed). > > > > 2) The vertical scrollbar doesn't respond to a click in the > non-thumb > > area at all (you'd expect to make it scroll a page up or > down that way) > > > > 3) When jerkily resizing the window, I can sometimes have a > vertical + > > horizontal scrollbar when there's a full row visible + > anywhere from 0 > > to 10 extra empty pixels (probably the potential height of a > > horizontal scrollbar) with the vertical scroll bar still > visible. The > > algorithm to hide the scrollbar apparently is not > deterministic and > > depends on mouse movement speed. > > > > 4) When a row is less than half visible, scrolling the > window down to > > another ImageView will jump the view and hide the first cell > that > > should still be visible for the bottom 0-49% of its height. > > > > 5) It's possible to get the vertical scroll bar in such a > state that > > it doesn't respond to the mouse any more at all, even by > dragging the > > thumb.? Some keyboard action and mouse scrolling sometimes > restores it > > to relatively normal functioning. > > > > 6) Mouse wheel scrolling acts weird.? With one large cell > visible and > > two rows available, scrolling only **down** on the mouse > wheel will > > scroll down, then jump back up, and scroll down again... it's > > impossible to scroll all the way down to get to a point > where it stops > > scrolling as it keeps jumping back. > > > > This is with ImageView's.? I suppose they're known to have > problems... > > but then I switched to a Region, which contain an ImageView with > > proper min/pref/max implementations.? This improved the > situation > > somewhat.? The scrollbar was much more reliable, but I still saw > > almost all of the above issues, but somewhat more reliable than > > before.? Still rows would disappear when (for the most part) > > invisible, those and the jumps of the view are just totally > unacceptable. > > > > I'm not quite sure what to make of this, it seems the > control is not > > meant for arbitrary graphics. > > > > --John > > > > > > > > package org.int4.sdui.ui; > > > > import hs.mediasystem.util.image.ImageHandle; > > import hs.mediasystem.util.javafx.control.Containers; > > > > import java.io.ByteArrayInputStream; > > import java.io.IOException; > > import java.util.Base64; > > import java.util.List; > > > > import javafx.application.Application; > > import javafx.scene.Scene; > > import javafx.scene.control.Button; > > import javafx.scene.control.ListCell; > > import javafx.scene.control.ListView; > > import javafx.scene.control.TextArea; > > import javafx.scene.image.Image; > > import javafx.scene.image.ImageView; > > import javafx.scene.layout.HBox; > > import javafx.scene.layout.Priority; > > import javafx.stage.Stage; > > > > import kong.unirest.core.Unirest; > > > > public class Main { > > > > ? public static void main(String[] args) { > > Application.launch(UI.class, args); > > ? } > > > > ? public static class UI extends Application { > > > > ??? @Override > > ??? public void start(Stage primaryStage) { > > ????? TextArea prompt = new TextArea("a flower on Mars"); > > ????? Button button = new Button("Submit"); > > ListView listView = new ListView<>(); > > > > listView.setCellFactory(lv -> { > > ??????? return new ListCell<>() { > > ????????? protected void updateItem(ImageHandle imageHandle, > boolean > > empty) { > > ??????????? if(empty) { > > ????????????? setGraphic(null); > > ??????????? } > > ??????????? else { > > ????????????? try { > > ??????????????? setGraphic(new ImageView(new Image(new > > ByteArrayInputStream(imageHandle.getImageData())))); > > ????????????? } > > ????????????? catch(IOException e) { > > e.printStackTrace(); > > ????????????? } > > ??????????? } > > ????????? } > > ??????? }; > > ????? }); > > > > ????? button.setOnAction(e -> { > > ??????? Txt2ImgResponse response = > textToImage(prompt.getText()); > > > > ??????? for(String image : response.images) { > > listView.getItems().add(new > > InMemoryImageHandle(Base64.getDecoder().decode(image))); > > ??????? } > > ????? }); > > > > ????? HBox hbox = Containers.hbox(Containers.vbox(prompt, > button), > > listView); > > > > ????? HBox.setHgrow(listView, Priority.ALWAYS); > > > > ????? Scene scene = new Scene(hbox); > > > > primaryStage.setScene(scene); > > ????? primaryStage.show(); > > ??? } > > > > ??? private Txt2ImgResponse textToImage(String prompt) { > > ????? return > Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > > ??????? .body(new Txt2Img(prompt, 5)) > > .contentType("application/json") > > .asObject(Txt2ImgResponse.class) > > ??????? .getBody(); > > ??? } > > ? } > > > > ? static class InMemoryImageHandle implements ImageHandle { > > ??? private final byte[] data; > > > > ??? public InMemoryImageHandle(byte[] data) { > > ????? this.data = data; > > ??? } > > > > ??? @Override > > ??? public byte[] getImageData() { > > ????? return data; > > ??? } > > > > ??? @Override > > ??? public String getKey() { > > ????? return null; > > ??? } > > > > ??? @Override > > ??? public boolean isFastSource() { > > ????? return true; > > ??? } > > ? } > > > > ? record Txt2Img(String prompt, int steps) {} > > ? record Txt2ImgResponse(List images) {} > > } > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Jul 12 15:13:46 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 12 Jul 2023 15:13:46 +0000 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: resending with a smaller screenshot - From: Andy Goryachev Date: Wednesday, July 12, 2023 at 08:02 To: Kevin Rushforth , Ajit Ghaisas , John Hendrikx Cc: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? I think we just found a bug in Eclipse: it shows javadoc for the wrong method - [cid:image002.png at 01D9B498.B88B8400] :-( -andy From: Kevin Rushforth Date: Wednesday, July 12, 2023 at 07:57 To: Andy Goryachev , Ajit Ghaisas , John Hendrikx Cc: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? The updateItem docs [1] already say this. I had missed that the test program didn't do this, so thanks to Ajit for pointing it out. And yes, https://bugs.openjdk.org/browse/JDK-8090254 should be closed as not an issue with a reference to the doc bug that clarified this. -- Kevin [1] https://download.java.net/java/early_access/javafx21/docs/api/javafx.controls/javafx/scene/control/Cell.html#updateItem(T,boolean) On 7/12/2023 7:50 AM, Andy Goryachev wrote: Ajit is right - perhaps javadoc for updateItem() should explicitly mention this? Also, perhaps https://bugs.openjdk.org/browse/JDK-8090254 should be closed - we recently updated javadoc to read Warning: Nodes should not be inserted directly into the items list (this is a different issue altogether) -andy From: Ajit Ghaisas Date: Wednesday, July 12, 2023 at 02:26 To: John Hendrikx Cc: openjfx-dev at openjdk.org , Andy Goryachev Subject: Re: ListView with ImageViews for cells very bugged? Hi John, This looks like a user code issue and not a JavaFX bug. Most of the vertical scrollbar issues that you have mentioned get fixed by adding a call to "super.updateItem(image, empty);" as a first call in the cell factory method "protected void updateItem(Image image, boolean empty)? I am seeing an exception when I scroll fully down and then scroll up by clicking empty area on the vertical scrollbar. This looks like a separate issue though. Regards, Ajit On 12-Jul-2023, at 5:18 AM, Andy Goryachev wrote: Thank you for the code sample, John! Had to replace loading from https:// to a local file://, but I do see some of the issues you've mentioned (on macOS): 2), 5), and 6). There is also a new issue: 7) when the top of the cell is outside of the view area, the image is not shown at all (but the cell is sized correctly). All this is indeed weird. Looks like the time is right to create a bug, unless it's this one: JDK-8090254 [ListView] page up/down navigation doesn't work, when items are large (again!) -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, July 11, 2023 at 16:34 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? I said I'd do it tomorrow, but here is a full example anyway with pre-loaded images, and without external dependencies: package org.int4.sdui.ui; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListCell; import javafx.scene.control.ListView; import javafx.scene.control.TextArea; import javafx.scene.image.Image; import javafx.scene.image.ImageView; import javafx.scene.layout.HBox; import javafx.scene.layout.Priority; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class Main2 { public static void main(String[] args) { Application.launch(UI.class, args); } public static class UI extends Application { @Override public void start(Stage primaryStage) throws InterruptedException { Image image1 = new Image("https://picsum.photos/512/512"); Image image2 = new Image("https://picsum.photos/512/512"); TextArea prompt = new TextArea("a flower on Mars"); Button button = new Button("Submit"); ListView listView = new ListView<>(); while(image1.isBackgroundLoading() || image2.isBackgroundLoading()) { Thread.sleep(100); } listView.getItems().addAll(image1, image2); listView.setCellFactory(lv -> { final ImageView imageView = new ImageView(); return new ListCell<>() { protected void updateItem(Image image, boolean empty) { if(empty) { setGraphic(null); } else { imageView.setImage(image); setGraphic(imageView); } } }; }); HBox hbox = new HBox() {{ getChildren().addAll( new VBox() {{ getChildren().addAll(prompt, button); }}, listView ); }}; HBox.setHgrow(listView, Priority.ALWAYS); Scene scene = new Scene(hbox); primaryStage.setScene(scene); primaryStage.show(); } } } --John On 12/07/2023 01:17, Andy Goryachev wrote: I'll need to replicate this scenario to be able to say anything definitive. Just by looking at the cell factory code though, I suspect there might be some async processing around new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); which might cause the issue. Could you try pre-loading images? -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, July 11, 2023 at 15:58 To: openjfx-dev at openjdk.org Subject: Re: ListView with ImageViews for cells very bugged? What you have should work, but will create redundant images and ImageView ojbects. The recommendation is to create the nodes (ImageView in this case) in the constructor of the cell factory and call setGraphic with either null or that factory's node. Having said that, I doubt that this is related to the visual problems you are seeing. Maybe Ajit or Andy have some ideas. -- Kevin On 7/11/2023 3:50 PM, John Hendrikx wrote: > I tend to avoid ListView, because for some reason it seems to just > never do what I want unless used for its mundane rows of text use > case. I so far always just implemented my own skin for ListView that > deals with displays that have many images that need to scroll > smoothly, but... > > Recently, I've again attempted to use ListView, this time for showing > (so far) fixed size ImageViews with images exactly 512x512 pixels in > size: > > The cell factory looks like this, which I think is a correct > implementation: > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > Now, this is with JavaFX 21-ea-24 (but also happens on 19). I spotted > the following IMHO bugs: > > 1) When the ImageView is so large that a single row is only partially > visible, the scrollbar is incorrect (it shows a full bar, even if half > of a row is displayed). > > 2) The vertical scrollbar doesn't respond to a click in the non-thumb > area at all (you'd expect to make it scroll a page up or down that way) > > 3) When jerkily resizing the window, I can sometimes have a vertical + > horizontal scrollbar when there's a full row visible + anywhere from 0 > to 10 extra empty pixels (probably the potential height of a > horizontal scrollbar) with the vertical scroll bar still visible. The > algorithm to hide the scrollbar apparently is not deterministic and > depends on mouse movement speed. > > 4) When a row is less than half visible, scrolling the window down to > another ImageView will jump the view and hide the first cell that > should still be visible for the bottom 0-49% of its height. > > 5) It's possible to get the vertical scroll bar in such a state that > it doesn't respond to the mouse any more at all, even by dragging the > thumb. Some keyboard action and mouse scrolling sometimes restores it > to relatively normal functioning. > > 6) Mouse wheel scrolling acts weird. With one large cell visible and > two rows available, scrolling only **down** on the mouse wheel will > scroll down, then jump back up, and scroll down again... it's > impossible to scroll all the way down to get to a point where it stops > scrolling as it keeps jumping back. > > This is with ImageView's. I suppose they're known to have problems... > but then I switched to a Region, which contain an ImageView with > proper min/pref/max implementations. This improved the situation > somewhat. The scrollbar was much more reliable, but I still saw > almost all of the above issues, but somewhat more reliable than > before. Still rows would disappear when (for the most part) > invisible, those and the jumps of the view are just totally unacceptable. > > I'm not quite sure what to make of this, it seems the control is not > meant for arbitrary graphics. > > --John > > > > package org.int4.sdui.ui; > > import hs.mediasystem.util.image.ImageHandle; > import hs.mediasystem.util.javafx.control.Containers; > > import java.io.ByteArrayInputStream; > import java.io.IOException; > import java.util.Base64; > import java.util.List; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListCell; > import javafx.scene.control.ListView; > import javafx.scene.control.TextArea; > import javafx.scene.image.Image; > import javafx.scene.image.ImageView; > import javafx.scene.layout.HBox; > import javafx.scene.layout.Priority; > import javafx.stage.Stage; > > import kong.unirest.core.Unirest; > > public class Main { > > public static void main(String[] args) { > Application.launch(UI.class, args); > } > > public static class UI extends Application { > > @Override > public void start(Stage primaryStage) { > TextArea prompt = new TextArea("a flower on Mars"); > Button button = new Button("Submit"); > ListView listView = new ListView<>(); > > listView.setCellFactory(lv -> { > return new ListCell<>() { > protected void updateItem(ImageHandle imageHandle, boolean > empty) { > if(empty) { > setGraphic(null); > } > else { > try { > setGraphic(new ImageView(new Image(new > ByteArrayInputStream(imageHandle.getImageData())))); > } > catch(IOException e) { > e.printStackTrace(); > } > } > } > }; > }); > > button.setOnAction(e -> { > Txt2ImgResponse response = textToImage(prompt.getText()); > > for(String image : response.images) { > listView.getItems().add(new > InMemoryImageHandle(Base64.getDecoder().decode(image))); > } > }); > > HBox hbox = Containers.hbox(Containers.vbox(prompt, button), > listView); > > HBox.setHgrow(listView, Priority.ALWAYS); > > Scene scene = new Scene(hbox); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > private Txt2ImgResponse textToImage(String prompt) { > return Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") > .body(new Txt2Img(prompt, 5)) > .contentType("application/json") > .asObject(Txt2ImgResponse.class) > .getBody(); > } > } > > static class InMemoryImageHandle implements ImageHandle { > private final byte[] data; > > public InMemoryImageHandle(byte[] data) { > this.data = data; > } > > @Override > public byte[] getImageData() { > return data; > } > > @Override > public String getKey() { > return null; > } > > @Override > public boolean isFastSource() { > return true; > } > } > > record Txt2Img(String prompt, int steps) {} > record Txt2ImgResponse(List images) {} > } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 127888 bytes Desc: image002.png URL: From arapte at openjdk.org Wed Jul 12 15:28:10 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 12 Jul 2023 15:28:10 GMT Subject: Integrated: 8310582: Update copyright header for files modified in 2023 In-Reply-To: <3sj90GhBO-T4w3VVp0y_Md1t-p20fktD8i-UBPmGmhg=.b721d179-2638-4f57-a6e1-6e438d7bec68@github.com> References: <3sj90GhBO-T4w3VVp0y_Md1t-p20fktD8i-UBPmGmhg=.b721d179-2638-4f57-a6e1-6e438d7bec68@github.com> Message-ID: <0ILRskAyYwGoXbN61xIXYhsA31rVJe5i7BUcIJpWmno=.fcda9e6c-4d6a-429f-9f7f-c798078195a6@github.com> On Wed, 12 Jul 2023 13:24:16 GMT, Ambarish Rapte wrote: > Updating last modified year in copyright header of the files that were modified during year 2023. This pull request has now been integrated. Changeset: 411c1b11 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/411c1b113bf626513127d50b2ec49fe04b944700 Stats: 328 lines in 328 files changed: 0 ins; 0 del; 328 mod 8310582: Update copyright header for files modified in 2023 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1176 From kizune at openjdk.org Wed Jul 12 16:24:10 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 12 Jul 2023 16:24:10 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: <4vGNtIhtb9EOw7HfvHSetiuEadZCsZiXmzF6KS0Hs38=.38e2f13e-f748-4767-9c27-e037cc25c4ff@github.com> References: <4vGNtIhtb9EOw7HfvHSetiuEadZCsZiXmzF6KS0Hs38=.38e2f13e-f748-4767-9c27-e037cc25c4ff@github.com> Message-ID: On Tue, 11 Jul 2023 20:12:44 GMT, Kevin Rushforth wrote: > Is there a way to hide the symbols so that they are not exported? I do not think we can hide these symbols from the library - they have to be public for us to instantiate them dynamically based on the accessibility role of the FX node. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1174#issuecomment-1632844649 From john.hendrikx at gmail.com Wed Jul 12 16:25:19 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Jul 2023 18:25:19 +0200 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: Hi Ajit, Thanks for checking, that is indeed a bit of a beginner mistake there... sorry for that. I added the line, and it is much improved (luckily), but I still see issues 2 and 3. I can narrow down 2 a bit.? When there is only space to show a single row (or less than a single line), the scrollbar won't respond to clicks in the empty area.? When at least a full row is visible, then it starts working normally. I wonder if it might be possible to warn if that line is missing somehow, or provide a different method to override that doesn't require calling super. On 12/07/2023 11:26, Ajit Ghaisas wrote: > Hi John, > > ? ?This looks like a user code issue and not a JavaFX bug. > ? ?Most of the vertical scrollbar issues that you have mentioned get > fixed by adding a call to "super.updateItem(image, empty);" as a first > call in the cell factory method "protected void updateItem(Image > image, boolean empty)? > > I am seeing an exception when I scroll fully down and then scroll up > by clicking empty area on the vertical scrollbar. This looks like a > separate issue though. I didn't see any exceptions, just that the scrollbar is unresponsive when clicking in the empty area when less than a full row is visible. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Jul 12 16:26:56 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Jul 2023 18:26:56 +0200 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: Yes, sorry, it does mention that, and I missed it by mistake, late night programming I guess. --John On 12/07/2023 16:57, Kevin Rushforth wrote: > The updateItem docs [1] already say this. I had missed that the test > program didn't do this, so thanks to Ajit for pointing it out. > > And yes, https://bugs.openjdk.org/browse/JDK-8090254 should be closed > as not an issue with a reference to the doc bug that clarified this. > > -- Kevin > > [1] > https://download.java.net/java/early_access/javafx21/docs/api/javafx.controls/javafx/scene/control/Cell.html#updateItem(T,boolean) > > On 7/12/2023 7:50 AM, Andy Goryachev wrote: >> >> Ajit is right - perhaps javadoc for updateItem() should explicitly >> mention this? >> >> Also, perhaps https://bugs.openjdk.org/browse/JDK-8090254 should be >> closed - we recently updated javadoc to read >> >> >> Warning: Nodes should not be inserted directly into the items list >> >> (this is a different issue altogether) >> >> -andy >> >> *From: *Ajit Ghaisas >> *Date: *Wednesday, July 12, 2023 at 02:26 >> *To: *John Hendrikx >> *Cc: *openjfx-dev at openjdk.org , Andy >> Goryachev >> *Subject: *Re: ListView with ImageViews for cells very bugged? >> >> Hi John, >> >> ?This looks like a user code issue and not a JavaFX bug. >> >> ?Most of the vertical scrollbar issues that you have mentioned get >> fixed by adding a call to "super.updateItem(image, empty);" as a >> first call in the cell factory method "protected void >> updateItem(Image image, boolean empty)? >> >> I am seeing an exception when I scroll fully down and then scroll up >> by clicking empty area on the vertical scrollbar. This looks like a >> separate issue though. >> >> Regards, >> >> Ajit >> >> >> >> On 12-Jul-2023, at 5:18 AM, Andy Goryachev >> wrote: >> >> Thank you for the code sample, John! >> >> Had to replace loading from https:// to a local file://, but I do >> see some of the issues you've mentioned (on macOS): >> >> 2), 5), and 6). >> >> There is also a new issue: >> >> 7) when the top of the cell is outside of the view area, the >> image is not shown at all (but the cell is sized correctly). >> >> All this is indeed weird. Looks like the time is right to create >> a bug, unless it's this one: >> >> JDK-8090254 >> >> >> >> [ListView] page up/down navigation doesn't work, when items are >> large (again!) >> >> -andy >> >> *From:*openjfx-dev on behalf of >> John Hendrikx >> *Date:*Tuesday, July 11, 2023 at 16:34 >> *To:*openjfx-dev at openjdk.org >> *Subject:*Re: ListView with ImageViews for cells very bugged? >> >> I said I'd do it tomorrow, but here is a full example anyway with >> pre-loaded images, and without external dependencies: >> >> package org.int4.sdui.ui; >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.ListCell; >> import javafx.scene.control.ListView; >> import javafx.scene.control.TextArea; >> import javafx.scene.image.Image; >> import javafx.scene.image.ImageView; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.Priority; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class Main2 { >> >> ? public static void main(String[] args) { >> ??? Application.launch(UI.class, args); >> ? } >> >> ? public static class UI extends Application { >> >> ??? @Override >> ??? public void start(Stage primaryStage) throws >> InterruptedException { >> ????? Image image1 = new Image("https://picsum.photos/512/512" >> ); >> ????? Image image2 = new Image("https://picsum.photos/512/512" >> ); >> >> ????? TextArea prompt = new TextArea("a flower on Mars"); >> ????? Button button = new Button("Submit"); >> ????? ListView listView = new ListView<>(); >> >> ????? while(image1.isBackgroundLoading() || >> image2.isBackgroundLoading()) { >> ??????? Thread.sleep(100); >> ????? } >> >> ????? listView.getItems().addAll(image1, image2); >> ????? listView.setCellFactory(lv -> { >> ??????? final ImageView imageView = new ImageView(); >> >> ??????? return new ListCell<>() { >> ????????? protected void updateItem(Image image, boolean empty) { >> ??????????? if(empty) { >> ????????????? setGraphic(null); >> ??????????? } >> ??????????? else { >> ????????????? imageView.setImage(image); >> ????????????? setGraphic(imageView); >> ??????????? } >> ????????? } >> ??????? }; >> ????? }); >> >> ????? HBox hbox = new HBox() {{ >> ??????? getChildren().addAll( >> ????????? new VBox() {{ >> ??????????? getChildren().addAll(prompt, button); >> ????????? }}, >> ????????? listView >> ??????? ); >> ????? }}; >> >> ????? HBox.setHgrow(listView, Priority.ALWAYS); >> >> ????? Scene scene = new Scene(hbox); >> >> ????? primaryStage.setScene(scene); >> ????? primaryStage.show(); >> ??? } >> ? } >> } >> >> >> >> >> >> --John >> >> On 12/07/2023 01:17, Andy Goryachev wrote: >> >> I'll need to replicate this scenario to be able to say >> anything definitive. >> >> Just by looking at the cell factory code though, I suspect >> there might be some async processing around >> >> new ImageView(new Image(new >> > ByteArrayInputStream(imageHandle.getImageData())))); >> >> which might cause the issue. >> >> Could you try pre-loading images? >> >> -andy >> >> *From:*openjfx-dev >> on behalf of Kevin >> Rushforth >> >> *Date:*Tuesday, July 11, 2023 at 15:58 >> *To:*openjfx-dev at openjdk.org >> >> *Subject:*Re: ListView with ImageViews for cells very bugged? >> >> What you have should work, but will create redundant images and >> ImageView ojbects. The recommendation is to create the nodes >> (ImageView >> in this case) in the constructor of the cell factory and call >> setGraphic >> with either null or that factory's node. >> >> Having said that, I doubt that this is related to the visual >> problems >> you are seeing. Maybe Ajit or Andy have some ideas. >> >> -- Kevin >> >> >> On 7/11/2023 3:50 PM, John Hendrikx wrote: >> > I tend to avoid ListView, because for some reason it seems >> to just >> > never do what I want unless used for its mundane rows of >> text use >> > case. I so far always just implemented my own skin for >> ListView that >> > deals with displays that have many images that need to scroll >> > smoothly, but... >> > >> > Recently, I've again attempted to use ListView, this time >> for showing >> > (so far) fixed size ImageViews with images exactly 512x512 >> pixels in >> > size: >> > >> > The cell factory looks like this, which I think is a correct >> > implementation: >> > >> > listView.setCellFactory(lv -> { >> > ??????? return new ListCell<>() { >> > ????????? protected void updateItem(ImageHandle >> imageHandle, boolean >> > empty) { >> > ??????????? if(empty) { >> > setGraphic(null); >> > ??????????? } >> > ??????????? else { >> > ????????????? try { >> > setGraphic(new ImageView(new Image(new >> > ByteArrayInputStream(imageHandle.getImageData())))); >> > ????????????? } >> > catch(IOException e) { >> > e.printStackTrace(); >> > ????????????? } >> > ??????????? } >> > ????????? } >> > ??????? }; >> > ????? }); >> > >> > Now, this is with JavaFX 21-ea-24 (but also happens on >> 19).? I spotted >> > the following IMHO bugs: >> > >> > 1) When the ImageView is so large that a single row is only >> partially >> > visible, the scrollbar is incorrect (it shows a full bar, >> even if half >> > of a row is displayed). >> > >> > 2) The vertical scrollbar doesn't respond to a click in the >> non-thumb >> > area at all (you'd expect to make it scroll a page up or >> down that way) >> > >> > 3) When jerkily resizing the window, I can sometimes have a >> vertical + >> > horizontal scrollbar when there's a full row visible + >> anywhere from 0 >> > to 10 extra empty pixels (probably the potential height of a >> > horizontal scrollbar) with the vertical scroll bar still >> visible.? The >> > algorithm to hide the scrollbar apparently is not >> deterministic and >> > depends on mouse movement speed. >> > >> > 4) When a row is less than half visible, scrolling the >> window down to >> > another ImageView will jump the view and hide the first >> cell that >> > should still be visible for the bottom 0-49% of its height. >> > >> > 5) It's possible to get the vertical scroll bar in such a >> state that >> > it doesn't respond to the mouse any more at all, even by >> dragging the >> > thumb.? Some keyboard action and mouse scrolling sometimes >> restores it >> > to relatively normal functioning. >> > >> > 6) Mouse wheel scrolling acts weird.? With one large cell >> visible and >> > two rows available, scrolling only **down** on the mouse >> wheel will >> > scroll down, then jump back up, and scroll down again... it's >> > impossible to scroll all the way down to get to a point >> where it stops >> > scrolling as it keeps jumping back. >> > >> > This is with ImageView's.? I suppose they're known to have >> problems... >> > but then I switched to a Region, which contain an ImageView >> with >> > proper min/pref/max implementations.? This improved the >> situation >> > somewhat.? The scrollbar was much more reliable, but I >> still saw >> > almost all of the above issues, but somewhat more reliable than >> > before.? Still rows would disappear when (for the most part) >> > invisible, those and the jumps of the view are just totally >> unacceptable. >> > >> > I'm not quite sure what to make of this, it seems the >> control is not >> > meant for arbitrary graphics. >> > >> > --John >> > >> > >> > >> > package org.int4.sdui.ui; >> > >> > import hs.mediasystem.util.image.ImageHandle; >> > import hs.mediasystem.util.javafx.control.Containers; >> > >> > import java.io.ByteArrayInputStream; >> > import java.io.IOException; >> > import java.util.Base64; >> > import java.util.List; >> > >> > import javafx.application.Application; >> > import javafx.scene.Scene; >> > import javafx.scene.control.Button; >> > import javafx.scene.control.ListCell; >> > import javafx.scene.control.ListView; >> > import javafx.scene.control.TextArea; >> > import javafx.scene.image.Image; >> > import javafx.scene.image.ImageView; >> > import javafx.scene.layout.HBox; >> > import javafx.scene.layout.Priority; >> > import javafx.stage.Stage; >> > >> > import kong.unirest.core.Unirest; >> > >> > public class Main { >> > >> > ? public static void main(String[] args) { >> > Application.launch(UI.class, args); >> > ? } >> > >> > ? public static class UI extends Application { >> > >> > ??? @Override >> > ??? public void start(Stage primaryStage) { >> > ????? TextArea prompt = new TextArea("a flower on Mars"); >> > ????? Button button = new Button("Submit"); >> > ListView listView = new ListView<>(); >> > >> > listView.setCellFactory(lv -> { >> > ??????? return new ListCell<>() { >> > ????????? protected void updateItem(ImageHandle >> imageHandle, boolean >> > empty) { >> > ??????????? if(empty) { >> > setGraphic(null); >> > ??????????? } >> > ??????????? else { >> > ????????????? try { >> > setGraphic(new ImageView(new Image(new >> > ByteArrayInputStream(imageHandle.getImageData())))); >> > ????????????? } >> > catch(IOException e) { >> > e.printStackTrace(); >> > ????????????? } >> > ??????????? } >> > ????????? } >> > ??????? }; >> > ????? }); >> > >> > ????? button.setOnAction(e -> { >> > ??????? Txt2ImgResponse response = >> textToImage(prompt.getText()); >> > >> > ??????? for(String image : response.images) { >> > listView.getItems().add(new >> > InMemoryImageHandle(Base64.getDecoder().decode(image))); >> > ??????? } >> > ????? }); >> > >> > ????? HBox hbox = Containers.hbox(Containers.vbox(prompt, >> button), >> > listView); >> > >> > ????? HBox.setHgrow(listView, Priority.ALWAYS); >> > >> > ????? Scene scene = new Scene(hbox); >> > >> > primaryStage.setScene(scene); >> > ????? primaryStage.show(); >> > ??? } >> > >> > ??? private Txt2ImgResponse textToImage(String prompt) { >> > ????? return >> Unirest.post("http://127.0.0.1:7860/sdapi/v1/txt2img") >> > ??????? .body(new Txt2Img(prompt, 5)) >> > .contentType("application/json") >> > .asObject(Txt2ImgResponse.class) >> > ??????? .getBody(); >> > ??? } >> > ? } >> > >> > ? static class InMemoryImageHandle implements ImageHandle { >> > ??? private final byte[] data; >> > >> > ??? public InMemoryImageHandle(byte[] data) { >> > ????? this.data = data; >> > ??? } >> > >> > ??? @Override >> > ??? public byte[] getImageData() { >> > ????? return data; >> > ??? } >> > >> > ??? @Override >> > ??? public String getKey() { >> > ????? return null; >> > ??? } >> > >> > ??? @Override >> > ??? public boolean isFastSource() { >> > ????? return true; >> > ??? } >> > ? } >> > >> > ? record Txt2Img(String prompt, int steps) {} >> > ? record Txt2ImgResponse(List images) {} >> > } >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Jul 12 16:28:41 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 12 Jul 2023 16:28:41 +0000 Subject: [External] : Re: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: ... and just by randomly clicking on the scrollbar I got this: Exception in thread "JavaFX Application Thread" java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) at java.base/java.util.Objects.checkIndex(Objects.java:359) at java.base/java.util.ArrayList.get(ArrayList.java:427) at javafx.controls/javafx.scene.control.skin.VirtualFlow.updateCellSize(VirtualFlow.java:3099) at javafx.controls/javafx.scene.control.skin.VirtualFlow.positionCell(VirtualFlow.java:1975) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollPixels(VirtualFlow.java:1650) at javafx.controls/javafx.scene.control.skin.VirtualFlow.tryScrollOneCell(VirtualFlow.java:1565) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollTo(VirtualFlow.java:1536) at javafx.controls/com.sun.javafx.scene.control.VirtualScrollBar.adjustValue(VirtualScrollBar.java:142) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.lambda$20(ScrollBarBehavior.java:162) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.trackPress(ScrollBarBehavior.java:173) at javafx.controls/javafx.scene.control.skin.ScrollBarSkin.lambda$7(ScrollBarSkin.java:411) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.controls/javafx.scene.control.skin.VirtualFlow.lambda$2(VirtualFlow.java:369) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:198) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3984) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1890) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2708) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:551) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:937) at javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:127) -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 09:25 To: Ajit Ghaisas Cc: openjfx-dev at openjdk.org , Andy Goryachev Subject: [External] : Re: ListView with ImageViews for cells very bugged? Hi Ajit, Thanks for checking, that is indeed a bit of a beginner mistake there... sorry for that. I added the line, and it is much improved (luckily), but I still see issues 2 and 3. I can narrow down 2 a bit. When there is only space to show a single row (or less than a single line), the scrollbar won't respond to clicks in the empty area. When at least a full row is visible, then it starts working normally. I wonder if it might be possible to warn if that line is missing somehow, or provide a different method to override that doesn't require calling super. On 12/07/2023 11:26, Ajit Ghaisas wrote: Hi John, This looks like a user code issue and not a JavaFX bug. Most of the vertical scrollbar issues that you have mentioned get fixed by adding a call to "super.updateItem(image, empty);" as a first call in the cell factory method "protected void updateItem(Image image, boolean empty)? I am seeing an exception when I scroll fully down and then scroll up by clicking empty area on the vertical scrollbar. This looks like a separate issue though. I didn't see any exceptions, just that the scrollbar is unresponsive when clicking in the empty area when less than a full row is visible. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Jul 12 16:32:16 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 12 Jul 2023 16:32:16 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v12] In-Reply-To: References: Message-ID: <8p8-IKr2vfhvA0mSr_tumZATNbsG1uZ7Wj569bUqDnE=.fd05489d-8bb7-48b4-82b5-6128eb81da52@github.com> On Tue, 11 Jul 2023 23:19:21 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix subscriber -> valueSubscriber LGTM ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1526768407 From john.hendrikx at gmail.com Wed Jul 12 16:33:07 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Jul 2023 18:33:07 +0200 Subject: [External] : Re: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: <039a522d-e7d6-859a-501c-81ee2fb05edb@gmail.com> I'm unable to get this one myself, but the trace can hopefully point us to the problem. I also find that the behavior of the Horizontal scrollbar leaves a lot to be desired.? Clicking in the empty area should shift it by a full view width, but it only shifts by like 16 pixels orso. So there are some bugs, but at least not quite as severe as I thought. --John On 12/07/2023 18:28, Andy Goryachev wrote: > > ... and just by randomly clicking on the scrollbar I got this: > > Exception in thread "JavaFX Application Thread" > _java.lang.IndexOutOfBoundsException_: Index -1 out of bounds for length 2 > > ????? at > java.base/jdk.internal.util.Preconditions.outOfBounds(_Preconditions.java:100_) > > ????? at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(_Preconditions.java:106_) > > ????? at > java.base/jdk.internal.util.Preconditions.checkIndex(_Preconditions.java:302_) > > ????? at java.base/java.util.Objects.checkIndex(_Objects.java:359_) > > ????? at java.base/java.util.ArrayList.get(_ArrayList.java:427_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.updateCellSize(_VirtualFlow.java:3099_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.positionCell(_VirtualFlow.java:1975_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollPixels(_VirtualFlow.java:1650_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.tryScrollOneCell(_VirtualFlow.java:1565_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollTo(_VirtualFlow.java:1536_) > > ????? at > javafx.controls/com.sun.javafx.scene.control.VirtualScrollBar.adjustValue(_VirtualScrollBar.java:142_) > > ????? at > javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.lambda$20(_ScrollBarBehavior.java:162_) > > ????? at > javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.trackPress(_ScrollBarBehavior.java:173_) > > ????? at > javafx.controls/javafx.scene.control.skin.ScrollBarSkin.lambda$7(_ScrollBarSkin.java:411_) > > ????? at > javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(_CompositeEventHandler.java:86_) > > ????? at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(_EventHandlerManager.java:232_) > > ????? at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(_EventHandlerManager.java:189_) > > ????? at > javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(_CompositeEventDispatcher.java:59_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:58_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.lambda$2(_VirtualFlow.java:369_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(_EventUtil.java:74_) > > ????? at > javafx.base/com.sun.javafx.event.EventUtil.fireEvent(_EventUtil.java:54_) > > ????? at javafx.base/javafx.event.Event.fireEvent(_Event.java:198_) > > ????? at > javafx.graphics/javafx.scene.Scene$MouseHandler.process(_Scene.java:3984_) > > ????? at > javafx.graphics/javafx.scene.Scene.processMouseEvent(_Scene.java:1890_) > > ????? at > javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(_Scene.java:2708_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(_GlassViewEventHandler.java:411_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(_GlassViewEventHandler.java:1_) > > ????? at > java.base/java.security.AccessController.doPrivileged(_AccessController.java:399_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(_GlassViewEventHandler.java:450_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(_QuantumToolkit.java:424_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(_GlassViewEventHandler.java:449_) > > ????? at > javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(_View.java:551_) > > ????? at > javafx.graphics/com.sun.glass.ui.View.notifyMouse(_View.java:937_) > > ????? at > javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(_MacView.java:127_) > > -andy > > *From: *John Hendrikx > *Date: *Wednesday, July 12, 2023 at 09:25 > *To: *Ajit Ghaisas > *Cc: *openjfx-dev at openjdk.org , Andy > Goryachev > *Subject: *[External] : Re: ListView with ImageViews for cells very > bugged? > > Hi Ajit, > > Thanks for checking, that is indeed a bit of a beginner mistake > there... sorry for that. > > I added the line, and it is much improved (luckily), but I still see > issues 2 and 3. > > I can narrow down 2 a bit.? When there is only space to show a single > row (or less than a single line), the scrollbar won't respond to > clicks in the empty area.? When at least a full row is visible, then > it starts working normally. > > I wonder if it might be possible to warn if that line is missing > somehow, or provide a different method to override that doesn't > require calling super. > > On 12/07/2023 11:26, Ajit Ghaisas wrote: > > Hi John, > > ?This looks like a user code issue and not a JavaFX bug. > > ?Most of the vertical scrollbar issues that you have mentioned get > fixed by adding a call to "super.updateItem(image, empty);" as a > first call in the cell factory method "protected void > updateItem(Image image, boolean empty)? > > I am seeing an exception when I scroll fully down and then scroll > up by clicking empty area on the vertical scrollbar. This looks > like a separate issue though. > > I didn't see any exceptions, just that the scrollbar is unresponsive > when clicking in the empty area when less than a full row is visible. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Jul 12 16:37:01 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Jul 2023 18:37:01 +0200 Subject: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> Message-ID: <98ac8f1b-53bc-87a9-67c6-b437cba4d3de@gmail.com> This is okay for me in Eclipse, although it will show the docs for the anonymous inner class updateItem method, which is not that helpful :) --John On 12/07/2023 17:13, Andy Goryachev wrote: > > I think we just found a bug in Eclipse: it shows javadoc for the wrong > method - > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Jul 12 16:37:54 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 12 Jul 2023 16:37:54 +0000 Subject: [External] : Re: ListView with ImageViews for cells very bugged? In-Reply-To: <039a522d-e7d6-859a-501c-81ee2fb05edb@gmail.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> <039a522d-e7d6-859a-501c-81ee2fb05edb@gmail.com> Message-ID: I have a video clip of how to reproduce the exception. Do you mind creating a bug? Thank you -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 09:33 To: Andy Goryachev , Ajit Ghaisas Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: ListView with ImageViews for cells very bugged? I'm unable to get this one myself, but the trace can hopefully point us to the problem. I also find that the behavior of the Horizontal scrollbar leaves a lot to be desired. Clicking in the empty area should shift it by a full view width, but it only shifts by like 16 pixels orso. So there are some bugs, but at least not quite as severe as I thought. --John On 12/07/2023 18:28, Andy Goryachev wrote: ... and just by randomly clicking on the scrollbar I got this: Exception in thread "JavaFX Application Thread" java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) at java.base/java.util.Objects.checkIndex(Objects.java:359) at java.base/java.util.ArrayList.get(ArrayList.java:427) at javafx.controls/javafx.scene.control.skin.VirtualFlow.updateCellSize(VirtualFlow.java:3099) at javafx.controls/javafx.scene.control.skin.VirtualFlow.positionCell(VirtualFlow.java:1975) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollPixels(VirtualFlow.java:1650) at javafx.controls/javafx.scene.control.skin.VirtualFlow.tryScrollOneCell(VirtualFlow.java:1565) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollTo(VirtualFlow.java:1536) at javafx.controls/com.sun.javafx.scene.control.VirtualScrollBar.adjustValue(VirtualScrollBar.java:142) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.lambda$20(ScrollBarBehavior.java:162) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.trackPress(ScrollBarBehavior.java:173) at javafx.controls/javafx.scene.control.skin.ScrollBarSkin.lambda$7(ScrollBarSkin.java:411) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.controls/javafx.scene.control.skin.VirtualFlow.lambda$2(VirtualFlow.java:369) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:198) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3984) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1890) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2708) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:551) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:937) at javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:127) -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 09:25 To: Ajit Ghaisas Cc: openjfx-dev at openjdk.org , Andy Goryachev Subject: [External] : Re: ListView with ImageViews for cells very bugged? Hi Ajit, Thanks for checking, that is indeed a bit of a beginner mistake there... sorry for that. I added the line, and it is much improved (luckily), but I still see issues 2 and 3. I can narrow down 2 a bit. When there is only space to show a single row (or less than a single line), the scrollbar won't respond to clicks in the empty area. When at least a full row is visible, then it starts working normally. I wonder if it might be possible to warn if that line is missing somehow, or provide a different method to override that doesn't require calling super. On 12/07/2023 11:26, Ajit Ghaisas wrote: Hi John, This looks like a user code issue and not a JavaFX bug. Most of the vertical scrollbar issues that you have mentioned get fixed by adding a call to "super.updateItem(image, empty);" as a first call in the cell factory method "protected void updateItem(Image image, boolean empty)? I am seeing an exception when I scroll fully down and then scroll up by clicking empty area on the vertical scrollbar. This looks like a separate issue though. I didn't see any exceptions, just that the scrollbar is unresponsive when clicking in the empty area when less than a full row is visible. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jul 12 20:10:08 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 12 Jul 2023 20:10:08 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v3] In-Reply-To: References: Message-ID: <_Am5VTuWqCf0IBnMd0y03OrZh9cvTdzfbAmSYSyGFJc=.21f36093-3f84-4c00-b4ff-e3a0cee1b0bf@github.com> On Mon, 10 Jul 2023 16:41:47 GMT, Andy Goryachev wrote: >> At this point I don't have a strong opinion on whether this field is private or not. Originally I wanted it to be private because I thought of it as "whatever magic value makes KeyCharacterCombinations work" and was concerned we might want to tweak that over time. That's less of a concern now that I've prototyped the implementation on three different platforms. >> >> This is largely a policy issue that's above my pay grade. This is an intrinsically platform-specific bit of information we would be exposing to developers. > > Are we going to create side effects when KeyEvents are synthesized? See, for instance, EmbeddedScene:366 or FXVKSkin:860 (and possibly other places)? A KeyEvent that doesn?t originate from Glass will not have a hardwareCode but will have a KeyCode. When matching it against a char combo the platform can just invoke the old getKeyCodeForChar logic and compare the result against the KeyEvent?s KeyCode. This is the same test that used to happen in the Java core so there should be no change in behavior. Unfortunately the current behavior is all over the map. On the Mac KeyCharacterCombinations don?t work when JavaFX is embedded in a JFXPanel (long story). On Windows and Linux they do work. I could make char combos work on the Mac but that would just lead to other bugs because AWT on the Mac does a poor job of assigning KeyCodes for punctuation and symbol keys. I will take a look at the VKFX skin but I also doubt it assigns KeyCodes ?correctly? for char combos, it just doesn?t have enough information to do the job right. (In general we should only match KeyCharacterCombinations against KeyEvents that Glass generates. Otherwise we?re depending on the creator of the KeyEvent to assign the same code that Glass would assign to that key. That?s a tall order.) So there?s nothing in this PR that would make matters worse but given the current behavior I don?t know how to write tests to ensure that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1261673784 From kcr at openjdk.org Wed Jul 12 22:48:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Jul 2023 22:48:13 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v12] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 23:19:21 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix subscriber -> valueSubscriber I left one comment on one of the tests. Presuming it should be changed, you can either do it now (and I'll reapprove) or file a follow-up test bug. Please wait until tomorrow (ideally, before 1600 UTC to be ahead of the RDP1 fork) to integrate this in order to give @johanvos @jperedadnr or @nlisker a chance to comment. modules/javafx.base/src/test/java/test/javafx/beans/ObservableSubscriptionsTest.java line 68: > 66: > 67: value.get(); > 68: value.set("C"); Should this be a different value from the previously set one to ensure that an invalidation listener would get called if it were still subscribed? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1527323433 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261787469 From jhendrikx at openjdk.org Thu Jul 13 00:01:23 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 00:01:23 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix ObservableSubscriptionsTest ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/170ca454..eafc67db Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Thu Jul 13 00:01:24 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 00:01:24 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v12] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 22:33:44 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix subscriber -> valueSubscriber > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableSubscriptionsTest.java line 68: > >> 66: >> 67: value.get(); >> 68: value.set("C"); > > Should this be a different value from the previously set one to ensure that an invalidation listener would get called if it were still subscribed? Yes, that's not correct, fixed it, thanks ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261830964 From mstrauss at openjdk.org Thu Jul 13 00:32:11 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Jul 2023 00:32:11 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: <3VfY3qP_HHKkX0DtdKnp3M6UZ4zixlVHJL1_I20Jq1k=.4be5113b-d816-448a-8f9c-428cd5596262@github.com> On Thu, 13 Jul 2023 00:01:23 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix ObservableSubscriptionsTest Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1527401282 From john.hendrikx at gmail.com Thu Jul 13 00:44:48 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 13 Jul 2023 02:44:48 +0200 Subject: [External] : Re: ListView with ImageViews for cells very bugged? In-Reply-To: References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> <039a522d-e7d6-859a-501c-81ee2fb05edb@gmail.com> Message-ID: <53e0a254-f085-d317-a607-03393894c46d@gmail.com> I've managed to reproduce it -- it seems it may be a regression, or it is exposing a new bug after a fix done to the scrollbar (in 19.0.2.1 I can't reproduce it, but I also can't fully click the scrollbar back up).? In 21-ea-24 I can reproduce it by scrolling all the way down, then trying to "click" it back up not using the scrollbar thumb. I created this ticket to track the issue: https://bugs.openjdk.org/browse/JDK-8311983 --John On 12/07/2023 18:37, Andy Goryachev wrote: > > I have a video clip of how to reproduce the exception.? Do you mind > creating a bug? > > Thank you > > -andy > > *From: *John Hendrikx > *Date: *Wednesday, July 12, 2023 at 09:33 > *To: *Andy Goryachev , Ajit Ghaisas > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: ListView with ImageViews for cells > very bugged? > > I'm unable to get this one myself, but the trace can hopefully point > us to the problem. > > I also find that the behavior of the Horizontal scrollbar leaves a lot > to be desired.? Clicking in the empty area should shift it by a full > view width, but it only shifts by like 16 pixels orso. > > So there are some bugs, but at least not quite as severe as I thought. > > --John > > On 12/07/2023 18:28, Andy Goryachev wrote: > > ... and just by randomly clicking on the scrollbar I got this: > > Exception in thread "JavaFX Application Thread" > _java.lang.IndexOutOfBoundsException_: Index -1 out of bounds for > length 2 > > ????? at > java.base/jdk.internal.util.Preconditions.outOfBounds(_Preconditions.java:100_) > > ????? at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(_Preconditions.java:106_) > > ????? at > java.base/jdk.internal.util.Preconditions.checkIndex(_Preconditions.java:302_) > > ????? at java.base/java.util.Objects.checkIndex(_Objects.java:359_) > > ????? at java.base/java.util.ArrayList.get(_ArrayList.java:427_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.updateCellSize(_VirtualFlow.java:3099_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.positionCell(_VirtualFlow.java:1975_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollPixels(_VirtualFlow.java:1650_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.tryScrollOneCell(_VirtualFlow.java:1565_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollTo(_VirtualFlow.java:1536_) > > ????? at > javafx.controls/com.sun.javafx.scene.control.VirtualScrollBar.adjustValue(_VirtualScrollBar.java:142_) > > ????? at > javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.lambda$20(_ScrollBarBehavior.java:162_) > > ????? at > javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.trackPress(_ScrollBarBehavior.java:173_) > > ????? at > javafx.controls/javafx.scene.control.skin.ScrollBarSkin.lambda$7(_ScrollBarSkin.java:411_) > > ????? at > javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(_CompositeEventHandler.java:86_) > > ????? at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(_EventHandlerManager.java:232_) > > ????? at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(_EventHandlerManager.java:189_) > > ????? at > javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(_CompositeEventDispatcher.java:59_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:58_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.controls/javafx.scene.control.skin.VirtualFlow.lambda$2(_VirtualFlow.java:369_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(_BasicEventDispatcher.java:56_) > > ????? at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(_EventDispatchChainImpl.java:114_) > > ????? at > javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(_EventUtil.java:74_) > > ????? at > javafx.base/com.sun.javafx.event.EventUtil.fireEvent(_EventUtil.java:54_) > > ????? at javafx.base/javafx.event.Event.fireEvent(_Event.java:198_) > > ????? at > javafx.graphics/javafx.scene.Scene$MouseHandler.process(_Scene.java:3984_) > > ????? at > javafx.graphics/javafx.scene.Scene.processMouseEvent(_Scene.java:1890_) > > ????? at > javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(_Scene.java:2708_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(_GlassViewEventHandler.java:411_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(_GlassViewEventHandler.java:1_) > > ????? at > java.base/java.security.AccessController.doPrivileged(_AccessController.java:399_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(_GlassViewEventHandler.java:450_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(_QuantumToolkit.java:424_) > > ????? at > javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(_GlassViewEventHandler.java:449_) > > ????? at > javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(_View.java:551_) > > ????? at > javafx.graphics/com.sun.glass.ui.View.notifyMouse(_View.java:937_) > > ????? at > javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(_MacView.java:127_) > > -andy > > *From: *John Hendrikx > > *Date: *Wednesday, July 12, 2023 at 09:25 > *To: *Ajit Ghaisas > > *Cc: *openjfx-dev at openjdk.org > , Andy Goryachev > > *Subject: *[External] : Re: ListView with ImageViews for cells > very bugged? > > Hi Ajit, > > Thanks for checking, that is indeed a bit of a beginner mistake > there... sorry for that. > > I added the line, and it is much improved (luckily), but I still > see issues 2 and 3. > > I can narrow down 2 a bit.? When there is only space to show a > single row (or less than a single line), the scrollbar won't > respond to clicks in the empty area.? When at least a full row is > visible, then it starts working normally. > > I wonder if it might be possible to warn if that line is missing > somehow, or provide a different method to override that doesn't > require calling super. > > On 12/07/2023 11:26, Ajit Ghaisas wrote: > > Hi John, > > ? ?This looks like a user code issue and not a JavaFX bug. > > ? ?Most of the vertical scrollbar issues that you have > mentioned get fixed by adding a call to > "super.updateItem(image, empty);" as a first call in the cell > factory method "protected void updateItem(Image image, boolean > empty)? > > I am seeing an exception when I scroll fully down and then > scroll up by clicking empty area on the vertical scrollbar. > This looks like a separate issue though. > > I didn't see any exceptions, just that the scrollbar is > unresponsive when clicking in the empty area when less than a full > row is visible. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jul 13 01:58:09 2023 From: duke at openjdk.org (Glavo) Date: Thu, 13 Jul 2023 01:58:09 GMT Subject: RFR: 8307316: Let JavaFX be built on unknown architectures [v2] In-Reply-To: <0050_dkkBoPts0EoSUAHCE6ZqV4KifO02QEAjGyZclE=.58e7ea3d-0334-4821-b809-ba0592a9658e@github.com> References: <0050_dkkBoPts0EoSUAHCE6ZqV4KifO02QEAjGyZclE=.58e7ea3d-0334-4821-b809-ba0592a9658e@github.com> Message-ID: On Tue, 13 Jun 2023 14:39:57 GMT, John Neffenger wrote: >> Please review these changes to the Gradle build files and the dependency verification file. The initial version of this pull request extends the permitted build platforms for Linux to the Java architectures `arm`, `ppc64le`, and `s390x` and adds an entry to the dependency verification file for the `i386` architecture. The Debian names for these architectures are `armhf`, `i386`, `ppc64el`, and `s390x`. > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x > - Warn instead of failing on unknown architectures > - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x > - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x > - Allow building on armhf, i386, ppc64el, and s390x I tested it on Debian RISC-V 64 and it works fine. ------------- Marked as reviewed by Glavo at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jfx/pull/1124#pullrequestreview-1527451251 From kcr at openjdk.org Thu Jul 13 02:23:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Jul 2023 02:23:12 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 00:01:23 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix ObservableSubscriptionsTest Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1527467901 From nlisker at openjdk.org Thu Jul 13 02:29:20 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 13 Jul 2023 02:29:20 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 00:01:23 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix ObservableSubscriptionsTest Reviewed the non-tests code. The implementation looks good, added comments on the docs. modules/javafx.base/src/main/java/javafx/beans/Observable.java line 101: > 99: * {@code invalidationSubscriber} whenever it becomes invalid. If the same > 100: * subscriber is subscribed more than once, then it will be notified more > 101: * than once. That is, no check is made to ensure uniqueness. Similar to the comments on `ObservableValue`: Creates a {@code Subscription} on this {@code Observable} that calls the given {@code invalidationSubscriber} whenever it becomes invalid. This {@code Subscription} is akin to an {@code InvalidationListener}. modules/javafx.base/src/main/java/javafx/beans/Observable.java line 109: > 107: * lifecycle than the subscriber, the subscriber must be unsubscribed > 108: * when no longer needed as the subscription will otherwise keep the subscriber > 109: * from being garbage collected. I think that the explanations starting from "If the same" are no longer needed if you add something like what I suggested for `Subscription`. It covers the lifecycle and multiple subscriptions explanations already. modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 33: > 31: /** > 32: * A subscription encapsulates how to cancel it without having > 33: * to keep track of how it was created. I would like to see some more info here, like what it is and how it's used, and a note on comparison with listeners. Taking a page out of `ChangeListener`, I took a stab at it: Executes code on change or invalidation events. A {@code Subscription} can be created by subscribing to invalidation events on an {@code Observable} using {@link Observable#subscribe(Runnable)} and to change events on an {@code ObsefvableValue} using {@link Observable#subscribe(Consumer)} and {@link Observable#subscribe(BiConsumer)}. It can be unsubscribed using {@link #unsuscribe}.

Subscriptions don't block the the {@code Observable} from being garbage collected, and will be collected with it (if they are not subscribed on other {@code Observable}s, see below). However, since {@code Observable}s blocks their subscriptions from being GC'd, {@code unsuscribe()} must be called if they are to be eligible for GC before the {@code Observable} is. Considering creating a derived {@code ObservableValue} using {@link #when(ObservableValue)} and subscribing on this derived observable value to automatically decouple the lifecycle of the subscriber from the original {@code ObservableValue} when some condition holds: {@code obs.when(cond).subscribe(...) }

Subscriptions can also be combined using {@link #combine} and {@link #and}, which allows for multiple subscriptions to be unsubscribed together. This is useful when they share the same lifecycle, which is usually the case when they are subscribed on the same {@code Observable}.

The same subscriber can be subscribed to multiple {@code Observable}s, including more than once on the same {@code Observable}, in which case it will be executed more than once. That is, no uniqueness check is made.

{@code Subscription}s behave similarly to {@link InvalidationListener}s and {@code ChangeListener}s. An advantage of {@code Subscription} is that it encapsulates how to cancel it without having to keep track of how it was created. This will also alleviate some repeated verbosity in the subscribe methods. modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 62: > 60: * Cancels this subscription, or does nothing if already cancelled.

> 61: * > 62: * Implementors must ensure the implementation is idempotent. Maybe add a short explanation on idempotent: "...is idempotent (a no-op if called more than once)". modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 321: > 319: * using {@link #when(ObservableValue)} and subscribing on this derived observable value > 320: * to automatically decouple the lifecycle of the subscriber from this > 321: * {@code ObservableValue} when some condition holds. I think that these explanations are no longer needed if you add something like what I suggested for `Subscription`. It covers the lifecycle and multiple subscriptions explanations already. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 343: > 341: * Creates a {@link Subscription} on this value which immediately provides > 342: * the current value to the given {@code valueSubscriber}, followed by any > 343: * subsequent values whenever its value changes. Similar comments to the other method, but I would also talk about why the value is also sent immediately. Consider this phrasing: Creates a {@code Subscription} on this {@code ObservableValue} that calls the given {@code changeSubscriber} with the new value immediately and whenever its value changes. This {@code Subscription} is akin to a {@code ChangeListener} with only the {@code T newValue} parameter. The {@code valueSubscriber} is called immediately for convenience since usually the user will want to initialize a value and then update on changes. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 354: > 352: * using {@link #when(ObservableValue)} and subscribing on this derived observable value > 353: * to automatically decouple the lifecycle of the subscriber from this > 354: * {@code ObservableValue} when some condition holds. I think that these explanations are no longer needed if you add something like what I suggested for `Subscription`. It covers the lifecycle and multiple subscriptions explanations already. ------------- PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1527377314 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261842659 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261895740 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261873147 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261901036 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261896234 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261839343 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261896328 From nlisker at openjdk.org Thu Jul 13 02:29:23 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 13 Jul 2023 02:29:23 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v12] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 23:19:21 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix subscriber -> valueSubscriber modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 307: > 305: /** > 306: * Creates a {@link Subscription} on this {@code Observable} which calls the given > 307: * {@code changeSubscriber} with the old and new value whenever its value changes. * There's no need to link `Subscription` since it's linked in the method description. * Maybe say "on this `{@code ObservableValue}`" to be more specific, even though it's also an `Observable`. * I would also note the similarities to a `ChangeListener` since it's used internally. Maybe this? Creates a {@code Subscription} on this {@code ObservableValue} that calls the given {@code changeSubscriber} with the old and new values whenever its value changes. This {@code Subscription} is akin to a {@code ChangeListener} without the {@code ObservableValue} parameter. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 310: > 308: *

> 309: * The parameters supplied to the {@link BiConsumer} are the old and new value > 310: * respectively. "values, respectively" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 356: > 354: * {@code ObservableValue} when some condition holds. > 355: * > 356: * @param valueSubscriber a {@link Consumer} to supply with the values of this No need for a link to `Consumer`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261833227 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261827415 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1261829173 From kcr at openjdk.org Thu Jul 13 03:25:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Jul 2023 03:25:10 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 00:01:23 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix ObservableSubscriptionsTest I might recommend filing a follow-up issue to improve the docs, since that can be done after RDP1. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1069#issuecomment-1633489188 From jhendrikx at openjdk.org Thu Jul 13 03:52:11 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 03:52:11 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 03:22:43 GMT, Kevin Rushforth wrote: > I might recommend filing a follow-up issue to improve the docs, since that can be done after RDP1. I'm fine with that, I can create one and then work through @nlisker comments. I plan to integrate this in a couple of hours, just before the stabilization branch is created. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1069#issuecomment-1633504996 From nlisker at openjdk.org Thu Jul 13 04:36:16 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 13 Jul 2023 04:36:16 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 00:01:23 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix ObservableSubscriptionsTest The tests look fine. Doc changes can be deferred. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1527552887 From arapte at openjdk.org Thu Jul 13 05:28:06 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 13 Jul 2023 05:28:06 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 20:39:34 GMT, Alexander Zuev wrote: > To avoid confusion on the os x dynamic linker side i renamed native classes from ButtonAccessibility to JFXButtonAccessibility. I will use JFX prefix down the line to avoid any confusion when running with the latest JDK that also migrated to the new a11y API. May I suggest an alternate naming pattern similar to AccessibleBase.h. Can we name our files as AccessibleButton, (AccessibleList, ... and so forth) ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1174#issuecomment-1633567944 From ajit.ghaisas at oracle.com Thu Jul 13 05:42:04 2023 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 13 Jul 2023 05:42:04 +0000 Subject: [External] : Re: ListView with ImageViews for cells very bugged? In-Reply-To: <53e0a254-f085-d317-a607-03393894c46d@gmail.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> <039a522d-e7d6-859a-501c-81ee2fb05edb@gmail.com> <53e0a254-f085-d317-a607-03393894c46d@gmail.com> Message-ID: <9562D89B-1170-498A-A1E7-CB08ED45078F@ORACLE.COM> Thanks for filing this bug. Regards, Ajit On 13-Jul-2023, at 6:14 AM, John Hendrikx wrote: I've managed to reproduce it -- it seems it may be a regression, or it is exposing a new bug after a fix done to the scrollbar (in 19.0.2.1 I can't reproduce it, but I also can't fully click the scrollbar back up). In 21-ea-24 I can reproduce it by scrolling all the way down, then trying to "click" it back up not using the scrollbar thumb. I created this ticket to track the issue: https://bugs.openjdk.org/browse/JDK-8311983 --John On 12/07/2023 18:37, Andy Goryachev wrote: I have a video clip of how to reproduce the exception. Do you mind creating a bug? Thank you -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 09:33 To: Andy Goryachev , Ajit Ghaisas Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: ListView with ImageViews for cells very bugged? I'm unable to get this one myself, but the trace can hopefully point us to the problem. I also find that the behavior of the Horizontal scrollbar leaves a lot to be desired. Clicking in the empty area should shift it by a full view width, but it only shifts by like 16 pixels orso. So there are some bugs, but at least not quite as severe as I thought. --John On 12/07/2023 18:28, Andy Goryachev wrote: ... and just by randomly clicking on the scrollbar I got this: Exception in thread "JavaFX Application Thread" java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) at java.base/java.util.Objects.checkIndex(Objects.java:359) at java.base/java.util.ArrayList.get(ArrayList.java:427) at javafx.controls/javafx.scene.control.skin.VirtualFlow.updateCellSize(VirtualFlow.java:3099) at javafx.controls/javafx.scene.control.skin.VirtualFlow.positionCell(VirtualFlow.java:1975) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollPixels(VirtualFlow.java:1650) at javafx.controls/javafx.scene.control.skin.VirtualFlow.tryScrollOneCell(VirtualFlow.java:1565) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollTo(VirtualFlow.java:1536) at javafx.controls/com.sun.javafx.scene.control.VirtualScrollBar.adjustValue(VirtualScrollBar.java:142) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.lambda$20(ScrollBarBehavior.java:162) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.trackPress(ScrollBarBehavior.java:173) at javafx.controls/javafx.scene.control.skin.ScrollBarSkin.lambda$7(ScrollBarSkin.java:411) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.controls/javafx.scene.control.skin.VirtualFlow.lambda$2(VirtualFlow.java:369) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:198) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3984) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1890) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2708) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:551) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:937) at javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:127) -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 09:25 To: Ajit Ghaisas Cc: openjfx-dev at openjdk.org , Andy Goryachev Subject: [External] : Re: ListView with ImageViews for cells very bugged? Hi Ajit, Thanks for checking, that is indeed a bit of a beginner mistake there... sorry for that. I added the line, and it is much improved (luckily), but I still see issues 2 and 3. I can narrow down 2 a bit. When there is only space to show a single row (or less than a single line), the scrollbar won't respond to clicks in the empty area. When at least a full row is visible, then it starts working normally. I wonder if it might be possible to warn if that line is missing somehow, or provide a different method to override that doesn't require calling super. On 12/07/2023 11:26, Ajit Ghaisas wrote: Hi John, This looks like a user code issue and not a JavaFX bug. Most of the vertical scrollbar issues that you have mentioned get fixed by adding a call to "super.updateItem(image, empty);" as a first call in the cell factory method "protected void updateItem(Image image, boolean empty)? I am seeing an exception when I scroll fully down and then scroll up by clicking empty area on the vertical scrollbar. This looks like a separate issue though. I didn't see any exceptions, just that the scrollbar is unresponsive when clicking in the empty area when less than a full row is visible. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Thu Jul 13 09:31:21 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 09:31:21 GMT Subject: Integrated: JDK-8304439: Subscription based listeners In-Reply-To: References: Message-ID: <_FfxtB1JM48bap_gYYnWC8RowROo8bixXBZOfL5uy7s=.70720c56-64c2-4a2f-830a-358503741592@github.com> On Sat, 25 Mar 2023 16:21:48 GMT, John Hendrikx wrote: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. This pull request has now been integrated. Changeset: 6961016c Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/6961016c357427ec7f8371a94cbeecc4de5b5660 Stats: 614 lines in 13 files changed: 482 ins; 122 del; 10 mod 8304439: Subscription based listeners Reviewed-by: nlisker, kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1069 From andy.goryachev at oracle.com Thu Jul 13 15:16:34 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 13 Jul 2023 15:16:34 +0000 Subject: [External] : Re: ListView with ImageViews for cells very bugged? In-Reply-To: <53e0a254-f085-d317-a607-03393894c46d@gmail.com> References: <6bde5a86-e885-2e00-1e6e-1606cad7db0f@gmail.com> <231a8d78-391e-3a79-f04a-51488b6d5bc2@oracle.com> <7b8631a8-a182-890e-9890-0746974dc126@gmail.com> <300C386B-93D0-4DB9-A4F6-384C8A806BF3@oracle.com> <039a522d-e7d6-859a-501c-81ee2fb05edb@gmail.com> <53e0a254-f085-d317-a607-03393894c46d@gmail.com> Message-ID: Thank you, John! I've added a video clip for the convenience. -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 17:44 To: Andy Goryachev , Ajit Ghaisas Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: ListView with ImageViews for cells very bugged? I've managed to reproduce it -- it seems it may be a regression, or it is exposing a new bug after a fix done to the scrollbar (in 19.0.2.1 I can't reproduce it, but I also can't fully click the scrollbar back up). In 21-ea-24 I can reproduce it by scrolling all the way down, then trying to "click" it back up not using the scrollbar thumb. I created this ticket to track the issue: https://bugs.openjdk.org/browse/JDK-8311983 --John On 12/07/2023 18:37, Andy Goryachev wrote: I have a video clip of how to reproduce the exception. Do you mind creating a bug? Thank you -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 09:33 To: Andy Goryachev , Ajit Ghaisas Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: ListView with ImageViews for cells very bugged? I'm unable to get this one myself, but the trace can hopefully point us to the problem. I also find that the behavior of the Horizontal scrollbar leaves a lot to be desired. Clicking in the empty area should shift it by a full view width, but it only shifts by like 16 pixels orso. So there are some bugs, but at least not quite as severe as I thought. --John On 12/07/2023 18:28, Andy Goryachev wrote: ... and just by randomly clicking on the scrollbar I got this: Exception in thread "JavaFX Application Thread" java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) at java.base/java.util.Objects.checkIndex(Objects.java:359) at java.base/java.util.ArrayList.get(ArrayList.java:427) at javafx.controls/javafx.scene.control.skin.VirtualFlow.updateCellSize(VirtualFlow.java:3099) at javafx.controls/javafx.scene.control.skin.VirtualFlow.positionCell(VirtualFlow.java:1975) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollPixels(VirtualFlow.java:1650) at javafx.controls/javafx.scene.control.skin.VirtualFlow.tryScrollOneCell(VirtualFlow.java:1565) at javafx.controls/javafx.scene.control.skin.VirtualFlow.scrollTo(VirtualFlow.java:1536) at javafx.controls/com.sun.javafx.scene.control.VirtualScrollBar.adjustValue(VirtualScrollBar.java:142) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.lambda$20(ScrollBarBehavior.java:162) at javafx.controls/com.sun.javafx.scene.control.behavior.ScrollBarBehavior.trackPress(ScrollBarBehavior.java:173) at javafx.controls/javafx.scene.control.skin.ScrollBarSkin.lambda$7(ScrollBarSkin.java:411) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.controls/javafx.scene.control.skin.VirtualFlow.lambda$2(VirtualFlow.java:369) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:198) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3984) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1890) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2708) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:551) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:937) at javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:127) -andy From: John Hendrikx Date: Wednesday, July 12, 2023 at 09:25 To: Ajit Ghaisas Cc: openjfx-dev at openjdk.org , Andy Goryachev Subject: [External] : Re: ListView with ImageViews for cells very bugged? Hi Ajit, Thanks for checking, that is indeed a bit of a beginner mistake there... sorry for that. I added the line, and it is much improved (luckily), but I still see issues 2 and 3. I can narrow down 2 a bit. When there is only space to show a single row (or less than a single line), the scrollbar won't respond to clicks in the empty area. When at least a full row is visible, then it starts working normally. I wonder if it might be possible to warn if that line is missing somehow, or provide a different method to override that doesn't require calling super. On 12/07/2023 11:26, Ajit Ghaisas wrote: Hi John, This looks like a user code issue and not a JavaFX bug. Most of the vertical scrollbar issues that you have mentioned get fixed by adding a call to "super.updateItem(image, empty);" as a first call in the cell factory method "protected void updateItem(Image image, boolean empty)? I am seeing an exception when I scroll fully down and then scroll up by clicking empty area on the vertical scrollbar. This looks like a separate issue though. I didn't see any exceptions, just that the scrollbar is unresponsive when clicking in the empty area when less than a full row is visible. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Jul 13 16:05:05 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Jul 2023 16:05:05 GMT Subject: Integrated: 8311844: Change JavaFX release version to 22 In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 10:56:25 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 22. I will integrate this to master as part of forking the jfx21 stabilization branch, which is scheduled for Thursday, July 13, 2023 at 16:00 UTC. This pull request has now been integrated. Changeset: 7e54b637 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/7e54b637c9742b8d19c902af21adca9313ba9204 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8311844: Change JavaFX release version to 22 Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1175 From kevin.rushforth at oracle.com Thu Jul 13 16:33:35 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Jul 2023 09:33:35 -0700 Subject: JavaFX 21 is in Rampdown Phase One (RDP1) Message-ID: <3ce16b8a-cc5b-5a14-0bbb-49bc64ed3ebe@oracle.com> JavaFX 21 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx21 branch [2] for stabilizing the JavaFX 21 release. PLEASE READ CAREFULLY as the procedure for getting fixes into the stabilization branch has changed. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for jfx22. Almost all fixes will be integrated to master for 22, even those intended to be fixed in 21. - The jfx21 branch of the jfx repo is now open for integrating fixes for jfx21 that meet the RDP1 criteria as outlined below. In contrast to past practice, in this release we will integrate almost all stabilization changes via backports from the master branch [3]. ? * Almost all fixes intended for the jfx21 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 [4].) ? * 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. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx21 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx21. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx21 branch. The master branch is open for all jfx22 fixes, including enhancements. As a reminder, we use a single openjdk/jfx GitHub repo with stabilization branches [5] rather than a separate stabilization repo. The jfx21 branch is used to stabilize the upcoming jfx21 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx21 to ensure that it doesn't contain any commits from master after the jfx21 fork date. What that means is that if you intend a PR to be for jfx21, don't merge master into your local source 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 22 as of today). This is usually what we want. A backport PR should be targeted to `jfx21` if, and only if, it is intended for JavaFX 21 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx21`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 22. Reviewers also need to be extra careful when reviewing PRs targeted to jfx21 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 jfx21 will be done as backport-style PRs, but it can still be a problem if the developer mistakenly merges master into their backport branch. We will use the same rules for RDP1 that the JDK uses [6], with the same three modifications we did for the previous release: 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 21 release. As an obvious choice, derived from the JBS fix version, we will use "jfx21-enhancement-request", "jfx21-enhancement-yes", "jfx21-enhancement-no" and "jfx21-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx21 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should only go into master for jfx22, since we do not want to risk anything that would destabilize the jfx21 release without a compelling reason. Also, we have only 3 weeks until RDP2 of jfx21 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for jfx21 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-April/039630.html [2] https://github.com/openjdk/jfx/tree/jfx21 [3] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [4] https://openjdk.org/guide/#working-with-backports-in-jbs [5] https://github.com/openjdk/jfx/branches/all [6] http://openjdk.org/jeps/3 From jhendrikx at openjdk.org Thu Jul 13 20:55:21 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 20:55:21 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 01:24:12 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix ObservableSubscriptionsTest > > modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 33: > >> 31: /** >> 32: * A subscription encapsulates how to cancel it without having >> 33: * to keep track of how it was created. > > I would like to see some more info here, like what it is and how it's used, and a note on comparison with listeners. Taking a page out of `ChangeListener`, I took a stab at it: > > > Executes code on change or invalidation events. A {@code Subscription} can be created by subscribing to invalidation > events on an {@code Observable} using {@link Observable#subscribe(Runnable)} > and to change events on an {@code ObsefvableValue} using {@link Observable#subscribe(Consumer)} > and {@link Observable#subscribe(BiConsumer)}. It can be unsubscribed using {@link #unsuscribe}. >

> Subscriptions don't block the the {@code Observable} from being garbage collected, and will be collected with > it (if they are not subscribed on other {@code Observable}s, see below). However, since {@code Observable}s > blocks their subscriptions from being GC'd, {@code unsuscribe()} must be called if they are to be eligible for > GC before the {@code Observable} is. Consider creating a derived {@code ObservableValue} > using {@link #when(ObservableValue)} and subscribing on this derived observable value > to automatically decouple the lifecycle of the subscriber from the original {@code ObservableValue} > when some condition holds: > {@code > obs.when(cond).subscribe(...) > } >

> Subscriptions can also be combined using {@link #combine} and {@link #and}, which allows for > multiple subscriptions to be unsubscribed together. This is useful when they share the same lifecycle, > which is usually the case when they are subscribed on the same {@code Observable}. >

> The same subscriber can be subscribed to multiple {@code Observable}s, including more than once on the > same {@code Observable}, in which case it will be executed more than once. That is, no uniqueness check is made. >

> {@code Subscription}s behave similarly to {@link InvalidationListener}s and {@code ChangeListener}s. An > advantage of {@code Subscription} is that it encapsulates how to cancel it without having to keep track of > how it was created. > > > This will also alleviate some repeated verbosity in the subscribe methods. I'm not entirely sure about this; the `Subscription` interface is pretty neutral in how it can be used, and does not have any direct link to observables at all; it's more of a token that you get that can be used to cancel a previous action, it doesn't actively do anything (unless you count the wrapper that it puts around the provided function). As it is, they don't even need to be associated with `Observable` or `ObservableValue` at all. Just as easily you could do: FileInputStream inputStream = .. ; Subscription combined = Subscription.combine( property.subscribe(this::invalidated), () -> inputStream.close() ); combined.subscribe(); // closes input stream and removes invalidations subscriber Although I think it is a good description, I'm not sure it belongs on this class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263043937 From jhendrikx at openjdk.org Thu Jul 13 21:02:21 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 21:02:21 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v12] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 00:00:50 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix subscriber -> valueSubscriber > > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 307: > >> 305: /** >> 306: * Creates a {@link Subscription} on this {@code Observable} which calls the given >> 307: * {@code changeSubscriber} with the old and new value whenever its value changes. > > * There's no need to link `Subscription` since it's linked in the method description. > * Maybe say "on this `{@code ObservableValue}`" to be more specific, even though it's also an `Observable`. > * I would also note the similarities to a `ChangeListener` since it's used internally. > > Maybe this? > > Creates a {@code Subscription} on this {@code ObservableValue} that calls the given {@code > changeSubscriber} with the old and new values whenever its value changes. This {@code Subscription} > is akin to a {@code ChangeListener} without the {@code ObservableValue} parameter. I put: The provided consumer is akin to a {@code ChangeListener} without the {@code ObservableValue} parameter ...as I think it's not correct to say the `Subscription` is like a change listener, the subscription is only a means to cancel it. The consumer you provide is like the change listener, with one less parameter. The other changes I added, and also fixed the inconsistencies between the two versions (Consumer/BiConsumer). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263049694 From jhendrikx at openjdk.org Thu Jul 13 21:10:23 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 21:10:23 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 00:21:19 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix ObservableSubscriptionsTest > > modules/javafx.base/src/main/java/javafx/beans/Observable.java line 101: > >> 99: * {@code invalidationSubscriber} whenever it becomes invalid. If the same >> 100: * subscriber is subscribed more than once, then it will be notified more >> 101: * than once. That is, no check is made to ensure uniqueness. > > Similar to the comments on `ObservableValue`: > > Creates a {@code Subscription} on this {@code Observable} that calls the given > {@code invalidationSubscriber} whenever it becomes invalid. This {@code Subscription} > is akin to an {@code InvalidationListener} without the {@code Observable} parameter. Added this, but reworded as: `The provided subscriber is akin ... ` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263053110 From jhendrikx at openjdk.org Thu Jul 13 21:10:20 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 21:10:20 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 00:01:23 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix ObservableSubscriptionsTest Created https://bugs.openjdk.org/browse/JDK-8312058 for doing the documentation changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1069#issuecomment-1634921208 From jhendrikx at openjdk.org Thu Jul 13 21:18:12 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 21:18:12 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners Message-ID: Incorporates review comments from #1069 ------------- Commit messages: - Documentation improvements Changes: https://git.openjdk.org/jfx/pull/1177/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312058 Stats: 18 lines in 3 files changed: 7 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1177.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1177/head:pull/1177 PR: https://git.openjdk.org/jfx/pull/1177 From jhendrikx at openjdk.org Thu Jul 13 21:19:19 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 21:19:19 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 20:52:15 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 33: >> >>> 31: /** >>> 32: * A subscription encapsulates how to cancel it without having >>> 33: * to keep track of how it was created. >> >> I would like to see some more info here, like what it is and how it's used, and a note on comparison with listeners. Taking a page out of `ChangeListener`, I took a stab at it: >> >> >> Executes code on change or invalidation events. A {@code Subscription} can be created by subscribing to invalidation >> events on an {@code Observable} using {@link Observable#subscribe(Runnable)} >> and to change events on an {@code ObsefvableValue} using {@link Observable#subscribe(Consumer)} >> and {@link Observable#subscribe(BiConsumer)}. It can be unsubscribed using {@link #unsuscribe}. >>

>> Subscriptions don't block the the {@code Observable} from being garbage collected, and will be collected with >> it (if they are not subscribed on other {@code Observable}s, see below). However, since {@code Observable}s >> blocks their subscriptions from being GC'd, {@code unsuscribe()} must be called if they are to be eligible for >> GC before the {@code Observable} is. Consider creating a derived {@code ObservableValue} >> using {@link #when(ObservableValue)} and subscribing on this derived observable value >> to automatically decouple the lifecycle of the subscriber from the original {@code ObservableValue} >> when some condition holds: >> {@code >> obs.when(cond).subscribe(...) >> } >>

>> Subscriptions can also be combined using {@link #combine} and {@link #and}, which allows for >> multiple subscriptions to be unsubscribed together. This is useful when they share the same lifecycle, >> which is usually the case when they are subscribed on the same {@code Observable}. >>

>> The same subscriber can be subscribed to multiple {@code Observable}s, including more than once on the >> same {@code Observable}, in which case it will be executed more than once. That is, no uniqueness check is made. >>

>> {@code Subscription}s behave similarly to {@link InvalidationListener}s and {@code ChangeListener}s. An >> advantage of {@code Subscription} is that it encapsulates how to cancel it without having to keep track of >> how it was created. >> >> >> This will also alleviate some repeated verbosity in the subscribe methods. > > I'm not entirely sure about this; the `Subscription` interface is pretty neutral in how it can be used, and does not have any direct link to observables at all; it's more of a token that you get that can be used to cancel a previous action, it doesn't actively do anything (unless you count the wrapper that it puts around the provided function). > > As it is, they don't even need to be associated with `Observable` or `ObservableValue` at all. Just as easily you could do: > > FileInputStream inputStream = .. ; > Subscription combined = Subscription.combine( > property.subscribe(this::invalidated), > () -> inputStream.close() > ); > > combined.subscribe(); // closes input stream and removes invalidations subscriber > > Although I think it is a good description, I'm not sure it belongs on this class. I put your changes (that we agree upon so far) in #1177 As I said I'm not sure about the description for the Subscription class, and it's not included yet, and so I also haven't yet removed the duplicated texts about GC-ability from the `subscribe` methods. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263061353 From jhendrikx at openjdk.org Thu Jul 13 21:24:14 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jul 2023 21:24:14 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 21:15:47 GMT, John Hendrikx wrote: >> I'm not entirely sure about this; the `Subscription` interface is pretty neutral in how it can be used, and does not have any direct link to observables at all; it's more of a token that you get that can be used to cancel a previous action, it doesn't actively do anything (unless you count the wrapper that it puts around the provided function). >> >> As it is, they don't even need to be associated with `Observable` or `ObservableValue` at all. Just as easily you could do: >> >> FileInputStream inputStream = .. ; >> Subscription combined = Subscription.combine( >> property.subscribe(this::invalidated), >> () -> inputStream.close() >> ); >> >> combined.subscribe(); // closes input stream and removes invalidations subscriber >> >> Although I think it is a good description, I'm not sure it belongs on this class. > > I put your changes (that we agree upon so far) in #1177 > > As I said I'm not sure about the description for the Subscription class, and it's not included yet, and so I also haven't yet removed the duplicated texts about GC-ability from the `subscribe` methods. I also now wonder if `Subscription` perhaps is in the wrong package (javafx.beans currently). Perhaps it should have been in javafx.util ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263065227 From kcr at openjdk.org Thu Jul 13 21:37:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Jul 2023 21:37:08 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 21:13:06 GMT, John Hendrikx wrote: > Incorporates documentation review comments from #1069. > > This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. As long as this is limited to clarification of the existing docs, no CSR is needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1177#issuecomment-1634950890 From nlisker at openjdk.org Fri Jul 14 01:48:09 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 14 Jul 2023 01:48:09 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 21:13:06 GMT, John Hendrikx wrote: > Incorporates documentation review comments from #1069. > > This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 63: > 61: * > 62: * Implementors must ensure the implementation is idempotent (a no-op > 63: * if called more than once). I now think this should be in an `@implSpec` tag since it specifies the implementation conditions. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1177#discussion_r1263201551 From nlisker at openjdk.org Fri Jul 14 02:13:20 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 14 Jul 2023 02:13:20 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 21:21:32 GMT, John Hendrikx wrote: >> I put your changes (that we agree upon so far) in #1177 >> >> As I said I'm not sure about the description for the Subscription class, and it's not included yet, and so I also haven't yet removed the duplicated texts about GC-ability from the `subscribe` methods. > > I also now wonder if `Subscription` perhaps is in the wrong package (javafx.beans currently). Perhaps it should have been in javafx.util ? Good point, I didn't think about subscriptions outside of the listeners contexts. let alone outside of the JavaFX content. It does look now like it belongs in the utils package. Maybe a quick correction can be made if Kevin agrees with this and you think it's worth it. Can you think where else in JavaFX subscriptions could be used? I'm thinking about the deprecated `finalize` and try-with-resource, anywhere where we need to release resources. This would give a better idea of what the class revolves around and thus what documentation fits it. Maybe the class should have a section about its use with JavaFX observables. I'm looking at the [`Service`](https://openjfx.io/javadoc/20/javafx.graphics/javafx/concurrent/Service.html) and [`Taks`](https://openjfx.io/javadoc/20/javafx.graphics/javafx/concurrent/Task.html) classes, which can also be used as general purpose, but have clear uses within JavaFX. So something like this structure: [General info about the class] How it can be used to release resources or finalize or undo... (the unsubscribe method)

Info about its `combine` and `and` methods (my 3rd paragraph) # In JavaFX Observables [Specific info about its use with observables] My paragraphs 1, 2, 4, 5 #Maybe some other wide specific use ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263216089 From arapte at openjdk.org Fri Jul 14 11:22:11 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 14 Jul 2023 11:22:11 GMT Subject: RFR: 8310847: [Mac] Silence OpenGL deprecation warnings [v2] In-Reply-To: References: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> Message-ID: On Wed, 28 Jun 2023 18:23:18 GMT, Martin Fox wrote: >> The Mac build issues a lot of warnings including several related to the deprecation of OpenGL in macOS 10.14. Now that the deployment target for JavaFX is 11.0 across the board these warnings are showing up on both M1 and Intel builds. Luckily Apple provides a simply way to silence these warnings by setting a single C preprocessor define. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Replaced deprecated constant Change looks good. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1161#pullrequestreview-1530117368 From kevin.rushforth at oracle.com Fri Jul 14 12:27:34 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Jul 2023 05:27:34 -0700 Subject: Changed fix version for open issues from jfx21 to jfx22 Message-ID: Now that we are in RDP1 for jfx21, and will use backports to integrate any further fixes that are needed for jfx21, I have bulk updated all JBS issues that were targeted to jfx21 to jfx22. Those that meet the RDP1 criteria can be backported after first being integrated into master for jfx22. -- Kevin From kpk at openjdk.org Fri Jul 14 12:31:49 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 14 Jul 2023 12:31:49 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v2] In-Reply-To: References: Message-ID: > In `TreeTableRowSkin`, graphic was not updated along with tree item update. > > Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. > > Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Add unit test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1172/files - new: https://git.openjdk.org/jfx/pull/1172/files/e15a3b24..8d8fdae8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1172&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1172&range=00-01 Stats: 47 lines in 1 file changed: 47 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1172.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1172/head:pull/1172 PR: https://git.openjdk.org/jfx/pull/1172 From kpk at openjdk.org Fri Jul 14 12:31:51 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 14 Jul 2023 12:31:51 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: <609F45dzQbunD-YAG7QYQ_rGLFjR_YtPtBkqxyq87vQ=.901308af-c77b-4f00-b61e-4c7f7769eee8@github.com> On Fri, 7 Jul 2023 05:25:34 GMT, Karthik P K wrote: > In `TreeTableRowSkin`, graphic was not updated along with tree item update. > > Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. > > Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. Added unit test as suggested above. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1635789658 From kcr at openjdk.org Fri Jul 14 13:19:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Jul 2023 13:19:08 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners In-Reply-To: References: Message-ID: <4pviASYTPD9fzGW4V-tkGKI3ZqFqdTkzLGMEuK3QoKY=.f00a1c44-4a39-4016-a68f-1fcf579c84ca@github.com> On Thu, 13 Jul 2023 21:13:06 GMT, John Hendrikx wrote: > Incorporates documentation review comments from #1069. > > This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. These changes look good to me, pending the addition of the `@implSpec` as noted by @nlisker If we decide to move the Subscription class to `javafx.util`, additional changes would be done as part of that fix (which would need a CSR). ------------- PR Review: https://git.openjdk.org/jfx/pull/1177#pullrequestreview-1530290673 From kcr at openjdk.org Fri Jul 14 13:22:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Jul 2023 13:22:16 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 02:10:34 GMT, Nir Lisker wrote: >> I also now wonder if `Subscription` perhaps is in the wrong package (javafx.beans currently). Perhaps it should have been in javafx.util ? > > Good point, I didn't think about subscriptions outside of the listeners contexts. let alone outside of the JavaFX content. It does look now like it belongs in the utils package. Maybe a quick correction can be made if Kevin agrees with this and you think it's worth it. > > Can you think where else in JavaFX subscriptions could be used? I'm thinking about the deprecated `finalize` and try-with-resource, anywhere where we need to release resources. This would give a better idea of what the class revolves around and thus what documentation fits it. > > Maybe the class should have a section about its use with JavaFX observables. I'm looking at the [`Service`](https://openjfx.io/javadoc/20/javafx.graphics/javafx/concurrent/Service.html) and [`Taks`](https://openjfx.io/javadoc/20/javafx.graphics/javafx/concurrent/Task.html) classes, which can also be used as general purpose, but have clear uses within JavaFX. > So something like this structure: > > > [General info about the class] > How it can be used to release resources or finalize or undo... (the unsubscribe method) >

> Info about its `combine` and `and` methods (my 3rd paragraph) > > # In JavaFX Observables [Specific info about its use with observables] > My paragraphs 1, 2, 4, 5 > > #Maybe some other wide specific use I also hadn't considered potential usage of Subscription outside of observables, but I can see some uses for it. John: I would support moving it to javafx.util (via a separate issue) if you think it is worth doing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263728904 From duke at openjdk.org Fri Jul 14 14:27:07 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 14 Jul 2023 14:27:07 GMT Subject: Integrated: 8310847: [Mac] Silence OpenGL deprecation warnings In-Reply-To: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> References: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> Message-ID: On Sat, 24 Jun 2023 17:53:31 GMT, Martin Fox wrote: > The Mac build issues a lot of warnings including several related to the deprecation of OpenGL in macOS 10.14. Now that the deployment target for JavaFX is 11.0 across the board these warnings are showing up on both M1 and Intel builds. Luckily Apple provides a simply way to silence these warnings by setting a single C preprocessor define. This pull request has now been integrated. Changeset: 440ce43e Author: Martin Fox Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/440ce43e8d45c781e65d0e8527d084e7d628f4a6 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8310847: [Mac] Silence OpenGL deprecation warnings Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1161 From jhendrikx at openjdk.org Fri Jul 14 15:02:17 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 14 Jul 2023 15:02:17 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: References: Message-ID: <_2sw1qP9WswVt-UfyiOUEJJAUYN4OUSHwYdhuFWAwno=.c544b10d-8e50-4779-8683-830833d2eeda@github.com> On Fri, 14 Jul 2023 13:19:22 GMT, Kevin Rushforth wrote: >> Good point, I didn't think about subscriptions outside of the listeners contexts, let alone outside of the JavaFX content. It does look now like it belongs in the utils package. Maybe a quick correction can be made if Kevin agrees with this and you think it's worth it. >> >> Can you think where else in JavaFX subscriptions could be used? I'm thinking about the deprecated `finalize` and try-with-resource, anywhere where we need to release resources. This would give a better idea of what the class revolves around and thus what documentation fits it. >> >> Maybe the class should have a section about its use with JavaFX observables. I'm looking at the [`Service`](https://openjfx.io/javadoc/20/javafx.graphics/javafx/concurrent/Service.html) and [`Taks`](https://openjfx.io/javadoc/20/javafx.graphics/javafx/concurrent/Task.html) classes, which can also be used as general purpose, but have clear uses within JavaFX. >> So something like this structure: >> >> >> [General info about the class] >> How it can be used to release resources or finalize or undo... (the unsubscribe method) >>

>> Info about its `combine` and `and` methods (my 3rd paragraph) >> >> # In JavaFX Observables [Specific info about its use with observables] >> My paragraphs 1, 2, 4, 5 >> >> #Maybe some other wide specific use > > I also hadn't considered potential usage of Subscription outside of observables, but I can see some uses for it. > > John: I would support moving it to javafx.util (via a separate issue) if you think it is worth doing. Correct packaging is often overlooked, so I think it is worth doing. I'll test to see if it doesn't cause any problems, and if not, I'll create an issue for it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263837195 From jhendrikx at openjdk.org Fri Jul 14 15:23:20 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 14 Jul 2023 15:23:20 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v13] In-Reply-To: <_2sw1qP9WswVt-UfyiOUEJJAUYN4OUSHwYdhuFWAwno=.c544b10d-8e50-4779-8683-830833d2eeda@github.com> References: <_2sw1qP9WswVt-UfyiOUEJJAUYN4OUSHwYdhuFWAwno=.c544b10d-8e50-4779-8683-830833d2eeda@github.com> Message-ID: On Fri, 14 Jul 2023 14:59:00 GMT, John Hendrikx wrote: >> I also hadn't considered potential usage of Subscription outside of observables, but I can see some uses for it. >> >> John: I would support moving it to javafx.util (via a separate issue) if you think it is worth doing. > > Correct packaging is often overlooked, so I think it is worth doing. I'll test to see if it doesn't cause any problems, and if not, I'll create an issue for it. > Good point, I didn't think about subscriptions outside of the listeners contexts, let alone outside of the JavaFX content. It does look now like it belongs in the utils package. Maybe a quick correction can be made if Kevin agrees with this and you think it's worth it. > > Can you think where else in JavaFX subscriptions could be used? I'm thinking about the deprecated `finalize` and try-with-resource, anywhere where we need to release resources. This would give a better idea of what the class revolves around and thus what documentation fits it. It's very general, basically a specifically purposed `Runnable` where `run` is called `unsubscribe` with some chaining methods. You could use it for purposes we may not be able to think of right now. I've looked at some `dispose` methods, which often have clean-up code for some inspiration: 1. Use it to clean up references: `() -> { this.skinnable = null; this.scrollBar = null; }` 2. Use it to stop animation timers or timelines : `() -> animationTimer.stop();` 3. You could wrap other add/remove style API that don't offer a `Subscription`: `() -> getSkinnable().removeEventHandler( ... )` I'm not saying you always should do this, but if you are releasing a `Subscription` anyway, you could combine some of these. Also, if new API decides to provide a subscription, they're not limited to only remove a listener, they could also stop a thread, a timer or release some resources that was started/allocated when the subscription was created. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1263857263 From angorya at openjdk.org Fri Jul 14 16:07:11 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Jul 2023 16:07:11 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 12:31:49 GMT, Karthik P K wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add unit test the test passes with the fix, fails in the master branch. one minor suggestion, unrelated, but probably worth addressing in to this PR. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 407: > 405: > 406: @AfterEach > 407: public void after() { unrelated to the current PR, but could this method be more defensive, to avoid any problems with the invocation order? @AfterEach public void after() { if (stageLoader != null) { stageLoader.dispose(); stageLoader = null; } } ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1172#pullrequestreview-1530560923 PR Review Comment: https://git.openjdk.org/jfx/pull/1172#discussion_r1263894796 From angorya at openjdk.org Fri Jul 14 16:40:11 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Jul 2023 16:40:11 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 12:31:49 GMT, Karthik P K wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add unit test github says it fails pre-submit check - probably some kind of spurious failure, local build and headful tests (minus web tests) are ok on macOS. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1636106227 From kevin.rushforth at oracle.com Fri Jul 14 16:51:36 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Jul 2023 09:51:36 -0700 Subject: State of JavaFX Notebook In-Reply-To: References: Message-ID: <071595da-be66-79f2-abd6-c3a889cd75dc@oracle.com> I was away from my email last week, so just getting to this. By way of very short update, I presented an updated JavaFX Notebook technology demo as part of a JavaFX 20 and Beyond talk I did for the JDK 20 day at Oracle's DevLive Level Up 2023 [1] in March. It's still in the early stages; I hope to have more to share later this year. -- Kevin [1] https://developer.oracle.com/community/events/devlive-level-up-march-2023-recordings.html On 7/6/2023 12:50 AM, Sven Reimers wrote: > Hi all, > > Greetings from JCrete, > > we are having a discussion about Java, Jupyter and JShell which > reminded me of the demo of JavaFX Notebook. > > Can anyone give a short update? Maybe I missed some good news? > > Thx > > Sven From kizune at openjdk.org Fri Jul 14 20:02:11 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 14 Jul 2023 20:02:11 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 05:25:45 GMT, Ambarish Rapte wrote: > May I suggest an alternate naming pattern similar to AccessibleBase.h. Can we name our files as AccessibleButton, (AccessibleList, ... and so forth) ? The slight issue with this approach is that in my opinion the class names will be too similar for the first look which will make code less readable. Also that will make code in JDK and JFX less similar which might be a problem for anyone who will support accessibility on both sides. For that reason i'm trying to keep naming and structure of the files as close as possible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1174#issuecomment-1636353075 From kcr at openjdk.org Fri Jul 14 22:13:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Jul 2023 22:13:09 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: <5m_Fy6gQ4BD1llVqg2QZUhhbGR9ArikcdZfA3r42u6w=.fcf77d24-730e-4fa8-a796-8a2d1a9ddcd3@github.com> On Mon, 10 Jul 2023 20:39:34 GMT, Alexander Zuev wrote: > To avoid confusion on the os x dynamic linker side i renamed native classes from ButtonAccessibility to JFXButtonAccessibility. I will use JFX prefix down the line to avoid any confusion when running with the latest JDK that also migrated to the new a11y API. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1174#pullrequestreview-1531107621 From kcr at openjdk.org Fri Jul 14 22:13:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Jul 2023 22:13:11 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: <32NQHGI0kzAZUQmT11vMIqrKoCH-GDy4NkwgBwG3S7A=.a48fdbdf-ab39-4c4b-9b2a-3016691a6f0f@github.com> On Fri, 14 Jul 2023 19:59:26 GMT, Alexander Zuev wrote: > The slight issue with this approach is that in my opinion the class names will be too similar for the first look which will make code less readable. Also that will make code in JDK and JFX less similar which might be a problem for anyone who will support accessibility on both sides. For that reason i'm trying to keep naming and structure of the files as close as possible. OK, that explanation makes sense to me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1174#issuecomment-1636500302 From kcr at openjdk.org Sat Jul 15 14:32:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 15 Jul 2023 14:32:09 GMT Subject: RFR: 8311185: VirtualFlow jump when cellcount changes In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 17:43:56 GMT, Johan Vos wrote: > When the cellcount changes, we need to make sure that the size of the current first visible cell is known. > > This avoids index errors due to the current offset (between the top of the viewport and the current first visible cell) being potentially larger than the new estimated cellsize. > > Added a test that fails before and succeeds after the patch. The test uses the same logic as the reproducer in the JBS issue. The fix looks good to me, as does the test. I can confirm that the test program attached to the JBS issue now works, and that the new unit test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1164#pullrequestreview-1531437130 From jvos at openjdk.org Sat Jul 15 15:09:09 2023 From: jvos at openjdk.org (Johan Vos) Date: Sat, 15 Jul 2023 15:09:09 GMT Subject: Integrated: 8311185: VirtualFlow jump when cellcount changes In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 17:43:56 GMT, Johan Vos wrote: > When the cellcount changes, we need to make sure that the size of the current first visible cell is known. > > This avoids index errors due to the current offset (between the top of the viewport and the current first visible cell) being potentially larger than the new estimated cellsize. > > Added a test that fails before and succeeds after the patch. The test uses the same logic as the reproducer in the JBS issue. This pull request has now been integrated. Changeset: 0371b349 Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/0371b349c929a0f8e71d8f2a01b1e565bb885e6c Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod 8311185: VirtualFlow jump when cellcount changes Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1164 From kpk at openjdk.org Mon Jul 17 07:06:43 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 17 Jul 2023 07:06:43 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v3] In-Reply-To: References: Message-ID: > In `TreeTableRowSkin`, graphic was not updated along with tree item update. > > Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. > > Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1172/files - new: https://git.openjdk.org/jfx/pull/1172/files/8d8fdae8..78a91a57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1172&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1172&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1172.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1172/head:pull/1172 PR: https://git.openjdk.org/jfx/pull/1172 From kpk at openjdk.org Mon Jul 17 07:06:45 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 17 Jul 2023 07:06:45 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 16:37:27 GMT, Andy Goryachev wrote: > github says it fails pre-submit check - probably some kind of spurious failure, local build and headful tests (minus web tests) are ok on macOS. Ran the pre-submit checks again. All checks are passing now ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1637484205 From kpk at openjdk.org Mon Jul 17 07:09:09 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 17 Jul 2023 07:09:09 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 16:00:33 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add unit test > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 407: > >> 405: >> 406: @AfterEach >> 407: public void after() { > > unrelated to the current PR, but could this method be more defensive, to avoid any problems with the invocation order? > > > @AfterEach > public void after() { > if (stageLoader != null) { > stageLoader.dispose(); > stageLoader = null; > } > } This looks like a good check to have. Made above suggested code changes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1172#discussion_r1264954990 From sebastian.stenzel at gmail.com Mon Jul 17 14:56:05 2023 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 17 Jul 2023 16:56:05 +0200 Subject: Suggestions for StageStyle.UNIFIED on macOS In-Reply-To: <6246220E-D396-48A5-A003-9111753EC1D6@gmail.com> References: <827F518D-F761-4E93-8808-B02EC9A42141@martinfox.com> <6246220E-D396-48A5-A003-9111753EC1D6@gmail.com> Message-ID: Other than announced, there wasn't any intend to deprecated `StageStyle.UNIFIED` yet. So I was wondering what is the status here? My suggestion to actually make it work (at least on one platform [1]) didn't seem to whip up much enthusiasm either. I'm still open to invest time into this feature, but not without any reliable info about what is the plan for window decorations. Is any strategy in which direction OpenJFX should evolve? Or if you allow me to ask a bit of a cynical question: Are desktop apps still of interest? ;-) [1] https://gist.github.com/overheadhunter/29af68f4c4eb7de28dd4a3a4772a0f09 > Am 09.02.2022 um 13:22 schrieb Sebastian Stenzel : > > Since there aren't any further comments on this, I assume there isn't much interest in this. Deprecating it is probably the right move, if it never worked as intended on any platform. I think I'm going to try and get this working as some kind of library instead. > >> On 3. Feb 2022, at 20:55, Martin Fox > wrote: >> >> I took a look at this and discovered that UNIFIED doesn?t really work on any platform. It was never supported on Linux, the Mac implementation doesn?t really unify anything, and Windows is broken (see JDK-8154847 ). In that bug report it?s suggested that UNIFIED be deprecated. >> >> I don?t think the UNIFIED API was ever complete. For example, I don?t see a way of querying the system to discover the location of the OS window controls so you can position your JavaFX controls appropriately. >> >> Getting this right on the Mac would require some plumbing. We would need an API so we know which JavaFX controls are supposed to be in the unified title bar area so we can get the hit-testing right to enable dragging, title bar double-clicks, etc. I could imagine a new control that you could wrap around an existing control (like a Toolbar) that would handle the hit-testing and positioning correctly. I?m fuzzier on what it would take on Windows and there?s still the drawing problems to sort out. >> >> Would be nice to have, the unified look is ascendant. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Jul 17 15:29:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 17 Jul 2023 15:29:12 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v3] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 07:06:43 GMT, Karthik P K wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments looks good, re-approving the latest changes. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1172#pullrequestreview-1533075921 From michaelstrau2 at gmail.com Mon Jul 17 19:23:47 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 17 Jul 2023 21:23:47 +0200 Subject: CSS Transitions In-Reply-To: References: Message-ID: Here's an updated summary of the proposed feature: https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a And here's the full implementation: https://github.com/openjdk/jfx/pull/870 I'm interested in hearing from you whether you think this is a useful feature and whether the proposed API is a good match for JavaFX. From martin at martinfox.com Mon Jul 17 23:35:38 2023 From: martin at martinfox.com (Martin Fox) Date: Mon, 17 Jul 2023 16:35:38 -0700 Subject: Suggestions for StageStyle.UNIFIED on macOS In-Reply-To: References: <827F518D-F761-4E93-8808-B02EC9A42141@martinfox.com> <6246220E-D396-48A5-A003-9111753EC1D6@gmail.com> Message-ID: <793B6750-2FFD-41EF-B861-9FB8337128D5@martinfox.com> Ignore my earlier comments on UNIFIED since I didn?t understand it. All UNIFIED did was alter the way the window background was drawn to support the ?sheet of glass? effect introduced in Windows Vista and the equivalent brushed metal effect on Mac (which I think dates back to Panther). As far as I can tell it worked fine on both platforms but Microsoft and Apple removed those visuals a long time ago. On Mac and Windows I?ve prototyped a different stage style (COMBINED) which is closer to what you want. It extends the JavaFX stage into the titlebar area so JavaFX controls can co-exist with the platform decorations. I?ve been meaning to submit this as a draft PR for comment but got side-tracked by other projects (including my keyboard-related PR?s which are still working their way through the review process). I?ll try to get it cleaned up and submit a PR in the next couple of weeks. Martin > On Jul 17, 2023, at 7:56 AM, Sebastian Stenzel wrote: > > Other than announced, there wasn't any intend to deprecated `StageStyle.UNIFIED` yet. So I was wondering what is the status here? My suggestion to actually make it work (at least on one platform [1]) didn't seem to whip up much enthusiasm either. > > I'm still open to invest time into this feature, but not without any reliable info about what is the plan for window decorations. Is any strategy in which direction OpenJFX should evolve? Or if you allow me to ask a bit of a cynical question: Are desktop apps still of interest? ;-) > > [1] https://gist.github.com/overheadhunter/29af68f4c4eb7de28dd4a3a4772a0f09 > >> Am 09.02.2022 um 13:22 schrieb Sebastian Stenzel : >> >> Since there aren't any further comments on this, I assume there isn't much interest in this. Deprecating it is probably the right move, if it never worked as intended on any platform. I think I'm going to try and get this working as some kind of library instead. >> >>> On 3. Feb 2022, at 20:55, Martin Fox > wrote: >>> >>> I took a look at this and discovered that UNIFIED doesn?t really work on any platform. It was never supported on Linux, the Mac implementation doesn?t really unify anything, and Windows is broken (see JDK-8154847 ). In that bug report it?s suggested that UNIFIED be deprecated. >>> >>> I don?t think the UNIFIED API was ever complete. For example, I don?t see a way of querying the system to discover the location of the OS window controls so you can position your JavaFX controls appropriately. >>> >>> Getting this right on the Mac would require some plumbing. We would need an API so we know which JavaFX controls are supposed to be in the unified title bar area so we can get the hit-testing right to enable dragging, title bar double-clicks, etc. I could imagine a new control that you could wrap around an existing control (like a Toolbar) that would handle the hit-testing and positioning correctly. I?m fuzzier on what it would take on Windows and there?s still the drawing problems to sort out. >>> >>> Would be nice to have, the unified look is ascendant. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Jul 18 05:14:07 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 18 Jul 2023 05:14:07 GMT Subject: RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: <7V6OKJsJybcVMxz7J9ee-MMOjzHWIe_suPrnHdaJtOI=.f7069cdb-2538-4f81-94ab-580a41e1a0ef@github.com> On Mon, 10 Jul 2023 20:39:34 GMT, Alexander Zuev wrote: > To avoid confusion on the os x dynamic linker side i renamed native classes from ButtonAccessibility to JFXButtonAccessibility. I will use JFX prefix down the line to avoid any confusion when running with the latest JDK that also migrated to the new a11y API. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1174#pullrequestreview-1534191202 From psadhukhan at openjdk.org Tue Jul 18 06:11:20 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 18 Jul 2023 06:11:20 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer Message-ID: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. ------------- Commit messages: - 8255248: NullPointerException in JFXPanel due to race condition in HostContainer Changes: https://git.openjdk.org/jfx/pull/1178/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8255248 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1178.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1178/head:pull/1178 PR: https://git.openjdk.org/jfx/pull/1178 From aghaisas at openjdk.org Tue Jul 18 10:18:06 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 18 Jul 2023 10:18:06 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer In-Reply-To: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Tue, 18 Jul 2023 06:05:06 GMT, Prasanta Sadhukhan wrote: > Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. This avoids the NPE. Overall, I think that we should choose between below options- - Option 1 : A null check should be added to every usage of `scenePeer` and `stagePeer` as close to the usage as possible. - Option 2: The usage of `scenePeer` and `stagePeer` should be `synchronized`. I am not well versed with this area of the code and hence cannot comment on ramifications of Option 2. Also, can we add a test? (either automated or manual) - I see that there is a sample in JBS that demonstrates this issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1178#issuecomment-1639942140 From kevin.rushforth at oracle.com Tue Jul 18 14:12:33 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Jul 2023 07:12:33 -0700 Subject: RFR: Request to sync July 2023 CPU changes into jfx:master, jfx:jfx21, jfx20u Message-ID: <10fd594d-afb4-bfa8-c23e-e16b98b552da@oracle.com> Hi Johan, I request approval to sync changes from to the just-released July 2023 CPU release into the 'master' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/0371b349c9...cpu-2307-sync NOTE: Since this is an integration of already-reviewed fixes, I will push it directly to the master branch of the jfx repo rather than via a pull request. I also plan to push the backports of these changes to jfx:jfx21 and jfx20u (for 20.0.2) along with the 20.0.2* tags. Thanks. -- Kevin From johan.vos at gluonhq.com Tue Jul 18 14:16:16 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 18 Jul 2023 16:16:16 +0200 Subject: RFR: Request to sync July 2023 CPU changes into jfx:master, jfx:jfx21, jfx20u In-Reply-To: <10fd594d-afb4-bfa8-c23e-e16b98b552da@oracle.com> References: <10fd594d-afb4-bfa8-c23e-e16b98b552da@oracle.com> Message-ID: approved On Tue, Jul 18, 2023 at 4:13?PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to sync changes from to the just-released July 2023 > CPU release into the 'master' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/0371b349c9...cpu-2307-sync > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the master branch of the jfx repo rather than via a > pull request. > > I also plan to push the backports of these changes to jfx:jfx21 and > jfx20u (for 20.0.2) along with the 20.0.2* tags. > > Thanks. > > -- Kevin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jul 18 14:22:27 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 18 Jul 2023 14:22:27 GMT Subject: [jfx20u] RFR: 8312097: Create release notes for JavaFX 20.0.2 Message-ID: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> Release notes for JavaFX 20.0.2. ------------- Commit messages: - Add CPU bug - 8312097: Create release notes for JavaFX 20.0.2 Changes: https://git.openjdk.org/jfx20u/pull/16/files Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=16&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312097 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx20u/pull/16.diff Fetch: git fetch https://git.openjdk.org/jfx20u.git pull/16/head:pull/16 PR: https://git.openjdk.org/jfx20u/pull/16 From kcr at openjdk.org Tue Jul 18 14:22:27 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 18 Jul 2023 14:22:27 GMT Subject: [jfx20u] RFR: 8312097: Create release notes for JavaFX 20.0.2 In-Reply-To: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> References: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> Message-ID: On Fri, 14 Jul 2023 14:08:56 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 20.0.2. @johanvos @abhinayagarwal Can you review this? ------------- PR Comment: https://git.openjdk.org/jfx20u/pull/16#issuecomment-1640317759 From jvos at openjdk.org Tue Jul 18 14:45:10 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 18 Jul 2023 14:45:10 GMT Subject: [jfx20u] RFR: 8312097: Create release notes for JavaFX 20.0.2 In-Reply-To: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> References: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> Message-ID: On Fri, 14 Jul 2023 14:08:56 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 20.0.2. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx20u/pull/16#pullrequestreview-1535208088 From kevin.rushforth at oracle.com Tue Jul 18 14:53:45 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Jul 2023 07:53:45 -0700 Subject: RFR: Request to sync July 2023 CPU changes into jfx:master, jfx:jfx21, jfx20u In-Reply-To: References: <10fd594d-afb4-bfa8-c23e-e16b98b552da@oracle.com> Message-ID: <76c39227-538f-b283-e0ce-3759a7b6c218@oracle.com> Done. -- Kevin On 7/18/2023 7:16 AM, Johan Vos wrote: > approved > > On Tue, Jul 18, 2023 at 4:13?PM Kevin Rushforth > wrote: > > Hi Johan, > > I request approval to sync changes from to the just-released July > 2023 > CPU release into the 'master' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/0371b349c9...cpu-2307-sync > > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the master branch of the jfx repo rather than > via a > pull request. > > I also plan to push the backports of these changes to jfx:jfx21 and > jfx20u (for 20.0.2) along with the 20.0.2* tags. > > Thanks. > > -- Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jul 18 14:55:08 2023 From: duke at openjdk.org (Abhinay Agarwal) Date: Tue, 18 Jul 2023 14:55:08 GMT Subject: [jfx20u] RFR: 8312097: Create release notes for JavaFX 20.0.2 In-Reply-To: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> References: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> Message-ID: On Fri, 14 Jul 2023 14:08:56 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 20.0.2. Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jfx20u/pull/16#pullrequestreview-1535229972 From kcr at openjdk.org Tue Jul 18 14:59:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 18 Jul 2023 14:59:08 GMT Subject: [jfx20u] Integrated: 8312097: Create release notes for JavaFX 20.0.2 In-Reply-To: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> References: <6k-nph3vqnsPQnjFtIhJc2B7MFRpvqJRQGcT2LUkV90=.0e1abcd2-d210-4fed-be44-677b2da570a6@github.com> Message-ID: On Fri, 14 Jul 2023 14:08:56 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 20.0.2. This pull request has now been integrated. Changeset: bf896e66 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx20u/commit/bf896e66827e3ab76f45d3e1c27fb21cd1b2c22c Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod 8312097: Create release notes for JavaFX 20.0.2 Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx20u/pull/16 From mstrauss at openjdk.org Tue Jul 18 15:07:11 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Jul 2023 15:07:11 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer In-Reply-To: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: <0wx7YSCiYOtwoWBO9Ygv3CHBzgUkIjUEFheFc2tiGIQ=.be8c951a-0c16-452f-9bd7-3d6847eaef67@github.com> On Tue, 18 Jul 2023 06:05:06 GMT, Prasanta Sadhukhan wrote: > Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. The proposed patch does not appear to fix the issue. Here's how the code currently looks like (after the patch is applied): 786 @Override 787 protected void paintComponent(Graphics g) { 788 if (scenePeer == null) { 789 return; 790 } 791 if (pixelsIm == null) { 792 createResizePixelBuffer(scaleFactorX, scaleFactorY); 793 if (pixelsIm == null) { 794 return; 795 } 796 } 797 DataBufferInt dataBuf = (DataBufferInt)pixelsIm.getRaster().getDataBuffer(); 798 int[] pixelsData = dataBuf.getData(); 799 IntBuffer buf = IntBuffer.wrap(pixelsData); 800 if (scenePeer != null && !scenePeer.getPixels(buf, pWidth, pHeight)) { 801 // In this case we just render what we have so far in the buffer. 802 } Note that in L788, we return early if `scenePeer` is null. The fact that `scenePeer` can sometimes be null in L800 means that the field is changed on a different thread. Since that's the case, no amount of null checking will ever be good enough: `scenePeer` can just as easily be null after the check succeeds in L800. Similiar issues can be observed in other places, for example later in the same file: private class HostContainer implements HostInterface { @Override public void setEmbeddedScene(EmbeddedSceneInterface embeddedScene) { ... scenePeer = embeddedScene; .... invokeOnClientEDT(() -> { .... if (scenePeer != null) { scenePeer.setDragStartListener(dnd.getDragStartListener()); } }); } } Note that `scenePeer` is assigned on the thread that calls `setEmbeddedScene`, and then its value is read from the EDT. Since it appears that `JFXPanel` is inherently multi-threaded, every usage of an unprotected shared field is potentially faulty. At the very least, every field that can be written to or read from multiple threads must be protected by a lock. Note that is is not enough to just protect all writes; all reads have to be protected as well. In addition to that, we need to account for concurrent code execution. What happens if thread A runs code on `scenePeer`, while thread B has already created a new scene peer? Is this safe? If not, then we need to prevent such concurrent execution. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1178#issuecomment-1640402709 From kizune at openjdk.org Tue Jul 18 17:58:52 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 18 Jul 2023 17:58:52 GMT Subject: Integrated: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 20:39:34 GMT, Alexander Zuev wrote: > To avoid confusion on the os x dynamic linker side i renamed native classes from ButtonAccessibility to JFXButtonAccessibility. I will use JFX prefix down the line to avoid any confusion when running with the latest JDK that also migrated to the new a11y API. This pull request has now been integrated. Changeset: ad5e66a7 Author: Alexander Zuev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/ad5e66a7ca31994ecbdae3fc7d0b951e0a6f8197 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod 8311806: Class ButtonAccessibility is implemented twice Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1174 From kizune at openjdk.org Tue Jul 18 20:24:12 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 18 Jul 2023 20:24:12 GMT Subject: [jfx21] RFR: 8311806: Class ButtonAccessibility is implemented twice Message-ID: Backport of the JDK-8311806 from main branch. ------------- Commit messages: - Backport ad5e66a7ca31994ecbdae3fc7d0b951e0a6f8197 Changes: https://git.openjdk.org/jfx/pull/1179/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311806 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1179.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1179/head:pull/1179 PR: https://git.openjdk.org/jfx/pull/1179 From kcr at openjdk.org Tue Jul 18 20:45:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 18 Jul 2023 20:45:46 GMT Subject: [jfx21] RFR: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 20:17:13 GMT, Alexander Zuev wrote: > Backport of the JDK-8311806 from main branch. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1179#pullrequestreview-1535876848 From kizune at openjdk.org Tue Jul 18 21:09:48 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 18 Jul 2023 21:09:48 GMT Subject: [jfx21] Integrated: 8311806: Class ButtonAccessibility is implemented twice In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 20:17:13 GMT, Alexander Zuev wrote: > Backport of the JDK-8311806 from main branch. This pull request has now been integrated. Changeset: 529d4796 Author: Alexander Zuev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/529d47961467b11e60fd06c634021912dc193c51 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod 8311806: Class ButtonAccessibility is implemented twice Reviewed-by: kcr Backport-of: ad5e66a7ca31994ecbdae3fc7d0b951e0a6f8197 ------------- PR: https://git.openjdk.org/jfx/pull/1179 From psadhukhan at openjdk.org Wed Jul 19 06:02:13 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 19 Jul 2023 06:02:13 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v2] In-Reply-To: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: > Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Add lock for read/write of scenePeer/stagePeer and added system test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1178/files - new: https://git.openjdk.org/jfx/pull/1178/files/f07c77ae..73a3e6b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=00-01 Stats: 224 lines in 2 files changed: 181 ins; 1 del; 42 mod Patch: https://git.openjdk.org/jfx/pull/1178.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1178/head:pull/1178 PR: https://git.openjdk.org/jfx/pull/1178 From kcr at openjdk.org Wed Jul 19 15:06:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Jul 2023 15:06:26 GMT Subject: [jfx21u] RFR: 8312128: Change JavaFX release version to 21.0.1 in jfx21u Message-ID: Updates for the beginning of the 21.0.1 release. ------------- Commit messages: - 8312128: Change JavaFX release version to 21.0.1 in jfx21u Changes: https://git.openjdk.org/jfx21u/pull/1/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=1&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312128 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/1.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/1/head:pull/1 PR: https://git.openjdk.org/jfx21u/pull/1 From kcr at openjdk.org Wed Jul 19 15:06:27 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Jul 2023 15:06:27 GMT Subject: [jfx21u] RFR: 8312128: Change JavaFX release version to 21.0.1 in jfx21u In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 14:50:54 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 21.0.1 release. Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/1#issuecomment-1642243440 From kpk at openjdk.org Wed Jul 19 16:06:48 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 19 Jul 2023 16:06:48 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 07:58:56 GMT, Johan Vos wrote: >> Is it possible to write a Unit test as well? > > +1 on @Maran23 to add a unit test. > For these kinds of changes, I think it is important to have a performance check as well (e.g. count the number of invocations to updateItem etc). @johanvos could you please review the latest updates? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1642364534 From arapte at openjdk.org Wed Jul 19 16:59:51 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 19 Jul 2023 16:59:51 GMT Subject: [jfx21u] RFR: 8312128: Change JavaFX release version to 21.0.1 in jfx21u In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 14:50:54 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 21.0.1 release. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/1#pullrequestreview-1537548556 From jvos at openjdk.org Wed Jul 19 17:00:52 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 19 Jul 2023 17:00:52 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v3] In-Reply-To: References: Message-ID: <9lzVzf0YHA6bH8frtUEukQ-ILzA9Z368-u-xbwKiHBI=.de77f65c-e9ef-410a-8a04-514414f8e439@github.com> On Mon, 17 Jul 2023 07:06:43 GMT, Karthik P K wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Looks ok now. Thanks @kleopatra for the guidance on the test. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1172#pullrequestreview-1537552808 From kcr at openjdk.org Wed Jul 19 17:09:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Jul 2023 17:09:52 GMT Subject: [jfx21u] Integrated: 8312128: Change JavaFX release version to 21.0.1 in jfx21u In-Reply-To: References: Message-ID: <8tnzg3jtOd9WMUYkk3VvkUkkcq4uR9OwHo4hH4NIW4s=.52c9df8f-5aab-4eaa-a07f-cfefca3e90bb@github.com> On Wed, 19 Jul 2023 14:50:54 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 21.0.1 release. This pull request has now been integrated. Changeset: 52f3fc86 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/52f3fc867d984a4d5a4835cdaab8b6431b561815 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8312128: Change JavaFX release version to 21.0.1 in jfx21u Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx21u/pull/1 From kcr at openjdk.org Wed Jul 19 17:20:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Jul 2023 17:20:21 GMT Subject: [jfx21u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Message-ID: <2WxEihukWHEyGSQAcOUcV74UdskYYxQyjd2BC_TjnF0=.0ec124e8-9aa8-47b7-81b0-19e41dfac15c@github.com> Backport the changes to the README and CONTTRIBUTING guidelines for update releases. There are two commits: the first is a clean backport of the fix that went into jfx20u. The second is a simple substitution changing 20 to 21 in the two files. ------------- Commit messages: - Change 20 --> 21 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Changes: https://git.openjdk.org/jfx21u/pull/2/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=2&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304008 Stats: 267 lines in 2 files changed: 1 ins; 254 del; 12 mod Patch: https://git.openjdk.org/jfx21u/pull/2.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/2/head:pull/2 PR: https://git.openjdk.org/jfx21u/pull/2 From kcr at openjdk.org Wed Jul 19 17:20:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Jul 2023 17:20:21 GMT Subject: [jfx21u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: <2WxEihukWHEyGSQAcOUcV74UdskYYxQyjd2BC_TjnF0=.0ec124e8-9aa8-47b7-81b0-19e41dfac15c@github.com> References: <2WxEihukWHEyGSQAcOUcV74UdskYYxQyjd2BC_TjnF0=.0ec124e8-9aa8-47b7-81b0-19e41dfac15c@github.com> Message-ID: On Wed, 19 Jul 2023 17:13:00 GMT, Kevin Rushforth wrote: > Backport the changes to the README and CONTTRIBUTING guidelines for update releases. There are two commits: the first is a clean backport of the fix that went into jfx20u. The second is a simple substitution changing 20 to 21 in the two files. @johanvos can you review this when you get a chance? This changes the README and CONTRIBUTING to match jfx20u, replacing 20 with 21. ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/2#issuecomment-1642461809 From jvos at openjdk.org Wed Jul 19 18:26:25 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 19 Jul 2023 18:26:25 GMT Subject: [jfx21u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: <2WxEihukWHEyGSQAcOUcV74UdskYYxQyjd2BC_TjnF0=.0ec124e8-9aa8-47b7-81b0-19e41dfac15c@github.com> References: <2WxEihukWHEyGSQAcOUcV74UdskYYxQyjd2BC_TjnF0=.0ec124e8-9aa8-47b7-81b0-19e41dfac15c@github.com> Message-ID: On Wed, 19 Jul 2023 17:13:00 GMT, Kevin Rushforth wrote: > Backport the changes to the README and CONTTRIBUTING guidelines for update releases. There are two commits: the first is a clean backport of the fix that went into jfx20u. The second is a simple substitution changing 20 to 21 in the two files. all good ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx21u/pull/2#pullrequestreview-1537709823 From mhanl at openjdk.org Wed Jul 19 19:04:09 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 19 Jul 2023 19:04:09 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v3] In-Reply-To: References: Message-ID: <9s2mFv1qXWXN1GGaELcVpP6CFmGqR09vIs6LnqwWiqs=.21a52b32-5695-46d1-8587-bef9a8e12088@github.com> On Mon, 17 Jul 2023 07:06:43 GMT, Karthik P K wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 372: > 370: > 371: for (int i = 0; i < 4; i++) { > 372: TreeItem parent = new TreeItem("item - " + i, new Rectangle(10, 10)); Generics should be added here modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 380: > 378: > 379: int itemNodeSize = tree.getRoot().getChildren().size(); > 380: TreeItem treeItem = (TreeItem)tree.getRoot().getChildren().get(itemNodeSize - 2); Cast is not needed here and below ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1172#discussion_r1268545646 PR Review Comment: https://git.openjdk.org/jfx/pull/1172#discussion_r1268545263 From kcr at openjdk.org Wed Jul 19 22:11:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Jul 2023 22:11:45 GMT Subject: [jfx21u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: <2WxEihukWHEyGSQAcOUcV74UdskYYxQyjd2BC_TjnF0=.0ec124e8-9aa8-47b7-81b0-19e41dfac15c@github.com> References: <2WxEihukWHEyGSQAcOUcV74UdskYYxQyjd2BC_TjnF0=.0ec124e8-9aa8-47b7-81b0-19e41dfac15c@github.com> Message-ID: On Wed, 19 Jul 2023 17:13:00 GMT, Kevin Rushforth wrote: > Backport the changes to the README and CONTTRIBUTING guidelines for update releases. There are two commits: the first is a clean backport of the fix that went into jfx20u. The second is a simple substitution changing 20 to 21 in the two files. This pull request has now been integrated. Changeset: d689dc12 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/d689dc12751660c14e558c37e82f8dc71d9a8037 Stats: 267 lines in 2 files changed: 1 ins; 254 del; 12 mod 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Reviewed-by: jvos Backport-of: 9733e7a925df2cf47d5994b55dbb563d7fa90e94 ------------- PR: https://git.openjdk.org/jfx21u/pull/2 From kpk at openjdk.org Thu Jul 20 06:54:14 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 20 Jul 2023 06:54:14 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v4] In-Reply-To: References: Message-ID: <_4j6cuDq-nxQsh8AUjEbTFya-uTeYhF9QciOxUs2RKw=.23acc0df-ea9b-4c3e-8399-3eb308bbf67f@github.com> > In `TreeTableRowSkin`, graphic was not updated along with tree item update. > > Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. > > Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1172/files - new: https://git.openjdk.org/jfx/pull/1172/files/78a91a57..369035c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1172&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1172&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1172.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1172/head:pull/1172 PR: https://git.openjdk.org/jfx/pull/1172 From kpk at openjdk.org Thu Jul 20 06:59:47 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 20 Jul 2023 06:59:47 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Sat, 8 Jul 2023 10:15:47 GMT, Marius Hanl wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Is it possible to write a Unit test as well? Made changes according to @Maran23's review comments. Please re-approve the changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1643381887 From mhanl at openjdk.org Thu Jul 20 09:08:52 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 20 Jul 2023 09:08:52 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v4] In-Reply-To: <_4j6cuDq-nxQsh8AUjEbTFya-uTeYhF9QciOxUs2RKw=.23acc0df-ea9b-4c3e-8399-3eb308bbf67f@github.com> References: <_4j6cuDq-nxQsh8AUjEbTFya-uTeYhF9QciOxUs2RKw=.23acc0df-ea9b-4c3e-8399-3eb308bbf67f@github.com> Message-ID: On Thu, 20 Jul 2023 06:54:14 GMT, Karthik P K wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Looks good. Can confirm that the test fails before. Thanks! ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1172#pullrequestreview-1538804843 From mhanl at openjdk.org Thu Jul 20 09:20:54 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 20 Jul 2023 09:20:54 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v2] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Wed, 19 Jul 2023 06:02:13 GMT, Prasanta Sadhukhan wrote: >> Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Add lock for read/write of scenePeer/stagePeer and added system test modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 428: > 426: private void sendMouseEventToFX(MouseEvent e) { > 427: EmbeddedSceneInterface lScenePeer = getScenePeer(); > 428: if (lScenePeer == null || !isFxEnabled()) { Probably minor, but maybe we should first check `!isFxEnabled()` and return fast before we actually call `getScenePeer()` and thus locking it ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1269185672 From psadhukhan at openjdk.org Thu Jul 20 10:12:09 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 20 Jul 2023 10:12:09 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: > Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Check FXEnabled initially ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1178/files - new: https://git.openjdk.org/jfx/pull/1178/files/73a3e6b0..c5c300db Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=01-02 Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1178.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1178/head:pull/1178 PR: https://git.openjdk.org/jfx/pull/1178 From psadhukhan at openjdk.org Thu Jul 20 10:12:10 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 20 Jul 2023 10:12:10 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v2] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Thu, 20 Jul 2023 09:17:37 GMT, Marius Hanl wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Add lock for read/write of scenePeer/stagePeer and added system test > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 428: > >> 426: private void sendMouseEventToFX(MouseEvent e) { >> 427: EmbeddedSceneInterface lScenePeer = getScenePeer(); >> 428: if (lScenePeer == null || !isFxEnabled()) { > > Probably minor, but maybe we should first check `!isFxEnabled()` and return fast before we actually call `getScenePeer()` and thus locking it ok..sure.. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1269243271 From angorya at openjdk.org Thu Jul 20 15:23:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jul 2023 15:23:53 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v4] In-Reply-To: <_4j6cuDq-nxQsh8AUjEbTFya-uTeYhF9QciOxUs2RKw=.23acc0df-ea9b-4c3e-8399-3eb308bbf67f@github.com> References: <_4j6cuDq-nxQsh8AUjEbTFya-uTeYhF9QciOxUs2RKw=.23acc0df-ea9b-4c3e-8399-3eb308bbf67f@github.com> Message-ID: On Thu, 20 Jul 2023 06:54:14 GMT, Karthik P K wrote: >> In `TreeTableRowSkin`, graphic was not updated along with tree item update. >> >> Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. >> >> Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments re-approving latest changes. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1172#pullrequestreview-1539538782 From kpk at openjdk.org Thu Jul 20 15:49:50 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 20 Jul 2023 15:49:50 GMT Subject: RFR: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 16:37:27 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add unit test > > github says it fails pre-submit check - probably some kind of spurious failure, local build and headful tests (minus web tests) are ok on macOS. Thanks @andy-goryachev-oracle , @johanvos and @Maran23 for the review and thanks @kleopatra for the guidance on the the test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1172#issuecomment-1644166153 From kpk at openjdk.org Thu Jul 20 15:49:51 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 20 Jul 2023 15:49:51 GMT Subject: Integrated: 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 05:25:34 GMT, Karthik P K wrote: > In `TreeTableRowSkin`, graphic was not updated along with tree item update. > > Made changes to update graphics of TreeTableView row in `updateTreeItem()` method. > > Added options in monkey tester to add graphics and subnodes to `TreeTableView` rows. This pull request has now been integrated. Changeset: 600cee70 Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/600cee70a2f6f907a53f7183315e6d7f79b291d6 Stats: 83 lines in 3 files changed: 81 ins; 0 del; 2 mod 8285700: [TreeTableView] graphic property of TreeItem is still visible after collapsing tree Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1172 From hmeda at openjdk.org Thu Jul 20 15:53:05 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 20 Jul 2023 15:53:05 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 Message-ID: Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). Verified the updated version build, sanity tests and stability. No issues have been observed. ------------- Commit messages: - Update WebKit to 616.1 Changes: https://git.openjdk.org/jfx/pull/1180/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310681 Stats: 381311 lines in 5888 files changed: 214321 ins; 124162 del; 42828 mod Patch: https://git.openjdk.org/jfx/pull/1180.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1180/head:pull/1180 PR: https://git.openjdk.org/jfx/pull/1180 From administrator at codedead.com Thu Jul 20 18:55:51 2023 From: administrator at codedead.com (Alessandro Mercier) Date: Thu, 20 Jul 2023 20:55:51 +0200 Subject: CSS heisenbug Message-ID: Hello, I possibly have some new information in regards to: https://bugs.openjdk.org/browse/JDK-8268657 It seems the bug is predominantly active on Linux Wayland systems and definitely not fixed and reproducible: https://github.com/mkpaz/atlantafx/issues/65#issuecomment-1644214727 The bug doesn't always happen but given enough tries, you will run into it at some point. The best way to effectively test for it is to run the Opal application in debug mode, and watch the logs as you switch themes. https://github.com/CodeDead/opal Hopefully this helps to locate the issue. Kind regards -- CodeDead Administrator https://codedead.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Fri Jul 21 06:53:51 2023 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 21 Jul 2023 09:53:51 +0300 Subject: CSS heisenbug In-Reply-To: References: Message-ID: I added the info to the ticket. On Fri, Jul 21, 2023 at 2:00?AM Alessandro Mercier < administrator at codedead.com> wrote: > Hello, > > I possibly have some new information in regards to: > https://bugs.openjdk.org/browse/JDK-8268657 > > It seems the bug is predominantly active on Linux Wayland systems and > definitely not fixed and reproducible: > https://github.com/mkpaz/atlantafx/issues/65#issuecomment-1644214727 > > The bug doesn't always happen but given enough tries, you will run into it > at some point. > The best way to effectively test for it is to run the Opal application in > debug mode, and watch the logs as you switch themes. > https://github.com/CodeDead/opal > > Hopefully this helps to locate the issue. > > Kind regards > -- > CodeDead Administrator > https://codedead.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Thorsten_Fischer at gmx.de Fri Jul 21 08:47:25 2023 From: Thorsten_Fischer at gmx.de (Thorsten Fischer) Date: Fri, 21 Jul 2023 10:47:25 +0200 Subject: JavaFX does not recover after graphic card driver crash Message-ID: <1MXXyP-1qPmU73Pg7-00YzdK@mail.gmx.net> Hi all, first off all I want to say ?thank you? to everyone in this community for all the effort you put in. I'm using JavaFX for years now and I'm really happy to work with it :) I have the following issue/question: One of my customers experiences an application crash when running their JavaFX application for a longer period on a notebook with integrated Intel graphics. First of all, I think JavaFX does not cause the issue, but is rather affected by it. We built a workaround in JavaFX, but I'd like to discuss what a good solution would look like, so that it can be integrated into the JFX code base. So, randomly between a couple of days to about 3 weeks the graphic card driver crashes. In the Windows (10) event log you can read: "Display driver igfx stopped responding and has successfully recovered.". In the console of the app it says: "D3DContext::testLostStateAndReset : Unknown D3D error 0x88760874". The app then just shows a black screen and keeps printing this error over and over to the console (rendering is triggered regularly in this app) and never recovers, even though the driver has been recovered and the whole system is running and is usable (again). The error code 0x88760874 translates to D3DERR_DEVICEHUNG (https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3derr), what corresponds to the error in the Windows event log. Now our initial workaround (within D3DContext.java#testLostStateAndReset) is basically the same as for D3DERR_DEVICEREMOVED, but with a loop to give the OS time to recover: public static final int D3DERR_DEVICEHUNG = 0X88760874; and at the end: if (hr == D3DERR_DEVICEHUNG) { setLost(); long retryMillis = TimeUnit.MINUTES.toMillis(5); long sleepingMillis = TimeUnit.SECONDS.toMillis(1); for (int i = 0; i < retryMillis; i += sleepingMillis) { int cooperativeLevel = D3DResourceFactory.nTestCooperativeLevel(pContext); System.err.println("Checking Cooperative Level: " + cooperativeLevel); if (cooperativeLevel == D3D_OK) { break; } else { try { Thread.sleep(sleepingMillis); } catch (InterruptedException e) { e.printStackTrace(); } } } // reinitialize after 5 mins anyway, even if result is not OK. // Reinitialize the D3DPipeline. This will dispose and recreate // the resource factory and context for each adapter. D3DPipeline.getInstance().reinitialize(); } Yesterday we experienced with this workaround, that the app did actually recover after 20 seconds. The System.err output generated inside the loop only showed again the D3DERR_DEVICEHUNG error code, and after 20 sec. console showed the initialization output. Very obviously Thread.sleep is not a good solution. To avoid it I thought about introducing another flag like isLost (-> "isHung") and if (hr == D3DERR_DEVICEHUNG) { setLost(); setHung(); } if (isHung && hr == D3D_OK) { isLost = false; // ? isHung = false; // Reinitialize the D3DPipeline. This will dispose and recreate // the resource factory and context for each adapter. D3DPipeline.getInstance().reinitialize(); } But before I continue with this direction (and because it takes weeks to reproduce this): Can anybody confidently tell me what a better/good solution may look like? Thank you, Thorsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Jul 21 14:26:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jul 2023 14:26:52 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. I have two questions. Because of the large number of files, I can't use the "diffs" view to add inline comments, so I will add them as general comments. --- a/modules/javafx.web/src/main/native/Source/WebCore/dom/Element.cpp +++ b/modules/javafx.web/src/main/native/Source/WebCore/dom/Element.cpp @@ -2295,8 +2295,11 @@ URL Element::absoluteLinkURL() const if (linkAttribute.isEmpty()) return URL(); - +#if PLATFORM(JAVA) + return document().completeURL(linkAttribute); +#else return document().completeURL(stripLeadingAndTrailingHTMLSpaces(linkAttribute)); +#endif } #if ENABLE(TOUCH_EVENTS) Why did we need to make this change? Will there be any problems as a result of our not stripping leading and trailing spaces? --- a/modules/javafx.web/src/main/native/Source/WebCore/dom/FullscreenManager.cpp +++ b/modules/javafx.web/src/main/native/Source/WebCore/dom/FullscreenManager.cpp @@ -389,6 +389,132 @@ void FullscreenManager::exitFullscreen(RefPtr&& promise) }); } +#if PLATFORM(JAVA) +void FullscreenManager::exitFullscreen() +{ ... +} + +void FullscreenManager::pushFullscreenElementStack(Element& element) +{ + m_fullscreenElementStack.append(&element); +} +#endif Is this new code or was it moved / refactored from elsewhere? If new code, what is its purpose, and who is calling it? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1645674592 PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1645675103 PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1645676091 From jbhaskar at openjdk.org Fri Jul 21 16:54:53 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 21 Jul 2023 16:54:53 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: <3Rl4wuNBWyHQD5tWi4O70K5-XBpzu5qmD3n4F3nurP8=.ba78e689-49c3-4bc2-93e3-f1027198bf7f@github.com> On Fri, 21 Jul 2023 14:24:17 GMT, Kevin Rushforth wrote: > Is this new code or was it moved / refactored from elsewhere? If new code, what is its purpose, and who is calling it? It was taken from last webkit update, as it was giving undefined reference error for current webkit update. > ``` > --- a/modules/javafx.web/src/main/native/Source/WebCore/dom/Element.cpp > +++ b/modules/javafx.web/src/main/native/Source/WebCore/dom/Element.cpp > @@ -2295,8 +2295,11 @@ URL Element::absoluteLinkURL() const > > if (linkAttribute.isEmpty()) > return URL(); > - > +#if PLATFORM(JAVA) > + return document().completeURL(linkAttribute); > +#else > return document().completeURL(stripLeadingAndTrailingHTMLSpaces(linkAttribute)); > +#endif > } > > #if ENABLE(TOUCH_EVENTS) > ``` > > Why did we need to make this change? Will there be any problems as a result of our not stripping leading and trailing spaces? The code is taken from the WebKit upstream main. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1645983062 PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1645986867 From kcr at openjdk.org Fri Jul 21 17:07:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jul 2023 17:07:53 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. Oh, I see that now. What led me to ask this question was that there is an alternative implementation in `#if PLATFORM(JAVA)`, which implies that we removed the call to `stripLeadingAndTrailingHTMLSpaces` and that it is still present in the upstream. Given that this code block now matches the upstream, the `if..else..endif` block should simply be replaced with: return document().completeURL(linkAttribute); removing the `#if PLATFORM(JAVA)` and the entire `#else` block (including the old call to `stripLeadingAndTrailingHTMLSpaces`). Otherwise it will be confusing and possibly lead to merge conflicts later. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1646001246 From mstrauss at openjdk.org Fri Jul 21 17:10:59 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 Jul 2023 17:10:59 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Thu, 20 Jul 2023 10:12:09 GMT, Prasanta Sadhukhan wrote: >> Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Check FXEnabled initially After looking at the class for a bit longer and seeing how its state is read and mutated on different threads, it might be a better approach to enforce serialized code execution in all cases. This might be done as follows: 1. Remove all `volatile` modifiers from the fields of the class. (Also, make `disableCount` an `int` field.) 2. Mark all non-private methods which are entry points into the class with the `synchronized` modifier. Private methods should not be marked with `synchronized`. 3. Wrap code in all other entry points (lambdas, anonymous implementations) in a `synchronized` block that synchronizes on the `JFXPanel` instance. If done correctly, no method of the class will ever run concurrently with another method of the class, and the memory effects of `synchronized` will ensure that we can always see the latest field values. What do you think about this approach? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1178#issuecomment-1646004694 From kcr at openjdk.org Fri Jul 21 17:40:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jul 2023 17:40:54 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: <6Ehzlfk1kfXpzlQURbC7AC5OSaizV1rh0xANubqGScQ=.04cbdf2f-582d-4fc4-8382-bbc1547b267c@github.com> On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. You can include this in the next "cherry-pick" update, if you prefer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1646037343 From hmeda at openjdk.org Fri Jul 21 17:47:47 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 21 Jul 2023 17:47:47 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. > You can include this in the next "cherry-pick" update, if you prefer. > You can include this in the next "cherry-pick" update, if you prefer. Noted. This change would be included as part of next Cherry-pick update ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1646044660 From angorya at openjdk.org Fri Jul 21 18:15:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jul 2023 18:15:49 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Fri, 21 Jul 2023 17:07:54 GMT, Michael Strau? wrote: > If done correctly, I think it makes sense, especially since there is at least one place where the whole method might need to be synchronized (JXFPanel:1090) The key word is **if done correctly**. One thing to look for is the possibility of introducing a deadlock and regression, so we may need to analyze the callers and perform more extensive testing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1178#issuecomment-1646073589 From angorya at openjdk.org Fri Jul 21 18:15:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jul 2023 18:15:54 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Thu, 20 Jul 2023 10:12:09 GMT, Prasanta Sadhukhan wrote: >> Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Check FXEnabled initially modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1047: > 1045: } > 1046: lStagePeer = embeddedStage; > 1047: if (lStagePeer == null) { there is something wrong with this code: why we need a locked assignment on line 1044 that immediately gets overwritten on line 1046? modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1092: > 1090: lScenePeer.setPixelScaleFactors((float) scaleFactorX, (float) scaleFactorY); > 1091: synchronized(LOCK) { > 1092: scenePeer = lScenePeer; I wonder if the whole method should be synchronized? the logic around scenePeer is asking to be atomic, isn't it? tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 98: > 96: }); > 97: SwingUtilities.invokeAndWait(JFXPanelNPETest::createUI); > 98: for (int i = 0; i < 300; i++) { is 300 sufficient? tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 101: > 99: SwingUtilities.invokeLater(contentPane::repaint); > 100: Platform.runLater(() -> contentPane.setScene(null)); > 101: Thread.sleep(100); I would recommend replacing a fixed number with a random value. (Typically, when a random is added to the test, it would make sense to print its seed to stdout, for the sake of reproducing a possible failure later; but in this case it might be unnecessary because we are dealing with multiple threads and that adds its own degree of randomness, completely eliminating reproducibility. Or, perhaps, we still need to print the seed to maximize the probability of reproducing the failed scenario.) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1270942415 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1270945833 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1270946674 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1270950218 From kcr at openjdk.org Fri Jul 21 18:19:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jul 2023 18:19:48 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Fri, 21 Jul 2023 18:12:55 GMT, Andy Goryachev wrote: > The key word is **if done correctly**. One thing to look for is the possibility of introducing a deadlock and regression, so we may need to analyze the callers and perform more extensive testing. That is exactly my concern. It would need a lot more very careful analysis before making this synchronous. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1178#issuecomment-1646078697 From mstrauss at openjdk.org Fri Jul 21 18:28:47 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 Jul 2023 18:28:47 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Fri, 21 Jul 2023 18:17:20 GMT, Kevin Rushforth wrote: > That is exactly my concern. It would need a lot more very careful analysis before making this synchronous. It seems to me that this whole class is asking for more careful analysis, considering that there seem to be several concurrency bugs in there. I don't quite like the idea of a system test "proving" that there's no race condition. That should be done through rigorous analysis instead. The first (and incorrect) proposed fix shows that the system test would have failed in demonstrating that the defects are no longer there. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1178#issuecomment-1646087041 From kcr at openjdk.org Fri Jul 21 20:33:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jul 2023 20:33:54 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. Looks good. Testing is green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1180#pullrequestreview-1541816193 From jhendrikx at openjdk.org Fri Jul 21 21:21:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 21 Jul 2023 21:21:49 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: <6TsdKkoNyvU_kNK8D2dN9_IL5S-32MZUuaEClZNYwIs=.7b81a747-0bee-4066-af87-94cb42021e27@github.com> On Thu, 20 Jul 2023 10:12:09 GMT, Prasanta Sadhukhan wrote: >> Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Check FXEnabled initially tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 98: > 96: }); > 97: SwingUtilities.invokeAndWait(JFXPanelNPETest::createUI); > 98: for (int i = 0; i < 300; i++) { I think this is way too long for a unit test. 300 iterations, 200 ms each = 60 seconds ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271118367 From angorya at openjdk.org Fri Jul 21 21:32:43 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jul 2023 21:32:43 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: <6TsdKkoNyvU_kNK8D2dN9_IL5S-32MZUuaEClZNYwIs=.7b81a747-0bee-4066-af87-94cb42021e27@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> <6TsdKkoNyvU_kNK8D2dN9_IL5S-32MZUuaEClZNYwIs=.7b81a747-0bee-4066-af87-94cb42021e27@github.com> Message-ID: On Fri, 21 Jul 2023 21:19:09 GMT, John Hendrikx wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Check FXEnabled initially > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 98: > >> 96: }); >> 97: SwingUtilities.invokeAndWait(JFXPanelNPETest::createUI); >> 98: for (int i = 0; i < 300; i++) { > > I think this is way too long for a unit test. 300 iterations, 200 ms each = 60 seconds good point! at the same time, we probably want to cover both extremes (short and long delays). what would be a reasonable upper limit for a test? 10 seconds? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271123737 From jhendrikx at openjdk.org Fri Jul 21 22:03:47 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 21 Jul 2023 22:03:47 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Thu, 20 Jul 2023 10:12:09 GMT, Prasanta Sadhukhan wrote: >> Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Check FXEnabled initially It's not entirely clear to me which thread is calling which methods in this class, and it would help to clearly mark which part of the class can be called from the FX thread and which parts from the AWT thread. I also question how some of the other fields are used. Many are marked `volatile` which is insufficient if you don't want to observe partial changes of x/y coordinates for example. I agree with @mstr2 that a more careful analysis couldn't hurt. There seem to be only 2 threads involved, the AWT and FX Thread. The fields they are sharing should be grouped and marked with a comment that they're shared. Any access to these fields should then be only while holding a lock. modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 152: > 150: > 151: private static final Object LOCK = new Object(); > 152: I very much doubt it is the intention to synchronize on all JFXPanel instances, so this should not be static. modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 416: > 414: } > 415: return lScenePeer; > 416: } Suggestion: private EmbeddedSceneInterface getScenePeer() { synchronized(LOCK) { return scenePeer; } } modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 424: > 422: } > 423: return lStagePeer; > 424: } Suggestion: private EmbeddedStageInterface getStagePeer() { synchronized(LOCK) { return stagePeer; } } modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1041: > 1039: > 1040: @Override > 1041: public void setEmbeddedStage(EmbeddedStageInterface embeddedStage) { These changes don't inspire confidence in this solution. `stagePeer` is now no longer updated when `embeddedStage` is `null`. IMHO they should be: @Override public void setEmbeddedStage(EmbeddedStageInterface embeddedStage) { synchronized(LOCK) { stagePeer = embeddedStage; if (stagePeer == null) { return; } } if (pWidth > 0 && pHeight > 0) { embeddedStage.setSize(pWidth, pHeight); } invokeOnClientEDT(() -> { if (JFXPanel.this.isFocusOwner()) { embeddedStage.setFocused(true, AbstractEvents.FOCUSEVENT_ACTIVATED); } }); sendMoveEventToFX(); } modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1069: > 1067: > 1068: @Override > 1069: public void setEmbeddedScene(EmbeddedSceneInterface embeddedScene) { Same comment as with `setEmbeddedStage`; surrounding all accesses to `scenePeer` and `stagePeer` like this is not the way to do it, and looks incorrect. I think this is more in the right direction: public void setEmbeddedScene(EmbeddedSceneInterface embeddedScene) { synchronized(LOCK) { if (scenePeer == embeddedScene) { return; } scenePeer = embeddedScene; } if (embeddedScene == null) { invokeOnClientEDT(() -> { if (dnd != null) { dnd.removeNotify(); dnd = null; } }); return; } if (pWidth > 0 && pHeight > 0) { embeddedScene.setSize(pWidth, pHeight); } embeddedScene.setPixelScaleFactors((float) scaleFactorX, (float) scaleFactorY); invokeOnClientEDT(() -> { dnd = new SwingDnD(JFXPanel.this, scenePeer); dnd.addNotify(); embeddedScene.setDragStartListener(dnd.getDragStartListener()); }); } ------------- PR Review: https://git.openjdk.org/jfx/pull/1178#pullrequestreview-1541862971 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271120246 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271119728 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271120451 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271129358 PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271131346 From jhendrikx at openjdk.org Fri Jul 21 22:03:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 21 Jul 2023 22:03:49 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Fri, 21 Jul 2023 18:01:15 GMT, Andy Goryachev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Check FXEnabled initially > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1092: > >> 1090: lScenePeer.setPixelScaleFactors((float) scaleFactorX, (float) scaleFactorY); >> 1091: synchronized(LOCK) { >> 1092: scenePeer = lScenePeer; > > I wonder if the whole method should be synchronized? > the logic around scenePeer is asking to be atomic, isn't it? The change as-is doesn't work correctly; if `embeddedScene` is `null`, `scenePeer` is now unchanged. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271129888 From jhendrikx at openjdk.org Fri Jul 21 22:21:03 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 21 Jul 2023 22:21:03 GMT Subject: RFR: JDK-8312528: Move Subscription interface from javafx.beans to javafx.util Message-ID: The Subscription interface is independent from FX beans and has uses unrelated to beans, it should therefore be placed in javafx.util. This should be fixed before [JDK-8311123](https://bugs.openjdk.org/browse/JDK-8311123) is released. ------------- Commit messages: - Move Subscription to javafx.util Changes: https://git.openjdk.org/jfx/pull/1182/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1182&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312528 Stats: 20 lines in 12 files changed: 9 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1182.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1182/head:pull/1182 PR: https://git.openjdk.org/jfx/pull/1182 From nlisker at openjdk.org Fri Jul 21 22:28:42 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 21 Jul 2023 22:28:42 GMT Subject: RFR: JDK-8312528: Move Subscription interface from javafx.beans to javafx.util In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 22:15:03 GMT, John Hendrikx wrote: > The Subscription interface is independent from FX beans and has uses unrelated to beans, it should therefore be placed in javafx.util. > > This should be fixed before [JDK-8311123](https://bugs.openjdk.org/browse/JDK-8311123) is released. Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1182#pullrequestreview-1541903779 From kcr at openjdk.org Fri Jul 21 22:42:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jul 2023 22:42:47 GMT Subject: RFR: JDK-8312528: Move Subscription interface from javafx.beans to javafx.util In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 22:15:03 GMT, John Hendrikx wrote: > The Subscription interface is independent from FX beans and has uses unrelated to beans, it should therefore be placed in javafx.util. > > This should be fixed before [JDK-8311123](https://bugs.openjdk.org/browse/JDK-8311123) is released. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1182#pullrequestreview-1541911350 From kcr at openjdk.org Fri Jul 21 23:24:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jul 2023 23:24:49 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. @johanvos or @tiainen Can one you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1646331734 From markus.mack at gmail.com Sat Jul 22 16:43:12 2023 From: markus.mack at gmail.com (Markus Mack) Date: Sat, 22 Jul 2023 18:43:12 +0200 Subject: CSS Transitions In-Reply-To: References: Message-ID: I'd love to see this feature in JavaFX. This would allow for much cleaner (and better reusable) implementations of modern-looking UI which I'd like to have for current and future JavaFX projects. In the current state of JavaFX, you'd usually need to roll your own custom control skins which is not very maintainable and typically not easy to get right. An API for programmatically defining these transitions would be good for completeness at some point, however it is probably better to do this as a separate next step to keep the API surface minimal for now. The current proposal adds a lot of value for little cost. Am 17.07.2023 um 21:23 schrieb Michael Strau?: > Here's an updated summary of the proposed feature: > https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a > > And here's the full implementation: > https://github.com/openjdk/jfx/pull/870 > > I'm interested in hearing from you whether you think this is a useful > feature and whether the proposed API is a good match for JavaFX. From duke at openjdk.org Sun Jul 23 10:30:49 2023 From: duke at openjdk.org (yosbits) Date: Sun, 23 Jul 2023 10:30:49 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: <6IeQF6xr3xTcrVCGKqbwi9xXC30fV0_yM8bQGZ2tTmk=.a141a821-0057-4a79-a1b4-b984a883a558@github.com> On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. I found a change to turn off DFGJIT by default, is this a fix for some problem? modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1646804000 From jvos at openjdk.org Sun Jul 23 15:58:49 2023 From: jvos at openjdk.org (Johan Vos) Date: Sun, 23 Jul 2023 15:58:49 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: <-NV0m4NIdHA-YwzyvSJvj_LjnecQvKYYrMY6slk-seI=.da407162-cb3f-4f5a-991f-26ae002c8d51@github.com> On Fri, 21 Jul 2023 17:04:44 GMT, Kevin Rushforth wrote: > Oh, I see that now. What led me to ask this question was that there is an alternative implementation in `#if PLATFORM(JAVA)`, which implies that we removed the call to `stripLeadingAndTrailingHTMLSpaces` and that it is still present in the upstream. > > Given that this code block now matches the upstream, the `if..else..endif` block should simply be replaced with: > > ``` > return document().completeURL(linkAttribute); > ``` > > removing the `#if PLATFORM(JAVA)` and the entire `#else` block (including the old call to `stripLeadingAndTrailingHTMLSpaces`). Otherwise it will be confusing and possibly lead to merge conflicts later. I agree with this. Is there a reason this can't be done in the current PR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1646875540 From kizune at openjdk.org Sun Jul 23 20:41:58 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Sun, 23 Jul 2023 20:41:58 GMT Subject: RFR: 8309558: Create implementation of NSAccessibilityCheckBox protocol Message-ID: also 8309629: Create implementation of NSAccessibilityRadioButton protocol Create implementation of NSAccessibilityCheckBox and NSAccessibilityRadioButton protocols Add workaround for the wrong focus owner announcement with radio buttons Add workaround for wrong magnifier text on buttons ------------- Commit messages: - 8309558: Create implementation of NSAccessibilityCheckBox protocol Changes: https://git.openjdk.org/jfx/pull/1184/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1184&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309558 Stats: 184 lines in 6 files changed: 183 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1184.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1184/head:pull/1184 PR: https://git.openjdk.org/jfx/pull/1184 From michaelstrau2 at gmail.com Sun Jul 23 23:46:39 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 24 Jul 2023 01:46:39 +0200 Subject: Platform preferences API In-Reply-To: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: I'd like to wrap up the discussion around the new `Appearance` enumeration proposed for the Platform Preferences API: public enum javafx.application.Appearance { LIGHT, DARK } When viewed with the goal of eventually supporting style themes, this might seem a bit limiting at first. Obvious questions are: 1. Can you have more modes than light or dark? What about blue or purple mode? 2. Can you have variations of these modes? For example: high-contrast light and high-contrast dark. 3. Should "appearance" include other aspects, for example rounded vs. non-rounded window corners, or title bar tint. I think the answer to all of these questions is: no. `Appearance` represents the binary light/dark mode distinction that most operating systems have settled on. If, at some point in the future, operating systems support additional modes, we can always consider adding more enumeration constants. This doesn't mean that JavaFX applications and style themes are limited to only supporting one light and one dark theme. A theme might have different variations for each appearance, or it might not use the platform's appearance information at all and use other sources of information. The question we need to solve is whether we should anticipate all of these future requirements and bake them into the Platform Preferences API (answer: no). As proposed, the `Appearance` information provided by the Platform Preferences API fits nicely with the upcoming Stage Appearance feature. This allows users to simply bind the two properties to sync up stage appearance with platform appearance: stage.appearanceProperty().bind( Application.getPreferences().appearanceProperty()); Basically, we're taking the light/dark information that we've received from the OS and forwarding this information to the windowing system to indicate whether we'd like to have light or dark window decorations (which are the only two options to choose from). I think this information is useful for JavaFX applications on its own, and doesn't need to wait for the Stage Appearance feature. From jbhaskar at openjdk.org Mon Jul 24 02:38:50 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 24 Jul 2023 02:38:50 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: <6IeQF6xr3xTcrVCGKqbwi9xXC30fV0_yM8bQGZ2tTmk=.a141a821-0057-4a79-a1b4-b984a883a558@github.com> References: <6IeQF6xr3xTcrVCGKqbwi9xXC30fV0_yM8bQGZ2tTmk=.a141a821-0057-4a79-a1b4-b984a883a558@github.com> Message-ID: On Sun, 23 Jul 2023 10:28:18 GMT, yosbits wrote: > I found a change to turn off DFGJIT by default, is this a fix for some problem? > > modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java The Change is required, as it is making issues with complex js code written for a website. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1647110532 From jbhaskar at openjdk.org Mon Jul 24 02:43:49 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 24 Jul 2023 02:43:49 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: <3Rl4wuNBWyHQD5tWi4O70K5-XBpzu5qmD3n4F3nurP8=.ba78e689-49c3-4bc2-93e3-f1027198bf7f@github.com> References: <3Rl4wuNBWyHQD5tWi4O70K5-XBpzu5qmD3n4F3nurP8=.ba78e689-49c3-4bc2-93e3-f1027198bf7f@github.com> Message-ID: On Fri, 21 Jul 2023 16:52:27 GMT, Jay Bhaskar wrote: > absoluteLinkURL Agree ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1647113499 From jbhaskar at openjdk.org Mon Jul 24 02:52:47 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 24 Jul 2023 02:52:47 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: <-NV0m4NIdHA-YwzyvSJvj_LjnecQvKYYrMY6slk-seI=.da407162-cb3f-4f5a-991f-26ae002c8d51@github.com> References: <-NV0m4NIdHA-YwzyvSJvj_LjnecQvKYYrMY6slk-seI=.da407162-cb3f-4f5a-991f-26ae002c8d51@github.com> Message-ID: On Sun, 23 Jul 2023 15:55:39 GMT, Johan Vos wrote: > > Oh, I see that now. What led me to ask this question was that there is an alternative implementation in `#if PLATFORM(JAVA)`, which implies that we removed the call to `stripLeadingAndTrailingHTMLSpaces` and that it is still present in the upstream. > > Given that this code block now matches the upstream, the `if..else..endif` block should simply be replaced with: > > ``` > > return document().completeURL(linkAttribute); > > ``` > > > > > > > > > > > > > > > > > > > > > > > > removing the `#if PLATFORM(JAVA)` and the entire `#else` block (including the old call to `stripLeadingAndTrailingHTMLSpaces`). Otherwise it will be confusing and possibly lead to merge conflicts later. > > I agree with this. Is there a reason this can't be done in the current PR? I agree, we will apply the suggestion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1647119576 From psadhukhan at openjdk.org Mon Jul 24 07:02:03 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 24 Jul 2023 07:02:03 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v4] In-Reply-To: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: > Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Modifications as per review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1178/files - new: https://git.openjdk.org/jfx/pull/1178/files/c5c300db..f078f0a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=02-03 Stats: 44 lines in 1 file changed: 1 ins; 25 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1178.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1178/head:pull/1178 PR: https://git.openjdk.org/jfx/pull/1178 From psadhukhan at openjdk.org Mon Jul 24 07:02:03 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 24 Jul 2023 07:02:03 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Fri, 21 Jul 2023 18:17:20 GMT, Kevin Rushforth wrote: > > The key word is **if done correctly**. One thing to look for is the possibility of introducing a deadlock and regression, so we may need to analyze the callers and perform more extensive testing. > > That is exactly my concern. It would need a lot more very careful analysis before making this synchronous. I guess if we have to make all public methods in JFXPanel synchronous, then the same might be called for SwingNode too, .. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1178#issuecomment-1647320399 From psadhukhan at openjdk.org Mon Jul 24 07:02:03 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 24 Jul 2023 07:02:03 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Fri, 21 Jul 2023 21:45:56 GMT, John Hendrikx wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Check FXEnabled initially > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1069: > >> 1067: >> 1068: @Override >> 1069: public void setEmbeddedScene(EmbeddedSceneInterface embeddedScene) { > > Same comment as with `setEmbeddedStage`; surrounding all accesses to `scenePeer` and `stagePeer` like this is not the way to do it, and looks incorrect. I think this is more in the right direction: > > public void setEmbeddedScene(EmbeddedSceneInterface embeddedScene) { > synchronized(LOCK) { > if (scenePeer == embeddedScene) { > return; > } > scenePeer = embeddedScene; > } > > if (embeddedScene == null) { > invokeOnClientEDT(() -> { > if (dnd != null) { > dnd.removeNotify(); > dnd = null; > } > }); > return; > } > if (pWidth > 0 && pHeight > 0) { > embeddedScene.setSize(pWidth, pHeight); > } > embeddedScene.setPixelScaleFactors((float) scaleFactorX, (float) scaleFactorY); > > invokeOnClientEDT(() -> { > dnd = new SwingDnD(JFXPanel.this, scenePeer); > dnd.addNotify(); > embeddedScene.setDragStartListener(dnd.getDragStartListener()); > }); > } ok ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271826532 From psadhukhan at openjdk.org Mon Jul 24 07:02:03 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 24 Jul 2023 07:02:03 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> <6TsdKkoNyvU_kNK8D2dN9_IL5S-32MZUuaEClZNYwIs=.7b81a747-0bee-4066-af87-94cb42021e27@github.com> Message-ID: On Fri, 21 Jul 2023 21:30:08 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 98: >> >>> 96: }); >>> 97: SwingUtilities.invokeAndWait(JFXPanelNPETest::createUI); >>> 98: for (int i = 0; i < 300; i++) { >> >> I think this is way too long for a unit test. 300 iterations, 200 ms each = 60 seconds > > good point! > > at the same time, we probably want to cover both extremes (short and long delays). > what would be a reasonable upper limit for a test? 10 seconds? It used to be 3000 for JBS reproducer which I reduced to 300 for consistent issue reproduction, below which the issue might not be seen so consistently even without the fix and I guess the test is supposed to fail without the fix and pass with it.. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1271828106 From john.hendrikx at gmail.com Mon Jul 24 07:43:31 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 24 Jul 2023 09:43:31 +0200 Subject: Platform preferences API In-Reply-To: References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: I think Appearance is exactly correct as it is.? It encodes a fundamental binary aspect of visual presentations that all themes, styles, displays, posters, prints, etc. must choose between: do I present text on a light background (and so the text is dark), or do I present text on a dark background (and so text is light)? There are no other choices without text becoming unreadable, and there never will be. So IMHO, the enum is correct, and will never need to extended. Encoding more than one dimension into an enum should be avoided in favor of another enum at all times, so encoding something like contrast into it would not be a sensible move. --John On 24/07/2023 01:46, Michael Strau? wrote: > I'd like to wrap up the discussion around the new `Appearance` > enumeration proposed for the Platform Preferences API: > > public enum javafx.application.Appearance { > LIGHT, DARK > } > > When viewed with the goal of eventually supporting style themes, this > might seem a bit limiting at first. Obvious questions are: > 1. Can you have more modes than light or dark? What about blue or purple mode? > 2. Can you have variations of these modes? For example: high-contrast > light and high-contrast dark. > 3. Should "appearance" include other aspects, for example rounded vs. > non-rounded window corners, or title bar tint. > > I think the answer to all of these questions is: no. `Appearance` > represents the binary light/dark mode distinction that most operating > systems have settled on. If, at some point in the future, operating > systems support additional modes, we can always consider adding more > enumeration constants. > > This doesn't mean that JavaFX applications and style themes are > limited to only supporting one light and one dark theme. A theme might > have different variations for each appearance, or it might not use the > platform's appearance information at all and use other sources of > information. The question we need to solve is whether we should > anticipate all of these future requirements and bake them into the > Platform Preferences API (answer: no). > > As proposed, the `Appearance` information provided by the Platform > Preferences API fits nicely with the upcoming Stage Appearance > feature. This allows users to simply bind the two properties to sync > up stage appearance with platform appearance: > > stage.appearanceProperty().bind( > Application.getPreferences().appearanceProperty()); > > Basically, we're taking the light/dark information that we've received > from the OS and forwarding this information to the windowing system to > indicate whether we'd like to have light or dark window decorations > (which are the only two options to choose from). > > I think this information is useful for JavaFX applications on its own, > and doesn't need to wait for the Stage Appearance feature. From mariushanl at web.de Mon Jul 24 07:52:38 2023 From: mariushanl at web.de (Marius Hanl) Date: Mon, 24 Jul 2023 09:52:38 +0200 Subject: =?UTF-8?Q?Aw=3A=C2=A0Re=3A_CSS_Transitions?= Message-ID: An HTML attachment was scrubbed... URL: From hmeda at openjdk.org Mon Jul 24 12:43:57 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 24 Jul 2023 12:43:57 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 [v2] In-Reply-To: References: Message-ID: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Remove check for PLATFORM(JAVA) as the change corresponds to webkit upstream ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1180/files - new: https://git.openjdk.org/jfx/pull/1180/files/5039b04b..3362baa6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1180&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1180&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1180.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1180/head:pull/1180 PR: https://git.openjdk.org/jfx/pull/1180 From hmeda at openjdk.org Mon Jul 24 12:43:59 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 24 Jul 2023 12:43:59 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: <-NV0m4NIdHA-YwzyvSJvj_LjnecQvKYYrMY6slk-seI=.da407162-cb3f-4f5a-991f-26ae002c8d51@github.com> Message-ID: On Mon, 24 Jul 2023 02:50:30 GMT, Jay Bhaskar wrote: > > Oh, I see that now. What led me to ask this question was that there is an alternative implementation in `#if PLATFORM(JAVA)`, which implies that we removed the call to `stripLeadingAndTrailingHTMLSpaces` and that it is still present in the upstream. > > Given that this code block now matches the upstream, the `if..else..endif` block should simply be replaced with: > > ``` > > return document().completeURL(linkAttribute); > > ``` > > > > > > > > > > > > > > > > > > > > > > > > removing the `#if PLATFORM(JAVA)` and the entire `#else` block (including the old call to `stripLeadingAndTrailingHTMLSpaces`). Otherwise it will be confusing and possibly lead to merge conflicts later. > > I agree with this. Is there a reason this can't be done in the current PR? Pushed the change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1180#issuecomment-1647811198 From kcr at openjdk.org Mon Jul 24 12:44:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 24 Jul 2023 12:44:21 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 [v2] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 12:43:57 GMT, Hima Bindu Meda wrote: >> Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). >> Verified the updated version build, sanity tests and stability. No issues have been observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove check for PLATFORM(JAVA) as the change corresponds to webkit upstream Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1180#pullrequestreview-1543405625 From duke at openjdk.org Mon Jul 24 12:48:58 2023 From: duke at openjdk.org (duke) Date: Mon, 24 Jul 2023 12:48:58 GMT Subject: Withdrawn: 8269907 memory leak - Dirty Nodes / Parent removed In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 11:29:38 GMT, Florian Kirmaier wrote: > After thinking about this issue for some time, I've now got a solution. > I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. > This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/584 From angorya at openjdk.org Mon Jul 24 14:51:51 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jul 2023 14:51:51 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Mon, 24 Jul 2023 06:55:19 GMT, Prasanta Sadhukhan wrote: >> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 1069: >> >>> 1067: >>> 1068: @Override >>> 1069: public void setEmbeddedScene(EmbeddedSceneInterface embeddedScene) { >> >> Same comment as with `setEmbeddedStage`; surrounding all accesses to `scenePeer` and `stagePeer` like this is not the way to do it, and looks incorrect. I think this is more in the right direction: >> >> public void setEmbeddedScene(EmbeddedSceneInterface embeddedScene) { >> synchronized(LOCK) { >> if (scenePeer == embeddedScene) { >> return; >> } >> scenePeer = embeddedScene; >> } >> >> if (embeddedScene == null) { >> invokeOnClientEDT(() -> { >> if (dnd != null) { >> dnd.removeNotify(); >> dnd = null; >> } >> }); >> return; >> } >> if (pWidth > 0 && pHeight > 0) { >> embeddedScene.setSize(pWidth, pHeight); >> } >> embeddedScene.setPixelScaleFactors((float) scaleFactorX, (float) scaleFactorY); >> >> invokeOnClientEDT(() -> { >> dnd = new SwingDnD(JFXPanel.this, scenePeer); >> dnd.addNotify(); >> embeddedScene.setDragStartListener(dnd.getDragStartListener()); >> }); >> } > > ok this code looks much better - eliminates TOC/TOU concern https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1272372993 From mstrauss at openjdk.org Mon Jul 24 16:10:51 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 16:10:51 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: On Mon, 24 Jul 2023 14:48:57 GMT, Andy Goryachev wrote: >> ok > > this code looks much better - eliminates TOC/TOU concern > https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use This code is still accessing shared state (`dnd`, `pWidth`, `pHeight`, `scaleFactorX`, `scaleFactorY`). Without further analysis of when and where these values are written, it is unclear whether this is the right move. In general, allowing interleaved code execution on multiple threads is very hard to get right. Better to not do it, if at all possible. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1272472480 From angorya at openjdk.org Mon Jul 24 17:17:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jul 2023 17:17:49 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: <-s4dS2zIfiLXfcvOizJr3MchYehlBAb5QQLrdkP0HTk=.2c115342-294f-4b67-b50b-dd657f231de5@github.com> On Mon, 24 Jul 2023 16:08:07 GMT, Michael Strau? wrote: >> this code looks much better - eliminates TOC/TOU concern >> https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use > > This code is still accessing shared state (`dnd`, `pWidth`, `pHeight`, `scaleFactorX`, `scaleFactorY`). Without further analysis of when and where these values are written, it is unclear whether this is the right move. In general, allowing interleaved code execution on multiple threads is very hard to get right. Better to not do it, if at all possible. No doubt. `dnd`, even though it's commented as "// Accessed on EDT only" (line 152) seems to be accessed from FX thread via setFxEnabled line 866. I tend to agree with @mstr2 that this component deserves a re-think and perhaps a re-design. I do recall seeing a number of issues with swing/fx interop in jdk8. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1272538884 From mstrauss at openjdk.org Mon Jul 24 17:45:31 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:31 GMT Subject: RFR: 8301302: Platform preferences API [v4] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <1wpQh3sviOLynWRd_lEAZ27iManns5ojKnDagHWua4A=.d2660433-6ad2-48fa-9999-ec63f08e514a@github.com> > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Added test - doc changes - Ensure that ColorProperty changes are atomic when observed - removed unused code - Move Appearance enum to javafx.application - doc changes - Removed platform-independent preference keys - documentation - Platform preferences implementation ------------- Changes: https://git.openjdk.org/jfx/pull/1014/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=03 Stats: 3259 lines in 35 files changed: 3159 ins; 58 del; 42 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From jhendrikx at openjdk.org Mon Jul 24 17:45:34 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 24 Jul 2023 17:45:34 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <6jZNqmMWy3nTCyl5_6Wn2_XfDlxNYhod70WGl1FnSpc=.1678efed-d742-4c4c-be7b-db1617669086@github.com> On Thu, 2 Feb 2023 19:54:33 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. I think this would still be good to add to JavaFX as it will allow better integration with the platforms it runs on, without requiring the user to query native libraries to good integration. > > 2. ObservableMap. Similarly to Node.getProperties(), I wonder if there might be a better way to observe the changes. May be a different metaphor (subscription?), like adding a value change listener to a specific key. We do need a set of keys (perhaps that can be an ObservableSet). Having said that, ObservableMap is good enough solution, and forgive me for stating the obvious, it should not initialize anything if the platform properties have not been requested by the application code. > > I've pulled on that string a little more: > > #### 1. `Optional` API + listeners > This would remove the `ObservableMap` implementation, and add the following methods instead: > > ```java > interface Preferences { > ... > void addListener(String key, InvalidationListener listener); > void removeListener(String key, InvalidationListener listener); > > void addListener(String key, ChangeListener listener); > void removeListener(String key, ChangeListener listener); > > Optional getInteger(String key); > Optional getDouble(String key); > ... > } > ``` > > I don't quite like this idea though, since it would allow developers to either add listeners to non-existent keys, or require developers to probe whether a key exists before adding a listener for it (maybe by also adding a `boolean keyExists(String key)` method. This kind of functionality already exists, see for example `Bindings#stringValueAt`; you can bind a key of a map (even if it doesn't exist, in which case it will be `null`). It's provided as separate from `ObservableMap`, although it could have been integrated as well. > It also doesn't allow developers to enumerate the keys that are available on a given platform. If we added a set of keys (maybe as an `ObservableSet`), the result is basically a map. We're better off implementing `ObservableMap` in this case. > > This API combines all aspects into a single method call. We also can't enumerate the platform preferences. > > I still think that implementing `ObservableMap` is preferable to all of these alternatives. I was on the fence about this before as well, but I think `ObservableMap` may be the way to go now. The thing that mainly irked me is all the mutation methods that will also be available, but I suppose that's inherent in the design of collections in Java. > > With the preferences Map, this could work similar perhaps; set a key to whatever you want with put, and restore it to its original value by setting it to null. > > This works when the changes originate from the OS, but it doesn't work when an application overrides preference mappings manually. `ObservableMap` doesn't support bulk changes, so repeatedly calling `override(...)` would end up firing multiple change notifications, and subscribers would have no way of knowing when the bulk change transaction has ended. > > That's where the concept of _uncommitted modifications_ comes into play: calling `override(...)` or any of the property setters like `setAppearance(...)` doesn't apply the changes immediately, it delays those changes until `commit()` is called or until an OS event causes the preference to be recomputed. When that happens, a single invalidation notification is fired, the same as it would have if the change originated from the OS. I'm not convinced that a delayed change + commit system is the correct way to do this. Properties should behave the same everywhere in JavaFX and this seems to change how they work quite a bit. Instead, I propose to look at how layout in JavaFX is handling this problem. Layout looks at thousands of properties, yet changing one or many of the involved properties does not involve an expensive layout recalculation per change. Instead, changes are tracked by marking certain aspects of the involved controls dirty. On the next pulse, the layout code notices that something that would influence layout and CSS decisions has changed, and performs the required changes. The properties involved are all normal properties, that can be changed quickly, reflect their current value immediately and that can be overridden by the user or reset back to defaults. There is no override or commit system needed. Have you considered allowing users to change preference values directly, but not acting on those changes until the next pulse occurs? Users can still listen for keys/properties, just like they can for layout properties, but the major changes that involve recomputing CSS is only done once per pulse. This would make it possible to change several preference values without penalty (which happens on the FX thread anyway, so pulses are on hold during that time), and they're automatically "committed" once the user is done on the FX thread and the next pulse fires. I think it would be a very good fit. > However, I'm thinking that the Preferences API might not be the right place to solve this problem. Maybe that should be built into the style theme API instead, for example with another interface: > > ```java > public interface PlatformStyleTheme extends StyleTheme { > void onPreferencesChanged(Iterable> changes); > } > ``` > > The Preferences _implementation_ would then aggregate the changes that have accumulated since the last pulse, and inform the current style theme by invoking its `onPreferencesChanged` method. This means that a style theme doesn't need to register listeners for different kinds of preferences, and the Preferences API can behave just as any normal property would behave. This would be an improvement, and since it is synced to a pulse it would do the calculation only once and only when necessary. I don't think you need to bother with aggregating the changes though, the theme can query whatever it needs easily enough and determine if a re-style is needed. I'm still not sold on the `override` method. Would it not be better to make the map writable (with `put`) and if there is need to reset properties back to default offer a `reset` method? I'm saying this because adding an override method makes the map effectively writable (although delayed, if that's not going to be changed), and in that case I'd prefer using existing map methods for this purpose. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1498951848 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1501205183 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1519428999 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1521494003 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1521504250 From mstrauss at openjdk.org Mon Jul 24 17:45:35 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:35 GMT Subject: RFR: 8301302: Platform preferences API [v2] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <-HhFDbEBCw-ihcDHTY-Gc5TBP_joo9nHDFdQcEFhHlI=.c5fe4af2-6a06-4896-bbbf-2d8236acfd05@github.com> On Tue, 31 Jan 2023 20:18:05 GMT, Michael Strau? wrote: > 2. ObservableMap. Similarly to Node.getProperties(), I wonder if there might be a better way to observe the changes. May be a different metaphor (subscription?), like adding a value change listener to a specific key. We do need a set of keys (perhaps that can be an ObservableSet). Having said that, ObservableMap is good enough solution, and forgive me for stating the obvious, it should not initialize anything if the platform properties have not been requested by the application code. I've pulled on that string a little more: #### 1. `Optional` API + listeners This would remove the `ObservableMap` implementation, and add the following methods instead: interface Preferences { ... void addListener(String key, InvalidationListener listener); void removeListener(String key, InvalidationListener listener); void addListener(String key, ChangeListener listener); void removeListener(String key, ChangeListener listener); Optional getInteger(String key); Optional getDouble(String key); ... } I don't quite like this idea though, since it would allow developers to either add listeners to non-existent keys, or require developers to probe whether a key exists before adding a listener for it (maybe by also adding a `boolean keyExists(String key)` method. It also doesn't allow developers to enumerate the keys that are available on a given platform. If we added a set of keys (maybe as an `ObservableSet`), the result is basically a map. We're better off implementing `ObservableMap` in this case. #### 2. `Property` API interface Preferences { ... ReadOnlyIntegerProperty getIntegerProperty(String key); ReadOnlyDoubleProperty getDoubleProperty(String key); ... } With this idea, instead of having manual listener management and an API to query value mappings, we'd expose read-only properties for keys. We might also need a method like `boolean keyExists(String key)`, but we can't enumerate all platform preferences with this approach. #### 3. `Optional` + `Property` API interface Preferences { ... Optional getIntegerProperty(String key); Optional getDoubleProperty(String key); ... } This API combines all aspects into a single method call. We also can't enumerate the platform preferences. I still think that implementing `ObservableMap` is preferable to all of these alternatives. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1500535347 From mstrauss at openjdk.org Mon Jul 24 17:45:36 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:36 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 2 Feb 2023 19:54:33 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. In general, platform preferences correspond to OS-level settings and are updated dynamically. Third-party themes might integrate platform preferences into their look and feel, which is often what users expect to see. But consider a scenario where an application uses a third-party theme that adapts to the OS appearance, but the application author only wants to support a dark appearance (independent from the OS appearance). For this scenario, platform preferences should be overridable from application code. I've considered several potential approaches: #### 1. Provide two sets of preferences: class Platform { Preferences getUserPreferences(); Preferences getPlatformPreferences(); } In this idea, `getUserPreferences` returns a mutable version of the immutable `getPlatformPreferences`. However, this requires theme authors to always use user preferences instead of platform preferences (or combine both); if they fail to do so, application authors are out of luck. #### 2. Add a separate, overridable property for each of the convenience API properties: interface Preferences { ... ReadOnlyObjectProperty appearanceProperty(); ObjectProperty appearanceOverrideProperty(); ... } The value of the read-only `appearanceProperty()` then corresponds to the value of `appearanceOverrideProperty()` if the property is set to a non-null value. Otherwise, it corresponds to the platform-provided value. #### 3. Add a special setter for each of the convenience API properties: interface Preferences { ... ReadOnlyObjectProperty appearanceProperty(); void setAppearance(Appearance appearance); ... } The `setAppearance` method can be used to _override_ the value of `appearanceProperty()`. When `null` is passed into this method, the platform default value is restored (or, put differently, the override is cleared). There is some precedence in JavaFX for a "special setter" pattern: for example, while the `Stage.widthProperty()` is read-only, `Stage.setWidth` is a special setter that attempts to set the stage width to the specified value (and may fail to do so). I prefer the third option (the special setter), as it seems to be the cleanest approach that doesn't unnecessarily expand the API. I think I've come around to the idea of dropping the `override` method in favor of `put`. However, I don't like the idea of using `put("key", null)` to reset an overridden mapping to its default value. Having "reset" be its own operation seems to work quite well, though: interface Preferences extends ObservableMap { ... /** * Overrides a preference mapping. *

* If a platform-provided mapping for the key already exists, calling this method overrides * the value that is mapped to the key. If a platform-provided mapping for the key doesn't * exist, this method creates a new mapping. * * @param key the key * @param value the new value * @throws NullPointerException if {@code key} or {@code value} is null * @throws IllegalArgumentException if a platform-provided mapping for the key exists, and * the specified value is an instance of a different class * than the platform-provided value * @return the previous value associated with {@code key} */ Object put(String key, Object value); /** * Resets an overridden preference mapping to its platform-provided value. *

* If the preference is overridden, but the platform does not provide a mapping for the * specified key, the mapping will be removed. If no mapping exists for the specified * key, calling this method has no effect. * * @param key the key * @throws NullPointerException if {@code key} is null */ void reset(String key); /** * Resets all overridden preference mappings to their platform-provided values and removes * all mappings for which the platform does not provide a default value. */ void reset(); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1501177237 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1531375810 From jhendrikx at openjdk.org Mon Jul 24 17:45:37 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 24 Jul 2023 17:45:37 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Sun, 9 Apr 2023 17:33:42 GMT, Michael Strau? wrote: > In general, platform preferences correspond to OS-level settings and are updated dynamically. Third-party themes might integrate platform preferences into their look and feel, which is often what users expect to see. But consider a scenario where an application uses a third-party theme that adapts to the OS appearance, but the application author only wants to support a dark appearance (independent from the OS appearance). > > For this scenario, platform preferences should be overridable from application code. I've considered several potential approaches: Would an approach similar to how Stylesheets do it be useful here? A property of a control can be overridden programmatically as well as set by CSS. In either case, the getter returns the current value (overridden or set by CSS). When set to a non-null value, the value takes precedence over CSS, and when set to `null` the CSS provided value takes over again. With the preferences Map, this could work similar perhaps; set a key to whatever you want with put, and restore it to its original value by setting it to null. > I think I've come around to the idea of dropping the `override` method in favor of `put`. However, I don't like the idea of using `put("key", null)` to reset an overridden mapping to its default value. Having "reset" be its own operation seems to work quite well, though: I'm a lot happier with this API. I wasn't sure about using `put("key", null)` either -- I was trying to compare it with how properties that can also be styled with CSS work, so we could use a consistent mechanism. But after some testing, I got the impression that CSS doesn't always respect programmatically set values, and still overwrites such values when pseudo classes are involved. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1501206250 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1532490625 From mstrauss at openjdk.org Mon Jul 24 17:45:37 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:37 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Sun, 9 Apr 2023 20:23:55 GMT, John Hendrikx wrote: > With the preferences Map, this could work similar perhaps; set a key to whatever you want with put, and restore it to its original value by setting it to null. That's how the current API works, with a little bit of added complexity: interface Preferences { ... /** * Overrides the value of the {@link #appearanceProperty() appearance} property. *

* Specifying {@code null} clears the override, which restores the value of the * {@code appearance} property to the platform-provided value. *

* Calling this method does not update the {@code appearance} property instantaneously; * instead, the property is only updated after calling {@link #commit()}, or after the * occurrence of an operating system event that causes the {@code appearance} property * to be recomputed. * * @param appearance the platform appearance override, or {@code null} to clear the override */ void setAppearance(Appearance appearance); ... /** * Overrides a key-value mapping. *

* If a platform-provided mapping for the key already exists, calling this method overrides * the value that is mapped to the key. If a platform-provided mapping for the key doesn't * exist, this method creates a new mapping. *

* Specifying a {@code null} value clears the override, which restores the value mapped to * the key to the platform-provided value. If the platform does not provide a mapping for * the specified key, the mapping is effectively removed. *

* Calling this method does not update the mapping instantaneously; instead, the mapping * is only updated after calling {@link #commit()}, or after the occurrence of an operating * system event that causes the mapped value to be recomputed. * * @param key the key * @param value the new value, or {@code null} to clear the override * @throws NullPointerException if {@code key} is null * @throws IllegalArgumentException if a platform-provided mapping for the key exists, and * the specified value is an instance of a different class * than the platform-provided value * @return the previous value associated with {@code key} */ T override(String key, T value); /** * Commits outstanding overridden preferences, which also causes the values of derived * properties to be recomputed. */ void commit(); } It is very likely the case that changing preferences can lead to very expensive operations in large real-world applications. For example, style themes or the entire user interface may be recreated, icons/images may be loaded, etc. The `Preferences` implementation accounts for this by firing only a single invalidation notification, even when multiple platform preferences have changed. The documentation of `Preferences` contains guidance for users of this API: * @implNote In many cases, multiple platform preferences can change at the same time. * For example, switching from light to dark mode changes various foreground elements to light * colors, and various background elements to dark colors. *

* The {@code Preferences} implementation returned from this method fires a single invalidation * event for such bulk changes. If a listener performs potentially heavy work, such as recreating * and applying CSS themes, it might be beneficial to use {@link javafx.beans.InvalidationListener} * instead of {@link javafx.collections.MapChangeListener} to prevent the listener from firing * multiple times in bulk change scenarios. This works when the changes originate from the OS, but it doesn't work when an application overrides preference mappings manually. `ObservableMap` doesn't support bulk changes, so repeatedly calling `override(...)` would end up firing multiple change notifications, and subscribers would have no way of knowing when the bulk change transaction has ended. That's where the concept of _uncommitted modifications_ comes into play: calling `override(...)` or any of the property setters like `setAppearance(...)` doesn't apply the changes immediately, it delays those changes until `commit()` is called or until an OS event causes the preference to be recomputed. When that happens, a single invalidation notification is fired, the same as it would have if the change originated from the OS. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1502081527 From mstrauss at openjdk.org Mon Jul 24 17:45:39 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:39 GMT Subject: RFR: 8301302: Platform preferences API [v2] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Jan 2023 23:04:50 GMT, Scott Palmer wrote: >> Michael Strau? has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > On Tue, Jan 31, 2023 at 3:00 PM Andy Goryachev ***@***.***> > wrote: > >> In the context of adding theme support in javafx, I think this PR is a >> step in the right direction. I also like a small set of >> platform-independent properties like fg and bg colors. I wonder if the same >> approach can be extended for other aspects of platform L&F, like fonts, >> spacing, and may be other aspects (like, hiding scrollbars setting on Mac?) >> >> I agree with @kevinrushforth - we'd >> need more discussion on the actual implementation. There are a few items >> that I feel are unnecessary, or might be done differently, and I'd like to >> learn what other people think. >> >> Specifically: >> >> 1. Appearance enum seems unnecessary - there might be more choices in >> a specific platform (Mac Ventura has three: dark/light/auto). >> >> > Is it necessary for any application to know about "auto"? Presumably when > the mode automatically changes from one to the other there would be an > event that should be handled, just as if the user changed the setting while > the application was running. > > Scott > >> Message ID: ***@***.***> >> @swpalmer @hjohn @andy-goryachev-oracle @kevinrushforth I think that the [Preferences API](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) has evolved quite well. There were quite some discussions on the mailing list, as well as here on GitHub. Given that there haven't been new arguments in favor or against this feature in a while, I'd like to wrap up the discussion on whether we want this in JavaFX. The main reason why I think this should go into core JavaFX is that it is adding a useful feature that can only be reasonably provided by the native windowing toolkits, and not by third-party libraries. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1514130844 From mstrauss at openjdk.org Mon Jul 24 17:45:41 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:41 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: <6jZNqmMWy3nTCyl5_6Wn2_XfDlxNYhod70WGl1FnSpc=.1678efed-d742-4c4c-be7b-db1617669086@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <6jZNqmMWy3nTCyl5_6Wn2_XfDlxNYhod70WGl1FnSpc=.1678efed-d742-4c4c-be7b-db1617669086@github.com> Message-ID: On Mon, 24 Apr 2023 06:01:58 GMT, John Hendrikx wrote: > I'm not convinced that a delayed change + commit system is the correct way to do this. Properties should behave the same everywhere in JavaFX and this seems to change how they work quite a bit. > > Instead, I propose to look at how layout in JavaFX is handling this problem. Layout looks at thousands of properties, yet changing one or many of the involved properties does not involve an expensive layout recalculation per change. Instead, changes are tracked by marking certain aspects of the involved controls dirty. On the next pulse, the layout code notices that something that would influence layout and CSS decisions has changed, and performs the required changes. The properties involved are all normal properties, that can be changed quickly, reflect their current value immediately and that can be overridden by the user or reset back to defaults. There is no override or commit system needed. > > Have you considered allowing users to change preference values directly, but not acting on those changes until the next pulse occurs? Users can still listen for keys/properties, just like they can for layout properties, but the major changes that involve recomputing CSS is only done once per pulse. > > This would make it possible to change several preference values without penalty (which happens on the FX thread anyway, so pulses are on hold during that time), and they're automatically "committed" once the user is done on the FX thread and the next pulse fires. I think it would be a very good fit. I think this could work, but it also means giving up on instant change notifications. A call to `setAppearance` or `override(key, value)` will not instantly fire a change notification (after the code that modifies the properties is done), but delay it until the next pulse. Resetting the value to its original value before the next pulse would probably also elide the change notification entirely. It's basically the same as change+commit, but with an implicit commit in the next pulse. > I'm still not sold on the `override` method. Would it not be better to make the map writable (with `put`) and if there is need to reset properties back to default offer a `reset` method? I'm saying this because adding an override method makes the map effectively writable (although delayed, if that's not going to be changed), and in that case I'd prefer using existing map methods for this purpose. Overriding a value is not the same thing as just changing it, since it also prevents further automatic updates of the value if the underlying system preference is changed. Since the semantics of overrides are quite different, I wonder if it?s a good idea to squeeze this into the `put` box, instead of just choosing a box with a different name. There are additional problems: if the map is fully mutable, it stands to reason that mappings should also be removable. But what if a mapping was removed, and the underlying system preference is changed? Do we add the mapping again (probably not)? In the end, we have a map where special rules apply for some of its mappings, even mappings that are not even in the map. All that just to avoid the `override` name? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1519456140 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1521710571 From jhendrikx at openjdk.org Mon Jul 24 17:45:41 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 24 Jul 2023 17:45:41 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <6jZNqmMWy3nTCyl5_6Wn2_XfDlxNYhod70WGl1FnSpc=.1678efed-d742-4c4c-be7b-db1617669086@github.com> Message-ID: On Mon, 24 Apr 2023 06:23:41 GMT, Michael Strau? wrote: > > I'm not convinced that a delayed change + commit system is the correct way to do this. Properties should behave the same everywhere in JavaFX and this seems to change how they work quite a bit. > > Instead, I propose to look at how layout in JavaFX is handling this problem. Layout looks at thousands of properties, yet changing one or many of the involved properties does not involve an expensive layout recalculation per change. Instead, changes are tracked by marking certain aspects of the involved controls dirty. On the next pulse, the layout code notices that something that would influence layout and CSS decisions has changed, and performs the required changes. The properties involved are all normal properties, that can be changed quickly, reflect their current value immediately and that can be overridden by the user or reset back to defaults. There is no override or commit system needed. > > Have you considered allowing users to change preference values directly, but not acting on those changes until the next pulse occurs? Users can still listen for keys/properties, just like they can for layout properties, but the major changes that involve recomputing CSS is only done once per pulse. > > This would make it possible to change several preference values without penalty (which happens on the FX thread anyway, so pulses are on hold during that time), and they're automatically "committed" once the user is done on the FX thread and the next pulse fires. I think it would be a very good fit. > > I think this could work, but it also means giving up on instant change notifications. A call to `setAppearance` or `override(key, value)` will not instantly fire a change notification (after the code that modifies the properties is done), but delay it until the next pulse. Resetting the value to its original value before the next pulse would probably also elide the change notification entirely. It's basically the same as change+commit, but with an implicit commit in the next pulse. That's not quite what I meant. You can add listeners still and get instant change notifications. Just like when I listen to the `backgroundProperty` of a control, and someone changes it, I get notified instantly and the change is reflected (in the property) instantly. Only when the next pulse fires is the change actually rendered. I would think the same is possible with say the appearance property. When I change it from LIGHT to DARK, everyone interested gets this notification immediately. On the next pulse, the change is noticed and only then do we change the stylesheets or make other adjustments that are high impact. Basically, the computationally expensive stuff happens during a pulse; it could register invalidation listeners on properties of interest which just set a flag, that is checked and reset on the next pulse. I'm not 100% sure, but it seems you want to add listeners to these properties yourself to instantly trigger the Theme updating code -- I'm saying, only set a boolean that they've changed, check it on the next pulse using `Scene#addPreLayoutPulseListener` (or perhaps there is another mechanism you can tap into internally), and then trigger the Theme change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1519514059 From mstrauss at openjdk.org Mon Jul 24 17:45:42 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:42 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <6jZNqmMWy3nTCyl5_6Wn2_XfDlxNYhod70WGl1FnSpc=.1678efed-d742-4c4c-be7b-db1617669086@github.com> Message-ID: On Mon, 24 Apr 2023 07:14:47 GMT, John Hendrikx wrote: > That's not quite what I meant. You can add listeners still and get instant change notifications. Just like when I listen to the `backgroundProperty` of a control, and someone changes it, I get notified instantly and the change is reflected (in the property) instantly. Only when the next pulse fires is the change actually rendered. > > I would think the same is possible with say the appearance property. When I change it from LIGHT to DARK, everyone interested gets this notification immediately. On the next pulse, the change is noticed and only then do we change the stylesheets or make other adjustments that are high impact. Basically, the computationally expensive stuff happens during a pulse; it could register invalidation listeners on properties of interest which just set a flag, that is checked and reset on the next pulse. > > I'm not 100% sure, but it seems you want to add listeners to these properties yourself to instantly trigger the Theme updating code -- I'm saying, only set a boolean that they've changed, check it on the next pulse using `Scene#addPreLayoutPulseListener` (or perhaps there is another mechanism you can tap into internally), and then trigger the Theme change. In the case of themes, listening to a changing preference may _be_ the expensive stuff, since it can involve recreating the entire list of stylesheets programmatically. Currently, a theme implementation might do something like this: public class MyTheme implements StyleTheme { private final InvalidationListener preferencesChanged = observable -> { // change getStylesheet() list }; public MyTheme() { Platform.getPreferences().addListener(new WeakInvalidationListener(preferencesChanged)); } ... } However, I'm thinking that the Preferences API might not be the right place to solve this problem. Maybe that should be built into the style theme API instead, for example with another interface: public interface PlatformStyleTheme extends StyleTheme { void onPreferencesChanged(Iterable> changes); } The Preferences _implementation_ would then aggregate the changes that have accumulated since the last pulse, and inform the current style theme by invoking its `onPreferencesChanged` method. This means that a style theme doesn't need to register listeners for different kinds of preferences, and the Preferences API can behave just as any normal property would behave. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520681831 From angorya at openjdk.org Mon Jul 24 17:45:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jul 2023 17:45:45 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <75gyP75cSGaORADOx9pqbR_CbmS_alGQpHal3zmz9Aw=.7c7e2e44-c3fa-479c-80f2-c5cb1cdf67f7@github.com> On Mon, 24 Apr 2023 20:13:30 GMT, Michael Strau? wrote: > Do you mean that you want `Preferences.appearanceProperty()`, `Preferences.backgroundColorProperty()` and `Preferences.foregroundColorProperty()` to be returned as a list? For example, by adding another method like: I meant ObjectProperty Preferences.getProperty(String key); Set listPropertyKeys(); it would also be nice to obtain a typed property right away. That might be more difficult, since one needs to use a dedicated class for the key what contains the value type, which might be clunky. > `ObservableMap` is my preferred solution. Map.containsValue() would have to resolve values for all the keys. Is this expected? If the code already resolves all values, I presume on the first call to `getPreferences`, the Map is probably ok. Does querying for all the values take long? Any possibility of getting blocked waiting for something? > What I've been calling `Appearance` in this PR is _one_ of those knobs. I think we are on the same page here. My point here is that, from the API design standpoint, it is better to think ahead and consider controlling multiple attributes instead of a singularly invented Appearance enum. Why not have `Stage.setAttributes(Set)` instead of `setAppearance()` then? We can still have an Apperance enum, but this time it will be just one of many possible attributes. it could be platform-independent if we agree that it's well defined, or it could be platform-specific like DWMWA_USE_IMMERSIVE_DARK_MODE. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520892988 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520935390 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520944848 From angorya at openjdk.org Mon Jul 24 17:45:43 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jul 2023 17:45:43 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 2 Feb 2023 19:54:33 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. catching up with the discussion: 1. ObservableMap. Is it unmodifiable? I'd expect it to be, since this API exposes the properties of the underlying platform. 2. Does this API track user changes (via OS widgets such as Control Panel in Windows) at runtime? 3. "Platform Preferences" name. We already have java.util.prefs.Preferences, the name might be confusing. Swing has UIDefaults, perhaps we could think of something along those lines? 4. Re: Property API. I think it is still a valid approach, once a call to list all the available keys is added. It would be nice to have a way to also obtain the type of the value for a specific key, or infer the type from the type of property returned. Even more, it might be nice to be able to query the: - list of all the keys exposed by the API - value type - possibly, a human-readable description of the property - possibly, whether the value can be changed by this application I am still not sold on the concept of Appearance (what if a Dusk mode will be added in addition to the Dark and Light?). However, it could be just another platform-specific key, could it not? What do you think? Also, this PR needs a CSR once everyone is happy with the outcome of this discussion. [discussion] the problem with ObservableMap is that it drags in a large API surface of Map. [discussion] A native window appearance might be more than one attribute. In that sense, I think it is better to treat them as such - as platform-specific attributes. (An example I have in mind is a gradient color accent in Windows 10 - I don't know if that's still a thing, or how it's done in windows 11 and the dark mode). But the idea of limiting the API to a very narrow set of existing variants bothers me. [question] when an application changes the value of one or more properties, does it change the appearance of that application alone, all of the javafx applications, or all of the platform applications? [opinion] I'd rather see UIPreferences name (PlatformUISettings?) and move it outside of the Platform class. [discussion] > `Appearance` is central to _all_ of those features >From the API perspective, Appearance, though important, is just one of many attributes. Adding a separate method where we could operate with a Set of attributes ("hints") is, in my opinion, a less optimal solution. For example, Stage.setAttributes(Set) is a much more flexible approach. If things change tomorrow with new attribute added, or some other change, this API does not have to be modified. (The Stage should silently ignore any attributes it does not recognize or that are not supported by the platform). For the Platform Preferences API, a native attribute such as `DWMWA_USE_IMMERSIVE_DARK_MODE` may also be echoed by an Appearance attribute, so the app dev can use either one depending on the requirements. I suppose we could have a dedicated getAppearance() method as shortcut (as well as some other frequently used shortcuts). What do you think? [opinion] I don't quite like the 'override' method and the idea of app modifying the values, as I see it as a purely informational API. The changes should, in my opinion, be triggered by the platform only. Any other functionality is app-specific. Another thing i am not comfortable with is the eager initialization (and that's another reason I don't quite like ObservableMap idea). Generally speaking, we should not be initializing things an application is not going to use. That's why I like the concept of accessing individual attributes - if a theme needs Appearance, only that value and its machinery gets initialized. Small delays added here and there add up. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520708740 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520894055 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520897723 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520898504 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520899926 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1523841849 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1523855676 From mstrauss at openjdk.org Mon Jul 24 17:45:45 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:45 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: <75gyP75cSGaORADOx9pqbR_CbmS_alGQpHal3zmz9Aw=.7c7e2e44-c3fa-479c-80f2-c5cb1cdf67f7@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <75gyP75cSGaORADOx9pqbR_CbmS_alGQpHal3zmz9Aw=.7c7e2e44-c3fa-479c-80f2-c5cb1cdf67f7@github.com> Message-ID: <18YzKYEehhw3amHjV_VKWa_r0ggnsMllKD3jWUtZAvA=.c2faab1e-ed29-4ab4-9746-9ac37e52c4c9@github.com> On Mon, 24 Apr 2023 22:08:20 GMT, Andy Goryachev wrote: > I meant > > ``` > ObjectProperty Preferences.getProperty(String key); > Set listPropertyKeys(); > ``` > > it would also be nice to obtain a typed property right away. That might be more difficult, since one needs to use a dedicated class for the key what contains the value type, which might be clunky. I discussed this briefly in a previous [comment](https://github.com/openjdk/jfx/pull/1014#issuecomment-1500535347). The problem with this idea is that you need to do two things: first, check whether a given preference is available on the current platform, and second, get the property for the key. What happens if you try to retrieve a property for a key that's not available? Do you get an exception? Do you get a property implementation that holds a default value? What if you want to control the default value? The `Optional` approach, as currently proposed, solves this problem with an API that Java users already know. For example, if you are targeting macOS and you are interested in the `macOS.NSColor.findHighlightColor` preference, which is only available starting with macOS 10.13, you could provide a suitable fallback like this: var findHighlightColor = Platform.getPreferences() .getColor("macOS.NSColor.findHighlightColor") .orElse(Color.BLUE); > Map.containsValue() would have to resolve values for all the keys. Is this expected? If the code already resolves all values, I presume on the first call to `getPreferences`, the Map is probably ok. > > Does querying for all the values take long? Any possibility of getting blocked waiting for something? Yes, the `Map` contract holds, which is why all values will have to be resolved by the time you're calling `Map.containsValue()`. From an API perspective, it is unspecified how that works, i.e. whether values are lazily or eagerly resolved. From an implementation perspective, all values are queried on application startup, and after that the values are updated as updates come in. For example, in the Windows toolkit, this works by intercepting several events in the main window loop, including `WM_SETTINGCHANGE`, `WM_THEMECHANGED`, or `WM_SYSCOLORCHANGE`. On macOS, the native toolkit subscribes to the `AppleColorPreferencesChangedNotification` and `AppleInterfaceThemeChangedNotification` events. After receiving one of these events, the updated values are sent back to the `PlatformImpl` class, where they are integrated into the `Preferences` map. The event-based approach of the current implementation doesn't run any risk of blocking calls. > > What I've been calling `Appearance` in this PR is _one_ of those knobs. > > I think we are on the same page here. > > My point here is that, from the API design standpoint, it is better to think ahead and consider controlling multiple attributes instead of a singularly invented Appearance enum. Why not have `Stage.setAttributes(Set)` instead of `setAppearance()` then? > > We can still have an Apperance enum, but this time it will be just one of many possible attributes. it could be platform-independent if we agree that it's well defined, or it could be platform-specific like DWMWA_USE_IMMERSIVE_DARK_MODE. There's a reason why `Appearance` is kind of singled out among all of the potential other knobs, and that is because it represents a concept that interacts very strongly with the upcoming Style Themes feature. In total, I propose three PRs: [JDK-8301302: Platform preferences API](https://bugs.openjdk.org/browse/JDK-8301302) [JDK-8301303: Allow Stage to control the appearance of window decorations](https://bugs.openjdk.org/browse/JDK-8301303) [JDK-8267546: Add CSS themes as a first-class concept](https://bugs.openjdk.org/browse/JDK-8267546) `Appearance` is central to _all_ of those features, as it encodes the "light mode or dark mode" knob. This is the most significant knob that users will interact with, as it represents: 1. An OS-wide system setting 2. The general "light or dark" appearance of window borders 3. The colors used in application stylesheets, icons, images, etc. For a style theme author, this bit of information is central, as the entire look and feel of the theme will be designed around it. Most likely there will be at least two hand-picked sets of colors for a style theme depending on whether light or dark mode is enabled. I don't think we'll want the style theme author to bother figuring out whether some obscure platform-specific `DWMWA_USE_IMMERSIVE_DARK_MODE` flag is set, or whether the current macOS appearance is named `NSAppearanceNameDarkAqua`. So we need a platform-independent way of encoding this bit, and `Appearance` is pretty easy to use for style theme authors: // Note that a real implementation would need to subscribe to Appearance changes, // and update the stylesheets accordingly public class MyTheme implements StyleTheme { public MyTheme() { if (Platform.getPreferences().getAppearance() == Appearance.LIGHT) { // compose light stylesheets } else { // compose dark stylesheets } } } Note that the water actually gets a bit muddy when you factor in accessibility themes. Is a high-contrast accessibility theme a separate appearance? What about an inverted color mode? My best answer to this is: no, it's not. On macOS, inverted color mode works without the application knowing about it. On Windows, accessibility themes certainly don't work without the application knowing about it, so a theme that works with high-contrast accessibility needs to monitor several very platform-specific keys, and then integrate those special colors into the theme. That's not something that we can easily represent or condense down, or even represent in a platform-agnostic way. I agree with you that we should carefully plan ahead and see how we might extend this in the future to control more knobs. The `Preferences` API is not the right place for this, since `Preferences` can only query settings from the OS, it cannot change them. My current thinking on this is that there are three categories of knobs: 1. Knobs that significantly affect the window border *and* the window content 2. Knobs that significantly affect *only* the window border 3. Knobs that affect OS-specific details of the window border The first category is represented by `Appearance`, that's why it gets to have its own enumeration. The second category is represented by `StageStyle`, because we have broad support on _most_ operating systems. The third category is currently unrepresented, and it includes knobs like `DWM_WINDOW_CORNER_PREFERENCE`, which is only available on Windows 11. I can imagine that we could have something like a `Stage.hints` property, where developers can specify those cat3 knobs. The name "hint" strongly suggests that we're talking about optional things. Yes, an app developer might want to have rounded window corners. But when the app runs on Windows 10, there simply won't be rounded corners, and that's not a big deal. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520924295 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520948693 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520968329 From mstrauss at openjdk.org Mon Jul 24 17:45:44 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:44 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Mon, 24 Apr 2023 19:24:31 GMT, Andy Goryachev wrote: > 1. ObservableMap. Is it unmodifiable? I'd expect it to be, since this API exposes the properties of the underlying platform. Yes and no. It is unmodifiable as it relates to the `Map` contract: you can't add, remove, or change mappings. However, you can _override_ mappings. For example, invoking `Platform.getPreferences().override("Windows.UIColor.Accent", Color.RED)` will change the _effective value_ of the mapping. This is also true for platform-independent properties: `Platform.getPreferences().setAppearance(Appearance.DARK)` will override the platform appearance with the specified value. Overriding a property or mapping with a new value causes the new value to have a higher precedence than the platform-provided value. If the override is removed by calling `override("Windows.UIColor.Accent", null)`, or `setAppearance(null)`, the platform-provided value is restored, i.e. the effective value now resolves to the immutable platform-provided value. This elaborate system ensures that platform-provided values are immutable and you can't "lose" them by overwriting or removing the values. > 2. Does this API track user changes (via OS widgets such as Control Panel in Windows) at runtime? Yes, it tracks changes in real-time when they occur. It even tracks changes for overridden preferences, and resolves the _current_ platform-provided value once the override is removed. > 3. "Platform Preferences" name. We already have java.util.prefs.Preferences, the name might be confusing. Swing has UIDefaults, perhaps we could think of something along those lines? I prefer "Preferences" for two reasons: it doesn't close the door to adding other kinds of platform-provided preferences in the future, which might not directly relate to graphics. Additionally, "UIDefaults" or something along those lines implies, well, that it's the default. But it's not really that; this API represents the _current_ configuration, not the _default_ configuration. > 4. Re: Property API. I think it is still a valid approach, once a call to list all the available keys is added. It would be nice to have a way to also obtain the type of the value for a specific key, or infer the type from the type of property returned. Even more, it might be nice to be able to query the: > > * list of all the keys exposed by the API > * value type Do you mean that you want `Preferences.appearanceProperty()`, `Preferences.backgroundColorProperty()` and `Preferences.foregroundColorProperty()` to be returned as a list? For example, by adding another method like: interface Preferences { ... List> getProperties() {...} ... } I don't really see the added value. > * possibly, a human-readable description of the property Why? If it is human-readable, do you envision this to be shown in the user interface of an application? If so, we'd also need it to be localizable. However, I don't see why the API should provide this information. Seems like it could be included in the documentation, though. > * possibly, whether the value can be changed by this application All preferences can be overridden by an application, even computed properties like `Preferences.appearanceProperty()`. > I am still not sold on the concept of Appearance (what if a Dusk mode will be added in addition to the Dark and Light?). However, it could be just another platform-specific key, could it not? At this point, I think that light and dark mode are deeply baked into the operating systems (at least when it comes to macOS and Windows). Please note that this aligns with a follow-up enhancement that would add a `Stage.preferences` property to control the platform appearance of the window decorations (see [Stage appearance](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#stage-appearance)). Supporting different OS appearances in client applications is quite hard, so I don't expect operating systems to add more than those two appearances in the forseeable future. But if that happens, we'll have two options: 1. If _Dusk Mode_ is widely supported by different operating systems, we can add it to the platform-independent `Appearance` enumeration. However, this would be a breaking change and not something we would do lightly. 2. If it is just a narrow feature of a single operating system, we can add a platform-specific key to the `Preferences` map, and style themes that want to support this particular appearance will then include code to handle just this platform-specific key. > [discussion] the problem with ObservableMap is that it drags in a large API surface of Map. I outlined several alternatives to using `ObservableMap` [here](https://github.com/openjdk/jfx/pull/1014#issuecomment-1500535347), and concluded that `ObservableMap` is my preferred solution. The main reason is that, by the time you add in all of the operations that we would like to have (querying available keys, iterating over the preferences, observing changes), you'll end up with what is functionally an `ObservableMap`. If we end up reinventing a map, I think we should actually make it a map. I don't see much wrong with introducing the `Map` API surface. After all, this _is_ a map of preference keys to their respective values. I'll go out on a limb and say that _not_ making a map a `Map` is a worse API choice. > [discussion] A native window appearance might be more than one attribute. In that sense, I think it is better to treat them as such - as platform-specific attributes. > > (An example I have in mind is a gradient color accent in Windows 10 - I don't know if that's still a thing, or how it's done in windows 11 and the dark mode). But the idea of limiting the API to a very narrow set of existing variants bothers me. Accent color and dark mode are two separate things, and they have different representations in the proposed API. The proposed `Stage.appearance` property controls exactly one bit of information: On Windows, it sets the `DWMWA_USE_IMMERSIVE_DARK_MODE` flag. On macOS, it changes the appearance from `NSAppearanceNameAqua` to `NSAppearanceNameDarkAqua`. At this point in time, I can't imagine that this will change in the forseeable future. If at some point we'll get a third mode, then we can evaluate whether we want to add a third value to the `Appearance` enumeration. However, you are making a point that is certainly true: the window appearance is actually _more_ than a single attribute. For example, we currently control other aspects of native window borders with `StageStyle`. Additionally, there are several aspects of a native window border that we currently can't control. For example, in Windows 11, you can choose whether a window has regular rounded corners, small rounded corners, or no rounded corners. This is controlled by `DWM_WINDOW_CORNER_PREFERENCE`, but a JavaFX application has no way of controlling this preference. My point is this: I agree that there are additional knobs that control how native windows are rendered. What I've been calling `Appearance` in this PR is _one_ of those knobs. I don't want to suggest that this is the only knob, but it's a knob that controls a well-defined single bit of information. > [question] when an application changes the value of one or more properties, does it change the appearance of that application alone, all of the javafx applications, or all of the platform applications? The `Preferences` map can only read OS prefs, it cannot change them. So when you override the value of one of the preferences, the change is only visible to the application alone, and not to other JavaFX applications or the OS. > I don't quite like the 'override' method and the idea of app modifying the values, as I see it as a purely informational API. The changes should, in my opinion, be triggered by the platform only. Any other functionality is app-specific. But what do you do when a style theme uses platform preferences to adjust its appearance (light/dark mode), but an application either doesn't want to offer a dark mode, or wants the _application_ (not the OS) be able to toggle light/dark appearance? If an application can't override the preferences that go into a style theme, then it can't control its appearance. > > Another thing i am not comfortable with is the eager initialization (and that's another reason I don't quite like ObservableMap idea). Generally speaking, we should not be initializing things an application is not going to use. That's why I like the concept of accessing individual attributes - if a theme needs Appearance, only that value and its machinery gets initialized. > > Small delays added here and there add up. I think you're chasing nanoseconds here. We're talking about a map that contains a few dozens of entries at max, and that exists as a singleton for the lifetime of the application. On top of that, from an implementation standpoint, we're querying all OS preferences anyways on the native side, there is no fine-grained and elaborate system to only query the preferences that have actually changed (the compexity just isn't worth the effort). This is not a performance-critical piece of code, since OS preferences don't change often. In fact, for most users, they don't change at all while the applications is running. > [discussion] > > > `Appearance` is central to _all_ of those features > > From the API perspective, Appearance, though important, is just one of many attributes. Adding a separate method where we could operate with a Set of attributes ("hints") is, in my opinion, a less optimal solution. > > For example, Stage.setAttributes(Set) is a much more flexible approach. If things change tomorrow with new attribute added, or some other change, this API does not have to be modified. (The Stage should silently ignore any attributes it does not recognize or that are not supported by the platform). > > For the Platform Preferences API, a native attribute such as `DWMWA_USE_IMMERSIVE_DARK_MODE` may also be echoed by an Appearance attribute, so the app dev can use either one depending on the requirements. > > I suppose we could have a dedicated getAppearance() method as shortcut (as well as some other frequently used shortcuts). > > What do you think? I think you're conflating platform preferences with stage styling here. `DWMWA_USE_IMMERSIVE_DARK_MODE` is not a platform preference, it is a window attribute (an implementation detail) that can be set independently from any preference. `Appearance`, on the other hand, is a platform preference that can be toggled by users and is directly meaningful for style theme authors and application developers. We should focus the discussion here on the preferences API, not on stage styling. I understand that those two topics have a bit of common ground, but extended discussions of new `Stage` APIs seem a bit premature. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520768361 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520918231 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520941610 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520971384 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1531396822 PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1532013105 From duke at openjdk.org Mon Jul 24 17:45:46 2023 From: duke at openjdk.org (airsquared) Date: Mon, 24 Jul 2023 17:45:46 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 2 May 2023 12:31:20 GMT, Michael Strau? wrote: > But what do you do when a style theme uses platform preferences to adjust its appearance (light/dark mode), but an application either doesn't want to offer a dark mode, or wants the _application_ (not the OS) be able to toggle light/dark appearance? If an application can't override the preferences that go into a style theme, then it can't control its appearance. Since this is mainly for if a user wants to adjust the preferences used in a style theme, would it make sense to provide this feature for overriding preferences in the style theme API? This could also give the user the option to override preferences only for a specific style theme instead of globally for all style themes. Moving the overriding preferences feature into the style theme API could also open the door for style theme authors to allow customization of other parts of a style theme. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1532502159 From mstrauss at openjdk.org Mon Jul 24 17:45:47 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:47 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 3 May 2023 06:23:48 GMT, airsquared wrote: > Since this is mainly for if a user wants to adjust the preferences used in a style theme, would it make sense to provide this feature for overriding preferences in the style theme API? This could also give the user the option to override preferences only for a specific style theme instead of globally for all style themes. Moving the overriding preferences feature into the style theme API could also open the door for style theme authors to allow customization of other parts of a style theme. Style themes are not the only place where platform preferences might be used. For example, macOS has an OS setting that controls whether clicking on a scrollbar moves the content page by page, or directly to the clicked spot. Skins could use those kinds of non-visual preferences in the future. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1533051522 From duke at openjdk.org Mon Jul 24 17:45:47 2023 From: duke at openjdk.org (Pedro Duque Vieira) Date: Mon, 24 Jul 2023 17:45:47 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 2 Feb 2023 19:54:33 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. Hi all, First of all, thanks for the efforts to integrate this new API into JavaFX. As a style theme developer myself I think this API is missing nowadays and will be a good addition to the SDK! A comment not related to this specific PR but... the discussion about this new API was being held on the mailing list some time ago, I was also involved in that discussion. It stopped so I thought this wasn't going to go forward. I've only recently realized the discussion moved to here. So, my comment is: is there a centralized place to check on all the new developments in the javafx platform including ongoing efforts (I thought the mailing list was that place) ...? For instance, I was having a small discussion on Twitter with a prominent member of the JavaFX community about how having this kind of API would be of interest to JavaFX. I don't think anyone involved knows that this PR (that would add such a feature) is ongoing... they might also have interesting insights to add... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1543837458 From mstrauss at openjdk.org Mon Jul 24 17:45:48 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:48 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> On Thu, 11 May 2023 11:38:14 GMT, Pedro Duque Vieira wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. > > Hi all, > > First of all, thanks for the efforts to integrate this new API into JavaFX. As a style theme developer myself I think this API is missing nowadays and will be a good addition to the SDK! > > A comment not related to this specific PR but... the discussion about this new API was being held on the mailing list some time ago, I was also involved in that discussion. It stopped so I thought this wasn't going to go forward. I've only recently realized the discussion moved to here. So, my comment is: is there a centralized place to check on all the new developments in the javafx platform including ongoing efforts (I thought the mailing list was that place) ...? > For instance, I was having a small discussion on Twitter with a prominent member of the JavaFX community about how having this kind of API would be of interest to JavaFX. I don't think anyone involved knows that this PR (that would add such a feature) is ongoing... they might also have interesting insights to add... @dukke I don't think there's a central place for all JavaFX discussions. I've observed that high-level discussions seem to happen on the mailing list, while discussions of concrete implementation proposals often happen on GitHub. You didn't get any notifications on the mailing list for this PR since it's still in the Draft state. That being said, this proposal seems to be stuck in the "do we want this in JavaFX?" stage. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1544107419 From duke at openjdk.org Mon Jul 24 17:45:49 2023 From: duke at openjdk.org (Pedro Duque Vieira) Date: Mon, 24 Jul 2023 17:45:49 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> Message-ID: On Thu, 11 May 2023 14:38:01 GMT, Michael Strau? wrote: >> Hi all, >> >> First of all, thanks for the efforts to integrate this new API into JavaFX. As a style theme developer myself I think this API is missing nowadays and will be a good addition to the SDK! >> >> A comment not related to this specific PR but... the discussion about this new API was being held on the mailing list some time ago, I was also involved in that discussion. It stopped so I thought this wasn't going to go forward. I've only recently realized the discussion moved to here. So, my comment is: is there a centralized place to check on all the new developments in the javafx platform including ongoing efforts (I thought the mailing list was that place) ...? >> For instance, I was having a small discussion on Twitter with a prominent member of the JavaFX community about how having this kind of API would be of interest to JavaFX. I don't think anyone involved knows that this PR (that would add such a feature) is ongoing... they might also have interesting insights to add... > > @dukke I don't think there's a central place for all JavaFX discussions. I've observed that high-level discussions seem to happen on the mailing list, while discussions of concrete implementation proposals often happen on GitHub. You didn't get any notifications on the mailing list for this PR since it's still in the Draft state. > > That being said, this proposal seems to be stuck in the "do we want this in JavaFX?" stage. @mstr2 I see minor bugs and minor features as well as implementation details being discussed in the mailing list. I think a centralized place to see all that's being done in the javafx sdk (including proposed features) would be nice. Personally, I feel that the ability to specify multiple user-agent stylesheets is a no-brainer. Right now, my javafx theme JMetro has to be composed of scene stylesheets which can be a hassle for many developers using it (given how it overrides styles set in code). The other features are also important and I would be happy to see them in the javafx sdk, especially since I'm a theme developer and I've been missing these features for a while. Perhaps if these features are discussed individually (for example only discussing the ability to have multiple user agent stylesheets) they would be "easier to sell"? And all the other ones, each in its own PR. At least they would be easier to discuss (as each PR would be less complex) and so potentially easier to sell. Without however missing the whole picture like you're doing here... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1544126580 From duke at openjdk.org Mon Jul 24 17:45:50 2023 From: duke at openjdk.org (Alessadro Parisi) Date: Mon, 24 Jul 2023 17:45:50 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> Message-ID: On Thu, 11 May 2023 14:38:01 GMT, Michael Strau? wrote: >> Hi all, >> >> First of all, thanks for the efforts to integrate this new API into JavaFX. As a style theme developer myself I think this API is missing nowadays and will be a good addition to the SDK! >> >> A comment not related to this specific PR but... the discussion about this new API was being held on the mailing list some time ago, I was also involved in that discussion. It stopped so I thought this wasn't going to go forward. I've only recently realized the discussion moved to here. So, my comment is: is there a centralized place to check on all the new developments in the javafx platform including ongoing efforts (I thought the mailing list was that place) ...? >> For instance, I was having a small discussion on Twitter with a prominent member of the JavaFX community about how having this kind of API would be of interest to JavaFX. I don't think anyone involved knows that this PR (that would add such a feature) is ongoing... they might also have interesting insights to add... > > @dukke I don't think there's a central place for all JavaFX discussions. I've observed that high-level discussions seem to happen on the mailing list, while discussions of concrete implementation proposals often happen on GitHub. You didn't get any notifications on the mailing list for this PR since it's still in the Draft state. > > That being said, this proposal seems to be stuck in the "do we want this in JavaFX?" stage. > @mstr2 I see minor bugs and minor features as well as implementation details being discussed in the mailing list. I think a centralized place to see all that's being done in the javafx sdk (including proposed features) would be nice. > > Personally, I feel that the ability to specify multiple user-agent stylesheets is a no-brainer. Right now, my javafx theme JMetro has to be composed of scene stylesheets which can be a hassle for many developers using it (given how it overrides styles set in code). > > The other features are also important and I would be happy to see them in the javafx sdk, especially since I'm a theme developer and I've been missing these features for a while. > > Perhaps if these features are discussed individually (for example only discussing the ability to have multiple user agent stylesheets) they would be "easier to sell"? And all the other ones, each in its own PR. At least they would be easier to discuss (as each PR would be less complex) and so potentially easier to sell. Without however missing the whole picture like you're doing here... I agree. Currently, the hardest challenge I'm facing is to find a way to style my applications entirely. Adding the stylesheets on the main Scene preserves the JavaFX user agent while still allowing me to style all my custom components in that Scene. The issue is that obviously, styles are not applied to other Windows/Scenes, which means that Dialogs are problematic components. Adding the entire theme on them leads to awful performance, and so the only way to also include them is to set the user agent...but then JavaFX controls would lose their styles. Recently, I came up with a naive workaround for this. I coded a mechanism that allows to merge/combine multiple stylesheets into one. The good thing about this is that I can produce a single user agent stylesheet that can cover both JavaFX controls and my controls in every single Window/Scene. The bad thing is that at-rules do not work, so no typefaces, no other stylesheets, only full themes can be merged. For the fonts, I found out th at it's enough to add the stylesheet containing the font-faces declarations on the main Scene, and they will be picked everywhere. Talking about #511 and #1014. I think that both the APIs are quite nice additions to JavaFX. However I was thinking, @mstr2 can't the two features be split? It seems to me, correct me if I'm wrong, that the Platform Preferences API still requires quite some work. On the other hand the support for themes seems to be easier and faster to implement. I think it would be worth splitting the two features, and trying to add the Theme API by the next release ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1566645669 From mstrauss at openjdk.org Mon Jul 24 17:45:51 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 17:45:51 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> Message-ID: On Thu, 11 May 2023 14:38:01 GMT, Michael Strau? wrote: >> Hi all, >> >> First of all, thanks for the efforts to integrate this new API into JavaFX. As a style theme developer myself I think this API is missing nowadays and will be a good addition to the SDK! >> >> A comment not related to this specific PR but... the discussion about this new API was being held on the mailing list some time ago, I was also involved in that discussion. It stopped so I thought this wasn't going to go forward. I've only recently realized the discussion moved to here. So, my comment is: is there a centralized place to check on all the new developments in the javafx platform including ongoing efforts (I thought the mailing list was that place) ...? >> For instance, I was having a small discussion on Twitter with a prominent member of the JavaFX community about how having this kind of API would be of interest to JavaFX. I don't think anyone involved knows that this PR (that would add such a feature) is ongoing... they might also have interesting insights to add... > > @dukke I don't think there's a central place for all JavaFX discussions. I've observed that high-level discussions seem to happen on the mailing list, while discussions of concrete implementation proposals often happen on GitHub. You didn't get any notifications on the mailing list for this PR since it's still in the Draft state. > > That being said, this proposal seems to be stuck in the "do we want this in JavaFX?" stage. > Talking about #511 and #1014. I think that both the APIs are quite nice additions to JavaFX. However I was thinking, @mstr2 can't the two features be split? It seems to me, correct me if I'm wrong, that the Platform Preferences API still requires quite some work. On the other hand the support for themes seems to be easier and faster to implement. I think it would be worth splitting the two features, and trying to add the Theme API by the next release I've already proposed to deliver the feature in three installments to make it easier to get it agreed upon and reviewed: 1. [Platform Preferences API](https://bugs.openjdk.org/browse/JDK-8301302) (this PR) 2. [Allow Stage to control the appearance of window decorations](https://bugs.openjdk.org/browse/JDK-8301303) 3. [Add CSS themes as a first-class concept](https://bugs.openjdk.org/browse/JDK-8267546) The Platform Preference API is ready to be reviewed, as far as I'm concerned. While it has been discussed extensively on the mailing list and here on GitHub, the feature proposal as a whole is still lacking buy-in from the OpenJFX project leads. Note that getting the Style Theme API in before Platform Preferences is harder than it sounds. The built-in JavaFX themes Caspian and Modena will need to be re-implemented as first-class themes, and that requires Platform Preferences to support high-contrast themes on Windows. The alternative of keeping two different code paths would lead to significant additional maintenance cost. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1568656832 From duke at openjdk.org Mon Jul 24 17:45:52 2023 From: duke at openjdk.org (Alessadro Parisi) Date: Mon, 24 Jul 2023 17:45:52 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <06hF1H2T-vBw9pWDAIsxsginfjCf2qMl90tZlaSDEDg=.93d94c2c-2218-4934-ad1d-b407db162c5d@github.com> Message-ID: On Tue, 30 May 2023 15:37:29 GMT, Michael Strau? wrote: > > Talking about #511 and #1014. I think that both the APIs are quite nice additions to JavaFX. However I was thinking, @mstr2 can't the two features be split? It seems to me, correct me if I'm wrong, that the Platform Preferences API still requires quite some work. On the other hand the support for themes seems to be easier and faster to implement. I think it would be worth splitting the two features, and trying to add the Theme API by the next release > > I've already proposed to deliver the feature in three installments to make it easier to get it agreed upon and reviewed: > > 1. [Platform Preferences API](https://bugs.openjdk.org/browse/JDK-8301302) (this PR) > > 2. [Allow Stage to control the appearance of window decorations](https://bugs.openjdk.org/browse/JDK-8301303) > > 3. [Add CSS themes as a first-class concept](https://bugs.openjdk.org/browse/JDK-8267546) > > > The Platform Preference API is ready to be reviewed, as far as I'm concerned. While it has been discussed extensively on the mailing list and here on GitHub, the feature proposal as a whole is still lacking buy-in from the OpenJFX project leads. > > Note that getting the Style Theme API in before Platform Preferences is harder than it sounds. The built-in JavaFX themes Caspian and Modena will need to be re-implemented as first-class themes, and that requires Platform Preferences to support high-contrast themes on Windows. The alternative of keeping two different code paths would lead to significant additional maintenance cost. I was hoping in getting at least the possibility of adding more than one stylesheet as the app user-agent, without necessarily implementing the Themes API yet. Guess I'll have to wait a bit more, in the meanwhile I'll try expanding my 'workaround' of converting multiple stylesheets to a single one on the fly to compensate And again, thanks for your work! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1569803226 From kizune at openjdk.org Mon Jul 24 18:34:22 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 24 Jul 2023 18:34:22 GMT Subject: RFR: 8309558: Create implementation of NSAccessibilityCheckBox protocol [v2] In-Reply-To: References: Message-ID: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> > also > 8309629: Create implementation of NSAccessibilityRadioButton protocol > > Create implementation of NSAccessibilityCheckBox and NSAccessibilityRadioButton protocols > Add workaround for the wrong focus owner announcement with radio buttons > Add workaround for wrong magnifier text on buttons Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Add newline at the end of the header files. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1184/files - new: https://git.openjdk.org/jfx/pull/1184/files/8010b18a..1ce209c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1184&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1184&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1184.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1184/head:pull/1184 PR: https://git.openjdk.org/jfx/pull/1184 From mstrauss at openjdk.org Mon Jul 24 20:03:04 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 Jul 2023 20:03:04 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Fri, 9 Jun 2023 12:00:06 GMT, John Hendrikx wrote: >> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. >> >> # Behavior >> >> |Listener...|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| >> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| >> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| >> >> ## Nested notifications: >> >> | |ExpressionHelper|ListenerManager| >> |---|---|---| >> |Type|Depth first (call stack increases for each nested level)|(same)| >> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| >> |Vetoing Possible?|No|Yes| >> |Old Value correctness|Only for listeners called before listeners making nested changes|Always| >> >> # Performance >> >> |Listener|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Addition|Array based, append in empty slot, resize as needed|(same)| >> |Removal|Array based, shift array, resize as needed|(same)| >> |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| >> |Removal during notification|As above|Entry is `null`ed| >> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| >> |Notifying Invalidation Listeners|1 ns each|(same)| >> |Notifying Change Listeners|1 ns each (*)|2-3 ns each| >> >> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values >> >> # Memory Use >> >> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. >> >> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| >> |---|---|---|---| >> |No Listeners|none|none|none| >> |Single InvalidationListener|16 bytes overhead|none|none| >> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| >> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| >> >> # About nested changes >> >> Nested changes are simply changes that are made to a property that is currently in the process of notif... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix generic warnings modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 143: > 141: */ > 142: public void fireValueChanged(I instance, T oldValue) { > 143: Object data = getData(instance); The `data` value could be passed into this method, which would save a (potentially not devirtualized) method call. modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 145: > 143: Object data = getData(instance); > 144: > 145: if (data instanceof ListenerList) { Why is `ListenerList` checked first, when most observables only have a single `InvalidationListener`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272690289 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272692011 From jhendrikx at openjdk.org Mon Jul 24 22:04:50 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 24 Jul 2023 22:04:50 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Mon, 24 Jul 2023 19:58:04 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix generic warnings > > modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 145: > >> 143: Object data = getData(instance); >> 144: >> 145: if (data instanceof ListenerList) { > > Why is `ListenerList` checked first, when most observables only have a single `InvalidationListener`? For some (unclear to me) reason this order performs better in my benchmark, even for the cases that only have a single invalidation listener. I've tweaked this method extensively, with different orders, and this was about the best I could get it. That said, the differences are small, and we can go with a more logical order. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272801049 From jhendrikx at openjdk.org Mon Jul 24 22:12:53 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 24 Jul 2023 22:12:53 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Mon, 24 Jul 2023 19:56:06 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix generic warnings > > modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 143: > >> 141: */ >> 142: public void fireValueChanged(I instance, T oldValue) { >> 143: Object data = getData(instance); > > The `data` value could be passed into this method, which would save a (potentially not devirtualized) method call. Thanks, I'll look into that, it might speed up the 1 listener cases a bit. The same applies to OldValueCachingListenerManager#getValue I think. I know it isn't possible for the add/remove calls, as the data may change if they're nested, but for `fireValueChanged` I never really checked after going to this strategy. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272805838 From kevin.rushforth at oracle.com Mon Jul 24 23:17:44 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Jul 2023 16:17:44 -0700 Subject: CSS Transitions In-Reply-To: References: Message-ID: <7aa85f0c-64f1-5c46-9365-e6c49c064dca@oracle.com> This seems like it might be a useful feature, if enough applications would want to take advantage of it. If we proceed, I have a couple comments: * All of our existing CSS attributes use "-fx-" as a prefix. My preference would be to do that for transitions as well, absent a compelling reason to do otherwise. I note that you say in your design doc that transition "...is special and distinct from all other CSS properties". Is that the reason you didn't prefix it with "-fx-"? Is it a sufficient reason? * Initially, I wondered about your providing the CSS attributes without corresponding API on the scene graph objects in question, but I think that's a very good idea. * This will need a lot of testing since it touches the CSS attribute resolution mechanism. -- Kevin On 7/17/2023 12:23 PM, Michael Strau? wrote: > Here's an updated summary of the proposed feature: > https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a > > And here's the full implementation: > https://github.com/openjdk/jfx/pull/870 > > I'm interested in hearing from you whether you think this is a useful > feature and whether the proposed API is a good match for JavaFX. From michaelstrau2 at gmail.com Tue Jul 25 00:09:43 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 25 Jul 2023 02:09:43 +0200 Subject: CSS Transitions In-Reply-To: <7aa85f0c-64f1-5c46-9365-e6c49c064dca@oracle.com> References: <7aa85f0c-64f1-5c46-9365-e6c49c064dca@oracle.com> Message-ID: My comments below: On Tue, Jul 25, 2023 at 1:18?AM Kevin Rushforth wrote: > > This seems like it might be a useful feature, if enough applications > would want to take advantage of it. > > If we proceed, I have a couple comments: > > * All of our existing CSS attributes use "-fx-" as a prefix. My > preference would be to do that for transitions as well, absent a > compelling reason to do otherwise. I note that you say in your design > doc that transition "...is special and distinct from all other CSS > properties". Is that the reason you didn't prefix it with "-fx-"? Is it > a sufficient reason? The vendor prefix indicates a nonstandard/proprietary CSS property (see also https://www.w3.org/TR/CSS/#proprietary). That's the case for almost all JavaFX CSS properties (with one notable exception: "visibility"). However, "transition" is an exact implementation of the CSS standard, so there's no need to use a vendor prefix. I think that would be setting a wrong expectation, as CSS developers might think that "-fx-transition" works differently than a standard-conforming "transition" property, when in reality it's the same. > * Initially, I wondered about your providing the CSS attributes without > corresponding API on the scene graph objects in question, but I think > that's a very good idea. Note that if there's ever a compelling need to have an API on SG objects, this can be retrofitted. But I doubt that such an API would be useful. > * This will need a lot of testing since it touches the CSS attribute > resolution mechanism. Agreed. From psadhukhan at openjdk.org Tue Jul 25 05:30:09 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Jul 2023 05:30:09 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v5] In-Reply-To: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> Message-ID: > Due to transient datatype of scenePeer, it can become null which can result in NPE in scenarios where scene is continuously been reset and set, which warrants a null check, as is done in other places for the same variable. Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Locking for all shared resource between Swing and FX thread - Locking for all shared resource between Swing and FX thread ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1178/files - new: https://git.openjdk.org/jfx/pull/1178/files/f078f0a2..595f40d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1178&range=03-04 Stats: 116 lines in 1 file changed: 71 ins; 0 del; 45 mod Patch: https://git.openjdk.org/jfx/pull/1178.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1178/head:pull/1178 PR: https://git.openjdk.org/jfx/pull/1178 From psadhukhan at openjdk.org Tue Jul 25 05:30:09 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Jul 2023 05:30:09 GMT Subject: RFR: 8255248: NullPointerException in JFXPanel due to race condition in HostContainer [v3] In-Reply-To: <-s4dS2zIfiLXfcvOizJr3MchYehlBAb5QQLrdkP0HTk=.2c115342-294f-4b67-b50b-dd657f231de5@github.com> References: <6mIdOYYOJ-zVkDbMqYHcBpLl_03KuKvGaicG1FwmIrQ=.1c66d318-93a1-430e-bd62-f01842009264@github.com> <-s4dS2zIfiLXfcvOizJr3MchYehlBAb5QQLrdkP0HTk=.2c115342-294f-4b67-b50b-dd657f231de5@github.com> Message-ID: <6oMXk8NWybT3BdsoARRYXKqwYwvmsmKH8C6xfu2Qzps=.f634ce9e-6c95-4fa0-b34b-74a51b85caad@github.com> On Mon, 24 Jul 2023 17:15:18 GMT, Andy Goryachev wrote: >> This code is still accessing shared state (`dnd`, `pWidth`, `pHeight`, `scaleFactorX`, `scaleFactorY`). Without further analysis of when and where these values are written, it is unclear whether this is the right move. In general, allowing interleaved code execution on multiple threads is very hard to get right. Better to not do it, if at all possible. > > No doubt. `dnd`, even though it's commented as "// Accessed on EDT only" (line 152) seems to be accessed from FX thread via setFxEnabled line 866. > I tend to agree with @mstr2 that this component deserves a re-think and perhaps a re-design (starting with clear separation of which methods can be accessed from which thread, or adding explicit synchronization primitives). > I do recall seeing a number of issues with swing/fx interop in jdk8. I have synchronized other shared resources. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1178#discussion_r1273010135 From mstrauss at openjdk.org Wed Jul 26 03:54:33 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 26 Jul 2023 03:54:33 GMT Subject: RFR: 8311895: CSS Transitions Message-ID: Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). ### Example .button { -fx-background-color: dodgerblue; } .button:hover { -fx-background-color: red; -fx-scale-x: 1.1; -fx-scale-y: 1.1; transition: -fx-background-color 0.5s ease, -fx-scale-x 0.5s ease, -fx-scale-y 0.5s ease; } ------------- Commit messages: - Removed test - Removed trailing whitespace - Added manual test application - Redundant transitions are discarded - Refactoring - Intern parsed property names - Start transitions only for showing nodes - Refactoring - Added documentation - Refactoring - ... and 25 more: https://git.openjdk.org/jfx/compare/5aad0406...9cdeb498 Changes: https://git.openjdk.org/jfx/pull/870/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311895 Stats: 4249 lines in 40 files changed: 4214 ins; 1 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From kcr at openjdk.org Wed Jul 26 03:54:33 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jul 2023 03:54:33 GMT Subject: RFR: 8311895: CSS Transitions In-Reply-To: References: Message-ID: <_SC6jLf9--qBMC702yWRzuX3ofau5Kn9fXdFQhqV8bU=.08c45e20-1d99-4d47-9371-ef0fb295aeb2@github.com> On Tue, 16 Aug 2022 03:01:23 GMT, Michael Strau? wrote: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > If this is moved forward, it will need a CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-1636140569 From mstrauss at openjdk.org Wed Jul 26 04:02:58 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 26 Jul 2023 04:02:58 GMT Subject: Withdrawn: 8264591: HBox/VBox child widths pixel-snap to wrong value In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 19:57:17 GMT, Michael Strau? wrote: > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/445 From michaelstrau2 at gmail.com Wed Jul 26 04:37:26 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 26 Jul 2023 06:37:26 +0200 Subject: CSS Transitions In-Reply-To: <7aa85f0c-64f1-5c46-9365-e6c49c064dca@oracle.com> References: <7aa85f0c-64f1-5c46-9365-e6c49c064dca@oracle.com> Message-ID: > This seems like it might be a useful feature, if enough applications > would want to take advantage of it. I think this feature is mainly useful for style themes, because it allows creating subtle animations for state transitions (hover, click, etc). Applications will probably continue to use the javafx.animation framework for complex animations. From duke at openjdk.org Wed Jul 26 08:10:02 2023 From: duke at openjdk.org (duke) Date: Wed, 26 Jul 2023 08:10:02 GMT Subject: Withdrawn: (draf): ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: Message-ID: On Sun, 17 Jul 2022 20:59:46 GMT, John Hendrikx wrote: > This contains the following: > - Nested changes or invalidations using ExpressionHelper are delayed until the current emission completes > - This fixes odd change events being produced (with incorrect oldValue) > - Also fixes a bug in ExpressionHelper where a nested change would unlock the listener list early, which could cause a `ConcurrentModificationException` if a nested change was combined with a remove/add listener call > - A test for ExpressionHelper to verify the new behavior > - A test for all *Property and *Binding classes that verifies correct listener behavior at the API level (this tests gets 85% coverage on ExpressionHelper on its own, the only thing it is not testing is the locking behavior, which is not relevant at the API level). > - A fix for `WebColorFieldSkin` which triggered a nested change which used a flag to prevent an event loop (I've changed it now to match how `DoubleFieldSkin` and `IntegerFieldSkin` do it This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/837 From jhendrikx at openjdk.org Wed Jul 26 08:25:51 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Jul 2023 08:25:51 GMT Subject: RFR: JDK-8312528: Move Subscription interface from javafx.beans to javafx.util In-Reply-To: References: Message-ID: <4FpK1gR5P4s_ESk7AhnRWhvgGcdvng42GDPSSiy8yNA=.b79e2d70-af48-40f6-9afc-5bd56b32c90d@github.com> On Fri, 21 Jul 2023 22:40:17 GMT, Kevin Rushforth wrote: >> The Subscription interface is independent from FX beans and has uses unrelated to beans, it should therefore be placed in javafx.util. >> >> This should be fixed before [JDK-8311123](https://bugs.openjdk.org/browse/JDK-8311123) is released. > > Looks good. @kevinrushforth should I integrate this now? Not entirely sure on the timing. The CSR was approved. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1182#issuecomment-1651212743 From kevin.rushforth at oracle.com Wed Jul 26 11:09:53 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Jul 2023 04:09:53 -0700 Subject: CSS Transitions In-Reply-To: References: <7aa85f0c-64f1-5c46-9365-e6c49c064dca@oracle.com> Message-ID: inline On 7/24/2023 5:09 PM, Michael Strau? wrote: > My comments below: > > On Tue, Jul 25, 2023 at 1:18?AM Kevin Rushforth > wrote: >> This seems like it might be a useful feature, if enough applications >> would want to take advantage of it. >> >> If we proceed, I have a couple comments: >> >> * All of our existing CSS attributes use "-fx-" as a prefix. My >> preference would be to do that for transitions as well, absent a >> compelling reason to do otherwise. I note that you say in your design >> doc that transition "...is special and distinct from all other CSS >> properties". Is that the reason you didn't prefix it with "-fx-"? Is it >> a sufficient reason? > The vendor prefix indicates a nonstandard/proprietary CSS property (see > also https://www.w3.org/TR/CSS/#proprietary). That's the case for almost > all JavaFX CSS properties (with one notable exception: "visibility"). > However, "transition" is an exact implementation of the CSS standard, so > there's no need to use a vendor prefix. I think that would be setting a wrong > expectation, as CSS developers might think that "-fx-transition" works > differently than a standard-conforming "transition" property, when in reality > it's the same. OK, that seems like a good enough reason. >> * Initially, I wondered about your providing the CSS attributes without >> corresponding API on the scene graph objects in question, but I think >> that's a very good idea. > Note that if there's ever a compelling need to have an API on SG objects, > this can be retrofitted. But I doubt that such an API would be useful. You're probably right. -- Kevin >> * This will need a lot of testing since it touches the CSS attribute >> resolution mechanism. > Agreed. From kcr at openjdk.org Wed Jul 26 11:24:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jul 2023 11:24:50 GMT Subject: RFR: JDK-8312528: Move Subscription interface from javafx.beans to javafx.util In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 22:15:03 GMT, John Hendrikx wrote: > The Subscription interface is independent from FX beans and has uses unrelated to beans, it should therefore be placed in javafx.util. > > This should be fixed before [JDK-8311123](https://bugs.openjdk.org/browse/JDK-8311123) is released. Yes, this can be integrated now. Once done, you can backport it to `jfx21`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1182#issuecomment-1651587963 From duke at openjdk.org Wed Jul 26 11:28:51 2023 From: duke at openjdk.org (ctipper) Date: Wed, 26 Jul 2023 11:28:51 GMT Subject: RFR: 8090267: JFXPanel Input Problem In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 05:54:54 GMT, Prasanta Sadhukhan wrote: > When Japanse (IME on) is inputted to the TextFIeld, which is on JFXPanel, > small window for inputting appears on top-left side of screen > > ![image](https://github.com/openjdk/jfx/assets/43534309/65833d59-528e-4087-9992-9f86b8b8c47f) > > For swing-interop case, WmImeStartComposition starts composition in native ImmSetCompositionWindow window as "m_useNativeCompWindow" below is true for FX > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3957 > > m_useNativeCompWindow is true because during sun.awt.im.InputContext#focusGained() calls activateInputMethod which calls WInputMethod.activate() which calls haveActiveClient() which checks for > clientComponent.getInputMethodRequests(). > Now, in JFXPanel, getInputMethodRequests() returns null as setEmbeddedScene() is not called yet. > Since getInputMethodRequests() returns null, haveActiveClient() is false which calls enableNativeIME() with 1 [thereby native composition window is enabled] > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java#L316 > > Proposed fix is to ensure there is an active client "initially" so that enableNativeIME() is called with 0 and no native compostion window is shown. > getInputMethodRequests() is called in setEmbeddedScene() so as to make sure getInputMethodRequest() is initialised to correct "InputMethodSupport.InputMethodRequestsAdapter.fxRequests" object and not NULL. > > AFter fix > ![image](https://github.com/openjdk/jfx/assets/43534309/ec3d8343-9295-4950-885b-f9983b9b017a) I'm a client side developer trying to add a custom input method event handler to my app and I have noticed this problem on Windows with the native client. These APIs don't seem to have an great deal of online documentation and I can't even get it to work in macOS. Sorry but I don't have privileges for JIRA. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1169#issuecomment-1651237983 From jhendrikx at openjdk.org Wed Jul 26 11:42:53 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Jul 2023 11:42:53 GMT Subject: Integrated: JDK-8312528: Move Subscription interface from javafx.beans to javafx.util In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 22:15:03 GMT, John Hendrikx wrote: > The Subscription interface is independent from FX beans and has uses unrelated to beans, it should therefore be placed in javafx.util. > > This should be fixed before [JDK-8311123](https://bugs.openjdk.org/browse/JDK-8311123) is released. This pull request has now been integrated. Changeset: cc57fb51 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/cc57fb51a9409f5d2a6d2ce8dcd3878d48f9cfc9 Stats: 20 lines in 12 files changed: 9 ins; 7 del; 4 mod 8312528: Move Subscription interface from javafx.beans to javafx.util Reviewed-by: nlisker, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1182 From jhendrikx at openjdk.org Wed Jul 26 11:59:12 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Jul 2023 11:59:12 GMT Subject: [jfx21] RFR: 8312528: Move Subscription interface from javafx.beans to javafx.util Message-ID: <316bOoc1VgJt4e6tTZsrgYVjBY4xYo6Da_S1h8JVxqs=.9a12a039-7a08-4286-8692-993ce1dd99b0@github.com> Backport of https://bugs.openjdk.org/browse/JDK-8312529 ------------- Commit messages: - Backport cc57fb51a9409f5d2a6d2ce8dcd3878d48f9cfc9 Changes: https://git.openjdk.org/jfx/pull/1185/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312528 Stats: 20 lines in 12 files changed: 9 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1185.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1185/head:pull/1185 PR: https://git.openjdk.org/jfx/pull/1185 From kcr at openjdk.org Wed Jul 26 12:03:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jul 2023 12:03:48 GMT Subject: [jfx21] RFR: 8312528: Move Subscription interface from javafx.beans to javafx.util In-Reply-To: <316bOoc1VgJt4e6tTZsrgYVjBY4xYo6Da_S1h8JVxqs=.9a12a039-7a08-4286-8692-993ce1dd99b0@github.com> References: <316bOoc1VgJt4e6tTZsrgYVjBY4xYo6Da_S1h8JVxqs=.9a12a039-7a08-4286-8692-993ce1dd99b0@github.com> Message-ID: On Wed, 26 Jul 2023 11:52:04 GMT, John Hendrikx wrote: > Backport of https://bugs.openjdk.org/browse/JDK-8312529 Looks good. Skara marked it as `clean`. It is approved in JBS for a late Enhancement to `jfx21`, so you can integrate when ready. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1185#pullrequestreview-1547567065 From jhendrikx at openjdk.org Wed Jul 26 12:11:48 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Jul 2023 12:11:48 GMT Subject: [jfx21] Integrated: 8312528: Move Subscription interface from javafx.beans to javafx.util In-Reply-To: <316bOoc1VgJt4e6tTZsrgYVjBY4xYo6Da_S1h8JVxqs=.9a12a039-7a08-4286-8692-993ce1dd99b0@github.com> References: <316bOoc1VgJt4e6tTZsrgYVjBY4xYo6Da_S1h8JVxqs=.9a12a039-7a08-4286-8692-993ce1dd99b0@github.com> Message-ID: On Wed, 26 Jul 2023 11:52:04 GMT, John Hendrikx wrote: > Backport of https://bugs.openjdk.org/browse/JDK-8312529 This pull request has now been integrated. Changeset: 6095445a Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/6095445a8aeb6f9c5b1cd68ecf682b1734673a95 Stats: 20 lines in 12 files changed: 9 ins; 7 del; 4 mod 8312528: Move Subscription interface from javafx.beans to javafx.util Reviewed-by: kcr Backport-of: cc57fb51a9409f5d2a6d2ce8dcd3878d48f9cfc9 ------------- PR: https://git.openjdk.org/jfx/pull/1185 From duke at openjdk.org Wed Jul 26 14:41:50 2023 From: duke at openjdk.org (leewyatt) Date: Wed, 26 Jul 2023 14:41:50 GMT Subject: RFR: 8311895: CSS Transitions In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 03:01:23 GMT, Michael Strau? wrote: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Wow, replacing some Java code with CSS can make the Java code more focused on business logic, making it much cleaner. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-1651945492 From Thorsten_Fischer at gmx.de Wed Jul 26 23:09:39 2023 From: Thorsten_Fischer at gmx.de (Thorsten Fischer) Date: Thu, 27 Jul 2023 01:09:39 +0200 Subject: AW: JavaFX does not recover after graphic card driver crash In-Reply-To: <1MXXyP-1qPmU73Pg7-00YzdK@mail.gmx.net> References: <1MXXyP-1qPmU73Pg7-00YzdK@mail.gmx.net> Message-ID: <1MQvD5-1qD3PL10kx-00O2Pl@mail.gmx.net> I now opened a bug report for my issue. But as I'm trying to figure out the implementation of the D3D pipeline I found two things: 1. Only somewhat related to my issue, but I found that the existing recovery method for D3DERR_DEVICELOST / D3DERR_DEVICENOTRESET is not working when a device lost error is forced via the command line "dxcap -forcetdr". To reproduce: just run any JavaFX app with prism.verbose and run the command (in an admin console). The window will stay white and D3DContext::testLostStateAndReset : D3DERR_DEVICELOST is printed over and over. I'm unsure if this test method is valid, but regardless: the app does not come into the D3DERR_DEVICENOTRESET state and therefore nResetDevice will not be called. When I'm chaning the implementation to if (hr == D3DERR_DEVICELOST) { // Reinitialize the D3DPipeline. This will dispose and recreate // the resource factory and context for each adapter. D3DPipeline.getInstance().reinitialize(); } then rendering works again. 2. D3DContextInit.cc seem to lack the implementation for D3D9Ex to call ResetEx But as Reset and ResetEx behave differently ("Unlike previous versions of DirectX, calling IDirect3DDevice9Ex::ResetEx does not cause surfaces, textures or state information to be lost.", regarding to this doc https://learn.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-idirect3ddevice9ex-resetex), I'm not sure if ResetEx should be called instead of Reset. Von: Thorsten Fischer Gesendet: Freitag, 21. Juli 2023 10:48 An: openjfx-dev at openjdk.org Betreff: JavaFX does not recover after graphic card driver crash Hi all, first off all I want to say ?thank you? to everyone in this community for all the effort you put in. I'm using JavaFX for years now and I'm really happy to work with it :) I have the following issue/question: One of my customers experiences an application crash when running their JavaFX application for a longer period on a notebook with integrated Intel graphics. First of all, I think JavaFX does not cause the issue, but is rather affected by it. We built a workaround in JavaFX, but I'd like to discuss what a good solution would look like, so that it can be integrated into the JFX code base. So, randomly between a couple of days to about 3 weeks the graphic card driver crashes. In the Windows (10) event log you can read: "Display driver igfx stopped responding and has successfully recovered.". In the console of the app it says: "D3DContext::testLostStateAndReset : Unknown D3D error 0x88760874". The app then just shows a black screen and keeps printing this error over and over to the console (rendering is triggered regularly in this app) and never recovers, even though the driver has been recovered and the whole system is running and is usable (again). The error code 0x88760874 translates to D3DERR_DEVICEHUNG (https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3derr), what corresponds to the error in the Windows event log. Now our initial workaround (within D3DContext.java#testLostStateAndReset) is basically the same as for D3DERR_DEVICEREMOVED, but with a loop to give the OS time to recover: ?????????? public static final int D3DERR_DEVICEHUNG??? ?? = 0X88760874; ?????????? ?????????? and at the end: ?????????? ??????????????????????????????? if (hr == D3DERR_DEVICEHUNG) { ??????????????????????????????? setLost(); ??????????????????????????????? long retryMillis = TimeUnit.MINUTES.toMillis(5); ??????????????????????????????? long sleepingMillis = TimeUnit.SECONDS.toMillis(1); ??????????????????????????????? for (int i = 0; i < retryMillis; i += sleepingMillis) { ????????????????????????????????????????? int cooperativeLevel = D3DResourceFactory.nTestCooperativeLevel(pContext); ????????????????????????????????????????? System.err.println("Checking Cooperative Level: " + cooperativeLevel); ????????????????????????????????????????? if (cooperativeLevel == D3D_OK) { ???????????????????????????????????????????????????? break; ????????????????????????????????????????? } else { ????????????????????????????????????????? ?????????? try { ??????????????????????????????????????????????????????????????? Thread.sleep(sleepingMillis); ???????????????????????????????????????????????????? } catch (InterruptedException e) { ??????????????????????????????????????????????????????????????? e.printStackTrace(); ???????????????????????????????????????????????????? } ????????????????????????????????????????? } ??????????????????????????????? } ??????????????????????????????? // reinitialize after 5 mins anyway, even if result is not OK. ??????????????????????????????? // Reinitialize the D3DPipeline. This will dispose and recreate ??????????????????????????????? // the resource factory and context for each adapter. ??????????????????????????????? D3DPipeline.getInstance().reinitialize(); ???????????????????? } Yesterday we experienced with this workaround, that the app did actually recover after 20 seconds. The System.err output generated inside the loop only showed again the D3DERR_DEVICEHUNG error code, and after 20 sec. console showed the initialization output. Very obviously Thread.sleep is not a good solution. To avoid it I thought about introducing another flag like isLost (-> "isHung") and ???????????????????? if (hr == D3DERR_DEVICEHUNG) { ??????????????????????????????? setLost(); ??????????????????????????????? setHung(); ???????????????????? } ???????????????????? ???????????????????? if (isHung && hr == D3D_OK) { ??????????????????????????????? isLost = false; // ? ??????????????????????????????? isHung = false; ??????????????????????????????? ??????????? // Reinitialize the D3DPipeline. This will dispose and recreate ??????????? // the resource factory and context for each adapter. ??????????? D3DPipeline.getInstance().reinitialize(); ???????????????????? } ???????????????????? ???????????????????? But before I continue with this direction (and because it takes weeks to reproduce this): Can anybody confidently tell me what a better/good solution may look like? Thank you, Thorsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Thu Jul 27 03:44:10 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 27 Jul 2023 03:44:10 GMT Subject: RFR: 8313227: Correct attenuation indicator for removed lights Message-ID: A simple fix of changing the attenuation toggle from 1 to 0 for removed lights. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jfx/pull/1186/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1186&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313227 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1186.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1186/head:pull/1186 PR: https://git.openjdk.org/jfx/pull/1186 From nlisker at openjdk.org Thu Jul 27 03:47:46 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 27 Jul 2023 03:47:46 GMT Subject: RFR: 8313227: Correct attenuation indicator for removed lights In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 03:39:06 GMT, Nir Lisker wrote: > A simple fix of changing the attenuation toggle from 1 to 0 for removed lights. @kevinrushforth I think that this is simple enough to be able to get into RDP1. There is some performance improvement regained here that was lost in one of my previous enhancements because of my mistake of setting this parameter to 1. I think that 1 reviewer is enough. By the way, the lighting in the LightingSample test application looks a bit off to me (regardless of this patch). It's as if the point and spot lights are too dim even at close range. Do you also notice that? Might need to look at previous revisions to see when it started, ------------- PR Comment: https://git.openjdk.org/jfx/pull/1186#issuecomment-1652865471 From psadhukhan at openjdk.org Thu Jul 27 13:55:49 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Jul 2023 13:55:49 GMT Subject: RFR: 8090267: JFXPanel Input Problem In-Reply-To: References: Message-ID: <2wChHd-X7Zs12QnwiSL9FWQtYQDhTeob6gK-g9RqaEg=.1cb0d412-f768-4dbc-8e42-38e30e83fc06@github.com> On Tue, 4 Jul 2023 05:54:54 GMT, Prasanta Sadhukhan wrote: > When Japanse (IME on) is inputted to the TextFIeld, which is on JFXPanel, > small window for inputting appears on top-left side of screen > > ![image](https://github.com/openjdk/jfx/assets/43534309/65833d59-528e-4087-9992-9f86b8b8c47f) > > For swing-interop case, WmImeStartComposition starts composition in native ImmSetCompositionWindow window as "m_useNativeCompWindow" below is true for FX > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3957 > > m_useNativeCompWindow is true because during sun.awt.im.InputContext#focusGained() calls activateInputMethod which calls WInputMethod.activate() which calls haveActiveClient() which checks for > clientComponent.getInputMethodRequests(). > Now, in JFXPanel, getInputMethodRequests() returns null as setEmbeddedScene() is not called yet. > Since getInputMethodRequests() returns null, haveActiveClient() is false which calls enableNativeIME() with 1 [thereby native composition window is enabled] > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java#L316 > > Proposed fix is to ensure there is an active client "initially" so that enableNativeIME() is called with 0 and no native compostion window is shown. > getInputMethodRequests() is called in setEmbeddedScene() so as to make sure getInputMethodRequest() is initialised to correct "InputMethodSupport.InputMethodRequestsAdapter.fxRequests" object and not NULL. > > AFter fix > ![image](https://github.com/openjdk/jfx/assets/43534309/ec3d8343-9295-4950-885b-f9983b9b017a) ping? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1169#issuecomment-1653674172 From psadhukhan at openjdk.org Thu Jul 27 13:55:52 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Jul 2023 13:55:52 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Tue, 11 Jul 2023 07:58:07 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into JDK-8274932 > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8274932 > - Fix to get correct scale in secondary monitor > - Set stage scale in FX thread > - Set stage scale in FX thread > - Set stage scale in FX thread > - 8274932: Render scales in EmbeddedWindow are not properly updated anyone for 2nd reviewer please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1653673067 From angorya at openjdk.org Thu Jul 27 17:02:58 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jul 2023 17:02:58 GMT Subject: RFR: 8090267: JFXPanel Input Problem In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 05:54:54 GMT, Prasanta Sadhukhan wrote: > When Japanse (IME on) is inputted to the TextFIeld, which is on JFXPanel, > small window for inputting appears on top-left side of screen > > ![image](https://github.com/openjdk/jfx/assets/43534309/65833d59-528e-4087-9992-9f86b8b8c47f) > > For swing-interop case, WmImeStartComposition starts composition in native ImmSetCompositionWindow window as "m_useNativeCompWindow" below is true for FX > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3957 > > m_useNativeCompWindow is true because during sun.awt.im.InputContext#focusGained() calls activateInputMethod which calls WInputMethod.activate() which calls haveActiveClient() which checks for > clientComponent.getInputMethodRequests(). > Now, in JFXPanel, getInputMethodRequests() returns null as setEmbeddedScene() is not called yet. > Since getInputMethodRequests() returns null, haveActiveClient() is false which calls enableNativeIME() with 1 [thereby native composition window is enabled] > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java#L316 > > Proposed fix is to ensure there is an active client "initially" so that enableNativeIME() is called with 0 and no native compostion window is shown. > getInputMethodRequests() is called in setEmbeddedScene() so as to make sure getInputMethodRequest() is initialised to correct "InputMethodSupport.InputMethodRequestsAdapter.fxRequests" object and not NULL. > > AFter fix > ![image](https://github.com/openjdk/jfx/assets/43534309/ec3d8343-9295-4950-885b-f9983b9b017a) I would love to review this, but for some reason, I could not get Japanese IME to work on my windows 11... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1169#issuecomment-1654006525 From jhendrikx at openjdk.org Thu Jul 27 17:52:53 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jul 2023 17:52:53 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Tue, 11 Jul 2023 07:58:07 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into JDK-8274932 > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8274932 > - Fix to get correct scale in secondary monitor > - Set stage scale in FX thread > - Set stage scale in FX thread > - Set stage scale in FX thread > - 8274932: Render scales in EmbeddedWindow are not properly updated This is how I understand this works: The `JFXPanel` makes use of an `EmbeddedWindow` that is a subclass of `Window`. This window listens to its `showing` property, and when it becomes visible will call `updateOutputScales`; this will in turn set the (correct?) render scales. Now the above fix seems to 2nd guess this logic, and overrides these values with render scales it gets from Swing/AWT (note that it didn't do this before). So, my questions: - If JFXPanel never called setRenderScale before, was the JFXPanel completely broken when used on monitors that are not set at 100% scale? Did they update correctly when moved between monitors? I get the impression that it sort of worked, except for this edge case. - If it wasn't completely broken, then why is this fix needed? Shouldn't `Window` already detect that it has become visible (with its `showing` listener) and update the render scales using the `updateOutputScales` method? In other words, isn't this a bug that perhaps needs to be fixed in `Window`s detection of when it should be updating the output scales? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1654113576 From kcr at openjdk.org Thu Jul 27 22:10:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Jul 2023 22:10:51 GMT Subject: RFR: 8313227: Correct attenuation indicator for removed lights In-Reply-To: References: Message-ID: <5cpTZ4avxPsJ3GMl4FwaxaTIgYOMFx-I1pdUMBNE83k=.2c7e0107-9327-4af8-bd46-9c5846928c66@github.com> On Thu, 27 Jul 2023 03:44:56 GMT, Nir Lisker wrote: > @kevinrushforth I think that this is simple enough to be able to get into RDP1. There is some performance improvement regained here that was lost in one of my previous enhancements because of my mistake of setting this parameter to 1. > > I think that 1 reviewer is enough. Yes, I agree that a single reviewer should be fine. This seems a reasonable candidate to backport to `jfx21` during RDP1 (no approval beyond the code review of the backport is needed). > By the way, the lighting in the LightingSample test application looks a bit off to me (regardless of this patch). It's as if the point and spot lights are too dim even at close range. Do you also notice that? Might need to look at previous revisions to see when it started, I'll take a quick look on both Mac and Windows and let you know what I find. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1186#issuecomment-1654647647 From kcr at openjdk.org Thu Jul 27 23:44:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Jul 2023 23:44:49 GMT Subject: RFR: 8313227: Correct attenuation indicator for removed lights In-Reply-To: <5cpTZ4avxPsJ3GMl4FwaxaTIgYOMFx-I1pdUMBNE83k=.2c7e0107-9327-4af8-bd46-9c5846928c66@github.com> References: <5cpTZ4avxPsJ3GMl4FwaxaTIgYOMFx-I1pdUMBNE83k=.2c7e0107-9327-4af8-bd46-9c5846928c66@github.com> Message-ID: On Thu, 27 Jul 2023 22:07:40 GMT, Kevin Rushforth wrote: > > By the way, the lighting in the LightingSample test application looks a bit off to me (regardless of this patch). It's as if the point and spot lights are too dim even at close range. Do you also notice that? Might need to look at previous revisions to see when it started, > > I'll take a quick look on both Mac and Windows and let you know what I find. Without attenuation, it looks fine to me on both OpenGL and D3D. When I turn on attenuation, it seems like it is attenuated more quickly (and thus dimmer) than I might expect, but I can't be sure. It might be worth checking it against earlier versions (so might need to comment out SpotLight and DirectionalLight so you can go back far enough). It's not related to this PR, though, so I'll approve it now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1186#issuecomment-1654764621 From kcr at openjdk.org Thu Jul 27 23:44:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Jul 2023 23:44:47 GMT Subject: RFR: 8313227: Correct attenuation indicator for removed lights In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 03:39:06 GMT, Nir Lisker wrote: > A simple fix of changing the attenuation toggle from 1 to 0 for removed lights. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1186#pullrequestreview-1551015235 From nlisker at openjdk.org Fri Jul 28 00:03:51 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 28 Jul 2023 00:03:51 GMT Subject: Integrated: 8313227: Correct attenuation indicator for removed lights In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 03:39:06 GMT, Nir Lisker wrote: > A simple fix of changing the attenuation toggle from 1 to 0 for removed lights. This pull request has now been integrated. Changeset: b323db26 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/b323db262906853afbdec7a747f3b2f5b6593b9b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8313227: Correct attenuation indicator for removed lights Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1186 From nlisker at openjdk.org Fri Jul 28 00:18:59 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 28 Jul 2023 00:18:59 GMT Subject: [jfx21] RFR: 8313227: Correct attenuation indicator for removed lights Message-ID: Backport of commit [b323db26](https://github.com/openjdk/jfx/commit/b323db262906853afbdec7a747f3b2f5b6593b9b) (PR https://github.com/openjdk/jfx/pull/1186) ------------- Commit messages: - Backport b323db262906853afbdec7a747f3b2f5b6593b9b Changes: https://git.openjdk.org/jfx/pull/1187/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1187&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313227 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1187.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1187/head:pull/1187 PR: https://git.openjdk.org/jfx/pull/1187 From psadhukhan at openjdk.org Fri Jul 28 03:55:48 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 28 Jul 2023 03:55:48 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 27 Jul 2023 17:50:11 GMT, John Hendrikx wrote: > This is how I understand this works: > > The `JFXPanel` makes use of an `EmbeddedWindow` that is a subclass of `Window`. This window listens to its `showing` property, and when it becomes visible will call `updateOutputScales`; this will in turn set the (correct?) render scales. > > Now the above fix seems to 2nd guess this logic, and overrides these values with render scales it gets from Swing/AWT (note that it didn't do this before). > > So, my questions: > > * If JFXPanel never called setRenderScale before, was the JFXPanel completely broken when used on monitors that are not set at 100% scale? Did they update correctly when moved between monitors? I get the impression that it sort of worked, except for this edge case. > > * If it wasn't completely broken, then why is this fix needed? Shouldn't `Window` already detect that it has become visible (with its `showing` listener) and update the render scales using the `updateOutputScales` method? In other words, isn't this a bug that perhaps needs to be fixed in `Window`s detection of when it should be updating the output scales? I think it is broken...See [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) I am not sure if it might be a bug in FX Embedded `Window` s detection logic and scale updation logic, might be FX windows-graphics/toolkit team can share their thoughts but I guess it's not as otherwise we will get lot more issues and not just in JFXPanel. Also, JFXPanel uses `GraphicsEnvironment.getLocalGraphicsEnvironment(). getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX()` which only works for primary screen and will not work if secondary screen has different scale, so that needs to be fixed in my opinion, which is being done in this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1654959756 From jpereda at openjdk.org Fri Jul 28 09:18:01 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 28 Jul 2023 09:18:01 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache Message-ID: This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. I've tested successfully such scenario on Linux, Mac and Windows. ------------- Commit messages: - Add a file lock to cache dir Changes: https://git.openjdk.org/jfx/pull/1188/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307536 Stats: 20 lines in 1 file changed: 18 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1188.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1188/head:pull/1188 PR: https://git.openjdk.org/jfx/pull/1188 From jhendrikx at openjdk.org Fri Jul 28 09:31:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Jul 2023 09:31:49 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Tue, 11 Jul 2023 07:58:07 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into JDK-8274932 > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8274932 > - Fix to get correct scale in secondary monitor > - Set stage scale in FX thread > - Set stage scale in FX thread > - Set stage scale in FX thread > - 8274932: Render scales in EmbeddedWindow are not properly updated I've taken a deeper look at this problem, and tried fixing the problem in JDK-8222209 as well as I think they're closely related. The problem IMHO is that the scaling actually is picked up properly when the JFXPanel moves to another screen, but it fails to repaint the Scene. I found what I think is a simple fix, that also does not require manually changing the render scales (they are being updated automatically). Please evaluate this PR: https://github.com/openjdk/jfx/pull/1189 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1655370607 From jhendrikx at openjdk.org Fri Jul 28 09:36:02 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Jul 2023 09:36:02 GMT Subject: RFR: JDK-8222209: Repaint properly when JFXPanel moves to another screen Message-ID: Alternative fix for JFXPanel issues. I added an extra line to **really** trigger the repainting in `EmbeddedScene`. This was inspired by this code in `GlassWindowEventHandler` which reacts to `WindowEvent.RESCALE`. It not only calls `entireSceneNeedsRepaint` but also `updateSceneState`. Snippet: case WindowEvent.RESCALE: { float outScaleX = window.getOutputScaleX(); float outScaleY = window.getOutputScaleY(); stage.stageListener.changedScale(outScaleX, outScaleY); // We need to sync the new scales for painting QuantumToolkit.runWithRenderLock(() -> { GlassScene scene = stage.getScene(); if (scene != null) { scene.entireSceneNeedsRepaint(); scene.updateSceneState(); } return null; }); break; } ------------- Commit messages: - Repaint properly when JFXPanel moves to another screen Changes: https://git.openjdk.org/jfx/pull/1189/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8222209 Stats: 20 lines in 2 files changed: 2 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1189.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1189/head:pull/1189 PR: https://git.openjdk.org/jfx/pull/1189 From kcr at openjdk.org Fri Jul 28 11:16:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jul 2023 11:16:46 GMT Subject: [jfx21] RFR: 8313227: Correct attenuation indicator for removed lights In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 00:13:16 GMT, Nir Lisker wrote: > Backport of commit [b323db26](https://github.com/openjdk/jfx/commit/b323db262906853afbdec7a747f3b2f5b6593b9b) (PR https://github.com/openjdk/jfx/pull/1186) Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1187#pullrequestreview-1551897306 From sykora at openjdk.org Fri Jul 28 11:49:51 2023 From: sykora at openjdk.org (Joeri Sykora) Date: Fri, 28 Jul 2023 11:49:51 GMT Subject: RFR: JDK-8310681: Update WebKit to 616.1 [v2] In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 12:43:57 GMT, Hima Bindu Meda wrote: >> Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). >> Verified the updated version build, sanity tests and stability. No issues have been observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove check for PLATFORM(JAVA) as the change corresponds to webkit upstream After upgrading our version of python from 3.7 to 3.8 all builds and tests completed successfully. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1180#pullrequestreview-1551971281 From hmeda at openjdk.org Fri Jul 28 12:50:51 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 28 Jul 2023 12:50:51 GMT Subject: Integrated: JDK-8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 15:36:28 GMT, Hima Bindu Meda wrote: > Updated JavaFX Webkit to GTK WebKit 2.40 (616.1). > Verified the updated version build, sanity tests and stability. No issues have been observed. This pull request has now been integrated. Changeset: 2dc699a8 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/2dc699a8661fb23040c9f8e3905713229e615816 Stats: 381300 lines in 5888 files changed: 214309 ins; 124154 del; 42837 mod 8310681: Update WebKit to 616.1 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1180 From nlisker at openjdk.org Fri Jul 28 12:57:47 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 28 Jul 2023 12:57:47 GMT Subject: [jfx21] Integrated: 8313227: Correct attenuation indicator for removed lights In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 00:13:16 GMT, Nir Lisker wrote: > Backport of commit [b323db26](https://github.com/openjdk/jfx/commit/b323db262906853afbdec7a747f3b2f5b6593b9b) (PR https://github.com/openjdk/jfx/pull/1186) This pull request has now been integrated. Changeset: 86e71094 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/86e71094b54901487b93c53eb5bcaf6bf9bee92b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8313227: Correct attenuation indicator for removed lights Reviewed-by: kcr Backport-of: b323db262906853afbdec7a747f3b2f5b6593b9b ------------- PR: https://git.openjdk.org/jfx/pull/1187 From hmeda at openjdk.org Fri Jul 28 13:28:29 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 28 Jul 2023 13:28:29 GMT Subject: [jfx21u] RFR: 8310681: Update WebKit to 616.1 Message-ID: Backport of webkit update to v616.1. Clean Backport ------------- Commit messages: - Backport 2dc699a8661fb23040c9f8e3905713229e615816 Changes: https://git.openjdk.org/jfx21u/pull/3/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=3&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310681 Stats: 381300 lines in 5888 files changed: 214309 ins; 124154 del; 42837 mod Patch: https://git.openjdk.org/jfx21u/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx21u/pull/3 From kcr at openjdk.org Fri Jul 28 13:28:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jul 2023 13:28:49 GMT Subject: [jfx21u] RFR: 8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 13:06:48 GMT, Hima Bindu Meda wrote: > Backport of webkit update to v616.1. Clean Backport Since this has been approved for inclusion in `jfx21u` in JBS, and the backport is clean, no review of the PR is needed prior to integrating it. ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/3#issuecomment-1655673770 From hmeda at openjdk.org Fri Jul 28 13:35:56 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 28 Jul 2023 13:35:56 GMT Subject: [jfx21u] Integrated: 8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 13:06:48 GMT, Hima Bindu Meda wrote: > Backport of webkit update to v616.1. Clean Backport This pull request has now been integrated. Changeset: 104e0584 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx21u/commit/104e0584b516536ad829a560e87f6eb71513a84f Stats: 381300 lines in 5888 files changed: 214309 ins; 124154 del; 42837 mod 8310681: Update WebKit to 616.1 Backport-of: 2dc699a8661fb23040c9f8e3905713229e615816 ------------- PR: https://git.openjdk.org/jfx21u/pull/3 From kcr at openjdk.org Fri Jul 28 14:24:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jul 2023 14:24:16 GMT Subject: [jfx21u] Integrated: Merge jfx:jfx21 Message-ID: Merge `jfx:jfx21` branch into `jfx21u:master` (21.0.1 is a superset of 21). ------------- Commit messages: - Merge remote-tracking branch 'jfx/jfx21' into merge-2023-07-28 - 8313227: Correct attenuation indicator for removed lights - 8312528: Move Subscription interface from javafx.beans to javafx.util The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx21u/pull/4/files Stats: 21 lines in 13 files changed: 9 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jfx21u/pull/4.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/4/head:pull/4 PR: https://git.openjdk.org/jfx21u/pull/4 From kcr at openjdk.org Fri Jul 28 14:24:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jul 2023 14:24:16 GMT Subject: [jfx21u] Integrated: Merge jfx:jfx21 In-Reply-To: References: Message-ID: <7z5F03sF7WpyvKQwarr39Auu-DsIzUV8-rejQjNcdzs=.59afd81d-d313-410b-8446-bd96fefd7dca@github.com> On Fri, 28 Jul 2023 14:17:29 GMT, Kevin Rushforth wrote: > Merge `jfx:jfx21` branch into `jfx21u:master` (21.0.1 is a superset of 21). This pull request has now been integrated. Changeset: 68aa85ce Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/68aa85ce933e3e3551b7eacccf1853f84426a1fd Stats: 21 lines in 13 files changed: 9 ins; 7 del; 5 mod Merge ------------- PR: https://git.openjdk.org/jfx21u/pull/4 From angorya at openjdk.org Fri Jul 28 15:13:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Jul 2023 15:13:49 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:11:07 GMT, Jose Pereda wrote: > This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. > > This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. > > No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. > > I've tested successfully such scenario on Linux, Mac and Windows. Would it still fail if an earlier JVM tries to write to the cache dir? Just a wild idea: what if we double-check (the file hash?) after writing files or something like that? I know, that still won't help if an older JVM writes to the same dir... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1188#issuecomment-1655863051 From kcr at openjdk.org Sat Jul 29 14:46:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 29 Jul 2023 14:46:49 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:11:07 GMT, Jose Pereda wrote: > This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. > > This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. > > No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. > > I've tested successfully such scenario on Linux, Mac and Windows. Since there is no robust solution that work in the presence of an older JavaFX writing to the cache concurrently, I'm not sure it would be worth the complexity to further narrow the window, but @jperedadnr can comment on that. The proposed solution seems reasonable to me. I presume you've tested it? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1188#issuecomment-1656745632 From kcr at openjdk.org Sat Jul 29 14:52:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 29 Jul 2023 14:52:45 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 21:13:06 GMT, John Hendrikx wrote: > Incorporates documentation review comments from #1069. > > This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. Now that `Subscription` has moved to `javafx.util`, this PR can resume. You first need to merge in the latest master and fix any merge conflicts. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1177#issuecomment-1656746778 From kcr at openjdk.org Sat Jul 29 15:13:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 29 Jul 2023 15:13:49 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <7Ncyp0c3-e4p7THnFlZ5yOAJ8YrVaYGigiaw4PiCAmE=.649a959c-870f-412f-88e0-af24a566926c@github.com> On Fri, 28 Jul 2023 03:53:17 GMT, Prasanta Sadhukhan wrote: >> This is how I understand this works: >> >> The `JFXPanel` makes use of an `EmbeddedWindow` that is a subclass of `Window`. This window listens to its `showing` property, and when it becomes visible will call `updateOutputScales`; this will in turn set the (correct?) render scales. >> >> Now the above fix seems to 2nd guess this logic, and overrides these values with render scales it gets from Swing/AWT (note that it didn't do this before). >> >> So, my questions: >> >> - If JFXPanel never called setRenderScale before, was the JFXPanel completely broken when used on monitors that are not set at 100% scale? Did they update correctly when moved between monitors? I get the impression that it sort of worked, except for this edge case. >> >> - If it wasn't completely broken, then why is this fix needed? Shouldn't `Window` already detect that it has become visible (with its `showing` listener) and update the render scales using the `updateOutputScales` method? In other words, isn't this a bug that perhaps needs to be fixed in `Window`s detection of when it should be updating the output scales? > >> This is how I understand this works: >> >> The `JFXPanel` makes use of an `EmbeddedWindow` that is a subclass of `Window`. This window listens to its `showing` property, and when it becomes visible will call `updateOutputScales`; this will in turn set the (correct?) render scales. >> >> Now the above fix seems to 2nd guess this logic, and overrides these values with render scales it gets from Swing/AWT (note that it didn't do this before). >> >> So, my questions: >> >> * If JFXPanel never called setRenderScale before, was the JFXPanel completely broken when used on monitors that are not set at 100% scale? Did they update correctly when moved between monitors? I get the impression that it sort of worked, except for this edge case. >> >> * If it wasn't completely broken, then why is this fix needed? Shouldn't `Window` already detect that it has become visible (with its `showing` listener) and update the render scales using the `updateOutputScales` method? In other words, isn't this a bug that perhaps needs to be fixed in `Window`s detection of when it should be updating the output scales? > > I think it is broken...See [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) > I am not sure if it might be a bug in FX Embedded `Window` s detection logic and scale updation logic, might be FX windows-graphics/toolkit team can share their thoughts but I guess it's not as otherwise we will get lot more issues and not just in JFXPanel. > Also, JFXPanel uses `GraphicsEnvironment.getLocalGraphicsEnvironment(). getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX()` which only works for primary screen and will not work if secondary screen has different scale, so that needs to be fixed in my opinion, which is being done in this PR. @prsadhuk @hjohn I'll take a closer look early next week, but I think the best way forward might be for Prasanta to evaluate #1189 and, if the modified fix in that PR is what we want to use, update _this_ PR to include the change that adds the call to `updateSceneState()` and removes the explicit call to `Stage::setRenderScale[XY]`. Then add John as a contributor to this PR using `/contributor add`. We can then close [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) as a duplicate of [JDK-8274932](https://bugs.openjdk.org/browse/JDK-8274932). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1656755453 From kcr at openjdk.org Sat Jul 29 15:15:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 29 Jul 2023 15:15:44 GMT Subject: RFR: JDK-8222209: Repaint properly when JFXPanel moves to another screen In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:26:35 GMT, John Hendrikx wrote: > Alternative fix for JFXPanel issues. > > I added an extra line to **really** trigger the repainting in `EmbeddedScene`. This was inspired by this code in `GlassWindowEventHandler` which reacts to `WindowEvent.RESCALE`. It not only calls `entireSceneNeedsRepaint` but also `updateSceneState`. Snippet: > > case WindowEvent.RESCALE: { > float outScaleX = window.getOutputScaleX(); > float outScaleY = window.getOutputScaleY(); > stage.stageListener.changedScale(outScaleX, outScaleY); > // We need to sync the new scales for painting > QuantumToolkit.runWithRenderLock(() -> { > GlassScene scene = stage.getScene(); > if (scene != null) { > scene.entireSceneNeedsRepaint(); > scene.updateSceneState(); > } > return null; > }); > break; > } Moving this to Draft, since we will likely end up folding this into #1171 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1189#issuecomment-1656755682 From jpereda at openjdk.org Sun Jul 30 09:08:50 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 30 Jul 2023 09:08:50 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: <8GV4C88Q4F-Pl_mYo7GCjERQlaM_yInvbwXxSnzsIG8=.c4545cdb-9622-4ede-8ef6-553a295cbe2d@github.com> On Fri, 28 Jul 2023 09:11:07 GMT, Jose Pereda wrote: > This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. > > This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. > > No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. > > I've tested successfully such scenario on Linux, Mac and Windows. This PR tries to solve the issue of two (or more) concurrent attempts to do the same thing when different JavaFX applications are launched at the same time, in case the cache was empty (or gets cleaned for some reason), and I've tested successfully such scenario on Linux, Mac and Windows. The cache directory doesn't get permanently locked, but only for a short period of time, while a file is being copied to it from resources. Therefore, I don't think there should be any issue with old running JVMs. Typically all the access to the cache is done during the launch of an application, where native libraries are loaded. And if you remove the cache folder _after_ the application was launched, it will still continue working. If for any reason it needs to access the cache after that, as I said, it won't be locked. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1188#issuecomment-1657085702 From jpereda at openjdk.org Sun Jul 30 09:16:48 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 30 Jul 2023 09:16:48 GMT Subject: RFR: 8159048: Null PulseReciever in AbstractMasterTimer Message-ID: This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). ------------- Commit messages: - remove trailing whitespace - Check FX thread on animation and animationTimer public methods, including tests Changes: https://git.openjdk.org/jfx/pull/1167/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1167&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8159048 Stats: 268 lines in 4 files changed: 255 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/1167.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1167/head:pull/1167 PR: https://git.openjdk.org/jfx/pull/1167 From kcr at openjdk.org Sun Jul 30 09:16:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 30 Jul 2023 09:16:49 GMT Subject: RFR: 8159048: Null PulseReciever in AbstractMasterTimer In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 15:49:31 GMT, Jose Pereda wrote: > This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. > > This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. > > The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. > > Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). @jperedadnr In case you missed it, this PR is not `rfr` due to white space errors. At first glance, this looks like a good fix. Since this enforces a new threading restriction on existing animation methods, it will need a CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1167#issuecomment-1656735642 PR Comment: https://git.openjdk.org/jfx/pull/1167#issuecomment-1656736296 From jpereda at openjdk.org Sun Jul 30 10:20:43 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 30 Jul 2023 10:20:43 GMT Subject: RFR: 8159048: Null PulseReciever in AbstractMasterTimer In-Reply-To: References: Message-ID: On Sat, 29 Jul 2023 13:53:06 GMT, Kevin Rushforth wrote: >> This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. >> >> This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. >> >> The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. >> >> Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). > > At first glance, this looks like a good fix. Since this enforces a new threading restriction on existing animation methods, it will need a CSR. Thanks, @kevinrushforth, I've missed that, indeed. I've filed the CSR draft: https://bugs.openjdk.org/browse/JDK-8313378 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1167#issuecomment-1657100415 From mstrauss at openjdk.org Mon Jul 31 00:09:38 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 00:09:38 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Make TransitionEvent final ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/9cdeb498..8e46c89f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From jbhaskar at openjdk.org Mon Jul 31 06:09:55 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 31 Jul 2023 06:09:55 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 Message-ID: Issue: Some web worker tests fail to finish. Root Cause: sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. ------------- Commit messages: - 8313177: Web Workers timeout with Webkit 616.1 Changes: https://git.openjdk.org/jfx/pull/1191/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313177 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1191.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1191/head:pull/1191 PR: https://git.openjdk.org/jfx/pull/1191 From jbhaskar at openjdk.org Mon Jul 31 08:16:12 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 31 Jul 2023 08:16:12 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v2] In-Reply-To: References: Message-ID: > Issue: Some web worker tests fail to finish. > Root Cause: > sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Add test case for worker timeout ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1191/files - new: https://git.openjdk.org/jfx/pull/1191/files/79b00ca7..06d46695 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1191&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1191&range=00-01 Stats: 120 lines in 3 files changed: 120 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1191.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1191/head:pull/1191 PR: https://git.openjdk.org/jfx/pull/1191 From jhendrikx at openjdk.org Mon Jul 31 11:51:24 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 31 Jul 2023 11:51:24 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners [v2] In-Reply-To: References: Message-ID: > Incorporates documentation review comments from #1069. > > This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Use @implSpec tag - Merge branch 'master' of https://git.openjdk.org/jfx into feature/subscriptions-doc-improvements - Documentation improvements ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1177/files - new: https://git.openjdk.org/jfx/pull/1177/files/73fb1c64..7382af03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1177&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1177&range=00-01 Stats: 381838 lines in 5915 files changed: 214648 ins; 124341 del; 42849 mod Patch: https://git.openjdk.org/jfx/pull/1177.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1177/head:pull/1177 PR: https://git.openjdk.org/jfx/pull/1177 From kcr at openjdk.org Mon Jul 31 13:28:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 31 Jul 2023 13:28:53 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 08:16:12 GMT, Jay Bhaskar wrote: >> Issue: Some web worker tests fail to finish. >> Root Cause: >> sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Add test case for worker timeout @HimaBinduMeda Can you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1191#issuecomment-1658370092 From jhendrikx at openjdk.org Mon Jul 31 13:47:17 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 31 Jul 2023 13:47:17 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: Message-ID: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> On Mon, 31 Jul 2023 00:09:38 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). >> >> ### Example >> >> .button { >> -fx-background-color: dodgerblue; >> } >> >> .button:hover { >> -fx-background-color: red; >> -fx-scale-x: 1.1; >> -fx-scale-y: 1.1; >> >> transition: -fx-background-color 0.5s ease, >> -fx-scale-x 0.5s ease, >> -fx-scale-y 0.5s ease; >> } >> >> >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Make TransitionEvent final Some early feedback, it's a lot of code :) modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1719: > 1717: > 1718: jump-start > 1719: the interval starts with a rise point when the input progress value is 0 This has a span closing tag without an opening one modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1723: > 1721: > 1722: jump-end > 1723: the interval ends with a rise point when the input progress value is 1 This has a span closing tag without an opening one modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1727: > 1725: > 1726: jump-none > 1727: all rise points are within the open interval (0..1) This has a span closing tag without an opening one modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1732: > 1730: jump-both > 1731: the interval starts with a rise point when the input progress value is 0, > 1732: and ends with a rise point when the input progress value is 1 This has a span closing tag without an opening one modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 29: > 27: > 28: import javafx.animation.Interpolator; > 29: import javafx.css.StyleableProperty; minor: this is only imported for the Javadoc, but not actually used by code; you could consider using a fully qualified name in the javadoc modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 45: > 43: */ > 44: public record TransitionDefinition(String propertyName, Duration duration, > 45: Duration delay, Interpolator interpolator) { I see this is an internal class that makes use of `javafx.util.Duration`. I think it's not further exposed. I see a lot of calls getting the duration/delay which almost instantly converts the value to nano seconds. It might be an idea to use nanos here immediately (ie. use `long` in the constructor) and have the converter supply longs. modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 54: > 52: */ > 53: public TransitionDefinition(String propertyName, Duration duration, > 54: Duration delay, Interpolator interpolator) { I think you should not repeat the parameters here, just use: Suggestion: public TransitionDefinition { I would also move the "@throws" documentation tags to the record class definition modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinitionConverter.java line 77: > 75: } else { > 76: propertyName = "all"; > 77: } minor: could consider: Suggestion: String propertyName = parsedProperty != null ? parsedProperty.convert(null) : "all"; Same for the other variable initializer block below this one. modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinitionConverter.java line 111: > 109: Duration[] durations = null; > 110: Duration[] delays = null; > 111: Interpolator[] timingFunctions = null; minor: you could consider initializing these with empty arrays, which would make the checks later in the code simpler; however, if the `convertedValues` can hold `null`s for values, this won't work (I don't think it does though). This would also make initializing the variables short enough to be perhaps be done immediately: Duration delay = delays.length == 0 ? Duration.ZERO : delays[i % delays.length]; modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinitionCssMetaData.java line 63: > 61: private static final Duration[] DURATION_ZERO = new Duration[] { Duration.ZERO }; > 62: > 63: private static final Interpolator[] INTERPOLATOR_EASE = new Interpolator[] { InterpolatorConverter.CSS_EASE }; Careful, the array contents could still be modified modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinitionCssMetaData.java line 89: > 87: } > 88: }, > 89: new CssMetaData( "transition-duration", minor: Inconsistent spacing used for these properties Suggestion: new CssMetaData("transition-duration", modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 49: > 47: private final P property; > 48: private Interpolator interpolator; > 49: private long startTime, endTime, delay, duration; minor: If these are not in the standard unit (seconds), it might be good to clarify the unit used. It seems to be nano seconds. modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 66: > 64: */ > 65: @SuppressWarnings("unchecked") > 66: public static & StyleableProperty> TransitionTimer run( minor: this should either be a comment, or a complete javadoc modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 126: > 124: * @param forceStop if {@code true}, the timer is stopped unconditionally > 125: * @return {@code true} if the timer was cancelled or {@code timer} is {@code null}, > 126: * {@code false} otherwise minor: Suggestion: * @return {@code true} if the timer was cancelled, or {@code timer} is {@code null}, * otherwise {@code false} modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 157: > 155: */ > 156: private static void adjustReversingTimer(TransitionTimer existingTimer, TransitionTimer newTimer, > 157: TransitionDefinition transition, long now) { minor: This should either be a comment or a full javadoc (all tags present) modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 179: > 177: * The elapsed time is computed according to the CSS Transitions specification. > 178: */ > 179: private static & StyleableProperty> void fireTransitionEvent( minor: incomplete javadoc, change to comment? modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 206: > 204: * Gets the styleable property targeted by this {@code TransitionTimer}. > 205: */ > 206: public final P getProperty() { minor: incomplete javadoc, missing return tag modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 263: > 261: * when the transition is interrupted by another transition, or when it ends normally. > 262: */ > 263: public final void stop(EventType eventType) { minor: Incomplete javadoc modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 302: > 300: * After this method is called, the {@link #updating} flag is {@code false}. > 301: */ > 302: private boolean pollUpdating() { minor: Incomplete javadoc, missing return tag modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 311: > 309: * Gets the progress of this timer along the input progress axis, ranging from 0 to 1. > 310: */ > 311: private double getProgress() { minor: missing return tag modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 345: > 343: * > 344: * @param timer the other timer > 345: * @return {@code true} if the target values are equal, {@code false} otherwise minor: I think this is more common: Suggestion: * @return {@code true} if the target values are equal, otherwise {@code false} modules/javafx.graphics/src/main/java/com/sun/scenario/animation/StepInterpolator.java line 73: > 71: } > 72: > 73: if (t >= 0 && step < 0) { `t >= 0` always holds, perhaps the original `t` was meant here? The `t` parameter is re-assigned, which may be confusing. modules/javafx.graphics/src/main/java/com/sun/scenario/animation/StepInterpolator.java line 83: > 81: }; > 82: > 83: if (t <= 1 && step > jumps) { `t <= 1` is always true, perhaps the original `t` was intended here? See other comment. modules/javafx.graphics/src/main/java/com/sun/scenario/animation/StepInterpolator.java line 97: > 95: @Override > 96: public boolean equals(Object obj) { > 97: return obj instanceof StepInterpolator other minor: Perhaps make `StepInterpolator` `final` modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 305: > 303: * @since 22 > 304: */ > 305: public static Interpolator STEP_START = STEPS(1, StepPosition.START); Suggestion: public static final Interpolator STEP_START = STEPS(1, StepPosition.START); modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 312: > 310: * @since 22 > 311: */ > 312: public static Interpolator STEP_END = STEPS(1, StepPosition.END); Suggestion: public static final Interpolator STEP_END = STEPS(1, StepPosition.END); modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 319: > 317: * The output time value is determined by the {@link StepPosition}. > 318: * > 319: * @param intervals the number of intervals in the step interpolator minor: When I see a plural like `intervals` (or `employees`) I think of a list of objects. Perhaps `intervalCount` would be better? modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 325: > 323: * @since 22 > 324: */ > 325: public static Interpolator STEPS(int intervals, StepPosition position) { This doesn't specify what happens when `position` is `null`, and is also missing the restrictions on `intervals`. modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 678: > 676: LOGGER.finest("Expected \'\'"); > 677: } > 678: ParseException re = new ParseException("Expected \'\'",token, this); Suggestion: ParseException re = new ParseException("Expected ''", token, this); modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 1022: > 1020: default -> new ParsedValueImpl<>(key, null, true); > 1021: }; > 1022: } minor: No need for `else` (saves nesting) modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 3949: > 3947: > 3948: private ParsedValueImpl parseTransition(Term term) > 3949: throws ParseException{ Suggestion: throws ParseException { modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 3958: > 3956: if (term == null) { > 3957: break; > 3958: } else if (isEasingFunction(term.token)) { minor: No need for `else` Suggestion: } if (isEasingFunction(term.token)) { modules/javafx.graphics/src/main/java/javafx/css/StyleableBooleanProperty.java line 80: > 78: setValue(v); > 79: } > 80: I'm not sure how I feel about this; the changes made don't really seem to belong here. The `StyleableXXXProperty` classes are convenient helpers, but all that matters is that they are `StyleableProperty` implementations. There is no requirement to use the helpers. So what happens when a property defines their own helper, or implements `StyleableProperty` directly? Or if classes are refactored at some point and they decide to stop using these helpers? modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 43: > 41: public final class TransitionEvent extends Event { > 42: > 43: private static final long serialVersionUID = 20220820L; minor: may I suggest `1L` as in version 1? It's not an existing class that needs to be compatible with older implementations for which a version was derived by the compiler. modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 88: > 86: * @param eventType the event type > 87: * @param property the {@code StyleableProperty} that is targeted by the transition > 88: * @param elapsedTime the time that has elapsed since the transition has entered its active period Can property be `null`? Any restrictions on `elapsedTime`? modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 111: > 109: * not including the time spent in the delay phase. > 110: * > 111: * @return the elapsed time Any guarantees here? Can it be `null`, negative, zero, infinite? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8937: > 8935: * a running {@link TransitionTimer} with this {@code Node}. This allows the node > 8936: * to keep track of running timers that are targeting its properties. > 8937: */ minor: incomplete javadoc modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8951: > 8949: * when their {@link TransitionTimer} has completed. > 8950: */ > 8951: private void removeTransitionTimer(TransitionTimer timer) { minor: incomplete javadoc modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8960: > 8958: * Finds the transition timer that targets the specified {@code property}. > 8959: * > 8960: * @return the transition timer, or {@code null} minor: missing @param tag modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8968: > 8966: > 8967: for (TransitionTimer timer : transitionTimers) { > 8968: if (timer.getProperty() == property) { minor: this probably works, but I'd still use `equals` here ------------- PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-1554590248 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279184581 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279185366 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279185442 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279185777 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279195463 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279235400 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279197467 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279199846 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279204340 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279208647 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279209361 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279217008 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279222846 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279225319 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279226794 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279236379 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279237951 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279241079 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279242702 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279249222 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279251667 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279256926 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279258025 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279263450 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279266478 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279266767 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279271364 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279268169 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279273159 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279275071 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279276790 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279277822 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279295992 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279300672 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279303855 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279302999 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279308190 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279308636 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279309244 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279310798 From kcr at openjdk.org Mon Jul 31 14:58:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 31 Jul 2023 14:58:52 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:11:07 GMT, Jose Pereda wrote: > This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. > > This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. > > No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. > > I've tested successfully such scenario on Linux, Mac and Windows. Marked as reviewed by kcr (Lead). Thanks for the additional explanation. One more thing I realized is that there won't ever be a conflict between an old (without the fix) and a new (with the fix) JavaFX release, because the version number is included in the directory name. So this fix looks good to me. ------------- PR Review: https://git.openjdk.org/jfx/pull/1188#pullrequestreview-1554998526 PR Comment: https://git.openjdk.org/jfx/pull/1188#issuecomment-1658539339 From angorya at openjdk.org Mon Jul 31 16:51:58 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Jul 2023 16:51:58 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:11:07 GMT, Jose Pereda wrote: > This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. > > This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. > > No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. > > I've tested successfully such scenario on Linux, Mac and Windows. modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java line 312: > 310: try { > 311: if (!Files.exists(path)) { > 312: Files.copy(is, path); I noticed `is` is not closed (also in the original code). Would that be a problem? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1279606813 From angorya at openjdk.org Mon Jul 31 16:54:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Jul 2023 16:54:50 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:11:07 GMT, Jose Pereda wrote: > This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. > > This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. > > No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. > > I've tested successfully such scenario on Linux, Mac and Windows. modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java line 311: > 309: FileLock fileLock = fileChannel.lock()) { > 310: try { > 311: if (!Files.exists(path)) { This code would fail if the target file exists but has a 0 length, or any length other that the actual resource length, or with the right length but wrong content. Do we want to address these scenarios? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1279611539 From angorya at openjdk.org Mon Jul 31 17:03:55 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Jul 2023 17:03:55 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 11:51:24 GMT, John Hendrikx wrote: >> Incorporates documentation review comments from #1069. >> >> This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use @implSpec tag > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/subscriptions-doc-improvements > - Documentation improvements LvGtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1177#pullrequestreview-1555368201 From angorya at openjdk.org Mon Jul 31 17:05:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Jul 2023 17:05:49 GMT Subject: RFR: 8159048: Null PulseReciever in AbstractMasterTimer In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 15:49:31 GMT, Jose Pereda wrote: > This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. > > This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. > > The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. > > Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). minor: spelling in the title (Receiver) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1167#issuecomment-1658782142 From angorya at openjdk.org Mon Jul 31 17:15:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Jul 2023 17:15:50 GMT Subject: RFR: 8159048: Null PulseReciever in AbstractMasterTimer In-Reply-To: References: Message-ID: <7xMZmkxN1DhZHC8aLJCq_Ev4SCN0TOSHqTcsXSWepi0=.7c971504-d13a-43fc-b4c0-6f4b8147422e@github.com> On Mon, 3 Jul 2023 15:49:31 GMT, Jose Pereda wrote: > This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. > > This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. > > The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. > > Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 990: > 988: */ > 989: public void play() { > 990: Toolkit.getToolkit().checkFxUserThread(); minor: perhaps this should first check for non-null parent, then for fx thread (here and below) tests/system/src/test/java/test/com/sun/javafx/animation/AnimationTimerTest.java line 62: > 60: startupLatch.countDown(); > 61: } > 62: minor: extra newline? tests/system/src/test/java/test/com/sun/javafx/animation/AnimationTimerTest.java line 82: > 80: @Override public void handle(long l) { > 81: frameCounter.countDown(); > 82: if (frameCounter.getCount() == 0L) { thank you for 0L! tests/system/src/test/java/test/com/sun/javafx/animation/AnimationTimerTest.java line 112: > 110: Platform.runLater(timer::start); > 111: } > 112: minor: extra newline ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279641091 PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279642701 PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279642982 PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279642236 From kcr at openjdk.org Mon Jul 31 17:32:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 31 Jul 2023 17:32:51 GMT Subject: RFR: 8159048: Null PulseReceiver in AbstractMasterTimer In-Reply-To: <7xMZmkxN1DhZHC8aLJCq_Ev4SCN0TOSHqTcsXSWepi0=.7c971504-d13a-43fc-b4c0-6f4b8147422e@github.com> References: <7xMZmkxN1DhZHC8aLJCq_Ev4SCN0TOSHqTcsXSWepi0=.7c971504-d13a-43fc-b4c0-6f4b8147422e@github.com> Message-ID: On Mon, 31 Jul 2023 17:11:06 GMT, Andy Goryachev wrote: >> This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. >> >> This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. >> >> The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. >> >> Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). > > modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 990: > >> 988: */ >> 989: public void play() { >> 990: Toolkit.getToolkit().checkFxUserThread(); > > minor: perhaps this should first check for non-null parent, then for fx thread (here and below) Our pattern everywhere else where we require the method to be called on the FX Application Thread is to do the thread check first. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279660911 From jpereda at openjdk.org Mon Jul 31 17:36:48 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 31 Jul 2023 17:36:48 GMT Subject: RFR: 8159048: Null PulseReceiver in AbstractMasterTimer In-Reply-To: References: <7xMZmkxN1DhZHC8aLJCq_Ev4SCN0TOSHqTcsXSWepi0=.7c971504-d13a-43fc-b4c0-6f4b8147422e@github.com> Message-ID: On Mon, 31 Jul 2023 17:30:16 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 990: >> >>> 988: */ >>> 989: public void play() { >>> 990: Toolkit.getToolkit().checkFxUserThread(); >> >> minor: perhaps this should first check for non-null parent, then for fx thread (here and below) > > Our pattern everywhere else where we require the method to be called on the FX Application Thread is to do the thread check first. I don't have a preference, but I see that this check is usually the first one being performed, and then others (see for instance `QuantumToolkit::enterNestedEventLoop`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279666074 From mstrauss at openjdk.org Mon Jul 31 17:36:50 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 17:36:50 GMT Subject: RFR: 8311895: CSS Transitions [v3] In-Reply-To: References: Message-ID: <8xBSuBWK5ZoSMctCjCqjpqtN6lO9sKNbtyLADodlV_Y=.d4b4fc81-238b-4ba1-97e1-48d04ae625f9@github.com> > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/8e46c89f..94fa9d2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=01-02 Stats: 130 lines in 8 files changed: 79 ins; 11 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From jpereda at openjdk.org Mon Jul 31 17:47:06 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 31 Jul 2023 17:47:06 GMT Subject: RFR: 8159048: Null PulseReceiver in AbstractMasterTimer [v2] In-Reply-To: References: Message-ID: > This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. > > This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. > > The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. > > Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Removed extra lines ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1167/files - new: https://git.openjdk.org/jfx/pull/1167/files/284c5a13..719817d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1167&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1167&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1167.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1167/head:pull/1167 PR: https://git.openjdk.org/jfx/pull/1167 From angorya at openjdk.org Mon Jul 31 17:47:06 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Jul 2023 17:47:06 GMT Subject: RFR: 8159048: Null PulseReceiver in AbstractMasterTimer [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 17:42:03 GMT, Jose Pereda wrote: >> This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. >> >> This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. >> >> The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. >> >> Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Removed extra lines looks good, thank you! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1167#pullrequestreview-1555437591 From jpereda at openjdk.org Mon Jul 31 17:47:07 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 31 Jul 2023 17:47:07 GMT Subject: RFR: 8159048: Null PulseReceiver in AbstractMasterTimer In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 15:49:31 GMT, Jose Pereda wrote: > This PR adds a check to the Animation and AnimationTimer public methods to verify that these are called from the JavaFX Application thread. If the call is done from any other thread, an IllegalStateException will be thrown. > > This will prevent users from getting unexpected errors (typically NPE, like the one posted in the JBS issue), and will fail fast with a clear exception and reason for it. > > The javadoc of the Animation and AnimationTimer classes and public methods has been updated accordingly. > > Tests for both classes have been included, failing (as in no exceptions were thrown when calling from a background thread) before this patch, and passing (as in ISE was thrown). I've edited the title of the original JBS issue https://bugs.openjdk.org/browse/JDK-8159048 to fix the typo. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1167#issuecomment-1658860453 From angorya at openjdk.org Mon Jul 31 17:47:08 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 31 Jul 2023 17:47:08 GMT Subject: RFR: 8159048: Null PulseReceiver in AbstractMasterTimer [v2] In-Reply-To: References: <7xMZmkxN1DhZHC8aLJCq_Ev4SCN0TOSHqTcsXSWepi0=.7c971504-d13a-43fc-b4c0-6f4b8147422e@github.com> Message-ID: On Mon, 31 Jul 2023 17:34:20 GMT, Jose Pereda wrote: >> Our pattern everywhere else where we require the method to be called on the FX Application Thread is to do the thread check first. > > I don't have a preference, but I see that this check is usually the first one being performed, and then others (see for instance `QuantumToolkit::enterNestedEventLoop`. It's ok if this is done for historical reasons. I would have expected the checks being done first on an entity of the innermost scope - the function argument, then progressively larger scope. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279672371 From jpereda at openjdk.org Mon Jul 31 17:47:08 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 31 Jul 2023 17:47:08 GMT Subject: RFR: 8159048: Null PulseReceiver in AbstractMasterTimer [v2] In-Reply-To: <7xMZmkxN1DhZHC8aLJCq_Ev4SCN0TOSHqTcsXSWepi0=.7c971504-d13a-43fc-b4c0-6f4b8147422e@github.com> References: <7xMZmkxN1DhZHC8aLJCq_Ev4SCN0TOSHqTcsXSWepi0=.7c971504-d13a-43fc-b4c0-6f4b8147422e@github.com> Message-ID: On Mon, 31 Jul 2023 17:12:41 GMT, Andy Goryachev wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed extra lines > > tests/system/src/test/java/test/com/sun/javafx/animation/AnimationTimerTest.java line 62: > >> 60: startupLatch.countDown(); >> 61: } >> 62: > > minor: extra newline? removed > tests/system/src/test/java/test/com/sun/javafx/animation/AnimationTimerTest.java line 82: > >> 80: @Override public void handle(long l) { >> 81: frameCounter.countDown(); >> 82: if (frameCounter.getCount() == 0L) { > > thank you for 0L! :) > tests/system/src/test/java/test/com/sun/javafx/animation/AnimationTimerTest.java line 112: > >> 110: Platform.runLater(timer::start); >> 111: } >> 112: > > minor: extra newline removed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279670408 PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279670299 PR Review Comment: https://git.openjdk.org/jfx/pull/1167#discussion_r1279670174 From mstrauss at openjdk.org Mon Jul 31 18:00:43 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:00:43 GMT Subject: RFR: 8311895: CSS Transitions [v4] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Make interpolator fields final ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/94fa9d2a..66ee849f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Mon Jul 31 18:03:56 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:03:56 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 12:56:10 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > modules/javafx.graphics/src/main/java/com/sun/scenario/animation/StepInterpolator.java line 73: > >> 71: } >> 72: >> 73: if (t >= 0 && step < 0) { > > `t >= 0` always holds, perhaps the original `t` was meant here? The `t` parameter is re-assigned, which may be confusing. This algorithm is implemented as [specified](https://www.w3.org/TR/css-easing-1/#step-easing-algo), which accounts for the possibility that the interpolator is used for a back-filling animation (`t < 0`). While this is not possible in JavaFX (but may be possible in the future), I think it makes sense to keep the algorithm as is, because it ensures that its results are always correct, even though negative values for `t` are currently out of spec. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279695148 From mstrauss at openjdk.org Mon Jul 31 18:07:54 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:07:54 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: <7T2hJ35sRpBuP327r9GhQuinVa2SbWp_cE6oGMbnklQ=.66c41a78-ac16-40e8-89db-8663fd6a236a@github.com> On Mon, 31 Jul 2023 12:39:26 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 45: > >> 43: */ >> 44: public record TransitionDefinition(String propertyName, Duration duration, >> 45: Duration delay, Interpolator interpolator) { > > I see this is an internal class that makes use of `javafx.util.Duration`. I think it's not further exposed. I see a lot of calls getting the duration/delay which almost instantly converts the value to nano seconds. It might be an idea to use nanos here immediately (ie. use `long` in the constructor) and have the converter supply longs. I've tried using `long` nanosecond fields. The amount of conversions doesn't change, it merely shifts around the location where the conversions happen. Since there's no obvious benefit, I prefer to use `javafx.util.Duration` for clarity. Additionally, I've introduced two helper methods in `TransitionTimer` (`nanosToMillis` and `millisToNanos`) to make sure that conversion is done correctly in all places. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279698006 From mstrauss at openjdk.org Mon Jul 31 18:13:56 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:13:56 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 12:16:05 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinitionCssMetaData.java line 63: > >> 61: private static final Duration[] DURATION_ZERO = new Duration[] { Duration.ZERO }; >> 62: >> 63: private static final Interpolator[] INTERPOLATOR_EASE = new Interpolator[] { InterpolatorConverter.CSS_EASE }; > > Careful, the array contents could still be modified That's true. However, `CssParser` is built around array-based sequences (see `StringConverter.SequenceConverter`), and changing these arrays to lists would seem out of place for this part of the codebase. What do you think? > modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 319: > >> 317: * The output time value is determined by the {@link StepPosition}. >> 318: * >> 319: * @param intervals the number of intervals in the step interpolator > > minor: When I see a plural like `intervals` (or `employees`) I think of a list of objects. Perhaps `intervalCount` would be better? Doesn't sound better to me, but I'll defer to what most people feel is best. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279700471 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279703051 From mstrauss at openjdk.org Mon Jul 31 18:19:02 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:19:02 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: <35UYdTAmgs9j3-F_283cQBco8IdaGTm608n0e7IEYVY=.e4edd814-003e-4755-8fd7-79ff59db20be@github.com> On Mon, 31 Jul 2023 13:33:41 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 88: > >> 86: * @param eventType the event type >> 87: * @param property the {@code StyleableProperty} that is targeted by the transition >> 88: * @param elapsedTime the time that has elapsed since the transition has entered its active period > > Can property be `null`? Any restrictions on `elapsedTime`? Added a `@throws` tag. Interestingly, `Event` doesn't specify or assert that its `eventType` parameter is non-null. Maybe we should investigate this further. > modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 111: > >> 109: * not including the time spent in the delay phase. >> 110: * >> 111: * @return the elapsed time > > Any guarantees here? Can it be `null`, negative, zero, infinite? Added that the elapsed time is zero if the transition has not entered its active period. I usually don't document that a return value is always non-null, since I believe this to be the default assumption unless otherwise noted. Additionally, the constructor of `TransitionEvent` now documents that it will not accept `null`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279708076 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279706369 From mstrauss at openjdk.org Mon Jul 31 18:22:54 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:22:54 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 13:39:06 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8968: > >> 8966: >> 8967: for (TransitionTimer timer : transitionTimers) { >> 8968: if (timer.getProperty() == property) { > > minor: this probably works, but I'd still use `equals` here Why would this be a sensible thing to do? I'm quite explicitly comparing the identity of `property`, since I'm interested in finding the one property that I'm looking for, not potentially any property that is in some way "equal" to the property. For (hopefully) all property implementations, `equals` trivially works because it is not an overridden method and therefore falls back to an identity comparison. What would it even mean for a property to be equal, but not identical to another property? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279711683 From mstrauss at openjdk.org Mon Jul 31 18:31:53 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:31:53 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 12:04:19 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 54: > >> 52: */ >> 53: public TransitionDefinition(String propertyName, Duration duration, >> 54: Duration delay, Interpolator interpolator) { > > I think you should not repeat the parameters here, just use: > > Suggestion: > > public TransitionDefinition { > > > I would also move the "@throws" documentation tags to the record class definition The constructor ensures that any spelling of "ALL" is converted to the interned constant "all", which is important as we would otherwise need a more computationally expensive case-insensitive string comparison in `Node.Transitions.find()`. Removing the constructor would mean that some unrelated piece of code would need to do this conversion. The `@throws` tag cannot is not allowed at the class level. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279720345 From mstrauss at openjdk.org Mon Jul 31 18:38:57 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:38:57 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: <0Rxr8I-rVXhUcDEdo-dM-Z3iCumjSMK2L68Y4y1rO8o=.27a776a5-7a88-4d85-97d0-a9be5ee17d2f@github.com> On Mon, 31 Jul 2023 12:29:28 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 126: > >> 124: * @param forceStop if {@code true}, the timer is stopped unconditionally >> 125: * @return {@code true} if the timer was cancelled or {@code timer} is {@code null}, >> 126: * {@code false} otherwise > > minor: > Suggestion: > > * @return {@code true} if the timer was cancelled, or {@code timer} is {@code null}, > * otherwise {@code false} I don't see any real difference here, but then again I'm not a native speaker. I'll defer to public opinion. > modules/javafx.graphics/src/main/java/javafx/css/StyleableBooleanProperty.java line 80: > >> 78: setValue(v); >> 79: } >> 80: > > I'm not sure how I feel about this; the changes made don't really seem to belong here. > > The `StyleableXXXProperty` classes are convenient helpers, but all that matters is that they are `StyleableProperty` implementations. There is no requirement to use the helpers. So what happens when a property defines their own helper, or implements `StyleableProperty` directly? Or if classes are refactored at some point and they decide to stop using these helpers? I don't see how I can make CSS transitions work without some property-specific implementation details. You're right that there is no requirement to use these classes. An easy solution would be to just document that CSS transitions are only supported for `StyleableXYZProperty` implementations. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279727042 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1279725899 From mstrauss at openjdk.org Mon Jul 31 18:59:39 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:59:39 GMT Subject: RFR: 8311895: CSS Transitions [v5] In-Reply-To: References: Message-ID: <4oNVuY07HfH4xKBHjvE9ro6MLWJKptws5EdPRd4KjCo=.343287e5-5648-48a8-807b-f55e878020fa@github.com> > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/66ee849f..deb65ea3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=03-04 Stats: 48 lines in 2 files changed: 4 ins; 25 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Mon Jul 31 18:59:51 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 31 Jul 2023 18:59:51 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 11:51:24 GMT, John Hendrikx wrote: >> Incorporates documentation review comments from #1069. >> >> This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use @implSpec tag > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/subscriptions-doc-improvements > - Documentation improvements LGTM ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1177#pullrequestreview-1555554937