From john.hendrikx at gmail.com Mon Jan 1 15:37:34 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 1 Jan 2024 16:37:34 +0100 Subject: Performance Regression in 21 - CSS In-Reply-To: <8cdf6073-0b62-4ffc-8da3-56750416fc91@xpipe.io> References: <8cdf6073-0b62-4ffc-8da3-56750416fc91@xpipe.io> Message-ID: <50b94cf7-2451-719a-aaaa-fb92581f0666@gmail.com> Hi, I think I've found the issue. Note that on my machine I can't really reproduce the problem as clearly (Windows 10) as the performance degradation is not quite as bad as mentioned in the issue (maybe a factor of 2, and scrolling was unaffected), but it's probably what you are seeing as little else changed in the PR that seems to be the root cause.? Still, VisualVM did hint at the probable culprit (SimpleSelector#applies). The problem is that BitSet (used for storing and comparing CSS style classes) has special logic to do fast containsAll checks if it detects it is compared against another BitSet. However, due to a read only wrapper on one of the sets this detection fails, and it will fall back to standard containsAll logic which is a bit slower. The fix should be relatively trivial, and I'll create a PR soon. I did note a few other things in my investigation: - JFXCentral has around 1000 style classes, which means a BitSet as currently implemented, could use 125 bytes of memory for each StyleClassSet if a high bit was set - Most selectors involve only 1 style class, sometimes 2 and rarely 3 or more - Most nodes have 1 style class, sometimes 2 and rarely 3 or more Now, if I were to implement this kind of logic knowing that the number of possible style classes can be quite high, and knowing that most selectors and nodes will rarely have 3 or more style classes assigned to them, I'd probably not use a non-sparse bit set as it is currently implemented. I've played around a bit with a sparse bitset, and although I did not see amazing (overall) performance gains, the change (after applying the regression fix) did shave off another 10-20 ms for the "loadTimeFX" measurement in the JFXCentral application. --John On 31/12/2023 15:24, Christopher Schnick wrote: > > Hello, > > I just tested this with our JavaFX application and can confirm that > there are massive differences. It takes around 1-2 seconds to > completely apply all application stylesheets in JavaFX 20 but takes > around 6-7 seconds in JavaFX 21. > > On 12/31/2023 3:00 PM, Florian Kirmaier wrote: >> Hi Everyone, >> >> Sorry for the delay - but I couldn?t find the time to extract the >> TestApplication for this bug. >> Luckily, I found another application, which is also open source, >> which is affected by the application. >> >> I'm speaking about https://www.jfx-central.com/?- both the desktop >> and web versions are affected. >> I?ve seen a performance deterioration of 10x when switching pages >> when using JavaFX21 compared to JavaFX20. >> >> I?ve created a ticket with further instructions on how to test it: >> https://bugs.openjdk.org/browse/JDK-8322795 >> >> Greetings >> >> Florian Kirmaier >> >> On Fri, 27 Oct 2023 at 21:31, Andy Goryachev >> wrote: >> >> Please create a ticket, Florian.? Would it be possible to profile >> the application when scrolling? >> >> Thank you >> >> -andy >> >> *From: *openjfx-dev on behalf of >> Florian Kirmaier >> *Date: *Friday, October 27, 2023 at 04:20 >> *To: *openjfx-dev at openjdk.java.net >> *Subject: *Performance Regression in 21 - CSS >> >> Hi everyone, >> >> I've noticed that some parts of one of my applications is >> significantly slower with 21. It's fast with 20. >> The application heavily uses (and reuses) TextFlow with a Cell >> pattern. >> When I scroll, it is smooth with 20, but has big freezes with 21. >> >> I've tried all the commits that happened in between, and >> pin-pointed it down to the following: >> ticket: https://bugs.openjdk.org/browse/JDK-8304959 >> PR: https://github.com/openjdk/jfx/pull/1070 >> commit: >> https://github.com/openjdk/jfx21u/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1 >> >> >> According to the description and the discussion in the PR - this >> wasn't supposed to change any performance. >> Is this regression known? >> Otherwise, I should create a ticket for it. >> >> Greetings Florian >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.kirmaier at gmail.com Tue Jan 2 12:06:45 2024 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Tue, 2 Jan 2024 13:06:45 +0100 Subject: Performance Regression in 21 - CSS In-Reply-To: <50b94cf7-2451-719a-aaaa-fb92581f0666@gmail.com> References: <8cdf6073-0b62-4ffc-8da3-56750416fc91@xpipe.io> <50b94cf7-2451-719a-aaaa-fb92581f0666@gmail.com> Message-ID: Hi John, That sounds very promising! Let me know when you have a PR available so I can test it out. Quite sure I measured 10x, but maybe we measured something slightly different - or it's hardware-dependent. (The issue with scrolling happened only in my closed-source project, which has a behavior similar to ListVIew.) Florian Kirmaier On Mon, 1 Jan 2024 at 16:37, John Hendrikx wrote: > Hi, > > I think I've found the issue. Note that on my machine I can't really > reproduce the problem as clearly (Windows 10) as the performance > degradation is not quite as bad as mentioned in the issue (maybe a factor > of 2, and scrolling was unaffected), but it's probably what you are seeing > as little else changed in the PR that seems to be the root cause. Still, > VisualVM did hint at the probable culprit (SimpleSelector#applies). > > The problem is that BitSet (used for storing and comparing CSS style > classes) has special logic to do fast containsAll checks if it detects it > is compared against another BitSet. However, due to a read only wrapper on > one of the sets this detection fails, and it will fall back to standard > containsAll logic which is a bit slower. > > The fix should be relatively trivial, and I'll create a PR soon. > > I did note a few other things in my investigation: > > - JFXCentral has around 1000 style classes, which means a BitSet as > currently implemented, could use 125 bytes of memory for each StyleClassSet > if a high bit was set > - Most selectors involve only 1 style class, sometimes 2 and rarely 3 or > more > - Most nodes have 1 style class, sometimes 2 and rarely 3 or more > > Now, if I were to implement this kind of logic knowing that the number of > possible style classes can be quite high, and knowing that most selectors > and nodes will rarely have 3 or more style classes assigned to them, I'd > probably not use a non-sparse bit set as it is currently implemented. > > I've played around a bit with a sparse bitset, and although I did not see > amazing (overall) performance gains, the change (after applying the > regression fix) did shave off another 10-20 ms for the "loadTimeFX" > measurement in the JFXCentral application. > > --John > > > On 31/12/2023 15:24, Christopher Schnick wrote: > > Hello, > > I just tested this with our JavaFX application and can confirm that there > are massive differences. It takes around 1-2 seconds to completely apply > all application stylesheets in JavaFX 20 but takes around 6-7 seconds in > JavaFX 21. > On 12/31/2023 3:00 PM, Florian Kirmaier wrote: > > Hi Everyone, > > Sorry for the delay - but I couldn?t find the time to extract the > TestApplication for this bug. > Luckily, I found another application, which is also open source, which is > affected by the application. > > I'm speaking about https://www.jfx-central.com/ - both the desktop and > web versions are affected. > I?ve seen a performance deterioration of 10x when switching pages when > using JavaFX21 compared to JavaFX20. > > I?ve created a ticket with further instructions on how to test it: > https://bugs.openjdk.org/browse/JDK-8322795 > > Greetings > > Florian Kirmaier > > On Fri, 27 Oct 2023 at 21:31, Andy Goryachev > wrote: > >> Please create a ticket, Florian. Would it be possible to profile the >> application when scrolling? >> >> >> >> Thank you >> >> -andy >> >> >> >> >> >> >> >> *From: *openjfx-dev on behalf of Florian >> Kirmaier >> *Date: *Friday, October 27, 2023 at 04:20 >> *To: *openjfx-dev at openjdk.java.net >> *Subject: *Performance Regression in 21 - CSS >> >> Hi everyone, >> >> I've noticed that some parts of one of my applications is significantly >> slower with 21. It's fast with 20. >> The application heavily uses (and reuses) TextFlow with a Cell pattern. >> When I scroll, it is smooth with 20, but has big freezes with 21. >> >> I've tried all the commits that happened in between, and pin-pointed it >> down to the following: >> ticket: https://bugs.openjdk.org/browse/JDK-8304959 >> PR: https://github.com/openjdk/jfx/pull/1070 >> commit: >> https://github.com/openjdk/jfx21u/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1 >> >> >> According to the description and the discussion in the PR - this wasn't >> supposed to change any performance. >> Is this regression known? >> Otherwise, I should create a ticket for it. >> >> Greetings Florian >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jan 2 15:48:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 2 Jan 2024 15:48:00 GMT Subject: Withdrawn: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Sat, 29 Jul 2023 00:12:45 GMT, Andy Goryachev wrote: > Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1190 From andy.goryachev at oracle.com Tue Jan 2 15:56:47 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 2 Jan 2024 15:56:47 +0000 Subject: Caret animation In-Reply-To: <32eab062-6703-b23d-78d7-eab25a4813f4@gmail.com> References: <32eab062-6703-b23d-78d7-eab25a4813f4@gmail.com> Message-ID: I agree - this makes sense. -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, December 26, 2023 at 21:54 To: openjfx-dev at openjdk.org Subject: Caret animation In light of a possible future Behavior API, I took a close look at the "complicated" behaviors surrounding TextFields and TextAreas. One thing that came out of this is that caret animation is controlled by the behaviors by looking at key presses and keys typed. It is a very convoluted way of doing this as there is a much simpler rule that governs caret animation: when the caret moves, animation should be reset This is how controls do it in browsers and on Windows, and it makes much more sense. The caret only needs highlighting when it actually changed position, and can remain animated when it doesn't. This also means that caret blinking can simply be a concern of the Skin, as it can listen for caret position changes. This also makes more sense. Replacing the Behavior but keeping the same Skin should not break caret blinking. Currently, the behaviors will wrap all possible key pressed/typed events to stop the blinking, but it gets it wrong in many situations (when the caret didn't actually move, or when a key press was not consumed or didn't do anything, or using keypad navigation which "forgets" to wrap it in the start/stop animation logic). It feels like a big hack when there is such an obvious alternative. I've created this ticket to address this: https://bugs.openjdk.org/browse/JDK-8322748 One of the immediate benefits (aside from solving all caret animation bugs) is probably a memory reduction as it removes a wrapper around every key press/type mapping... --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Tue Jan 2 17:01:00 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 2 Jan 2024 17:01:00 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Sat, 16 Dec 2023 22:55:42 GMT, Thiago Milczarek Sayao wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java line 681: >> >>> 679: public double[] getInputMethodCandidateRelativePos(int offset) { >>> 680: Point2D p2d = scene.inputMethodRequests.getTextLocationRelative(offset); >>> 681: return new double[] { p2d.getX(), p2d.getY() }; >> >> On my system the IM window is incorrectly positioned. This appears to be because I'm running a high-DPI display with 200% magnification. I think you need to call getPlatformScaleX and getPlatformScaleY and apply those scaling factors before passing these coordinates on to glass. You'll see other places in this file where conversions like that are being performed. > > I did revert the relative positioning change as it will get in the way of merging this. Could you check if it's correctly positioned now? I don't own a fancy monitor :) Tried 200% scale here and everything looks monstrous. 125% scale looks correct. I think the problem is deeper in the Java code since it also affects Windows. See PR #1311. >> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 120: >> >>> 118: if (!filtered || (filtered && im_ctx.send_keypress)) { >>> 119: process_key(&event->key); >>> 120: im_ctx.send_keypress = false; >> >> I'm seeing two RELEASE events on each keystroke. If you call process_key() here you need to set `filtered` to true to ensure the event isn't processed again. > > I changed to "if not filtered", just propagate. Looks good to me. >> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 175: >> >>> 173: if (im_ctx.ctx != NULL) { >>> 174: g_signal_handlers_disconnect_matched(im_ctx.ctx, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NULL); >>> 175: g_object_unref(im_ctx.ctx); >> >> If the IM window is visible when the window is closed disableIME() can get called twice; I'm seeing debug output being generated. Set im_ctx.ctx to NULL here or you'll unref it twice. > > Fixed. Looks good to me. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1439634871 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1439635767 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1439635167 From mfox at openjdk.org Tue Jan 2 17:01:01 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 2 Jan 2024 17:01:01 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Mon, 25 Dec 2023 20:45:00 GMT, Thiago Milczarek Sayao wrote: >> There's a check before. >> >> >> if (!jview) { >> return; >> } > > I see what you mean now. Fixed it. Looks good to me. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1439635364 From mfox at openjdk.org Tue Jan 2 17:01:03 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 2 Jan 2024 17:01:03 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v17] In-Reply-To: <_TxY4SdwrrDUcS3GiT7rcYuukW81kRIueh-8jLUG9S0=.118128fe-88ef-48de-a13b-7353bea92fa5@github.com> References: <_TxY4SdwrrDUcS3GiT7rcYuukW81kRIueh-8jLUG9S0=.118128fe-88ef-48de-a13b-7353bea92fa5@github.com> Message-ID: On Mon, 25 Dec 2023 20:48:09 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add check for jview modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 163: > 161: g_signal_connect(im_ctx.ctx, "preedit-changed", G_CALLBACK(on_preedit_changed), this); > 162: g_signal_connect(im_ctx.ctx, "preedit-end", G_CALLBACK(on_preedit_end), this); > 163: g_signal_connect(im_ctx.ctx, "commit", G_CALLBACK(on_commit), this); On Ubuntu 22.04 using the Japanese (Mozc) input method I get a bunch of debug output from IBus. The message reads `IBUS-WARNING **: 08:50:12.994: java has no capability of surrounding-text feature` I was able to silence this by connecting to the surrounding text signal and simply returning TRUE from the callback. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1439638790 From kcr at openjdk.org Tue Jan 2 23:16:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Jan 2024 23:16:49 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v2] In-Reply-To: References: Message-ID: <-xiFqP-bTnkrA3jHbnxclCOh1ZfWbThZej70wHwyhKA=.f7ea836f-ab06-4aff-b6fd-f0ed22fff76f@github.com> On Tue, 26 Dec 2023 23:42:56 GMT, Martin Fox wrote: >> When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. >> >> This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > IM coordinates are relative to main screen The fix looks correct to me. I'll test it on Windows as part of formally reviewing it. .idea/misc.xml line 1: > 1: The changes in this file should be reverted, since it isn't related to the bug being fixed. ------------- PR Review: https://git.openjdk.org/jfx/pull/1311#pullrequestreview-1801197698 PR Review Comment: https://git.openjdk.org/jfx/pull/1311#discussion_r1439937166 From mfox at openjdk.org Wed Jan 3 03:33:05 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 3 Jan 2024 03:33:05 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v3] In-Reply-To: References: Message-ID: > When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. > > This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Reverting file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1311/files - new: https://git.openjdk.org/jfx/pull/1311/files/401f5117..6ce899f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1311.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1311/head:pull/1311 PR: https://git.openjdk.org/jfx/pull/1311 From jhendrikx at openjdk.org Wed Jan 3 17:33:57 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 3 Jan 2024 17:33:57 GMT Subject: RFR: JDK-8322795 CSS performance regression up to 10x Message-ID: The regression is caused by the `Collections.unmodifiableSet` wrapper not being recognized by `BitSet`, and a fall back is done to a less optimized version of `containsAll`. As this is a regression fix, I've kept the fix as small as reasonable. I'll provide a further optimized version as part of https://bugs.openjdk.org/browse/JDK-8322964 which eliminates the need for `BitSet` and `StyleClass` in the hot code paths which should result in a further CSS performance improvement. I've tested this solution with the JFXCentral application locally and the regression seems resolved. ------------- Commit messages: - Fix regression Changes: https://git.openjdk.org/jfx/pull/1314/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1314&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322795 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1314.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1314/head:pull/1314 PR: https://git.openjdk.org/jfx/pull/1314 From kcr at openjdk.org Wed Jan 3 18:39:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Jan 2024 18:39:36 GMT Subject: RFR: JDK-8322795 CSS performance regression up to 10x In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 01:14:13 GMT, John Hendrikx wrote: > As this is a regression fix, I've kept the fix as small as reasonable Thanks. That seems like the best solution. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1314#issuecomment-1875796318 From kcr at openjdk.org Wed Jan 3 18:53:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Jan 2024 18:53:09 GMT Subject: RFR: 8321638: Update to SWT 4.30 Message-ID: This PR updates the version of SWT that we use we use when building and testing the `javafx.swt` modules to 4.30. NOTE: we do not distribute SWT, but only use it during build and (manual) test. We currently use SWT 4.6. In addition to being old, this version does not provide macOS / aarch64 binaries, which are needed for testing on that platform. I've tested this on all platforms. ------------- Commit messages: - 8321638: Update to SWT 4.30 Changes: https://git.openjdk.org/jfx/pull/1315/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321638 Stats: 25 lines in 2 files changed: 2 ins; 4 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1315.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1315/head:pull/1315 PR: https://git.openjdk.org/jfx/pull/1315 From mstrauss at openjdk.org Wed Jan 3 19:58:31 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 3 Jan 2024 19:58:31 GMT Subject: RFR: JDK-8322795 CSS performance regression up to 10x In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 01:14:13 GMT, John Hendrikx wrote: > The regression is caused by the `Collections.unmodifiableSet` wrapper not being recognized by `BitSet`, and a fall back is done to a less optimized version of `containsAll`. > > As this is a regression fix, I've kept the fix as small as reasonable. I'll provide a further optimized version as part of https://bugs.openjdk.org/browse/JDK-8322964 which eliminates the need for `BitSet` and `StyleClass` in the hot code paths which should result in a further CSS performance improvement. > > I've tested this solution with the JFXCentral application locally and the regression seems resolved. LGTM ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1314#pullrequestreview-1802984796 From kcr at openjdk.org Wed Jan 3 20:30:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Jan 2024 20:30:36 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v3] In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:33:05 GMT, Martin Fox wrote: >> When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. >> >> This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Reverting file This works fine for a single screen, but not for multiple screens. Also, it isn't sufficient to multiply the x and y by the platform scale for screens that don't touch the origin of the virtual screen space. See [this comment in PR #853](https://github.com/openjdk/jfx/pull/853#issuecomment-1206747079). I left inline comments with what I think needs to be changed. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java line 672: > 670: public double[] getInputMethodCandidatePos(int offset) { > 671: Point2D p2d = scene.inputMethodRequests.getTextLocation(offset); > 672: final Screen s = Screen.getMainScreen(); This won't work for multiple screens. You'll need something like `scene.getPlatformView().getWindow().getScreen()` (with the appropriate null checks). modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java line 677: > 675: double[] ret = new double[2]; > 676: ret[0] = p2d.getX() * pScaleX; > 677: ret[1] = p2d.getY() * pScaleY; You should use `Screen::toPlatformX/Y` or it won't work for all screen arrangements. ------------- PR Review: https://git.openjdk.org/jfx/pull/1311#pullrequestreview-1803016057 PR Review Comment: https://git.openjdk.org/jfx/pull/1311#discussion_r1440905659 PR Review Comment: https://git.openjdk.org/jfx/pull/1311#discussion_r1440906238 From arapte at openjdk.org Thu Jan 4 05:04:31 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 4 Jan 2024 05:04:31 GMT Subject: RFR: 8321638: Update to SWT 4.30 In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 18:39:58 GMT, Kevin Rushforth wrote: > This PR updates the version of SWT that we use we use when building and testing the `javafx.swt` modules to 4.30. > > NOTE: we do not distribute SWT, but only use it during build and (manual) test. > > We currently use SWT 4.6. In addition to being old, this version does not provide macOS / aarch64 binaries, which are needed for testing on that platform. > > I've tested this on all platforms. Verified on Windows. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1315#pullrequestreview-1803428694 From jhendrikx at openjdk.org Thu Jan 4 12:31:53 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 4 Jan 2024 12:31:53 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching Message-ID: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. The performance improvements are the result of several factors: - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). ------------- Commit messages: - Deprecate StyleClass and remove StyleClassSet for faster solution - Fix regression Changes: https://git.openjdk.org/jfx/pull/1316/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322964 Stats: 878 lines in 8 files changed: 643 ins; 172 del; 63 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From nlisker at openjdk.org Thu Jan 4 14:25:39 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 4 Jan 2024 14:25:39 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 12:21:15 GMT, John Hendrikx wrote: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). I just scrolled quickly through the changes and left some comments, If deprecation for removal is part of the PR the consequences will need to be discussed. Are the for-removal classes and methods not widely used? modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 81: > 79: * collection or making a read-only copy. > 80: */ > 81: public abstract void freeze(); All the permitted subclasses have the same implementation of this method. Any reason not to pull up the `boolean frozen` field to this class and make this method concrete with `frozen = true;`? modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 81: > 79: * @deprecated for future removal, use {@link #getStyleClassNames()} instead > 80: */ > 81: public List getStyleClasses() { Deprecating requires the `@Deprecate` annotation (possibly with setting `forRemoval = true`). The javadoc tag needs only to mention why (e.g., "no longer needed because...") and what to replace it with. Same for the other deprecations. modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 82: > 80: */ > 81: public List getStyleClasses() { > 82: return Collections.unmodifiableList(new ArrayList<>(selectorStyleClassNames)); Is `List.copyOf` not good here? modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 291: > 289: > 290: if (matchOnStyleClass) { > 291: if (!matchesStyleClasses(styleable.getStyleClass())) { Should the 2 `if` conditions not be combined instead of nested? modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 364: > 362: return false; > 363: } > 364: if (this.selectorStyleClassNames.equals(other.selectorStyleClassNames) == false) { Maybe replace the `==false` with `!`. modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 383: > 381: hash = (id != null) ? 31 * (hash + id.hashCode()) : 0; > 382: hash = 31 * (hash + pseudoClassState.hashCode()); > 383: return hash; Is it worth caching the hash code for this class? ------------- PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-1804174369 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441758180 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441770930 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441772947 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441777174 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441798989 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441792235 From kcr at openjdk.org Thu Jan 4 14:34:34 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jan 2024 14:34:34 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 14:23:14 GMT, Nir Lisker wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > I just scrolled quickly through the changes and left some comments, > > If deprecation for removal is part of the PR the consequences will need to be discussed. Are the for-removal classes and methods not widely used? As @nlisker notes, the implications of any deprecation will need to be discussed. In particular, we need to consider what the consequences are for existing applications. If any of them might be used by apps, then simple deprecation (rather than deprecating for removal) might be best. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1877191484 From kcr at openjdk.org Thu Jan 4 14:49:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jan 2024 14:49:35 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 12:21:15 GMT, John Hendrikx wrote: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). Left a couple inline comments. modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 1: > 1: package com.sun.javafx.css; This needs a standard copyright header block. modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 140: > 138: public Set getStyleClassNames() { > 139: return selectorStyleClassNames; > 140: } This is new API, and as such needs an `@since 23`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-1804292170 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441838456 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441835248 From mstrauss at openjdk.org Thu Jan 4 15:31:32 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 4 Jan 2024 15:31:32 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 12:21:15 GMT, John Hendrikx wrote: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 81: > 79: * @deprecated for future removal, use {@link #getStyleClassNames()} instead > 80: */ > 81: public List getStyleClasses() { Have you considered keeping this method (instead of adding a new `getStyleClassNames`), and have `FixedCapacitySet` implement `List` to make it work? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1441902895 From arapte at openjdk.org Thu Jan 4 15:39:45 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 4 Jan 2024 15:39:45 GMT Subject: RFR: 8322953: Update copyright header for files modified in 2023 Message-ID: Update the copyright year in files modified in year 2023. ------------- Commit messages: - copyright year 2023 Changes: https://git.openjdk.org/jfx/pull/1317/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322953 Stats: 27 lines in 27 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1317.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1317/head:pull/1317 PR: https://git.openjdk.org/jfx/pull/1317 From kcr at openjdk.org Thu Jan 4 15:39:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jan 2024 15:39:46 GMT Subject: RFR: 8322953: Update copyright header for files modified in 2023 In-Reply-To: References: Message-ID: <5xipgd921-Q2yBl37luspDFFGH6UwAlgApOc5Cv4pi0=.7ab1c927-3981-4c11-999a-3621594f9043@github.com> On Thu, 4 Jan 2024 15:31:12 GMT, Ambarish Rapte wrote: > Update the copyright year in files modified in year 2023. +1 ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1317#pullrequestreview-1804425189 From kcr at openjdk.org Thu Jan 4 15:49:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jan 2024 15:49:36 GMT Subject: Integrated: 8321638: Update to SWT 4.30 In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 18:39:58 GMT, Kevin Rushforth wrote: > This PR updates the version of SWT that we use we use when building and testing the `javafx.swt` modules to 4.30. > > NOTE: we do not distribute SWT, but only use it during build and (manual) test. > > We currently use SWT 4.6. In addition to being old, this version does not provide macOS / aarch64 binaries, which are needed for testing on that platform. > > I've tested this on all platforms. This pull request has now been integrated. Changeset: 2476a3e8 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/2476a3e8f54ff66b0acd2c9da42b7653120a0b70 Stats: 25 lines in 2 files changed: 2 ins; 4 del; 19 mod 8321638: Update to SWT 4.30 Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1315 From arapte at openjdk.org Thu Jan 4 16:08:39 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 4 Jan 2024 16:08:39 GMT Subject: Integrated: 8322953: Update copyright header for files modified in 2023 In-Reply-To: References: Message-ID: On Thu, 4 Jan 2024 15:31:12 GMT, Ambarish Rapte wrote: > Update the copyright year in files modified in year 2023. This pull request has now been integrated. Changeset: bad94a6c Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/bad94a6c3551a2f299d387aec0ed597238a3c4f7 Stats: 27 lines in 27 files changed: 0 ins; 0 del; 27 mod 8322953: Update copyright header for files modified in 2023 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1317 From mfox at openjdk.org Thu Jan 4 17:47:42 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 4 Jan 2024 17:47:42 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v4] In-Reply-To: References: Message-ID: > When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. > > This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Better handling of multiple monitors when converting IM coords ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1311/files - new: https://git.openjdk.org/jfx/pull/1311/files/6ce899f9..3a599216 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=02-03 Stats: 16 lines in 1 file changed: 11 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1311.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1311/head:pull/1311 PR: https://git.openjdk.org/jfx/pull/1311 From dlemmermann at gmail.com Thu Jan 4 21:49:56 2024 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 4 Jan 2024 22:49:56 +0100 Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: I truly love the fact that you guys are starting to use JFXCentral for benchmarking / testing :-) If anyone encounters things bad for performance unrelated to JavaFX itself but caused by JFXCentral then please let me know. Dirk > Am 04.01.2024 um 13:31 schrieb John Hendrikx : > > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > ------------- > > Commit messages: > - Deprecate StyleClass and remove StyleClassSet for faster solution > - Fix regression > > Changes: https://git.openjdk.org/jfx/pull/1316/files > Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8322964 > Stats: 878 lines in 8 files changed: 643 ins; 172 del; 63 mod > Patch: https://git.openjdk.org/jfx/pull/1316.diff > Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 > > PR: https://git.openjdk.org/jfx/pull/1316 From kcr at openjdk.org Thu Jan 4 22:19:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jan 2024 22:19:36 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v4] In-Reply-To: References: Message-ID: <1B_18DdzB7QM_2BQ8g-nPNMj0Bd7o6MUcs7Tl-pdfz4=.f8a3eb3e-1e77-48b1-aaf5-9fbcc3f86df4@github.com> On Thu, 4 Jan 2024 17:47:42 GMT, Martin Fox wrote: >> When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. >> >> This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Better handling of multiple monitors when converting IM coords This is closer, but doesn't correctly handle the case where a window straddles two screens. In that case, you really do want the screen associated with the window (even though that might seem a bit counter-intuitive). That's what's done pretty consistently in the rest of the code. To test this, configure two screens with different scale factors, and move the window partially onto one screen such that most of the window (and importantly the scale associated with that window) is on one screen, an d the text insertion point is on the other. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java line 678: > 676: > 677: for (Screen scr : Screen.getScreens()) { > 678: Rectangle2D bounds = new Rectangle2D(scr.getX(), scr.getY(), scr.getWidth(), scr.getHeight()); To correctly handle the case of a window straddling two screens, you need the screen associated with the window, not the screen that the anchor point intersects. ------------- PR Review: https://git.openjdk.org/jfx/pull/1311#pullrequestreview-1805048829 PR Review Comment: https://git.openjdk.org/jfx/pull/1311#discussion_r1442300561 From kcr at openjdk.org Thu Jan 4 22:38:29 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jan 2024 22:38:29 GMT Subject: RFR: 8301893: IME window position is off on secondary screen In-Reply-To: References: Message-ID: <8TsR3erKGAFGJIlWFoiuOPuHUWHg5RNkCTLgYpt5nCA=.e25df8af-d320-413d-bf1c-be81f99c435b@github.com> On Wed, 27 Dec 2023 00:01:10 GMT, Martin Fox wrote: > The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). Looks good. Tested on macOS 14.2.1 with dual monitors. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1313#pullrequestreview-1805069568 From kcr at openjdk.org Thu Jan 4 22:45:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jan 2024 22:45:33 GMT Subject: RFR: JDK-8322795 CSS performance regression up to 10x In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 01:14:13 GMT, John Hendrikx wrote: > The regression is caused by the `Collections.unmodifiableSet` wrapper not being recognized by `BitSet`, and a fall back is done to a less optimized version of `containsAll`. > > As this is a regression fix, I've kept the fix as small as reasonable. I'll provide a further optimized version as part of https://bugs.openjdk.org/browse/JDK-8322964 which eliminates the need for `BitSet` and `StyleClass` in the hot code paths which should result in a further CSS performance improvement. > > I've tested this solution with the JFXCentral application locally and the regression seems resolved. This looks like a safe and effective performance fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1314#pullrequestreview-1805077520 From jhendrikx at openjdk.org Fri Jan 5 00:37:31 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 00:37:31 GMT Subject: Integrated: JDK-8322795 CSS performance regression up to 10x In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 01:14:13 GMT, John Hendrikx wrote: > The regression is caused by the `Collections.unmodifiableSet` wrapper not being recognized by `BitSet`, and a fall back is done to a less optimized version of `containsAll`. > > As this is a regression fix, I've kept the fix as small as reasonable. I'll provide a further optimized version as part of https://bugs.openjdk.org/browse/JDK-8322964 which eliminates the need for `BitSet` and `StyleClass` in the hot code paths which should result in a further CSS performance improvement. > > I've tested this solution with the JFXCentral application locally and the regression seems resolved. This pull request has now been integrated. Changeset: 1dff7a16 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/1dff7a1618a945a9a10ad2168f78aad3658e91a9 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8322795: CSS performance regression up to 10x Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1314 From jhendrikx at openjdk.org Fri Jan 5 00:46:32 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 00:46:32 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 13:53:28 GMT, Nir Lisker wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 82: > >> 80: */ >> 81: public List getStyleClasses() { >> 82: return Collections.unmodifiableList(new ArrayList<>(selectorStyleClassNames)); > > Is `List.copyOf` not good here? I will change this, I just simplified what was there (no need for the loop), and didn't look further. `copyOf` would be better for sure. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1442402395 From jhendrikx at openjdk.org Fri Jan 5 00:50:31 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 00:50:31 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 13:57:16 GMT, Nir Lisker wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 291: > >> 289: >> 290: if (matchOnStyleClass) { >> 291: if (!matchesStyleClasses(styleable.getStyleClass())) { > > Should the 2 `if` conditions not be combined instead of nested? They absolutely can be, but I've left it in the style of the rest of the method (they do `if (matchOnXYZ)` and return `false` for failures, and fall through everywhere to reach the `return true` at the end). So just trying to keep it consistent without cleaning up the whole method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1442403883 From jhendrikx at openjdk.org Fri Jan 5 00:59:34 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 00:59:34 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 14:17:48 GMT, Nir Lisker wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 364: > >> 362: return false; >> 363: } >> 364: if (this.selectorStyleClassNames.equals(other.selectorStyleClassNames) == false) { > > Maybe replace the `==false` with `!`. I've kept the style the same, there is another line like this just below it. Don't like it either personally :) > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 383: > >> 381: hash = (id != null) ? 31 * (hash + id.hashCode()) : 0; >> 382: hash = 31 * (hash + pseudoClassState.hashCode()); >> 383: return hash; > > Is it worth caching the hash code for this class? I put a debug print in to this method, and then started JFXCentral application (which is quite big) -- it's never called, so doesn't look like it is used anywhere. Selectors are most often stored in `List`s, didn't find any `Map`s or `Set`s that use it as a key. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1442407347 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1442406830 From mfox at openjdk.org Fri Jan 5 01:05:45 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 5 Jan 2024 01:05:45 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v5] In-Reply-To: References: Message-ID: > When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. > > This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Now handling stages that straddle two screens ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1311/files - new: https://git.openjdk.org/jfx/pull/1311/files/3a599216..9198fc52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=03-04 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1311.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1311/head:pull/1311 PR: https://git.openjdk.org/jfx/pull/1311 From john.hendrikx at gmail.com Fri Jan 5 01:15:03 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 5 Jan 2024 02:15:03 +0100 Subject: Possible removal of public API in SimpleSelector Message-ID: In a new PR (https://github.com/openjdk/jfx/pull/1316) I've deprecated two methods for removal. ???? SimpleSelector#getStyleClasses ???? SimpleSelector#getStyleClassSet I think these are safe to remove because even though they are public, and part of public API, the only way to reach them is by casting a `Selector` to `SimpleSelector` as `SimpleSelector`s cannot be publicly constructed (they have a package private constructor only). The first method which returns a `List` is not used within FX, and seems to have been created to allow users to get the style classes as a List, but its unreachable without casting.? A search on Google using the quoted "javafx.css.SimpleSelector" (which you would find in an import) and this method name returns no results outside of SimpleSelector itself. The second method was used by FX before the PR to get the style classes for use by the internal class `SelectorPartitioning`.? It is public so that this internal class can reach it.? It does this by doing an instanceof check (it gets the generic Selector class, and then tests if it is a CompoundSelector or SimpleSelector).? As this was the only user of this method (checked with Google search again), and the method is hard to reach (must do a cast), I think it is safe to remove it. Please let me know if I missed anything. --John From mfox at openjdk.org Fri Jan 5 01:22:59 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 5 Jan 2024 01:22:59 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v6] In-Reply-To: References: Message-ID: > When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. > > This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Removed superfluous import ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1311/files - new: https://git.openjdk.org/jfx/pull/1311/files/9198fc52..17bc11d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1311.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1311/head:pull/1311 PR: https://git.openjdk.org/jfx/pull/1311 From jhendrikx at openjdk.org Fri Jan 5 01:30:32 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 01:30:32 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <41KEOn_R4VM6l2HZajl_o53dYjEO3YVUEf5qj2xF9c4=.cefb5692-49bb-43c7-8533-7476422b045f@github.com> On Thu, 4 Jan 2024 14:23:14 GMT, Nir Lisker wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > I just scrolled quickly through the changes and left some comments, > > If deprecation for removal is part of the PR the consequences will need to be discussed. Are the for-removal classes and methods not widely used? > As @nlisker notes, the implications of any deprecation will need to be discussed. In particular, we need to consider what the consequences are for existing applications. If any of them might be used by apps, then simple deprecation (rather than deprecating for removal) might be best. The methods cannot be reached easily even though they are public. It would involve creating a `Selector` using `Selector#createSelector`, and then casting it to `SimpleSelector` to get access to its public methods that are not inherited from `Selector`. `SimpleSelector` itself does not have a public constructor, and the type `SimpleSelector` is not returned anywhere directly (it is always just `Selector` in the public API). The only use of one of the deprecated methods is to allow access for the internal class `SelectorPartitioning` which indeed does an `instanceof` to reach it. The other method is not used anywhere, and seems to have been an attempt to make the selectors available in the same form as you'd find them on nodes `Styleable#getStyleClass` (which is a `List`), but is hard to reach (probably an oversight that it got exposed in the final API). Google searches turn up no hits in 3rd party code for either of these. I've posted on the mailing list to discuss it further. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1877986349 From jhendrikx at openjdk.org Fri Jan 5 01:34:34 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 01:34:34 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 15:28:45 GMT, Michael Strau? wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 81: > >> 79: * @deprecated for future removal, use {@link #getStyleClassNames()} instead >> 80: */ >> 81: public List getStyleClasses() { > > Have you considered keeping this method (instead of adding a new `getStyleClassNames`), and have `FixedCapacitySet` implement `List` to make it work? This is possible, although `List#get` would not perform too well when it is implemented for `FixedCapacitySet.OpenAddressed` as the array used as hash table in this class can have gaps (so we'd need to iterate to find the index). However, I am very sure this method is not used anywhere (not even in 3rd party code as it requires casting to access), and I wouldn't encourage its use, so I'd be more inclined to remove it completely. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1442420901 From jhendrikx at openjdk.org Fri Jan 5 01:45:56 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 01:45:56 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). 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 eight additional commits since the last revision: - Merge branch 'master' into feature/selector-performance-improvement - Add since tag to new API - Add deprecated annotation and fixed deprecation descriptions - Use copyOf instead of Collections.unmodifiableList(new ArrayList<>(x)) - Pull up frozen field to abstract FixedCapacitySet class - Add copyright header - Deprecate StyleClass and remove StyleClassSet for faster solution - Fix regression ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/8da98928..6c3271b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=00-01 Stats: 155 lines in 31 files changed: 51 ins; 44 del; 60 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From jhendrikx at openjdk.org Fri Jan 5 01:45:57 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 Jan 2024 01:45:57 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 4 Jan 2024 13:38:31 GMT, Nir Lisker wrote: >> 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 eight additional commits since the last revision: >> >> - Merge branch 'master' into feature/selector-performance-improvement >> - Add since tag to new API >> - Add deprecated annotation and fixed deprecation descriptions >> - Use copyOf instead of Collections.unmodifiableList(new ArrayList<>(x)) >> - Pull up frozen field to abstract FixedCapacitySet class >> - Add copyright header >> - Deprecate StyleClass and remove StyleClassSet for faster solution >> - Fix regression > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 81: > >> 79: * collection or making a read-only copy. >> 80: */ >> 81: public abstract void freeze(); > > All the permitted subclasses have the same implementation of this method. Any reason not to pull up the `boolean frozen` field to this class and make this method concrete with `frozen = true;`? I've pulled it up, it does make it a bit nicer. > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 81: > >> 79: * @deprecated for future removal, use {@link #getStyleClassNames()} instead >> 80: */ >> 81: public List getStyleClasses() { > > Deprecating requires the `@Deprecate` annotation (possibly with setting `forRemoval = true`). The javadoc tag needs only to mention why (e.g., "no longer needed because...") and what to replace it with. > > Same for the other deprecations. Thanks, I've updated these. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1442425021 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1442424866 From fweimer at openjdk.org Fri Jan 5 17:55:59 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Fri, 5 Jan 2024 17:55:59 GMT Subject: RFR: 8323077: C type error (incompatible function pointer) in X11GLContext.c Message-ID: 8323077: C type error (incompatible function pointer) in X11GLContext.c ------------- Commit messages: - 8323077: C type error (incompatible function pointer type) in X11GLContext.c Changes: https://git.openjdk.org/jfx/pull/1319/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323077 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1319.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1319/head:pull/1319 PR: https://git.openjdk.org/jfx/pull/1319 From fweimer at openjdk.org Fri Jan 5 18:32:38 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Fri, 5 Jan 2024 18:32:38 GMT Subject: RFR: 8323078: Incorrect length argument to g_utf8_strlen in pango.c Message-ID: 8323078: Incorrect length argument to g_utf8_strlen in pango.c ------------- Commit messages: - 8323078: Incorrect length argument to g_utf8_strlen in pango.c Changes: https://git.openjdk.org/jfx/pull/1320/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1320&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323078 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1320.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1320/head:pull/1320 PR: https://git.openjdk.org/jfx/pull/1320 From kcr at openjdk.org Fri Jan 5 18:55:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Jan 2024 18:55:40 GMT Subject: RFR: 8323078: Incorrect length argument to g_utf8_strlen in pango.c In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 17:52:03 GMT, Florian Weimer wrote: > 8323078: Incorrect length argument to g_utf8_strlen in pango.c I wonder if casting to `gssize` would be better than removing the cast entirely? Are there any platforms on which `gssize` could be a 32-bit int? If so, there might still be a warning on those platforms? If it's always guaranteed to be 64-bits, then your fix is fine. > issue add JDK-8323078 As an FYI, this is not necessary if you include the bug ID in the PR title (which you did). It's not harmful either, just a no-op. modules/javafx.graphics/src/main/native-font/pango.c line 427: > 425: { > 426: if (!str) return 0; > 427: return (jlong)g_utf8_strlen((const gchar *)str, pos); Should this be cast to `(gssize)`? ------------- PR Review: https://git.openjdk.org/jfx/pull/1320#pullrequestreview-1806653439 PR Comment: https://git.openjdk.org/jfx/pull/1320#issuecomment-1879122792 PR Review Comment: https://git.openjdk.org/jfx/pull/1320#discussion_r1443258905 From kcr at openjdk.org Sat Jan 6 00:03:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 Jan 2024 00:03:40 GMT Subject: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Message-ID: As noted in the JBS bug, this is a follow-on to [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered while testing the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the IME code when using WebView in a JFXPanel on macOS). I have tested this in connection with with the proposed fix for JDK-8221261, although it is a valid fix regardless. This expands the fix done in [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the WebKit methods on the right thread. Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. ------------- Commit messages: - 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Changes: https://git.openjdk.org/jfx/pull/1321/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322703 Stats: 62 lines in 1 file changed: 33 ins; 18 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1321.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1321/head:pull/1321 PR: https://git.openjdk.org/jfx/pull/1321 From kcr at openjdk.org Sat Jan 6 00:03:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 Jan 2024 00:03:40 GMT Subject: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 23:59:31 GMT, Kevin Rushforth wrote: > As noted in the JBS bug, this is a follow-on to [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered while testing the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the IME code when using WebView in a JFXPanel on macOS). > > I have tested this in connection with with the proposed fix for JDK-8221261, although it is a valid fix regardless. > > This expands the fix done in [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the WebKit methods on the right thread. Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. @jaybhaskar Can you be one of the reviewers? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1321#issuecomment-1879411014 From john.hendrikx at gmail.com Sat Jan 6 10:29:04 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 6 Jan 2024 11:29:04 +0100 Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <2a35cc76-83fc-2e1c-6197-21611c3f25e6@gmail.com> It's a very nice application, I had never seen it before.? As the original bug was reported against it that caused a performance regression, I started using it to also test a potential performance improvement.? Although I think it does a back-end call every time I "refresh", so I might have been hitting your servers a bit during that period. I'll let you know if I discover that's off.? Only thing I did was disable a piece of code that was causing a stack trace to be logged each time (a bug in one of the components, fx tray icon, I think). --John On 04/01/2024 22:49, Dirk Lemmermann wrote: > I truly love the fact that you guys are starting to use JFXCentral for benchmarking / testing :-) If anyone encounters things bad for performance unrelated to JavaFX itself but caused by JFXCentral then please let me know. > > Dirk > > >> Am 04.01.2024 um 13:31 schrieb John Hendrikx : >> >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). >> >> ------------- >> >> Commit messages: >> - Deprecate StyleClass and remove StyleClassSet for faster solution >> - Fix regression >> >> Changes: https://git.openjdk.org/jfx/pull/1316/files >> Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=00 >> Issue: https://bugs.openjdk.org/browse/JDK-8322964 >> Stats: 878 lines in 8 files changed: 643 ins; 172 del; 63 mod >> Patch: https://git.openjdk.org/jfx/pull/1316.diff >> Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 >> >> PR: https://git.openjdk.org/jfx/pull/1316 From kevin.rushforth at oracle.com Sat Jan 6 15:01:35 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 6 Jan 2024 07:01:35 -0800 Subject: Fwd: JavaFX WebView and markdown rendering... In-Reply-To: References: Message-ID: Redirecting this discussion to openjfx-dev (which is where it belongs). -- Kevin -------- Forwarded Message -------- Subject: Re: JavaFX WebView and markdown rendering... Date: Sat, 6 Jan 2024 06:58:14 -0800 From: Kevin Rushforth To: Davide Perini , openjfx-discuss at openjdk.org No, WebView does not render markdown. That is something done on the server. Some websites (e.g., GitHub) will render markdown by generating the appropriate HTML on the fly. I can reproduce what you are seeing using a GitHub gist containing a simple markdown file: https://gist.github.com/kevinrushforth/26a76c5ccd2d41df798c2a29542a3414 That page is rendered correctly in Chrome and Firefox. It shows both bold and italic for the last line of text (the one that reads "This is some bold text and some italicized text"). The"GitHub openjdk/jfx" link also works and takes you to the openjdk/jfx repo on GitHub. When rendered using WebView (on Windows 11 at least), everything is correctly rendered except the bold text. The link works correctly. I'm not sure where the problem is, but I can file a bug. It might be related to synthetic bolding of text...we've had other bugs in that area in the past. I can't recall whether there are still outstanding bugs. -- Kevin On 1/6/2024 4:22 AM, Davide Perini wrote: > I think that the webview itself is able to turn the markdown into > something that is correctly rendered. > > [this text](http://acme.org) > for example is correctly turned into a clickable link, where the text > of the link is "this text" and the click opens the acme.org website. > > I'm not really into the webview implementation... > > > Il 05/01/2024 22:34, Tom Eugelink ha scritto: >> I'm missing the part on how the markdown is turned into HTML. Because >> the WebView cannot render markdown directly...? >> >> Bold in HTML is not done using **, it is done with font-weight >> (https://www.udacity.com/blog/2021/01/html-css-font-weight.html) or >> (https://www.w3schools.com/tags/tag_b.asp), so something is >> turning that ** into actual HTML, and that is not working. >> >> >> >> On 2024-01-05 18:45, Davide Perini wrote: >>> Hi all, >>> I have a simple javafx.scene.web.WebView >>> >>> code is as simple as this: >>> >>> WebViewwv =new WebView(); >>> wv.getEngine().load(webUrl); >>> Alert alert = createAlert(title, header, alertType); >>> alert.getDialogPane().setContent(wv); >>> alert.showAndWait(); >>> >>> >>> As you can see the webview loads a webUrl, that web url returns a >>> markdown. >>> >>> Mark down is correctly rendered, I can see correct headings, links >>> are interpreted correctly like links and are clickable, ecc. >>> The only things that seems to not work is the bold text. >>> >>> Bold text **like this** or __like this__ >>> is interpreted "like this", without the ** or __ >>> but it's not bold, it is rendered like a normal text. >>> >>> Any idea on how to fix it? :) >>> >>> Thanks >>> Davide >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Sat Jan 6 15:04:27 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 6 Jan 2024 07:04:27 -0800 Subject: JavaFX WebView and markdown rendering... In-Reply-To: <6ddc8591-f894-457c-91f0-76a4a587356e@dpsoftware.org> References: <0101ccd5-7a22-4972-a8a8-df2d13323211@dpsoftware.org> <1631f5da-b658-4240-a1f9-fc86e746d479@tbee.org> <6ddc8591-f894-457c-91f0-76a4a587356e@dpsoftware.org> Message-ID: Redirecting to openjfx-dev As I mentioned in my last message (which I sent before reading this), I think there is a JavaFX bug at work here. Other browsers correctly render the HTML that GitHub turns the markdown into. JavaFX WebView renders most of it correctly, but does not render the bold text as bold. -- Kevin On 1/6/2024 5:47 AM, Davide Perini wrote: > Ooops, it was my bad. > I was loading a markdown from GitHub pages, and it seems that GitHub > pages automatically translates markdown into HTML > if the markdown is named like index.md... > > Problem solved, it's a GitHub pages one, not a JavaFX one :) > > Thanks > Davide > > Il 06/01/2024 13:22, Davide Perini ha scritto: >> I think that the webview itself is able to turn the markdown into >> something that is correctly rendered. >> >> [this text](http://acme.org) >> for example is correctly turned into a clickable link, where the text >> of the link is "this text" and the click opens the acme.org website. >> >> I'm not really into the webview implementation... >> >> >> Il 05/01/2024 22:34, Tom Eugelink ha scritto: >>> I'm missing the part on how the markdown is turned into HTML. >>> Because the WebView cannot render markdown directly...? >>> >>> Bold in HTML is not done using **, it is done with font-weight >>> (https://www.udacity.com/blog/2021/01/html-css-font-weight.html) or >>> (https://www.w3schools.com/tags/tag_b.asp), so something is >>> turning that ** into actual HTML, and that is not working. >>> >>> >>> >>> On 2024-01-05 18:45, Davide Perini wrote: >>>> Hi all, >>>> I have a simple javafx.scene.web.WebView >>>> >>>> code is as simple as this: >>>> >>>> WebViewwv =new WebView(); >>>> wv.getEngine().load(webUrl); >>>> Alert alert = createAlert(title, header, alertType); >>>> alert.getDialogPane().setContent(wv); >>>> alert.showAndWait(); >>>> >>>> >>>> As you can see the webview loads a webUrl, that web url returns a >>>> markdown. >>>> >>>> Mark down is correctly rendered, I can see correct headings, links >>>> are interpreted correctly like links and are clickable, ecc. >>>> The only things that seems to not work is the bold text. >>>> >>>> Bold text **like this** or __like this__ >>>> is interpreted "like this", without the ** or __ >>>> but it's not bold, it is rendered like a normal text. >>>> >>>> Any idea on how to fix it? :) >>>> >>>> Thanks >>>> Davide >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Jan 6 15:12:34 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 Jan 2024 15:12:34 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v6] In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 01:22:59 GMT, Martin Fox wrote: >> When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. >> >> This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Removed superfluous import Looks good. I tested it on a dual-screen system with different screen scales and it all works as expected. @arapte Can you be the second reviewer? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1311#pullrequestreview-1807484278 PR Comment: https://git.openjdk.org/jfx/pull/1311#issuecomment-1879724220 From kcr at openjdk.org Sat Jan 6 15:13:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 Jan 2024 15:13:31 GMT Subject: RFR: 8301893: IME window position is off on secondary screen In-Reply-To: References: Message-ID: <7f6UwpfVWWiyKm6t8o4QAFgy_3f_TuDYutjb4f1COdo=.d9d9b8e3-c02f-4543-9539-32c467893c33@github.com> On Wed, 27 Dec 2023 00:01:10 GMT, Martin Fox wrote: > The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). @andy-goryachev-oracle Can you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1313#issuecomment-1879724473 From kevin.rushforth at oracle.com Sat Jan 6 15:36:53 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 6 Jan 2024 07:36:53 -0800 Subject: JavaFX WebView and markdown rendering... In-Reply-To: References: Message-ID: <24f3d977-1cfb-4d7b-bdf5-f09a0eb521b9@oracle.com> I filed https://bugs.openjdk.org/browse/JDK-8323099 to track this bug. -- Kevin On 1/6/2024 7:01 AM, Kevin Rushforth wrote: > Redirecting this discussion to openjfx-dev (which is where it belongs). > > -- Kevin > > > -------- Forwarded Message -------- > Subject: Re: JavaFX WebView and markdown rendering... > Date: Sat, 6 Jan 2024 06:58:14 -0800 > From: Kevin Rushforth > To: Davide Perini , > openjfx-discuss at openjdk.org > > > > No, WebView does not render markdown. That is something done on the > server. Some websites (e.g., GitHub) will render markdown by > generating the appropriate HTML on the fly. > > I can reproduce what you are seeing using a GitHub gist containing a > simple markdown file: > > https://gist.github.com/kevinrushforth/26a76c5ccd2d41df798c2a29542a3414 > > That page is rendered correctly in Chrome and Firefox. It shows both > bold and italic for the last line of text (the one that reads "This is > some bold text and some italicized text"). The"GitHub openjdk/jfx" > link also works and takes you to the openjdk/jfx repo on GitHub. > > When rendered using WebView (on Windows 11 at least), everything is > correctly rendered except the bold text. The link works correctly. > > I'm not sure where the problem is, but I can file a bug. It might be > related to synthetic bolding of text...we've had other bugs in that > area in the past. I can't recall whether there are still outstanding bugs. > > -- Kevin > > > On 1/6/2024 4:22 AM, Davide Perini wrote: >> I think that the webview itself is able to turn the markdown into >> something that is correctly rendered. >> >> [this text](http://acme.org) >> for example is correctly turned into a clickable link, where the text >> of the link is "this text" and the click opens the acme.org website. >> >> I'm not really into the webview implementation... >> >> >> Il 05/01/2024 22:34, Tom Eugelink ha scritto: >>> I'm missing the part on how the markdown is turned into HTML. >>> Because the WebView cannot render markdown directly...? >>> >>> Bold in HTML is not done using **, it is done with font-weight >>> (https://www.udacity.com/blog/2021/01/html-css-font-weight.html) or >>> (https://www.w3schools.com/tags/tag_b.asp), so something is >>> turning that ** into actual HTML, and that is not working. >>> >>> >>> >>> On 2024-01-05 18:45, Davide Perini wrote: >>>> Hi all, >>>> I have a simple javafx.scene.web.WebView >>>> >>>> code is as simple as this: >>>> >>>> WebViewwv =new WebView(); >>>> wv.getEngine().load(webUrl); >>>> Alert alert = createAlert(title, header, alertType); >>>> alert.getDialogPane().setContent(wv); >>>> alert.showAndWait(); >>>> >>>> >>>> As you can see the webview loads a webUrl, that web url returns a >>>> markdown. >>>> >>>> Mark down is correctly rendered, I can see correct headings, links >>>> are interpreted correctly like links and are clickable, ecc. >>>> The only things that seems to not work is the bold text. >>>> >>>> Bold text **like this** or __like this__ >>>> is interpreted "like this", without the ** or __ >>>> but it's not bold, it is rendered like a normal text. >>>> >>>> Any idea on how to fix it? :) >>>> >>>> Thanks >>>> Davide >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Jan 6 16:44:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 Jan 2024 16:44:31 GMT Subject: RFR: 8323077: C type error (incompatible function pointer) in X11GLContext.c In-Reply-To: References: Message-ID: <9n-SUqiCFr9eBruwEo1wTEqBBLF-WdiCKZ7tYpvhomQ=.6d158b80-766b-4c0f-a245-3569a358e7d4@github.com> On Fri, 5 Jan 2024 17:01:25 GMT, Florian Weimer wrote: > 8323077: C type error (incompatible function pointer) in X11GLContext.c Looks good. In looking at the logs from the GHA run I can see that the warning is gone. I note that there is an additional warning on that same line: 2024-01-05T23:04:38.0399339Z /home/runner/work/jfx/jfx/jfx/modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c:278:61: warning: pointer targets in passing argument 1 of ?glXGetProcAddress? differ in signedness [-Wpointer-sign] 2024-01-05T23:04:38.0403438Z 278 | ctxInfo->glXSwapIntervalSGI = glXGetProcAddress("glXSwapIntervalSGI"); 2024-01-05T23:04:38.0404485Z Successfully started process 'command 'gcc'' 2024-01-05T23:04:38.0406410Z | ^~~~~~~~~~~~~~~~~~~~ As long as you are fixing one of the warnings, it would be helpful to fix the other. ------------- PR Review: https://git.openjdk.org/jfx/pull/1319#pullrequestreview-1807506661 From fweimer at openjdk.org Mon Jan 8 09:28:44 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 8 Jan 2024 09:28:44 GMT Subject: RFR: 8323077: C type error (incompatible function pointer) in X11GLContext.c In-Reply-To: <9n-SUqiCFr9eBruwEo1wTEqBBLF-WdiCKZ7tYpvhomQ=.6d158b80-766b-4c0f-a245-3569a358e7d4@github.com> References: <9n-SUqiCFr9eBruwEo1wTEqBBLF-WdiCKZ7tYpvhomQ=.6d158b80-766b-4c0f-a245-3569a358e7d4@github.com> Message-ID: <8BIcffgSP_oP7dK2EfJU1sAay13kSETnNBXhoQ5ssa8=.db950634-bb08-4665-88a8-13ba3fb39f7f@github.com> On Sat, 6 Jan 2024 16:42:19 GMT, Kevin Rushforth wrote: > Looks good. In looking at the logs from the GHA run I can see that the warning is gone. > > I note that there is an additional warning on that same line: > > ``` > 2024-01-05T23:04:38.0399339Z /home/runner/work/jfx/jfx/jfx/modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c:278:61: warning: pointer targets in passing argument 1 of ?glXGetProcAddress? differ in signedness [-Wpointer-sign] > 2024-01-05T23:04:38.0403438Z 278 | ctxInfo->glXSwapIntervalSGI = glXGetProcAddress("glXSwapIntervalSGI"); > 2024-01-05T23:04:38.0404485Z Successfully started process 'command 'gcc'' > 2024-01-05T23:04:38.0406410Z | ^~~~~~~~~~~~~~~~~~~~ > ``` > > As long as you are fixing one of the warnings, it would be helpful to fix the other. I wanted to make the minimal change to fix the build error. I can add the cast to `const GLubyte *`, but I couldn't find an official prototype for the `glXGetProcAddress` function, so I'm not sure if it's consistent across OpenGL implementations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1319#issuecomment-1880638934 From fweimer at openjdk.org Mon Jan 8 10:16:45 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 8 Jan 2024 10:16:45 GMT Subject: RFR: 8323078: Incorrect length argument to g_utf8_strlen in pango.c [v2] In-Reply-To: References: Message-ID: <8r3EcJyL_ln18T3X2kfsLm33baqAia3KVg4yBSl1hI8=.3bb534ee-2fd0-4991-a927-bbd1ff5d65e6@github.com> > 8323078: Incorrect length argument to g_utf8_strlen in pango.c Florian Weimer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8323078: Incorrect length argument to g_utf8_strlen in pango.c ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1320/files - new: https://git.openjdk.org/jfx/pull/1320/files/603e2348..28fd2885 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1320&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1320&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1320.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1320/head:pull/1320 PR: https://git.openjdk.org/jfx/pull/1320 From fweimer at openjdk.org Mon Jan 8 10:16:48 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 8 Jan 2024 10:16:48 GMT Subject: RFR: 8323078: Incorrect length argument to g_utf8_strlen in pango.c [v2] In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 18:48:25 GMT, Kevin Rushforth wrote: >> Florian Weimer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8323078: Incorrect length argument to g_utf8_strlen in pango.c > > modules/javafx.graphics/src/main/native-font/pango.c line 427: > >> 425: { >> 426: if (!str) return 0; >> 427: return (jlong)g_utf8_strlen((const gchar *)str, pos); > > Should this be cast to `(gssize)`? Makes sense, if only for consistency with the `(jlong)` cast of the return type. (Sorry, I forgot I shouldn't force-push for contributions here ?) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1320#discussion_r1444394820 From fweimer at openjdk.org Mon Jan 8 10:19:08 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 8 Jan 2024 10:19:08 GMT Subject: RFR: 8323077: C type error (incompatible function pointer) in X11GLContext.c [v2] In-Reply-To: References: Message-ID: > 8323077: C type error (incompatible function pointer) in X11GLContext.c Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: Suppress -Wpointer-sign warning ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1319/files - new: https://git.openjdk.org/jfx/pull/1319/files/75365a6d..e8349042 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1319&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1319&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1319.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1319/head:pull/1319 PR: https://git.openjdk.org/jfx/pull/1319 From angorya at openjdk.org Mon Jan 8 16:03:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jan 2024 16:03:38 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> Message-ID: <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> On Fri, 5 Jan 2024 01:45:56 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > 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 eight additional commits since the last revision: > > - Merge branch 'master' into feature/selector-performance-improvement > - Add since tag to new API > - Add deprecated annotation and fixed deprecation descriptions > - Use copyOf instead of Collections.unmodifiableList(new ArrayList<>(x)) > - Pull up frozen field to abstract FixedCapacitySet class > - Add copyright header > - Deprecate StyleClass and remove StyleClassSet for faster solution > - Fix regression modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 382: > 380: hash = 31 * (hash + name.hashCode()); > 381: hash = 31 * (hash + selectorStyleClassNames.hashCode()); > 382: hash = 31 * (hash + selectorStyleClassNames.hashCode()); this pattern destroys some information that otherwise should be used to produce a better hash code. instead of `hash = 31 * (hash + newPart);` it should be `hash = 31 * hash + newPart;` (also in CompoundSelector) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1444901165 From jhendrikx at openjdk.org Mon Jan 8 16:21:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 8 Jan 2024 16:21:40 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> Message-ID: On Mon, 8 Jan 2024 16:01:01 GMT, Andy Goryachev wrote: >> 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 eight additional commits since the last revision: >> >> - Merge branch 'master' into feature/selector-performance-improvement >> - Add since tag to new API >> - Add deprecated annotation and fixed deprecation descriptions >> - Use copyOf instead of Collections.unmodifiableList(new ArrayList<>(x)) >> - Pull up frozen field to abstract FixedCapacitySet class >> - Add copyright header >> - Deprecate StyleClass and remove StyleClassSet for faster solution >> - Fix regression > > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 382: > >> 380: hash = 31 * (hash + name.hashCode()); >> 381: hash = 31 * (hash + selectorStyleClassNames.hashCode()); >> 382: hash = 31 * (hash + selectorStyleClassNames.hashCode()); > > this pattern destroys some information that otherwise should be used to produce a better hash code. > instead of > `hash = 31 * (hash + newPart);` > it should be > `hash = 31 * hash + newPart;` > > (also in CompoundSelector) I agree that it is not nice :) However, changing this seems out of scope for this PR as my changes are unrelated to this, and I didn't even touch `CompoundSelector`. As selectors are never stored in sets/maps, it is hard to justify changing this as part of this PR as it would not be related to improving performance. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1444941427 From angorya at openjdk.org Mon Jan 8 16:25:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jan 2024 16:25:36 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> Message-ID: On Mon, 8 Jan 2024 16:19:05 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 382: >> >>> 380: hash = 31 * (hash + name.hashCode()); >>> 381: hash = 31 * (hash + selectorStyleClassNames.hashCode()); >>> 382: hash = 31 * (hash + selectorStyleClassNames.hashCode()); >> >> this pattern destroys some information that otherwise should be used to produce a better hash code. >> instead of >> `hash = 31 * (hash + newPart);` >> it should be >> `hash = 31 * hash + newPart;` >> >> (also in CompoundSelector) > > I agree that it is not nice :) However, changing this seems out of scope for this PR as my changes are unrelated to this, and I didn't even touch `CompoundSelector`. As selectors are never stored in sets/maps, it is hard to justify changing this as part of this PR as it would not be related to improving performance. these lines discard about 4.5 bits of information on each step, surely that will affect performance, no? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1444947194 From kcr at openjdk.org Mon Jan 8 17:18:34 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jan 2024 17:18:34 GMT Subject: RFR: 8323077: C type error (incompatible function pointer) in X11GLContext.c [v2] In-Reply-To: References: Message-ID: <4AhHKBB2KOx-5vzW8XjK-TTKSad1PS_0kkZ22J2d2EY=.fab7b6de-e583-4300-b429-987cf3e10631@github.com> On Mon, 8 Jan 2024 10:19:08 GMT, Florian Weimer wrote: >> 8323077: C type error (incompatible function pointer) in X11GLContext.c > > Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: > > Suppress -Wpointer-sign warning > I wanted to make the minimal change to fix the build error. Always a good idea. The reason I mentioned the other warning is that the two warnings are very related (both are type mismatches due to missing casts). > I can add the cast to const GLubyte *, but I couldn't find an official prototype for the glXGetProcAddress function, so I'm not sure if it's consistent across OpenGL implementations. Thanks for addressing it as well. `glXGetProcAddress` is defined in `glxext.h`, which we include in our sources. See [glxext.h line 155](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-es2/GL/glxext.h#L155) ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1319#pullrequestreview-1809646203 From fweimer at openjdk.org Mon Jan 8 17:23:32 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 8 Jan 2024 17:23:32 GMT Subject: RFR: 8323077: C type error (incompatible function pointer) in X11GLContext.c [v2] In-Reply-To: <4AhHKBB2KOx-5vzW8XjK-TTKSad1PS_0kkZ22J2d2EY=.fab7b6de-e583-4300-b429-987cf3e10631@github.com> References: <4AhHKBB2KOx-5vzW8XjK-TTKSad1PS_0kkZ22J2d2EY=.fab7b6de-e583-4300-b429-987cf3e10631@github.com> Message-ID: <40M862qxt6cSZzxSqYygOsQIHhpdXf9_cRSUS3r-wfA=.9ab8122d-16cf-4da4-9050-290a381f2909@github.com> On Mon, 8 Jan 2024 17:15:39 GMT, Kevin Rushforth wrote: > Thanks for addressing it as well. `glXGetProcAddress` is defined in `glxext.h`, which we include in our sources. See [glxext.h line 155](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-es2/GL/glxext.h#L155) Ahh, then the cast should be correct, thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1319#issuecomment-1881513373 From fweimer at openjdk.org Mon Jan 8 18:02:35 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 8 Jan 2024 18:02:35 GMT Subject: Integrated: 8323077: C type error (incompatible function pointer) in X11GLContext.c In-Reply-To: References: Message-ID: <933hqApN5fOYxvHbvzwp5MsOiZCm1DyfzyytoiGRlic=.81cd600c-ecdf-4a57-bb63-8824db58a9aa@github.com> On Fri, 5 Jan 2024 17:01:25 GMT, Florian Weimer wrote: > 8323077: C type error (incompatible function pointer) in X11GLContext.c This pull request has now been integrated. Changeset: e3f2e968 Author: Florian Weimer Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e3f2e968158f03316f81634ca4b9888aefc3ea48 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8323077: C type error (incompatible function pointer) in X11GLContext.c Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1319 From kcr at openjdk.org Mon Jan 8 18:11:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jan 2024 18:11:33 GMT Subject: RFR: 8323078: Incorrect length argument to g_utf8_strlen in pango.c [v2] In-Reply-To: <8r3EcJyL_ln18T3X2kfsLm33baqAia3KVg4yBSl1hI8=.3bb534ee-2fd0-4991-a927-bbd1ff5d65e6@github.com> References: <8r3EcJyL_ln18T3X2kfsLm33baqAia3KVg4yBSl1hI8=.3bb534ee-2fd0-4991-a927-bbd1ff5d65e6@github.com> Message-ID: <0749K93jlF-vViBtsu4JG9CjbLWcHgcViRWd7HvLakI=.141eb31d-0088-4fd1-939c-4484fe6618af@github.com> On Mon, 8 Jan 2024 10:16:45 GMT, Florian Weimer wrote: >> 8323078: Incorrect length argument to g_utf8_strlen in pango.c > > Florian Weimer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8323078: Incorrect length argument to g_utf8_strlen in pango.c Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1320#pullrequestreview-1809729692 From fweimer at openjdk.org Mon Jan 8 18:38:34 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 8 Jan 2024 18:38:34 GMT Subject: Integrated: 8323078: Incorrect length argument to g_utf8_strlen in pango.c In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 17:52:03 GMT, Florian Weimer wrote: > 8323078: Incorrect length argument to g_utf8_strlen in pango.c This pull request has now been integrated. Changeset: 366b062c Author: Florian Weimer Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/366b062c2f9fd4196cecb7f2113c923491202e59 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8323078: Incorrect length argument to g_utf8_strlen in pango.c Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1320 From jhendrikx at openjdk.org Mon Jan 8 19:18:33 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 8 Jan 2024 19:18:33 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> Message-ID: On Mon, 8 Jan 2024 16:22:42 GMT, Andy Goryachev wrote: >> I agree that it is not nice :) However, changing this seems out of scope for this PR as my changes are unrelated to this, and I didn't even touch `CompoundSelector`. As selectors are never stored in sets/maps, it is hard to justify changing this as part of this PR as it would not be related to improving performance. > > these lines discard about 4.5 bits of information on each step, surely that will affect performance, no? I am confused, and maybe I am missing something. As far as I know, this method is not called anywhere. I put a breakpoint in it. JavaFX does not use this method anywhere, nor are Selectors ever used as keys in Sets or Maps. What am I missing? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1445218594 From angorya at openjdk.org Mon Jan 8 19:26:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jan 2024 19:26:34 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> Message-ID: On Mon, 8 Jan 2024 19:15:31 GMT, John Hendrikx wrote: >> these lines discard about 4.5 bits of information on each step, surely that will affect performance, no? > > I am confused, and maybe I am missing something. As far as I know, this method is not called anywhere. I put a breakpoint in it. JavaFX does not use this method anywhere, nor are Selectors ever used as keys in Sets or Maps. > > What am I missing? you are right, this code does not affect performance (I could not hit a break point here either). still, since you are touching these lines, why not do it right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1445228209 From kcr at openjdk.org Mon Jan 8 21:29:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jan 2024 21:29:44 GMT Subject: RFR: 8323209: Change JavaFX release version to 23 Message-ID: Bump the version number of JavaFX to 23. I will integrate this to master as part of forking the jfx22 stabilization branch, which is scheduled for Thursday, January 11, 2024 at 16:00 UTC. ------------- Commit messages: - 8323209: Change JavaFX release version to 23 Changes: https://git.openjdk.org/jfx/pull/1322/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323209 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1322.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1322/head:pull/1322 PR: https://git.openjdk.org/jfx/pull/1322 From angorya at openjdk.org Mon Jan 8 21:37:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jan 2024 21:37:34 GMT Subject: RFR: 8323209: Change JavaFX release version to 23 In-Reply-To: References: Message-ID: <4_Vf_KZasIIzwu9m3oadbFvc7LMGRjeLP2cYXx89vw4=.c9357472-db08-4403-80b0-2beaeca9680f@github.com> On Mon, 8 Jan 2024 21:24:43 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 23. I will integrate this to master as part of forking the jfx22 stabilization branch, which is scheduled for Thursday, January 11, 2024 at 16:00 UTC. looks good ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1322#pullrequestreview-1810063801 From angorya at openjdk.org Tue Jan 9 00:27:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jan 2024 00:27:31 GMT Subject: RFR: 8301893: IME window position is off on secondary screen In-Reply-To: References: Message-ID: On Wed, 27 Dec 2023 00:01:10 GMT, Martin Fox wrote: > The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). The fix looks good. While testing, I noticed a different issue: - switch input language to Japanese, start typing `arigato` until the candidate list popup appears - backspace to remove the popup - move the application window - type something to bring the IME popup again I expect the IME popup to appear below the new caret position, but instead it pops up where it used to be: ![Screenshot 2024-01-08 at 16 05 54](https://github.com/openjdk/jfx/assets/107069028/c46a6700-dde6-4b5d-90e2-cfd1af7e3ac0) This might be a platform issue, since it can also be reproduced with TextEdit. Could you please confirm? modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 814: > 812: NSRect result = [self->_delegate getInputMethodCandidatePosRequest:0]; > 813: if (NSScreen.screens.count) { > 814: NSRect screenFrame = NSScreen.screens[0].frame; I assume this code block is not entered in the case of a single monitor? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1313#issuecomment-1882041019 PR Review Comment: https://git.openjdk.org/jfx/pull/1313#discussion_r1445502243 From mfox at openjdk.org Tue Jan 9 01:04:33 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 9 Jan 2024 01:04:33 GMT Subject: RFR: 8301893: IME window position is off on secondary screen In-Reply-To: References: Message-ID: <881eZSD15gnqOqpshjTqZLuY3yk3xNJKLRVna2Bo7xg=.2ca6572d-9c91-4e4e-b715-ad4505be2c3f@github.com> On Tue, 9 Jan 2024 00:17:33 GMT, Andy Goryachev wrote: >> The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). > > modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 814: > >> 812: NSRect result = [self->_delegate getInputMethodCandidatePosRequest:0]; >> 813: if (NSScreen.screens.count) { >> 814: NSRect screenFrame = NSScreen.screens[0].frame; > > I assume this code block is not entered in the case of a single monitor? Yes, it is entered if there's a single monitor (NSScreen.screens.count will be 1). We always have to flip the y coordinate. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1313#discussion_r1445522864 From mfox at openjdk.org Tue Jan 9 01:10:31 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 9 Jan 2024 01:10:31 GMT Subject: RFR: 8301893: IME window position is off on secondary screen In-Reply-To: References: Message-ID: <4IrvVzkb0XlydIIGPbaksHcHd6wHti-HtG4vLx_X4L4=.dbfe1718-d250-4b6a-a246-eb8a547057f6@github.com> On Tue, 9 Jan 2024 00:23:23 GMT, Andy Goryachev wrote: >> The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). > > The fix looks good. > While testing, I noticed a different issue: > > - switch input language to Japanese, start typing `arigato` until the candidate list popup appears > - backspace to remove the popup > - move the application window > - type something to bring the IME popup again > I expect the IME popup to appear below the new caret position, but instead it pops up where it used to be: > > ![Screenshot 2024-01-08 at 16 05 54](https://github.com/openjdk/jfx/assets/107069028/c46a6700-dde6-4b5d-90e2-cfd1af7e3ac0) > > This might be a platform issue, since it can also be reproduced with TextEdit. Could you please confirm? @andy-goryachev-oracle On my Mac OS 14.1.2 system I see the same problem where the IM window doesn't track the JavaFX window. I'm seeing the exact same behavior with TextEdit, Pages, and Safari so it appears to be an Apple problem. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1313#issuecomment-1882109049 From angorya at openjdk.org Tue Jan 9 01:25:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jan 2024 01:25:31 GMT Subject: RFR: 8301893: IME window position is off on secondary screen In-Reply-To: References: Message-ID: On Wed, 27 Dec 2023 00:01:10 GMT, Martin Fox wrote: > The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). thank you for clarification! looks good - tested with 1 external monitor and no external monitor. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1313#pullrequestreview-1810268503 From mfox at openjdk.org Tue Jan 9 03:06:32 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 9 Jan 2024 03:06:32 GMT Subject: Integrated: 8301893: IME window position is off on secondary screen In-Reply-To: References: Message-ID: On Wed, 27 Dec 2023 00:01:10 GMT, Martin Fox wrote: > The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). This pull request has now been integrated. Changeset: 37d7561c Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/37d7561c390f706b9e711dd535580fe5ae76e879 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8301893: IME window position is off on secondary screen Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1313 From kpk at openjdk.org Tue Jan 9 07:36:46 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 9 Jan 2024 07:36:46 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation Message-ID: In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. Added system tests to validate the changes. ------------- Commit messages: - Fix rtl text hittest issue Changes: https://git.openjdk.org/jfx/pull/1323/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319844 Stats: 1018 lines in 5 files changed: 980 ins; 10 del; 28 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From arapte at openjdk.org Tue Jan 9 07:51:34 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Jan 2024 07:51:34 GMT Subject: RFR: 8323209: Change JavaFX release version to 23 In-Reply-To: References: Message-ID: <2AW2E5MniR5gje_t8kZaFt_bFcm1hiUOFpv8I-Rc2Vw=.15fd46ee-d8e1-4006-a2f8-2460116a46f0@github.com> On Mon, 8 Jan 2024 21:24:43 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 23. I will integrate this to master as part of forking the jfx22 stabilization branch, which is scheduled for Thursday, January 11, 2024 at 16:00 UTC. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1322#pullrequestreview-1810568804 From jvos at openjdk.org Tue Jan 9 09:21:32 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jan 2024 09:21:32 GMT Subject: RFR: 8323209: Change JavaFX release version to 23 In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 21:24:43 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 23. I will integrate this to master as part of forking the jfx22 stabilization branch, which is scheduled for Thursday, January 11, 2024 at 16:00 UTC. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1322#pullrequestreview-1810720622 From jvos at openjdk.org Tue Jan 9 13:19:53 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jan 2024 13:19:53 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with two additional commits since the last revision: - Cleanup test - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. Add a test to make sure those references are gone. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/9b1133cd..d5a78749 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=04-05 Stats: 493 lines in 5 files changed: 317 ins; 175 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Tue Jan 9 13:25:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jan 2024 13:25:33 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 13:19:53 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with two additional commits since the last revision: > > - Cleanup test > - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. > Add a test to make sure those references are gone. I added a systemtest using a new Shim (`GlassSystemMenuShim`) that keeps track of the `com.sun.glass.ui.Menu` instances that are created in the `GlassSystemMenu`. I had to do a few more hacks since you don't normally access `GlassSystemMenu` yourself (the MenuBarSkin is doing most of the work). Note that this is very platform-dependent, as the creation of the `com.sun.glass.ui.Menu` is done by the `com.sun.glass.ui.Application` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1883047997 From angorya at openjdk.org Tue Jan 9 16:36:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jan 2024 16:36:39 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 13:19:53 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with two additional commits since the last revision: > > - Cleanup test > - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. > Add a test to make sure those references are gone. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 98: > 96: active.set(false); > 97: } > 98: active = new SimpleBooleanProperty(true); should this be if(active == null) { active = new ... } else { active.set(false); } instead? modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 224: > 222: mb.textProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); > 223: mb.disableProperty().when(active).addListener(valueModel -> glassMenu.setEnabled(!mb.isDisable())); > 224: mb.mnemonicParsingProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); is `active` guaranteed to be non-null at this point (and also on L279)? assuming the code on L98 is fixed and does not clobber the old pointer. tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 227: > 225: if (!JMemoryBuddy.checkCollectable(wr)) { > 226: strongCount++; > 227: assertTrue("Too much refs", strongCount < 2); "too many" ? tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 254: > 252: return menuBar; > 253: } > 254: extra newline? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1446313415 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1446323094 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1446325052 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1446327877 From duke at openjdk.org Tue Jan 9 17:48:46 2024 From: duke at openjdk.org (duke) Date: Tue, 9 Jan 2024 17:48:46 GMT Subject: Withdrawn: 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/870 From arapte at openjdk.org Wed Jan 10 05:16:36 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Jan 2024 05:16:36 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v6] In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 01:22:59 GMT, Martin Fox wrote: >> When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. >> >> This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Removed superfluous import Looks good , tested on Windows 11 ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1311#pullrequestreview-1812421050 From johan.vos at gluonhq.com Wed Jan 10 10:10:40 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 10 Jan 2024 11:10:40 +0100 Subject: MacOS windowDidBecomeKey inconsistency Message-ID: I noticed different test results when running systemtests on a mac/intel versus an M2. when running systemtests from a command line using `sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest :systemTests:test --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` I traced it down to `windowDidBecomeKey` on `GlassWindow+Overrides.m` not being called on the M2. That of course leads to different paths, hence different test results. I wonder if this is somehow related to https://bugs.openjdk.org/browse/JDK-8089848. Before looking into this, is this something others observed as well? - Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fkirmaier at openjdk.org Wed Jan 10 12:35:55 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 10 Jan 2024 12:35:55 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels Message-ID: As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. With this PR, always the default cell height is used, to determine how much is scrolled. This makes the behavior more consistent. Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 ------------- Commit messages: - JDK-8323511 Changes: https://git.openjdk.org/jfx/pull/1326/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323511 Stats: 82 lines in 3 files changed: 67 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From kcr at openjdk.org Wed Jan 10 12:39:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 12:39:35 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 12:31:20 GMT, Florian Kirmaier wrote: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Reviewers: @johanvos @andy-goryachev-oracle ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1884771651 From jvos at openjdk.org Wed Jan 10 12:54:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 10 Jan 2024 12:54:33 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 12:31:20 GMT, Florian Kirmaier wrote: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Thanks for the PR! Quick observations: * The unit test is indeed clear and at first sight, it looks to me that this is reasonable behavior. One of the hard parts with the VirtualFlow and related concepts, is that different use case scenarios assume different "reasonable behavior". Since we now have more tests than before, I am increasingly confident that a new change to the behavior is not causing regression. * Until we have the exact heights of all cells, the different measurable values (thumb location of scrollbar, position of the cell) can not be set simultaneously to desired values. (That is one of the other hard parts). Hence, changing the behavior of the scrollbar may affect the accuracy of the cell positioning in other scenario's. Again, since we have a growing amount of tests, I'm less worried about this. I'll look into this more detailed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1884795204 From angorya at openjdk.org Wed Jan 10 16:05:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 16:05:35 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 12:31:20 GMT, Florian Kirmaier wrote: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 For what it's worth, I just wanted to mention an alternative algorithm that was used in another project: 1. keep a cache of at least one screenful of laid out cells above and below the view port (a sliding window). this enables correct scrolling when pixels (screen dimensions) are used, as in page up / page down, or when navigating close to the start/end 2. do not update scroll bar min/max/thumb while the user is scrolling using the scroll bar. do update on MOUSE_RELEASED event. this eliminates flicker when cells with different sizes come into play Please let me know if you want to see the code. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1885141138 From angorya at openjdk.org Wed Jan 10 17:29:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 17:29:35 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 07:31:51 GMT, Karthik P K wrote: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. MonkeyTester encounters an NPE on launch: Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.scene.Scene.getNodeOrientation()" because the return value of "javafx.scene.text.Text.getScene()" is null at javafx.graphics/javafx.scene.text.Text.findRunIndex(Text.java:1042) at javafx.graphics/javafx.scene.text.Text.hitTest(Text.java:1027) at javafx.controls/com.sun.javafx.scene.control.skin.Utils.computeTruncationIndex(Utils.java:208) at javafx.controls/com.sun.javafx.scene.control.skin.Utils.computeClippedText(Utils.java:281) at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.updateDisplayedText(LabeledSkinBase.java:1136) at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.layoutLabelInArea(LabeledSkinBase.java:552) at javafx.controls/javafx.scene.control.skin.LabeledSkinBase.layoutLabelInArea(LabeledSkinBase.java:475) at javafx.controls/javafx.scene.control.skin.TableCellSkinBase.layoutChildren(TableCellSkinBase.java:147) at javafx.controls/javafx.scene.control.Control.layoutChildren(Control.java:612) at javafx.controls/javafx.scene.control.Cell.layoutChildren(Cell.java:635) at javafx.controls/javafx.scene.control.TableCell.layoutChildren(TableCell.java:711) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1208) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:595) at javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2601) at javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:598) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:578) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:571) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$11(QuantumToolkit.java:352) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1885288059 From kcr at openjdk.org Wed Jan 10 17:37:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 17:37:17 GMT Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Message-ID: As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWait` allows them to run when in `doAWTRunLoop` so there is no deadlock. This is a better fix than the proposed fix in PR openjdk/jdk#17290 for two reasons. First, it is a more targeted fix. For example, it doesn't open the door for processing mouse events while in `doAWTRunLoop`. Second, by fixing it in JavaFX, we can fix additional threading bugs like [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703) and [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784) without worrying about introducing deadlocks if run on a JDK without the fix. ------------- Commit messages: - 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Changes: https://git.openjdk.org/jfx/pull/1327/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1327&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8221261 Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1327.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1327/head:pull/1327 PR: https://git.openjdk.org/jfx/pull/1327 From kcr at openjdk.org Wed Jan 10 17:37:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 17:37:18 GMT Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: <5oOLWHkQQnkZnobXS6i45KdpTq8mEIL4Zt4I687Gb1U=.43b590fa-2414-42f9-8d0f-11d4de2b17d4@github.com> On Wed, 10 Jan 2024 14:54:47 GMT, Kevin Rushforth wrote: > As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. > > This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. > > This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. > > The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). > > A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. > > Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. > > NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. > > Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWait` allows them to run when in... Reviewers: @prrace @jaybhaskar ------------- PR Comment: https://git.openjdk.org/jfx/pull/1327#issuecomment-1885299231 From kpk at openjdk.org Wed Jan 10 17:41:34 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 10 Jan 2024 17:41:34 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 17:25:35 GMT, Andy Goryachev wrote: > MonkeyTester encounters an NPE on launch: > @andy-goryachev-oracle did you find this NPE on any specific page? I couldn't see this issue ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1885310400 From kcr at openjdk.org Wed Jan 10 17:42:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 17:42:32 GMT Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 14:54:47 GMT, Kevin Rushforth wrote: > As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. > > This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. > > This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. > > The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). > > A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. > > Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. > > NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. > > Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWait` allows them to run when in... NOTE to reviewers: If you want to test this with WebView in a JFXPanel, you will also need the fix for [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703), which is under review in PR #1321 to avoid a crash (that crash was effectively hidden by this deadlock so it was missed earlier). I have created a test branch that has both fixes: https://github.com/kevinrushforth/jfx/tree/test-8221261-8322703 You can either fetch that branch or fetch both PR branches and build. It is not necessary to build the native WebKit if you have an up-to-date library in your cache. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1327#issuecomment-1885311069 From mfox at openjdk.org Wed Jan 10 17:48:39 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 10 Jan 2024 17:48:39 GMT Subject: Integrated: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows In-Reply-To: References: Message-ID: <3DvWwdpVc6EwTZuR2CMC96UMVu3sNiVslJSz65uSaHM=.2c8843b9-9d5e-4c0e-b139-c7db2016aaf3@github.com> On Tue, 26 Dec 2023 16:48:19 GMT, Martin Fox wrote: > When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. > > This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. This pull request has now been integrated. Changeset: 5b1fce55 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/5b1fce559d6a3abb8ab19daf6b1177dc4ba3fcdd Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows 8254126: the position of Chinese Input Method candidates window is wrong Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1311 From hmeda at openjdk.org Wed Jan 10 18:16:49 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 10 Jan 2024 18:16:49 GMT Subject: RFR: 8318614: Update WebKit to 617.1 Message-ID: This PR updates webkit to v617.1. Verified build on Mac,Windows and linux. Sanity testing looks fine. No issues observed in HelloWebView as well ------------- Commit messages: - Remove unwanted files - Update webkit to v617.1 Changes: https://git.openjdk.org/jfx/pull/1328/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1328&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318614 Stats: 289254 lines in 6439 files changed: 170206 ins; 83308 del; 35740 mod Patch: https://git.openjdk.org/jfx/pull/1328.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1328/head:pull/1328 PR: https://git.openjdk.org/jfx/pull/1328 From angorya at openjdk.org Wed Jan 10 18:36:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 18:36:36 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 07:31:51 GMT, Karthik P K wrote: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Table View Page (TVP), I think. Select TVP, close the app, restart. Also seems to happen when navigating to the TVP. In any case, we should be checking for null or maybe use the node's orientation rather than the scene's. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1885406548 From kcr at openjdk.org Wed Jan 10 18:44:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 18:44:42 GMT Subject: RFR: 8318614: Update WebKit to 617.1 In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 17:53:46 GMT, Hima Bindu Meda wrote: > This PR updates webkit to v617.1. Verified build on Mac,Windows and linux. > Sanity testing looks fine. No issues observed in HelloWebView as well This will not be integrated until after tomorrow's `jfx22` fork (so the warning about the fixVersion not matching can be ignored). Reviewers: @kevinrushforth @johanvos @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1328#issuecomment-1885419246 From kcr at openjdk.org Wed Jan 10 18:51:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 18:51:35 GMT Subject: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 23:59:31 GMT, Kevin Rushforth wrote: > As noted in the JBS bug, this is a follow-on to [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered while testing the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the IME code when using WebView in a JFXPanel on macOS). > > I have tested this in connection with with the proposed fix for JDK-8221261, although it is a valid fix regardless. > > This expands the fix done in [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the WebKit methods on the right thread. Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. NOTE to reviewers: If you want to test this, you will also need the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261), which is under review in PR #1327 to avoid the deadlock. I have created a test branch that has both fixes: https://github.com/kevinrushforth/jfx/tree/test-8221261-8322703 You can either fetch that branch or fetch both PR branches and build. It is not necessary to build the native WebKit if you have an up-to-date library in your cache. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1321#issuecomment-1885428778 From duke at openjdk.org Wed Jan 10 18:58:45 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Wed, 10 Jan 2024 18:58:45 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null Message-ID: This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. ------------- Commit messages: - JDK-8323543: adds similar safety test in TreeTableViewTest - JDK-8323543: Fixes Nullpointer in TableSkinUtils Changes: https://git.openjdk.org/jfx/pull/1329/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323543 Stats: 53 lines in 4 files changed: 41 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1329.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1329/head:pull/1329 PR: https://git.openjdk.org/jfx/pull/1329 From duke at openjdk.org Wed Jan 10 19:09:47 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Wed, 10 Jan 2024 19:09:47 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v2] In-Reply-To: References: Message-ID: > This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: JDK-8323543: clean up code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1329/files - new: https://git.openjdk.org/jfx/pull/1329/files/31b408c6..54e8668e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1329.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1329/head:pull/1329 PR: https://git.openjdk.org/jfx/pull/1329 From duke at openjdk.org Wed Jan 10 19:14:37 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Wed, 10 Jan 2024 19:14:37 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:09:47 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: clean up code should i add the null checks in this PR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1885486133 From angorya at openjdk.org Wed Jan 10 19:14:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 19:14:35 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 18:53:02 GMT, Carl D?bbelin wrote: > This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. FYI: there is also a possibility of an NPE in TableCellBehavior:70 TableView:2198 TableView:1922 I think we should add null checks there as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1885471906 From angorya at openjdk.org Wed Jan 10 19:22:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 19:22:37 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:09:47 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: clean up code I think it makes sense to add the checks in this PR. We are addressing the issue and not introducing new code paths. I wonder if we should also add the unit tests to cover the newly added checks. What do you think? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 6081: > 6079: > 6080: assertDoesNotThrow(() -> Toolkit.getToolkit().firePulse()); > 6081: extra newline? modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 7276: > 7274: > 7275: assertDoesNotThrow(() -> Toolkit.getToolkit().firePulse()); > 7276: please remove extra newline ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1885514538 PR Review Comment: https://git.openjdk.org/jfx/pull/1329#discussion_r1447838560 PR Review Comment: https://git.openjdk.org/jfx/pull/1329#discussion_r1447808424 From duke at openjdk.org Wed Jan 10 19:22:38 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Wed, 10 Jan 2024 19:22:38 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:09:47 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: clean up code i will look into whether it is possible to generate a nullpointer with the current code, and add a test to check that they are not thrown anymore. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1885532560 From angorya at openjdk.org Wed Jan 10 19:22:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 19:22:38 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v2] In-Reply-To: References: Message-ID: <9yksv2Drb_FaUlvmeW6GC3IKOphn7PP9r0dykPnT1FM=.d4b075cd-ef54-4a3f-8a55-93552e2d86ba@github.com> On Wed, 10 Jan 2024 19:18:22 GMT, Carl D?bbelin wrote: >> Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323543: clean up code > > i will look into whether it is possible to generate a nullpointer with the current code, and add a test to check that they are not thrown anymore. Thank you @EstelonAgarwaen and @Maran23 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1885541182 From mhanl at openjdk.org Wed Jan 10 19:26:38 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Jan 2024 19:26:38 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling Message-ID: This PR fixes the border glitch/gap as explained in both linked tickets. I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). And this also fixes the issue, while behaving the same as before. In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` To better understand this, the container structure (tree) is shown below: - ScrollPane - viewRect -> `setClip` -> clipRect (viewContent size) - viewContent -> `setLayoutX` - Content - vsb - hsb - corner --- - VirtualFlow - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) - clippedContainer/clipView -> `setLayoutX` (when scrolling) - sheet - Cell - vsb - hsb - corner ------------- Commit messages: - JDK-8218745: TableView: visual glitch at borders on horizontal scrolling Changes: https://git.openjdk.org/jfx/pull/1330/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1330&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8218745 Stats: 306 lines in 14 files changed: 122 ins; 41 del; 143 mod Patch: https://git.openjdk.org/jfx/pull/1330.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1330/head:pull/1330 PR: https://git.openjdk.org/jfx/pull/1330 From jvos at openjdk.org Wed Jan 10 19:58:37 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 10 Jan 2024 19:58:37 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 16:21:39 GMT, Andy Goryachev wrote: >> Johan Vos has updated the pull request incrementally with two additional commits since the last revision: >> >> - Cleanup test >> - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. >> Add a test to make sure those references are gone. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 98: > >> 96: active.set(false); >> 97: } >> 98: active = new SimpleBooleanProperty(true); > > should this be > > if(active == null) { > active = new ... > } else { > active.set(false); > } > > instead? No, the explicit goal of this construction is to set active to false (in case it exists) so that existing listeners can be released; followed by creating a new active property that is by default set to true until `setMenus` is called again (e.g. after unfocus/focus events). I noticed however that it is not as simple as that, and the current PR introduces regression, as the `SystemMenuBarTest.testMemoryLeak` test is now failing. Listeners are not only registered when `setMenus` is called, but also when menu(Item)s are added to menus. I'm not sure if a single `active` property can address this, as we don't want to remove all listeners for all menuitems in case a particular menuitem is added to a particular menu. @hjohn does that make sense? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1447895647 From angorya at openjdk.org Wed Jan 10 20:07:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 20:07:34 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:55:35 GMT, Johan Vos wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 98: >> >>> 96: active.set(false); >>> 97: } >>> 98: active = new SimpleBooleanProperty(true); >> >> should this be >> >> if(active == null) { >> active = new ... >> } else { >> active.set(false); >> } >> >> instead? > > No, the explicit goal of this construction is to set active to false (in case it exists) so that existing listeners can be released; followed by creating a new active property that is by default set to true until `setMenus` is called again (e.g. after unfocus/focus events). > I noticed however that it is not as simple as that, and the current PR introduces regression, as the `SystemMenuBarTest.testMemoryLeak` test is now failing. Listeners are not only registered when `setMenus` is called, but also when menu(Item)s are added to menus. I'm not sure if a single `active` property can address this, as we don't want to remove all listeners for all menuitems in case a particular menuitem is added to a particular menu. > @hjohn does that make sense? thank you for clarification! perhaps we ought to add a comment explaining why: it's one thing to create a single chain of conditions linked to a property, but here we keep creating new property instance, so the side effects are not that obvious. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1447910710 From kevin.rushforth at oracle.com Wed Jan 10 20:44:27 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2024 12:44:27 -0800 Subject: FINAL REMINDER: JavaFX 22 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 22] In-Reply-To: References: Message-ID: <02491001-14a9-415a-a2f6-ee3555352a7f@oracle.com> As a reminder, JavaFX 22 RDP1 starts tomorrow, January 11th. I will fork the 'jfx22' branch at 16:00 UTC. -- Kevin On 12/18/2023 9:24 AM, Kevin Rushforth wrote: > As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 22 starts on > Thursday, January 11, 2024 at 16:00 UTC (08:00 US/Pacific time). Given > the upcoming holidays, that's a little over 2 working weeks from now. > > During rampdown of JavaFX 22, the "master" branch of the jfx repo will > be open for JavaFX 23 fixes. > > Please allow sufficient time for any feature that needs a CSR. New > features should be far enough along in the review process that you can > finalize the CSR no later than Thursday, January 4, or it is likely to > miss the window for this release, in which case it can be targeted for > JavaFX 23. > > We will follow the same process as in previous releases for getting > fixes into JavaFX 22 during rampdown. I'll send a message with > detailed information when we fork, but candidates for fixing during > RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc > bugs of any priority. Some small enhancements might be considered > during RDP1, but they require explicit approval; the bar will be high > for such requests. > > -- Kevin > > On 9/21/2023 7:41 AM, Kevin Rushforth wrote: >> Here is the proposed schedule for JavaFX 22. >> >> RDP1: Jan 11, 2024 (aka ?feature freeze?) >> RDP2: Feb 1, 2024 >> Freeze: Feb 29, 2024 >> GA: Mar 19, 2024 >> >> We plan to fork a jfx22 stabilization branch at RDP1. >> >> The start of RDP1, the start of RDP2, and the code freeze will be >> 16:00 UTC on the respective dates. >> >> Please let Johan or me know if you have any questions. >> >> -- Kevin >> > From angorya at openjdk.org Wed Jan 10 21:19:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 21:19:38 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 07:31:51 GMT, Karthik P K wrote: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Preliminary testing looks ok, though it does suffer from effects of JDK-8318095 (and I did remove `this.getScene().` in Text:1042) I wonder if we should address JDK-8318095 first to be able to test this fix fully. Right now there are scenarios when things fail after resizing the split: ![Screenshot 2024-01-10 at 11 48 39](https://github.com/openjdk/jfx/assets/107069028/3852b9dc-1d19-406f-bf39-b81790ec61ca) modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1042: > 1040: int runIndex = 0; > 1041: if (runs.length != 0) { > 1042: if (this.getScene().getNodeOrientation() == NodeOrientation.RIGHT_TO_LEFT) { I think this should not refer to scene: if (getNodeOrientation() == NodeOrientation.RIGHT_TO_LEFT) { modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 202: > 200: double x = point.getX(); > 201: double y = point.getY(); > 202: TextLayout.Hit h = layout.getHitInfo((float)x, (float)y, null, -1, -1); -1 looks like magic value, could you please describe it in the `com.sun.javafx.scene.tex.TextLayout` javadoc in both cases (textRunStart and curRunStart)? tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 48: > 46: import javafx.stage.StageStyle; > 47: import javafx.stage.Window; > 48: import org.junit.After; should we be using junit5 for all new tests? tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 133: > 131: Util.runAndWait(() -> { > 132: Window w = scene.getWindow(); > 133: robot.mouseMove((int) (w.getX() + scene.getX() + x), is there a reason to cast to int? fx robot does accept double arguments, and we might be dealing with fractional scale on some platforms tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 149: > 147: textOne.setFont(new Font(48)); > 148: vBox.getChildren().clear(); > 149: vBox.getChildren().add(textOne); setAll(...) does clear() and add(...) tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 209: > 207: moveMouseOverText(x, 0); > 208: if (isLeading) { > 209: Assert.assertEquals(charIndex, insertionIndex); junit5: Assertions.assertEquals tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 135: > 133: Util.runAndWait(() -> { > 134: Window w = scene.getWindow(); > 135: robot.mouseMove((int) (w.getX() + scene.getX() + x), same comments as for RTLTextCharacterIndexTest... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1885746224 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447887330 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447893349 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447919208 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447917225 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447918283 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447919870 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447925706 From angorya at openjdk.org Wed Jan 10 21:19:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 21:19:38 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:54:34 GMT, Andy Goryachev wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 202: > >> 200: double x = point.getX(); >> 201: double y = point.getY(); >> 202: TextLayout.Hit h = layout.getHitInfo((float)x, (float)y, null, -1, -1); > > -1 looks like magic value, could you please describe it in the `com.sun.javafx.scene.tex.TextLayout` javadoc in both cases (textRunStart and curRunStart)? or, would it make more sense to simply pass a boolean flag instead of magic values? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1447936114 From kcr at openjdk.org Wed Jan 10 21:48:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 21:48:32 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner This will need careful review and testing. @johanvos : I presume you will want to review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-1885786939 PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-1885787623 From angorya at openjdk.org Wed Jan 10 22:41:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jan 2024 22:41:32 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css line 1508: > 1506: } > 1507: > 1508: .list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell:focused { This might require a CSR as it might break custom stylesheets that modify list/tree/table/views. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1330#discussion_r1448068150 From jhendrikx at openjdk.org Wed Jan 10 23:23:34 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 10 Jan 2024 23:23:34 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 20:05:16 GMT, Andy Goryachev wrote: >> No, the explicit goal of this construction is to set active to false (in case it exists) so that existing listeners can be released; followed by creating a new active property that is by default set to true until `setMenus` is called again (e.g. after unfocus/focus events). >> I noticed however that it is not as simple as that, and the current PR introduces regression, as the `SystemMenuBarTest.testMemoryLeak` test is now failing. Listeners are not only registered when `setMenus` is called, but also when menu(Item)s are added to menus. I'm not sure if a single `active` property can address this, as we don't want to remove all listeners for all menuitems in case a particular menuitem is added to a particular menu. >> @hjohn does that make sense? > > thank you for clarification! > > perhaps we ought to add a comment explaining why: it's one thing to create a single chain of conditions linked to a property, but here we keep creating new property instance, so the side effects are not that obvious. > I noticed however that it is not as simple as that, and the current PR introduces regression, as the SystemMenuBarTest.testMemoryLeak test is now failing. Listeners are not only registered when setMenus is called, but also when menu(Item)s are added to menus. I'm not sure if a single active property can address this, as we don't want to remove all listeners for all menuitems in case a particular menuitem is added to a particular menu. @hjohn does that make sense? So, if I understood correctly, that test is dealing not with the entire menu bar disappearing (for which the `active` property ensures clean up), but with a submenu getting cleared, and then a new item added. Any old items that were added should be garbage collectable after clearing. This is a bit tricky. Basically I think it means that the listeners on a certain `MenuBase` wrapper should be removed in two cases: 1. When the entire menu is no longer needed (what we have now) 2. When the `MenuBase` in question is removed from its parent I think this may be resolved in one of two ways: 1. Create a specific active condition for `when` that includes a check on parent and on the top level `active` property 2. Gather all listeners added into a single `Subscription` (currently the `Subscription` that is returned is discarded, track this somewhere (probably easiest in a the user property map) taking care not to create a new hard reference (not sure if that will be an issue). The `Subscription` can then be obtained and unsubscribed early. Now I think option 1 can be achieved by doing something like the code below. **Note:** completely untested, and did not check yet if we aren't creating any new problematic hard references; I can test this out over the weekend if you like. // given the global `active` property... // and a MenuBase mb, for which we can discover if it is a root menu or not... // and which exposes a new property hasParentProperty (you can derive this property // if you like by doing `parentMenuProperty.map(Objects::nonNull)`) BooleanProperty forWhen = active; if (mb "is not a root menu") { // important we don't do this for root // include "and" condition that it also must have a parent to be considered "active" forWen = active.flatMap(b -> b ? mb.hasParentProperty() : active); } // then use `forWhen` in your `when` conditions instead of `active` as before. What the above does is that using `flatMap` it creates a listener on `hasParentProperty`. If it changes, the entire expression result may change. In normal Java code it would simply be: boolean forWhen = active && mb.hasParent(); ... except of course that the above code would not react to changes. The logical and (`&&`) is achieved with the ternary expression. If `b` is `true` then we need to check the second part of the `&&` which is `hasParentProperty`. If `b` was already `false`, then the there is no need to check further. In any case, a new **property** must be returned from `flatMap`, so that will either be `hasParentProperty` in case `active` is `true` or the `active` property (which then must be `false`). Such scenario's are rare, but I've been considering adding specific support on `ObservableValue` for this. There is also the `and` function on `ObservableBooleanValue` -- you can test this one as well, but I fear that it may be using a weak listener in there and that it may get collected early if you don't reference the intermediate expressions. There is no such risk with `flatMap`. I haven't looked further into option 2. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1448099725 From kcr at openjdk.org Wed Jan 10 23:25:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jan 2024 23:25:33 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:52:22 GMT, Andy Goryachev wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1042: > >> 1040: int runIndex = 0; >> 1041: if (runs.length != 0) { >> 1042: if (this.getScene().getNodeOrientation() == NodeOrientation.RIGHT_TO_LEFT) { > > I think this should not refer to scene: > > > if (getNodeOrientation() == NodeOrientation.RIGHT_TO_LEFT) { I agree. Using the scene's orientation seems conceptually wrong. Shouldn't this use `Node::getEffectiveNodeOrientation`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1448101240 From jhendrikx at openjdk.org Wed Jan 10 23:52:32 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 10 Jan 2024 23:52:32 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 23:20:23 GMT, John Hendrikx wrote: >> thank you for clarification! >> >> perhaps we ought to add a comment explaining why: it's one thing to create a single chain of conditions linked to a property, but here we keep creating new property instance, so the side effects are not that obvious. > >> I noticed however that it is not as simple as that, and the current PR introduces regression, as the SystemMenuBarTest.testMemoryLeak test is now failing. Listeners are not only registered when setMenus is called, but also when menu(Item)s are added to menus. I'm not sure if a single active property can address this, as we don't want to remove all listeners for all menuitems in case a particular menuitem is added to a particular menu. > @hjohn does that make sense? > > So, if I understood correctly, that test is dealing not with the entire menu bar disappearing (for which the `active` property ensures clean up), but with a submenu getting cleared, and then a new item added. Any old items that were added should be garbage collectable after clearing. > > This is a bit tricky. Basically I think it means that the listeners on a certain `MenuBase` wrapper should be removed in two cases: > > 1. When the entire menu is no longer needed (what we have now) > 2. When the `MenuBase` in question is removed from its parent > > I think this may be resolved in one of two ways: > > 1. Create a specific active condition for `when` that includes a check on parent and on the top level `active` property > 2. Gather all listeners added into a single `Subscription` (currently the `Subscription` that is returned is discarded, track this somewhere (probably easiest in a the user property map) taking care not to create a new hard reference (not sure if that will be an issue). The `Subscription` can then be obtained and unsubscribed early. > > Now I think option 1 can be achieved by doing something like the code below. > > **Note:** completely untested, and did not check yet if we aren't creating any new problematic hard references; I can test this out over the weekend if you like. > > // given the global `active` property... > // and a MenuBase mb, for which we can discover if it is a root menu or not... > // and which exposes a new property hasParentProperty (you can derive this property > // if you like by doing `parentMenuProperty.map(Objects::nonNull)`) > > BooleanProperty forWhen = active; > > if (mb "is not a root menu") { // important we don't do this for root > // include "and" condition that it also must have a parent to be considered "active" > forWen = active.flatMap(b -> b ? mb.hasParentProperty() : active); > } > > // then use `forWhen` in your `when` conditions instead of `active` as before. > > What the above does is that using `flatMap` it creates a l... > perhaps we ought to add a comment explaining why: it's one thing to create a single chain of conditions linked to a property, but here we keep creating new property instance, so the side effects are not that obvious. Yeah, the replacing of the property used in `when` is not a normal scenario. Normally, the property used in the `when` goes out of scope at the same time as the rest of the references, in cases like: label.textProperty().when(userInterfaceIsShowing).addListener( ... ); The `userInterfaceIsShowing` is then part of a `Node` based container, or is not referenced anywhere at all (it's just derived from say `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::isShowingProperty)`. It is important to realize that `when` uses two (normal) listeners: - One on its condition property (`active`), which is not weak and is **never** removed (iirc, it can't be weak as otherwise the observable created by `when` could get GC'd when the condition is `false`, but shouldn't have been as the condition may yet become `true` again). - One on its parent property (x in `x.when( ... )`) -- this listener (and thus its hard reference) is only present when the condition evaluates to `true` In this specific case there is nothing that tells us that the menu disappeared, so the best we can do is that when a **new** menu is created that at that time we discard the old one. To be able to discard it, we unfortunately need to keep a hard reference to the `active` property we used (so it can be set to `false`). However, the `when` has a listener on that `active` property (as it needs to know when the condition changes), and a listener points back to the observable value that `when` created (it is not, and can't be, a weak listener). So in order to also cut that hard reference, we need to replace the `active` property as well after setting it to `false` (if you don't set it to `false`, there will be a listener on the parent of `when` that keeps a hard reference still... setting it to `false` removes that listener first). So definitely not your run-of-the-mill `when` example, but it will at least always behave deterministically as there are no weak listeners used anywhere. If there is a bug, it will be easy to reproduce on someone else's machine. The illustration I added earlier above should hopefully make the above a bit more clear, but of course some documentation in the code to explain this may be good too. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1448115136 From angorya at openjdk.org Thu Jan 11 00:00:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 00:00:32 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner The scrolling works correctly with the fix (tested TableView on macOS (scale=1 and 2) and win11 (scale=200%, 225%). I'll continue testing tomorrow. It might be a dumb question: would it be possible to avoid creating an intermediate container and keep the existing .css files? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-1885946034 From jhendrikx at openjdk.org Thu Jan 11 00:22:32 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 11 Jan 2024 00:22:32 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:55:35 GMT, Johan Vos wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 98: >> >>> 96: active.set(false); >>> 97: } >>> 98: active = new SimpleBooleanProperty(true); >> >> should this be >> >> if(active == null) { >> active = new ... >> } else { >> active.set(false); >> } >> >> instead? > > No, the explicit goal of this construction is to set active to false (in case it exists) so that existing listeners can be released; followed by creating a new active property that is by default set to true until `setMenus` is called again (e.g. after unfocus/focus events). > I noticed however that it is not as simple as that, and the current PR introduces regression, as the `SystemMenuBarTest.testMemoryLeak` test is now failing. Listeners are not only registered when `setMenus` is called, but also when menu(Item)s are added to menus. I'm not sure if a single `active` property can address this, as we don't want to remove all listeners for all menuitems in case a particular menuitem is added to a particular menu. > @hjohn does that make sense? @johanvos I don't think what I wrote above (option 1) will work -- there will still be a reference from the `active` property that keeps the menu item alive; a reference is indeed removed when `hasParent` becomes `false`, but there is another (same reason we had to recreate the active property)... I will think on this some more over the weekend. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1448132951 From jvos at openjdk.org Thu Jan 11 08:04:59 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 11 Jan 2024 08:04:59 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v7] In-Reply-To: References: Message-ID: <9stlpt_Y5Pqwx4CHT0XDjzD5qEXWPgXvUt1ysf0Z0wQ=.373dad1e-478e-4992-bfcc-ceff76770037@github.com> > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos 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 eight additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8319779-systemmenu - Cleanup test - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. Add a test to make sure those references are gone. - Revert WeakInvalidationListeners and use new listener resource management approach. - Fix more memoryleaks due to listeners never being unregistered. - These changes are related to JBS-8318841 so we want to have that code in as well. Merge branch 'master' into 8319779-systemmenu - process reviewers comments - A listener was added but never removed. This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/d5a78749..703fd3c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=05-06 Stats: 290 lines in 39 files changed: 222 ins; 6 del; 62 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From johan.vos at gluonhq.com Thu Jan 11 08:08:16 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 11 Jan 2024 09:08:16 +0100 Subject: MacOS windowDidBecomeKey inconsistency In-Reply-To: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> Message-ID: Hi Martin, Thanks for testing this. Just to make sure: the fact that the systemtest pass, is the problem. It shouldn't pass. The change in PR 1283 caused regression that I didn't notice on the M2, but I heard the test correctly fails on M1, and I could confirm it correctly fails on Mac/Intel as well. Now that I know that this is not just my local M2 setup, I can have a look at the cause -- thanks for your useful feedback! - Johan On Wed, Jan 10, 2024 at 7:58?PM Martin Fox wrote: > Johan, > > Are you referring to PR 1283? And are you seeing test failures on Intel or > M2? > > I just grabbed PR 1283 and the system test works fine on my M2 Mac. As for > JDK-8089848 I recently looked into that and it was very specific to > changing the focus while processing windowDidResignKey (though I suppose it > could also happen if you changed focus while processing > windowDidBecomeKey). In that bug I didn?t see any cases where > windowDidBecomeKey wasn?t called, just cases where it was called on the > wrong window. I don?t see any obvious smoking guns in the SystemMenuBarTest > that would lead to the same condition. > > Martin > > On Jan 10, 2024, at 2:10?AM, Johan Vos wrote: > > I noticed different test results when running systemtests on a mac/intel > versus an M2. > when running systemtests from a command line using > > `sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest > :systemTests:test --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` > > I traced it down to `windowDidBecomeKey` on `GlassWindow+Overrides.m` not > being called on the M2. That of course leads to different paths, hence > different test results. > > I wonder if this is somehow related to > https://bugs.openjdk.org/browse/JDK-8089848. Before looking into this, is > this something others observed as well? > > - Johan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Thu Jan 11 08:50:40 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 08:50:40 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 23:57:24 GMT, Andy Goryachev wrote: > It might be a dumb question: would it be possible to avoid creating an intermediate container and keep the existing .css files? Not a dumb question, that is what I tried at first. See also my old PR: https://github.com/openjdk/jfx/pull/630. I tried multiple things with the container and snapping, but never managed to fix all the issues with all scales. So I didn't found a way to fix this issue other than having the same container structure as `ScrollPane`, which works very well with whatever you put into it. > modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css line 1508: > >> 1506: } >> 1507: >> 1508: .list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell:focused { > > This might require a CSR as it might break custom stylesheets that modify list/tree/table/views. Probably. Was not sure since this is a very specific case which we never had before (as far as I can tell). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-1886636679 PR Review Comment: https://git.openjdk.org/jfx/pull/1330#discussion_r1448500125 From mhanl at openjdk.org Thu Jan 11 09:35:36 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 09:35:36 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> Message-ID: On Fri, 5 Jan 2024 01:45:56 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > 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 eight additional commits since the last revision: > > - Merge branch 'master' into feature/selector-performance-improvement > - Add since tag to new API > - Add deprecated annotation and fixed deprecation descriptions > - Use copyOf instead of Collections.unmodifiableList(new ArrayList<>(x)) > - Pull up frozen field to abstract FixedCapacitySet class > - Add copyright header > - Deprecate StyleClass and remove StyleClassSet for faster solution > - Fix regression modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 94: > 92: return maximumCapacity == 0 ? empty() > 93: : maximumCapacity == 1 ? new Single<>() > 94: : maximumCapacity == 2 ? new Duo<>() I can confirm that most of the code in my application uses 1-2 styleclasses. Since all controls have one styleclass by default (some even more, think about `TextInputControl` with `text-input` -> `TextField` with `text-field`), does it make sense to also implement a specialized `Triple` class? We also often add 2 more styleclasses, so 3 style classes seems like a usecase that happens quite often. I also can confirm that 4 styleclasses or even more are very rare. I only found one: (`.label` + 3 added from us) ![image](https://github.com/openjdk/jfx/assets/66004280/2d80db3d-aca6-488e-a338-0759c82c35c8) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1448557802 From johan.vos at gluonhq.com Thu Jan 11 09:57:40 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 11 Jan 2024 10:57:40 +0100 Subject: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> Message-ID: I should add that the inconsistency only happens when running the systemtests using Gradle. When I isolate the failing systemtest and run it as a Java process, it correctly fails on both M2 and Mac/Intel. At this point, I don't have enough information to create a JBS issue though. I added debug info in the native code where the windowDidBecomeKey is received, but the Gradle output shows that debug even before it outputs that the test is starting. - Johan On Thu, Jan 11, 2024 at 9:08?AM Johan Vos wrote: > Hi Martin, > > Thanks for testing this. Just to make sure: the fact that the > systemtest pass, is the problem. It shouldn't pass. The change in PR 1283 > caused regression that I didn't notice on the M2, but I heard the test > correctly fails on M1, and I could confirm it correctly fails on Mac/Intel > as well. > Now that I know that this is not just my local M2 setup, I can have a look > at the cause -- thanks for your useful feedback! > > - Johan > > > On Wed, Jan 10, 2024 at 7:58?PM Martin Fox wrote: > >> Johan, >> >> Are you referring to PR 1283? And are you seeing test failures on Intel >> or M2? >> >> I just grabbed PR 1283 and the system test works fine on my M2 Mac. As >> for JDK-8089848 I recently looked into that and it was very specific to >> changing the focus while processing windowDidResignKey (though I suppose it >> could also happen if you changed focus while processing >> windowDidBecomeKey). In that bug I didn?t see any cases where >> windowDidBecomeKey wasn?t called, just cases where it was called on the >> wrong window. I don?t see any obvious smoking guns in the SystemMenuBarTest >> that would lead to the same condition. >> >> Martin >> >> On Jan 10, 2024, at 2:10?AM, Johan Vos wrote: >> >> I noticed different test results when running systemtests on a mac/intel >> versus an M2. >> when running systemtests from a command line using >> >> `sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest >> :systemTests:test --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >> >> I traced it down to `windowDidBecomeKey` on `GlassWindow+Overrides.m` not >> being called on the M2. That of course leads to different paths, hence >> different test results. >> >> I wonder if this is somehow related to >> https://bugs.openjdk.org/browse/JDK-8089848. Before looking into this, >> is this something others observed as well? >> >> - Johan >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Thu Jan 11 10:15:01 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 Jan 2024 10:15:01 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Code review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/8d42bd37..b23e4910 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=00-01 Stats: 115 lines in 4 files changed: 5 ins; 18 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Thu Jan 11 10:31:37 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 Jan 2024 10:31:37 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: <2KCi2NAAGoK1i-IxJc4a4fLtzPTv7N9ksaMh0gdKeKw=.857480da-94a9-47aa-8c59-36955e0b7897@github.com> On Wed, 10 Jan 2024 23:23:14 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1042: >> >>> 1040: int runIndex = 0; >>> 1041: if (runs.length != 0) { >>> 1042: if (this.getScene().getNodeOrientation() == NodeOrientation.RIGHT_TO_LEFT) { >> >> I think this should not refer to scene: >> >> >> if (getNodeOrientation() == NodeOrientation.RIGHT_TO_LEFT) { > > I agree. Using the scene's orientation seems conceptually wrong. Shouldn't this use `Node::getEffectiveNodeOrientation`? Agreed. scene's orientation shouldn't be used here. Made changes to use `getEffectiveNodeOrientation`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1448625157 From kpk at openjdk.org Thu Jan 11 10:31:39 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 Jan 2024 10:31:39 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 20:31:43 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 202: >> >>> 200: double x = point.getX(); >>> 201: double y = point.getY(); >>> 202: TextLayout.Hit h = layout.getHitInfo((float)x, (float)y, null, -1, -1); >> >> -1 looks like magic value, could you please describe it in the `com.sun.javafx.scene.tex.TextLayout` javadoc in both cases (textRunStart and curRunStart)? > > or, would it make more sense to simply pass a boolean flag instead of magic values? I changed 0 to -1 to figure out if the `getHitInfo` in `PrismTextLayout` is invoked by `Text` or `TextFlow`. Added comment regarding this in `com.sun.javafx.scene.tex.TextLayout`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1448627945 From kpk at openjdk.org Thu Jan 11 10:31:42 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 Jan 2024 10:31:42 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 20:13:24 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Code review changes > > tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 48: > >> 46: import javafx.stage.StageStyle; >> 47: import javafx.stage.Window; >> 48: import org.junit.After; > > should we be using junit5 for all new tests? Made changes in both the test files to use unit5 > is there a reason to cast to int? No, I reused an old test file and developed these tests based on that. Hence the cast was kept as it is. >fx robot does accept double arguments, and we might be dealing with fractional scale on some platforms Removed the cast. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1448631575 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1448631045 From kpk at openjdk.org Thu Jan 11 10:41:35 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 Jan 2024 10:41:35 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:16:01 GMT, Andy Goryachev wrote: > Preliminary testing looks ok, though it does suffer from effects of JDK-8318095 (and I did remove `this.getScene().` in Text:1042) > Thanks @andy-goryachev-oracle for testing and reviewing the PR. Yes, to fully test this fix we need to address JDK-8318095. If you are planning to fix that issue, I'm ok to come back to this PR after the fix is done. However I do believe that we can review this in parallel as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1886826066 From jvos at openjdk.org Thu Jan 11 11:45:02 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 11 Jan 2024 11:45:02 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v8] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Revert some of the conditional bindings. Clear menu construction when an menuitem that is a menu needs to be removed Add a test for the latter ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/703fd3c2..1ce8fe9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=06-07 Stats: 56 lines in 2 files changed: 46 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From mhanl at openjdk.org Thu Jan 11 12:19:31 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 12:19:31 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 12:31:20 GMT, Florian Kirmaier wrote: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Agree, with all the tests added, especially in this area in https://github.com/openjdk/jfx/pull/1194 and in https://github.com/openjdk/jfx/pull/1246, it is much easier for us to catch regression. I will also have a look in the next days. I also noted that I got weird scrolling behaviour once, but could never reproduce it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1887039217 From mariushanl at web.de Thu Jan 11 12:28:07 2024 From: mariushanl at web.de (Marius Hanl) Date: Thu, 11 Jan 2024 13:28:07 +0100 Subject: Aw: Re: New properties: focusOwner and focusOwnerWithin In-Reply-To: <69ce289d-3e58-97fe-524d-c90f0908ff7a@gmail.com> References: <7618de08-d74f-0581-fdff-17b1fcb84133@gmail.com> <69ce289d-3e58-97fe-524d-c90f0908ff7a@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Thu Jan 11 13:40:28 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Jan 2024 05:40:28 -0800 Subject: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> Message-ID: <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> Hi Johan, I can also try this today, since I have an M1 laptop and have access to an M2 Mac Mini, both running macOS 14.x. -- Kevin On 1/11/2024 12:08 AM, Johan Vos wrote: > Hi Martin, > > Thanks for testing this. Just to make sure: the fact that the > systemtest?pass, is the problem. It shouldn't pass. The change in PR > 1283 caused regression that I didn't notice on the M2, but I heard the > test correctly fails on M1, and I could confirm it correctly fails on > Mac/Intel as well. > Now that I know that this is not just my local M2 setup, I can have a > look at the cause -- thanks for your useful feedback! > > - Johan > > > On Wed, Jan 10, 2024 at 7:58?PM Martin Fox wrote: > > Johan, > > Are you referring to PR 1283? And are you seeing test failures on > Intel or M2? > > I just grabbed PR 1283 and the system test works fine on my M2 > Mac. As for JDK-8089848 I recently looked into that and it was > very specific to changing the focus while processing > windowDidResignKey (though I suppose it could also happen if you > changed focus while processing windowDidBecomeKey). In that bug I > didn?t see any cases where windowDidBecomeKey wasn?t called, just > cases where it was called on the wrong window. I don?t see any > obvious smoking guns in the SystemMenuBarTest that would lead to > the same condition. > > Martin > >> On Jan 10, 2024, at 2:10?AM, Johan Vos wrote: >> >> I noticed different test results when running systemtests on a >> mac/intel versus an M2. >> when running systemtests from a command line using >> >> `sh gradlew --info -PFULL_TEST=true ?:systemTests:cleanTest >> :systemTests:test >> --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >> >> I traced it down to `windowDidBecomeKey` on >> `GlassWindow+Overrides.m` not being called on the M2. That of >> course leads to different paths, hence different test results. >> >> I wonder if this is somehow related to >> https://bugs.openjdk.org/browse/JDK-8089848. Before?looking into >> this, is this something others observed as well? >> >> - Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sykora at openjdk.org Thu Jan 11 13:52:38 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Thu, 11 Jan 2024 13:52:38 GMT Subject: RFR: 8318614: Update WebKit to 617.1 In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 17:53:46 GMT, Hima Bindu Meda wrote: > This PR updates webkit to v617.1. Verified build on Mac,Windows and linux. > Sanity testing looks fine. No issues observed in HelloWebView as well All builds and tests went fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1328#pullrequestreview-1815631832 From jvos at openjdk.org Thu Jan 11 14:07:38 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 11 Jan 2024 14:07:38 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v8] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 11:45:02 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Revert some of the conditional bindings. > Clear menu construction when an menuitem that is a menu needs to be removed > Add a test for the latter A few things about the latest commit: 1. The usage of the `active` property caused regression: the memoryLeak test that was introduced in the fix for JDK-8318841 now failed. A number of listeners were hard referenced from the `active` property. The complexity is that there are different entry points by which a listener should be removed. What we try to do in this PR, is making sure we remove listeners after a defocus/focus operation that would otherwise stay referenced. A focus operation will result in GlassSystemMenu.setMenus() being called. I reverted some of the dependencies on the `active` property, and kept those that were directly created as a consequence of the setMenus call. 2. I added a test that demonstrates the issue when not removing menu's completely inside the listener, as reported by @jperedadnr and this issue is fixed as well now. 3. All tests now pass, but I noticed that in some cases, the systemtests do not correctly work with the application lifecycle management (see https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044516.html). For now, I consider this anomaly to be independent from JDK-8319779 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1887227196 From kcr at openjdk.org Thu Jan 11 16:03:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 16:03:38 GMT Subject: Integrated: 8323209: Change JavaFX release version to 23 In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 21:24:43 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 23. I will integrate this to master as part of forking the jfx22 stabilization branch, which is scheduled for Thursday, January 11, 2024 at 16:00 UTC. This pull request has now been integrated. Changeset: caba6788 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/caba6788e2b62b3c1af102d1ff311ac2eaeab8c5 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8323209: Change JavaFX release version to 23 Reviewed-by: angorya, arapte, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1322 From kevin.rushforth at oracle.com Thu Jan 11 16:25:02 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Jan 2024 08:25:02 -0800 Subject: JavaFX 22 is in Rampdown Phase One (RDP1) Message-ID: JavaFX 22 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx22 branch [2] for stabilizing the JavaFX 22 release. 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 jfx23. Almost all fixes will be integrated to master for 23, even those intended to be fixed in 22. - The jfx22 branch of the jfx repo is now open for integrating fixes for jfx22 that meet the RDP1 criteria as outlined below. As with the previous release, in this release we will integrate almost all stabilization changes via backports from the master branch [3]. ? * Almost all fixes intended for the jfx22 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 jfx22 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx22. 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 jfx22 branch. The master branch is open for all jfx23 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 jfx22 branch is used to stabilize the upcoming jfx22 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 jfx22 to ensure that it doesn't contain any commits from master after the jfx22 fork date. What that means is that if you intend a PR to be for jfx22, 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 23 as of today). This is usually what we want. A backport PR should be targeted to `jfx22` if, and only if, it is intended for JavaFX 22 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 `jfx22`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 23. Reviewers also need to be extra careful when reviewing PRs targeted to jfx22 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 jfx22 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 22 release. As an obvious choice, derived from the JBS fix version, we will use "jfx22-enhancement-request", "jfx22-enhancement-yes", "jfx22-enhancement-no" and "jfx22-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx22 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 jfx23, since we do not want to risk anything that would destabilize the jfx22 release without a compelling reason. Also, we have only 3 weeks until RDP2 of jfx22 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 jfx22 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042703.html [2] https://github.com/openjdk/jfx/tree/jfx22 [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 duke at openjdk.org Thu Jan 11 16:43:36 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 Jan 2024 16:43:36 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:09:47 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: clean up code Regarding the NPEs: - i was able to trigger an exception in TableView:1922 - the code in TableCellBehaviour:70 is only reachable by user interaction with a cell. A cell only exists when a TableView has items. The interaction will never happen while `items` is null, because the code is unreachable in that case ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887550425 From duke at openjdk.org Thu Jan 11 16:48:53 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 Jan 2024 16:48:53 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: References: Message-ID: > This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: JDK-8323543: add test and fix for another npe ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1329/files - new: https://git.openjdk.org/jfx/pull/1329/files/54e8668e..f883a003 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=01-02 Stats: 11 lines in 3 files changed: 9 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1329.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1329/head:pull/1329 PR: https://git.openjdk.org/jfx/pull/1329 From angorya at openjdk.org Thu Jan 11 16:58:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 16:58:33 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 16:48:53 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: add test and fix for another npe I might suggest to add a null check to TableCellBehaviour:70 regardless, just to be on the safe side. We can skip the unit test because there is no way to interact with a cell in this particular case. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887572456 From duke at openjdk.org Thu Jan 11 18:26:38 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 Jan 2024 18:26:38 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 16:48:53 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: add test and fix for another npe since the conditions needed for TableCellBehaiviour:70 to be execute require items to not be null for that code to even be triggered, i think it does not make sense to check whether the items are null. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887723911 From angorya at openjdk.org Thu Jan 11 18:36:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 18:36:32 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 16:48:53 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: add test and fix for another npe Looks good, thank you for finding and fixing the issue! This PR has a very narrow focus to be a candidate for a back port to jfx22 @kevinrushforth ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1329#pullrequestreview-1816269167 From duke at openjdk.org Thu Jan 11 18:56:03 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 Jan 2024 18:56:03 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v4] In-Reply-To: References: Message-ID: > This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. Carl D?bbelin has updated the pull request incrementally with two additional commits since the last revision: - JDK-8323543: refactors tests and adds accessible attribute test for treetable - JDK-8323543: remove unneeded comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1329/files - new: https://git.openjdk.org/jfx/pull/1329/files/f883a003..bc515d7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=02-03 Stats: 11 lines in 3 files changed: 7 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1329.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1329/head:pull/1329 PR: https://git.openjdk.org/jfx/pull/1329 From angorya at openjdk.org Thu Jan 11 18:56:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 18:56:03 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v4] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 18:53:16 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8323543: refactors tests and adds accessible attribute test for treetable > - JDK-8323543: remove unneeded comment FYI, pushing another commit requires re-review (easy in this particular case). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1329#pullrequestreview-1816309708 From duke at openjdk.org Thu Jan 11 18:56:04 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 Jan 2024 18:56:04 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 16:48:53 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: add test and fix for another npe dont worry, im in a call with @Maran23 rn ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887762661 From angorya at openjdk.org Thu Jan 11 18:56:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 18:56:04 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: References: Message-ID: <2ZxAMEZE7l72gDT3a9cNShjdAj6JHRpCGP4uDe6SiXQ=.c6c8f9a5-ac6a-4314-8667-6fc990df3ff2@github.com> On Thu, 11 Jan 2024 16:48:53 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: add test and fix for another npe @Maran23 would you like to double check and sponsor? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887762846 From mhanl at openjdk.org Thu Jan 11 18:56:04 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 18:56:04 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: <2ZxAMEZE7l72gDT3a9cNShjdAj6JHRpCGP4uDe6SiXQ=.c6c8f9a5-ac6a-4314-8667-6fc990df3ff2@github.com> References: <2ZxAMEZE7l72gDT3a9cNShjdAj6JHRpCGP4uDe6SiXQ=.c6c8f9a5-ac6a-4314-8667-6fc990df3ff2@github.com> Message-ID: On Thu, 11 Jan 2024 18:49:42 GMT, Andy Goryachev wrote: > @Maran23 would you like to double check and sponsor? sure! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887764274 From kcr at openjdk.org Thu Jan 11 18:56:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 18:56:04 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v3] In-Reply-To: References: Message-ID: <8NvQ66l0-fwhUBTqugS8DTljBqbw6h42UfNYVr1txnw=.c2275b62-f460-4594-8e01-002f15587774@github.com> On Thu, 11 Jan 2024 18:33:45 GMT, Andy Goryachev wrote: > This PR has a very narrow focus to be a candidate for a back port to jfx22 @kevinrushforth This seems a safe and targeted fix. I have no objection. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887768250 From kcr at openjdk.org Thu Jan 11 18:58:34 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 18:58:34 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v4] In-Reply-To: References: Message-ID: <7zWYDPC6ju2qOjpwPsh7UlyJABk7TUzHiibditjtDg4=.20378dfd-d1e7-4284-9117-f8143bfba79a@github.com> On Thu, 11 Jan 2024 18:56:03 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8323543: refactors tests and adds accessible attribute test for treetable > - JDK-8323543: remove unneeded comment Although... I just spotted something. The updated tests use JUnit5 assertions into what is otherwise a JUnit4 test. We generally avoid doing this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887774310 From mhanl at openjdk.org Thu Jan 11 19:12:38 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 19:12:38 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v4] In-Reply-To: <7zWYDPC6ju2qOjpwPsh7UlyJABk7TUzHiibditjtDg4=.20378dfd-d1e7-4284-9117-f8143bfba79a@github.com> References: <7zWYDPC6ju2qOjpwPsh7UlyJABk7TUzHiibditjtDg4=.20378dfd-d1e7-4284-9117-f8143bfba79a@github.com> Message-ID: <4HnpgXSJ0wXgV3m9VUwX3lju5jer0xrVgcQOG1eix2c=.f6d1ba05-23db-4eca-9112-b05d5f7bf654@github.com> On Thu, 11 Jan 2024 18:56:13 GMT, Kevin Rushforth wrote: > Although... I just spotted something. The updated tests use JUnit5 assertions into what is otherwise a JUnit4 test. We generally avoid doing this. Should we use the JUnit5 `@Test` annotation, or migrate the class to JUnit5? The migration is also fine, although some assert need to be switched from `assertEquals(text, expected, actual)` -> `assertEquals(expected, actual, text)` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887792781 From duke at openjdk.org Thu Jan 11 19:50:49 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 Jan 2024 19:50:49 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v5] In-Reply-To: References: Message-ID: > This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: JDK-8323543: migrates tests to junit 5 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1329/files - new: https://git.openjdk.org/jfx/pull/1329/files/bc515d7d..6bd6e18c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=03-04 Stats: 684 lines in 2 files changed: 289 ins; 13 del; 382 mod Patch: https://git.openjdk.org/jfx/pull/1329.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1329/head:pull/1329 PR: https://git.openjdk.org/jfx/pull/1329 From angorya at openjdk.org Thu Jan 11 20:08:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 20:08:10 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v5] In-Reply-To: References: Message-ID: <8Zx-NiMi4-1JuxVyox5D04KBLQ9d7cDYOct9WqmZtLI=.cc91cbb8-6941-452f-ad29-9423c6fb3cfb@github.com> On Thu, 11 Jan 2024 19:50:49 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: migrates tests to junit 5 I wonder if it was a mistake to migrate to junit5 in this PR, it should have been a separate task: the scope of the change has exploded, it might cause issues with backporting, etc. Would it be possible to separate the migration from the fix? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 3932: > 3930: } > 3931: > 3932: @Disabled("Fix not yet developed for TableView") `@Test` was placed on its own line elsewhere but not in this file? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5414: > 5412: @Test public void test_rt_40319_toRight_toBottom() { test_rt_40319(true, true, false); } > 5413: @Test public void test_rt_40319_toRight_toTop() { test_rt_40319(true, false, false); } > 5414: @Test inconsistent formatting? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5784: > 5782: final Thread.UncaughtExceptionHandler exceptionHandler = Thread.currentThread().getUncaughtExceptionHandler(); > 5783: Thread.currentThread().setUncaughtExceptionHandler((t, e) -> fail( > 5784: "We don't expect any exceptions in this test!")); unrelated change? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887870661 PR Review Comment: https://git.openjdk.org/jfx/pull/1329#discussion_r1449327699 PR Review Comment: https://git.openjdk.org/jfx/pull/1329#discussion_r1449329017 PR Review Comment: https://git.openjdk.org/jfx/pull/1329#discussion_r1449329777 From mhanl at openjdk.org Thu Jan 11 20:08:20 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 20:08:20 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v5] In-Reply-To: <8Zx-NiMi4-1JuxVyox5D04KBLQ9d7cDYOct9WqmZtLI=.cc91cbb8-6941-452f-ad29-9423c6fb3cfb@github.com> References: <8Zx-NiMi4-1JuxVyox5D04KBLQ9d7cDYOct9WqmZtLI=.cc91cbb8-6941-452f-ad29-9423c6fb3cfb@github.com> Message-ID: <5oaomApXPdk_UiPbzZkU2W7qsoBVoL6tf-cRXIZyiWg=.a8df3d29-87b3-4e01-a0df-fda76ba904cf@github.com> On Thu, 11 Jan 2024 19:57:21 GMT, Andy Goryachev wrote: > Would it be possible to separate the migration from the fix? Another idea could be to use the full qualified path: `@org.junit.jupiter.api.Test`. But `@Before` and `@After` are still JUnit 4. Or we can reduce the change by at least reverting the new line changes? Then the diff should be much smaller. > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 3932: > >> 3930: } >> 3931: >> 3932: @Disabled("Fix not yet developed for TableView") > > `@Test` was placed on its own line elsewhere but not in this file? Hmm, I suggested @EstelonAgarwaen to use the IntelliJ JUnit 5 Migration functionality. So looks like it is not always putting `@Test` in a new line. Only when nothing is above it seems? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887878588 PR Review Comment: https://git.openjdk.org/jfx/pull/1329#discussion_r1449329912 From angorya at openjdk.org Thu Jan 11 20:13:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 20:13:20 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v5] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 19:50:49 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323543: migrates tests to junit 5 I think the problem is that we are trying to address two issues in one PR - the fix and migration to junit5. It might be better to go back one commit (but keep the most recent changes on a separate branch), convert the fix to use junit4 and submit the fix in this PR. Then, create a separate JBS ticket for junit5 migration. This way the scope of the fix is reduced to a minimum, and it can be easily backported and not cause many issues. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887888222 From mhanl at openjdk.org Thu Jan 11 20:27:33 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 20:27:33 GMT Subject: RFR: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin Message-ID: For some reason the `skinProperty` did not allow to set a new skin when it is the same class as the previous one. This leads to multiple issues: 1. When creating a new skin (same class as previous), the skin will likely install listener but is then rejected when setting it due to the `skinProperty` class constraint -> `PopupControl` is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous -> Just imagine we have the following skin class class MyCustomSkin extends Skin { public MyCustomSkin(C skinnable, boolean someFlag) { ... } } Now if we would change the skin of the `PopupControl` two times like this: popup.setSkin(new MyCustomSkin(popup, true)); popup.setSkin(new MyCustomSkin(popup, false)); The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. This is the same issue and fix as done for `Control` in [JDK-8276056](https://bugs.openjdk.org/browse/JDK-8276056) (PR: https://github.com/openjdk/jfx/pull/806) ------------- Commit messages: - JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin Changes: https://git.openjdk.org/jfx/pull/1331/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1331&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323615 Stats: 42 lines in 2 files changed: 28 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1331.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1331/head:pull/1331 PR: https://git.openjdk.org/jfx/pull/1331 From kcr at openjdk.org Thu Jan 11 20:29:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 20:29:38 GMT Subject: RFR: 8318614: Update WebKit to 617.1 In-Reply-To: References: Message-ID: <7Lir1ABZ1OZjMMI5n7Oxzu6nw0ofLy6gdqZJBzZNB6k=.e8161786-0a4c-46f4-8faa-c1e7b72be16f@github.com> On Wed, 10 Jan 2024 17:53:46 GMT, Hima Bindu Meda wrote: > This PR updates webkit to v617.1. Verified build on Mac,Windows and linux. > Sanity testing looks fine. No issues observed in HelloWebView as well Looks good. Testing is green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1328#pullrequestreview-1816581166 From angorya at openjdk.org Thu Jan 11 20:37:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 20:37:48 GMT Subject: RFR: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:13:09 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin when it is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install listener but is then rejected when setting it due to the `skinProperty` class constraint > -> `PopupControl` is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomSkin extends Skin { > public MyCustomSkin(C skinnable, boolean someFlag) { ... } > } > > Now if we would change the skin of the `PopupControl` two times like this: > > popup.setSkin(new MyCustomSkin(popup, true)); > popup.setSkin(new MyCustomSkin(popup, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. > > This is the same issue and fix as done for `Control` in [JDK-8276056](https://bugs.openjdk.org/browse/JDK-8276056) (PR: https://github.com/openjdk/jfx/pull/806) modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 216: > 214: private Skin oldValue; > 215: > 216: @Override This logic was introduce to deal with skins set from the css [JDK-8096194](https://bugs.openjdk.org/browse/JDK-8096194) Are you sure it will still work? Do we need to test this scenario explicitly? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1331#discussion_r1449367019 From mhanl at openjdk.org Thu Jan 11 20:53:33 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jan 2024 20:53:33 GMT Subject: RFR: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:35:08 GMT, Andy Goryachev wrote: >> For some reason the `skinProperty` did not allow to set a new skin when it is the same class as the previous one. >> This leads to multiple issues: >> 1. When creating a new skin (same class as previous), the skin will likely install listener but is then rejected when setting it due to the `skinProperty` class constraint >> -> `PopupControl` is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin >> 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous >> -> Just imagine we have the following skin class >> >> class MyCustomSkin extends Skin { >> public MyCustomSkin(C skinnable, boolean someFlag) { ... } >> } >> >> Now if we would change the skin of the `PopupControl` two times like this: >> >> popup.setSkin(new MyCustomSkin(popup, true)); >> popup.setSkin(new MyCustomSkin(popup, false)); >> >> The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. >> >> This is the same issue and fix as done for `Control` in [JDK-8276056](https://bugs.openjdk.org/browse/JDK-8276056) (PR: https://github.com/openjdk/jfx/pull/806) > > modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 216: > >> 214: private Skin oldValue; >> 215: >> 216: @Override > > This logic was introduce to deal with skins set from the css [JDK-8096194](https://bugs.openjdk.org/browse/JDK-8096194) > > Are you sure it will still work? Do we need to test this scenario explicitly? No, the `skin`/`skinProperty` logic was there before, just moved. It was added in https://bugs.openjdk.org/browse/JDK-8127070, with the comment from `David Grieve`: `The code for handling the skin property in PopupControl needs to look like the code in Control.` So they basically synchronized the whole skin/skin name API to `PopupControl`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1331#discussion_r1449380322 From jhendrikx at openjdk.org Thu Jan 11 22:39:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 11 Jan 2024 22:39:38 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> Message-ID: On Thu, 11 Jan 2024 09:33:09 GMT, Marius Hanl wrote: >> 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 eight additional commits since the last revision: >> >> - Merge branch 'master' into feature/selector-performance-improvement >> - Add since tag to new API >> - Add deprecated annotation and fixed deprecation descriptions >> - Use copyOf instead of Collections.unmodifiableList(new ArrayList<>(x)) >> - Pull up frozen field to abstract FixedCapacitySet class >> - Add copyright header >> - Deprecate StyleClass and remove StyleClassSet for faster solution >> - Fix regression > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 94: > >> 92: return maximumCapacity == 0 ? empty() >> 93: : maximumCapacity == 1 ? new Single<>() >> 94: : maximumCapacity == 2 ? new Duo<>() > > I can confirm that most of the code in my application uses 1-2 styleclasses. > Since all controls have one styleclass by default (some even more, think about `TextInputControl` with `text-input` -> `TextField` with `text-field`), does it make sense to also implement a specialized `Triple` class? > > We also often add 2 more styleclasses, so 3 style classes seems like a usecase that happens quite often. > I also can confirm that 4 styleclasses or even more are very rare. > I only found one: (`.label` + 3 added from us) > ![image](https://github.com/openjdk/jfx/assets/66004280/2d80db3d-aca6-488e-a338-0759c82c35c8) Thanks for having a look, it's good to have some more use cases from other applications! The sets are used both for the style classes on `Node`s but also the set of style classes in CSS selectors (multiple style classes in selectors are even more rare I think than multiple style classes on `Node`s). I think from a performance perspective, `Duo` and `Hashless` are likely very closely matched, but I can do some testing in that area. The reason I say this is that I only got a very minor boost from including `Duo`, but kept it because it is a bit more memory efficient. If you want, I'm also curious about how many styles are used in your application (you can see this by looking at the size of `StyleClassSet#styleClasses` after all styles are loaded). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1449480442 From jhendrikx at openjdk.org Thu Jan 11 22:53:30 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 11 Jan 2024 22:53:30 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> Message-ID: On Mon, 8 Jan 2024 19:24:14 GMT, Andy Goryachev wrote: >> I am confused, and maybe I am missing something. As far as I know, this method is not called anywhere. I put a breakpoint in it. JavaFX does not use this method anywhere, nor are Selectors ever used as keys in Sets or Maps. >> >> What am I missing? > > you are right, this code does not affect performance (I could not hit a break point here either). > still, since you are touching these lines, why not do it right? I can undo the rename so they're not touched. My problem with fixing this is that I then also should do it for `CompoundSelector`, which is just completely unrelated to the intent of this PR. I'm pretty sure that within JavaFX we don't change lines that are unrelated to the intent of the change (these lines were only hit because of a clarifying field rename related to this change). Normally I would do such fixes in an extra commit, where the first commit would be something like "fix: Improve selector match performance" and the second is "fix: Fix bug in Selectors hashCode algorithm"... ... but since everything is squashed as the way of working in FX (instead of having stand alone commits that are fast forwarded when included in master), it would have to be done the official way, which is file a ticket, create a new PR, have it also reviewed, etc. This puts an additional burden on the already long review queue, with well intentioned solid PR's that are abandoned because of lack of feedback and reviews... Even simple things like fixing warnings I've given up on as I see it taking time away from more pressing issues. So, I can file a ticket and create another PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1449489869 From angorya at openjdk.org Thu Jan 11 23:03:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jan 2024 23:03:32 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> Message-ID: On Thu, 11 Jan 2024 22:50:32 GMT, John Hendrikx wrote: >> you are right, this code does not affect performance (I could not hit a break point here either). >> still, since you are touching these lines, why not do it right? > > I can undo the rename so they're not touched. My problem with fixing this is that I then also should do it for `CompoundSelector`, which is just completely unrelated to the intent of this PR. I'm pretty sure that within JavaFX we don't change lines that are unrelated to the intent of the change (these lines were only hit because of a clarifying field rename related to this change). > > Normally I would do such fixes in an extra commit, where the first commit would be something like "fix: Improve selector match performance" and the second is "fix: Fix bug in Selectors hashCode algorithm"... > > ... but since everything is squashed as the way of working in FX (instead of having stand alone commits that are fast forwarded when included in master), it would have to be done the official way, which is file a ticket, create a new PR, have it also reviewed, etc. This puts an additional burden on the already long review queue, with well intentioned solid PR's that are abandoned because of lack of feedback and reviews... Even simple things like fixing warnings I've given up on as I see it taking time away from more pressing issues. > > So, I can file a ticket and create another PR. I feel the same kind of frustration sometimes. The review process is indeed painfully slow. A different JBS/PR would be fine, I think, something along the lines of "suboptimal hashCode() implementation in ...". I also think it's ok to keep the new names (so you don't have to do extra work) since there will be a new PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1449495652 From kcr at openjdk.org Thu Jan 11 23:10:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 23:10:30 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <9LGQrPe3krjvDw8V_HOL2h3oVPCW1q_WI0hC0jsuMxM=.35ee9079-e9b2-4728-a7b3-c9cc59e095c3@github.com> Message-ID: On Thu, 11 Jan 2024 22:59:33 GMT, Andy Goryachev wrote: >> I can undo the rename so they're not touched. My problem with fixing this is that I then also should do it for `CompoundSelector`, which is just completely unrelated to the intent of this PR. I'm pretty sure that within JavaFX we don't change lines that are unrelated to the intent of the change (these lines were only hit because of a clarifying field rename related to this change). >> >> Normally I would do such fixes in an extra commit, where the first commit would be something like "fix: Improve selector match performance" and the second is "fix: Fix bug in Selectors hashCode algorithm"... >> >> ... but since everything is squashed as the way of working in FX (instead of having stand alone commits that are fast forwarded when included in master), it would have to be done the official way, which is file a ticket, create a new PR, have it also reviewed, etc. This puts an additional burden on the already long review queue, with well intentioned solid PR's that are abandoned because of lack of feedback and reviews... Even simple things like fixing warnings I've given up on as I see it taking time away from more pressing issues. >> >> So, I can file a ticket and create another PR. > > I feel the same kind of frustration sometimes. The review process is indeed painfully slow. > > A different JBS/PR would be fine, I think, something along the lines of "suboptimal hashCode() implementation in ...". I also think it's ok to keep the new names (so you don't have to do extra work) since there will be a new PR. I agree with John that changing the existing hash algorithm is really out of scope for this PR (even if it is suboptimal, which it is). Filing a separate bug has the advantage of decoupling it in time as well as not burdening this review. It may or may not even be worth implementing the optimization if no one uses it, but in any case, it can be done later. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1449506858 From kcr at openjdk.org Thu Jan 11 23:19:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 23:19:07 GMT Subject: [jfx22u] RFR: 8323555: Change JavaFX release version to 22.0.1 in jfx22u Message-ID: Updates for the beginning of the 22.0.1 release. ------------- Commit messages: - Empty commit to trigger GHA run - 8323555: Change JavaFX release version to 22.0.1 in jfx22u Changes: https://git.openjdk.org/jfx22u/pull/1/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=1&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323555 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx22u/pull/1.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/1/head:pull/1 PR: https://git.openjdk.org/jfx22u/pull/1 From kcr at openjdk.org Thu Jan 11 23:19:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 23:19:07 GMT Subject: [jfx22u] RFR: 8323555: Change JavaFX release version to 22.0.1 in jfx22u In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 23:11:12 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 22.0.1 release. Reviewers: @johanvos or @arapte ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/1#issuecomment-1888113845 From kcr at openjdk.org Thu Jan 11 23:54:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jan 2024 23:54:13 GMT Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls [v2] In-Reply-To: References: Message-ID: > As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. > > This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. > > This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. > > The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). > > A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. > > Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. > > NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. > > Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWait` allows them to run when in... Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Remove reference to JBS bug ID ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1327/files - new: https://git.openjdk.org/jfx/pull/1327/files/ca1d06e2..05d742b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1327&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1327&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1327.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1327/head:pull/1327 PR: https://git.openjdk.org/jfx/pull/1327 From kcr at openjdk.org Fri Jan 12 00:06:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jan 2024 00:06:41 GMT Subject: [jfx22u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Message-ID: 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 jfx21u. The second is a simple substitution changing 21 to 22 in the two files. ------------- Commit messages: - Change 21 --> 22 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Changes: https://git.openjdk.org/jfx22u/pull/2/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&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/jfx22u/pull/2.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/2/head:pull/2 PR: https://git.openjdk.org/jfx22u/pull/2 From kcr at openjdk.org Fri Jan 12 00:06:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jan 2024 00:06:42 GMT Subject: [jfx22u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 00:00:43 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 jfx21u. The second is a simple substitution changing 21 to 22 in the two files. Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/2#issuecomment-1888160572 From angorya at openjdk.org Fri Jan 12 00:13:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 00:13:34 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner looks good, tested list/tree/table views on macOS 14.1.2 in light mode ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1330#pullrequestreview-1817051712 From prr at openjdk.org Fri Jan 12 00:15:32 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 12 Jan 2024 00:15:32 GMT Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 23:54:13 GMT, Kevin Rushforth wrote: >> As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. >> >> This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. >> >> This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. >> >> The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). >> >> A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. >> >> Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. >> >> NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. >> >> Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWa... > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove reference to JBS bug ID Marked as reviewed by prr (Reviewer). I think there's a bit of additional explanation joining the dots that would be helpful here > The AWT IME callback methods, for example characterIndexForPoint, call invokeAndWait to run the IME handler on the AWT Event thread. And that means specifically call AWT's LWCToolkit.invokeAndWait() and THAT uses doAWTRunLoop(), which when entered uses the flag 'inAWT' (which will be true) to invoke NSRunLoop (in a loop) in a way that it should ONLY process requests that specify the special mode [[NSRunLoop currentRunLoop] runMode:(inAWT ? [ThreadUtilities javaRunLoopMode] : NSDefaultRunLoopMode) It stays in this loop until it is informed that the thing it was waiting for is done. This won't happen unless FX specifies that mode so its call is eligible to be processed. ------------- PR Review: https://git.openjdk.org/jfx/pull/1327#pullrequestreview-1817052712 PR Comment: https://git.openjdk.org/jfx/pull/1327#issuecomment-1888179598 From angorya at openjdk.org Fri Jan 12 00:21:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 00:21:33 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 10:25:44 GMT, Karthik P K wrote: >> or, would it make more sense to simply pass a boolean flag instead of magic values? > > I changed 0 to -1 to figure out if the `getHitInfo` in `PrismTextLayout` is invoked by `Text` or `TextFlow`. > Added comment regarding this in `com.sun.javafx.scene.tex.TextLayout`. @karthikpandelu , the more I think about it, the less I like the idea of overloading (textRunStart and curRunStart). what if things will change in the future? I think it'll be much cleaner to pass a boolean forTextFlow (or forText) or some such. we have to compute such a boolean flag anyway, why not just pass it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1449575341 From psadhukhan at openjdk.org Fri Jan 12 04:48:32 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Jan 2024 04:48:32 GMT Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 23:54:13 GMT, Kevin Rushforth wrote: >> As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. >> >> This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. >> >> This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. >> >> The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). >> >> A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. >> >> Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. >> >> NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. >> >> Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWa... > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove reference to JBS bug ID Looks good to me.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1327#pullrequestreview-1817352905 From kpk at openjdk.org Fri Jan 12 05:19:32 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 12 Jan 2024 05:19:32 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 00:18:38 GMT, Andy Goryachev wrote: >> I changed 0 to -1 to figure out if the `getHitInfo` in `PrismTextLayout` is invoked by `Text` or `TextFlow`. >> Added comment regarding this in `com.sun.javafx.scene.tex.TextLayout`. > > @karthikpandelu , the more I think about it, the less I like the idea of overloading (textRunStart and curRunStart). > what if things will change in the future? > > I think it'll be much cleaner to pass a boolean forTextFlow (or forText) or some such. we have to compute such a boolean flag anyway, why not just pass it? Are you suggesting to pass boolean as parameter in addition to textRunStart and curRunStart? If that is the case then yes I think it would be better. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1449853445 From kpk at openjdk.org Fri Jan 12 06:32:31 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 12 Jan 2024 06:32:31 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:16:01 GMT, Andy Goryachev wrote: > I wonder if we should address JDK-8318095 first to be able to test this fix fully. We have another bug [JDK-8319050](https://bugs.openjdk.org/browse/JDK-8319050) for the issue with `careShape()` and `rangeShape()`. Do you think it is better to address that issue after we complete JDK-8318095? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1888505780 From jvos at openjdk.org Fri Jan 12 07:26:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 12 Jan 2024 07:26:33 GMT Subject: [jfx22u] RFR: 8323555: Change JavaFX release version to 22.0.1 in jfx22u In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 23:11:12 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 22.0.1 release. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx22u/pull/1#pullrequestreview-1817553253 From jvos at openjdk.org Fri Jan 12 07:31:30 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 12 Jan 2024 07:31:30 GMT Subject: [jfx22u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 00:00:43 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 jfx21u. The second is a simple substitution changing 21 to 22 in the two files. I compared the result with the 17u CONTRIBUTING.md and README.md and apart from the 17-22 change, it is similar. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx22u/pull/2#pullrequestreview-1817559198 From johan.vos at gluonhq.com Fri Jan 12 08:40:13 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 12 Jan 2024 09:40:13 +0100 Subject: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> Message-ID: Hi Martin, Great analysis, and that sounds very well possible. Indeed, there is a specific launch approach for the systemtests where the launch command is created (in tests/system/src/test/java/test/util/Util). It is still unclear to me why this would happen on M2 only (and not on M1 or Intel), but maybe there is no causal relation. In any case, this means that we have to rethink how to do the system tests, as people (including me) can falsely assume that all tests passed correctly. - Johan On Thu, Jan 11, 2024 at 6:18?PM Martin Fox wrote: > Johan, > > I think I see what?s going on (maybe). When I run the test app from gradle > it fails to activate. I suspect this is due to changes in macOS 14 that > makes it harder for an application to come to the front and start grabbing > keyboard input while the user is interacting with another app. Search for > "macos cooperative activation? (I?m leery of adding a link since it might > trigger a spam filter). > > When I run a JavaFX app from Terminal it allows the Java app to activate > unless I have Terminal > Secure Keyboard Entry turned on in which case the > app comes to the front but doesn?t activate. That setting doesn?t make a > difference when running a test from Gradle. No idea why you would see > different behavior on M2 vs Intel. > > I ran into this on Windows which has had this sort of protection for a > long time. I was only having trouble when running a test app using Gradle > and the msys2 shell (it worked with Cygwin). There?s a set of rules that > govern the handoff but I could never figure out which one was failing. The > solution there was to use a Robot to synthesize a mouse click on the window. > > This all suggests that gradle is spawning a background process and > launching the JavaFX app from there. On both Windows and macOS 14 that > could trigger this security/privacy feature. > > Martin > > On Jan 11, 2024, at 5:40?AM, Kevin Rushforth > wrote: > > Hi Johan, > > I can also try this today, since I have an M1 laptop and have access to an > M2 Mac Mini, both running macOS 14.x. > > -- Kevin > > > On 1/11/2024 12:08 AM, Johan Vos wrote: > > Hi Martin, > > Thanks for testing this. Just to make sure: the fact that the > systemtest pass, is the problem. It shouldn't pass. The change in PR 1283 > caused regression that I didn't notice on the M2, but I heard the test > correctly fails on M1, and I could confirm it correctly fails on Mac/Intel > as well. > Now that I know that this is not just my local M2 setup, I can have a look > at the cause -- thanks for your useful feedback! > > - Johan > > > On Wed, Jan 10, 2024 at 7:58?PM Martin Fox wrote: > >> Johan, >> >> Are you referring to PR 1283? And are you seeing test failures on Intel >> or M2? >> >> I just grabbed PR 1283 and the system test works fine on my M2 Mac. As >> for JDK-8089848 I recently looked into that and it was very specific to >> changing the focus while processing windowDidResignKey (though I suppose it >> could also happen if you changed focus while processing >> windowDidBecomeKey). In that bug I didn?t see any cases where >> windowDidBecomeKey wasn?t called, just cases where it was called on the >> wrong window. I don?t see any obvious smoking guns in the SystemMenuBarTest >> that would lead to the same condition. >> >> Martin >> >> On Jan 10, 2024, at 2:10?AM, Johan Vos wrote: >> >> I noticed different test results when running systemtests on a mac/intel >> versus an M2. >> when running systemtests from a command line using >> >> `sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest >> :systemTests:test --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >> >> I traced it down to `windowDidBecomeKey` on `GlassWindow+Overrides.m` not >> being called on the M2. That of course leads to different paths, hence >> different test results. >> >> I wonder if this is somehow related to >> https://bugs.openjdk.org/browse/JDK-8089848. Before looking into this, >> is this something others observed as well? >> >> - Johan >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Fri Jan 12 08:40:29 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 12 Jan 2024 08:40:29 GMT Subject: [jfx22u] RFR: 8323555: Change JavaFX release version to 22.0.1 in jfx22u In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 23:11:12 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 22.0.1 release. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx22u/pull/1#pullrequestreview-1817662768 From mhanl at openjdk.org Fri Jan 12 12:23:34 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 Jan 2024 12:23:34 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> Message-ID: <7pcrusrJnemJxKwFIYSlK6jLlgu01PFZSEJigdf-p98=.995a3cd0-4a90-40de-a2ae-6f56683c4c88@github.com> On Thu, 11 Jan 2024 22:36:58 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 94: >> >>> 92: return maximumCapacity == 0 ? empty() >>> 93: : maximumCapacity == 1 ? new Single<>() >>> 94: : maximumCapacity == 2 ? new Duo<>() >> >> I can confirm that most of the code in my application uses 1-2 styleclasses. >> Since all controls have one styleclass by default (some even more, think about `TextInputControl` with `text-input` -> `TextField` with `text-field`), does it make sense to also implement a specialized `Triple` class? >> >> We also often add 2 more styleclasses, so 3 style classes seems like a usecase that happens quite often. >> I also can confirm that 4 styleclasses or even more are very rare. >> I only found one: (`.label` + 3 added from us) >> ![image](https://github.com/openjdk/jfx/assets/66004280/2d80db3d-aca6-488e-a338-0759c82c35c8) > > Thanks for having a look, it's good to have some more use cases from other applications! The sets are used both for the style classes on `Node`s but also the set of style classes in CSS selectors (multiple style classes in selectors are even more rare I think than multiple style classes on `Node`s). > > I think from a performance perspective, `Duo` and `Hashless` are likely very closely matched, but I can do some testing in that area. The reason I say this is that I only got a very minor boost from including `Duo`, but kept it because it is a bit more memory efficient. > > If you want, I'm also curious about how many styles are used in your application (you can see this by looking at the size of `StyleClassSet#styleClasses` after all styles are loaded). I see, thanks for checking that out. I checked the application, here is the result: After starting the app: ![image](https://github.com/openjdk/jfx/assets/66004280/623049ac-c525-4854-8f06-b9712de5d746) After using it a little bit: ![image](https://github.com/openjdk/jfx/assets/66004280/cca4df47-829a-4d9b-b937-705b6c058172) --- I also checked out Scenebuilder after using it a little bit: ![image](https://github.com/openjdk/jfx/assets/66004280/0f8992b5-1073-4c77-b906-356b86c61389) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1450360838 From kevin.rushforth at oracle.com Fri Jan 12 12:52:52 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jan 2024 04:52:52 -0800 Subject: [External] : Re: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> Message-ID: I ran the then latest version of the test from PR?1283 yesterday afternoon, and for me it passed on both M1 and M2. I didn't try it on an Intel Mac, but will do so this morning. I hadn't noticed any problems with our other tests when getting things running on macOS 14 (beyond the bugs we already fixed related to activation), but I'll take a closer look at them. It's certainly possible we have other tests that are "passing" because they never get activated. -- Kevin On 1/12/2024 12:40 AM, Johan Vos wrote: > Hi Martin, > > Great analysis, and that sounds very well possible. Indeed, there is a > specific launch approach for the systemtests?where the launch command > is created (in tests/system/src/test/java/test/util/Util). > It is still unclear to me why this would happen on M2 only (and not on > M1 or Intel), but maybe there is no causal relation. In any case, this > means that we have to rethink how to do the system tests, as people > (including me) can falsely assume that all tests passed correctly. > > - Johan > > On Thu, Jan 11, 2024 at 6:18?PM Martin Fox wrote: > > Johan, > > I think I see what?s going on (maybe). When I run the test app > from gradle it fails to activate. I suspect this is due to changes > in macOS 14 that makes it harder for an application to come to the > front and start grabbing keyboard input while the user is > interacting with another app. Search for "macos cooperative > activation? (I?m leery of adding a link since it might trigger a > spam filter). > > When I run a JavaFX app from Terminal it allows the Java app to > activate unless I have Terminal > Secure Keyboard Entry turned on > in which case the app comes to the front but doesn?t activate. > That setting doesn?t make a difference when running a test from > Gradle. No idea why you would see different behavior on M2 vs Intel. > > I ran into this on Windows which has had this sort of protection > for a long time. I was only having trouble when running a test app > using Gradle and the msys2 shell (it worked with Cygwin). There?s > a set of rules that govern the handoff but I could never figure > out which one was failing. The solution there was to use a Robot > to synthesize a mouse click on the window. > > This all suggests that gradle is spawning a background process and > launching the JavaFX app from there. On both Windows and macOS 14 > that could trigger this security/privacy feature. > > Martin > >> On Jan 11, 2024, at 5:40?AM, Kevin Rushforth >> wrote: >> >> Hi Johan, >> >> I can also try this today, since I have an M1 laptop and have >> access to an M2 Mac Mini, both running macOS 14.x. >> >> -- Kevin >> >> >> On 1/11/2024 12:08 AM, Johan Vos wrote: >>> Hi Martin, >>> >>> Thanks for testing this. Just to make sure: the fact that the >>> systemtest?pass, is the problem. It shouldn't pass. The change >>> in PR 1283 caused regression that I didn't notice on the M2, but >>> I heard the test correctly fails on M1, and I could confirm it >>> correctly fails on Mac/Intel as well. >>> Now that I know that this is not just my local M2 setup, I can >>> have a look at the cause -- thanks for your useful feedback! >>> >>> - Johan >>> >>> >>> On Wed, Jan 10, 2024 at 7:58?PM Martin Fox >>> wrote: >>> >>> Johan, >>> >>> Are you referring to PR 1283? And are you seeing test >>> failures on Intel or M2? >>> >>> I just grabbed PR 1283 and the system test works fine on my >>> M2 Mac. As for JDK-8089848 I recently looked into that and >>> it was very specific to changing the focus while processing >>> windowDidResignKey (though I suppose it could also happen if >>> you changed focus while processing windowDidBecomeKey). In >>> that bug I didn?t see any cases where windowDidBecomeKey >>> wasn?t called, just cases where it was called on the wrong >>> window. I don?t see any obvious smoking guns in the >>> SystemMenuBarTest that would lead to the same condition. >>> >>> Martin >>> >>>> On Jan 10, 2024, at 2:10?AM, Johan Vos >>>> wrote: >>>> >>>> I noticed different test results when running systemtests >>>> on a mac/intel versus an M2. >>>> when running systemtests from a command line using >>>> >>>> `sh gradlew --info -PFULL_TEST=true ?:systemTests:cleanTest >>>> :systemTests:test >>>> --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >>>> >>>> I traced it down to `windowDidBecomeKey` on >>>> `GlassWindow+Overrides.m` not being called on the M2. That >>>> of course leads to different paths, hence different test >>>> results. >>>> >>>> I wonder if this is somehow related to >>>> https://bugs.openjdk.org/browse/JDK-8089848. Before?looking >>>> into this, is this something others observed as well? >>>> >>>> - Johan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Jan 12 12:59:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jan 2024 12:59:36 GMT Subject: [jfx22u] RFR: 8323555: Change JavaFX release version to 22.0.1 in jfx22u In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 07:23:56 GMT, Johan Vos wrote: >> Updates for the beginning of the 22.0.1 release. > > Marked as reviewed by jvos (Reviewer). @johanvos Thanks for the review. Can you add the needed maintainer approval, either using the Skara `/approve` command or directly in JBS? No hurry, since I do not plan to announce that this repo is open until next week. ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/1#issuecomment-1889126013 From kcr at openjdk.org Fri Jan 12 13:01:34 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jan 2024 13:01:34 GMT Subject: [jfx22u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: <_xUgywDcFfrCbpl_yHq2H6uL6vUurRH9VZmYLuZwNzE=.ce9e9261-54ce-475a-a732-8dd98ed04d5c@github.com> On Fri, 12 Jan 2024 00:00:43 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 jfx21u. The second is a simple substitution changing 21 to 22 in the two files. NOTE: this PR must not be integrated until after PR #1 is integrated. ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/2#issuecomment-1889130537 From kcr at openjdk.org Fri Jan 12 13:02:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jan 2024 13:02:30 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 22:39:22 GMT, Andy Goryachev wrote: >> This PR fixes the border glitch/gap as explained in both linked tickets. >> >> I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. >> >> So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). >> And this also fixes the issue, while behaving the same as before. >> >> In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. >> >> Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: >> Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` >> After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` >> >> To better understand this, the container structure (tree) is shown below: >> >> - ScrollPane >> - viewRect -> `setClip` -> clipRect (viewContent size) >> - viewContent -> `setLayoutX` >> - Content >> - vsb >> - hsb >> - corner >> >> --- >> - VirtualFlow >> - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) >> - clippedContainer/clipView -> `setLayoutX` (when scrolling) >> - sheet >> - Cell >> - vsb >> - hsb >> - corner > > modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css line 1508: > >> 1506: } >> 1507: >> 1508: .list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell:focused { > > This might require a CSR as it might break custom stylesheets that modify list/tree/table/views. Yes, I think a CSR would be in order. Thanks for bringing this up @andy-goryachev-oracle ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1330#discussion_r1450407373 From johan.vos at gluonhq.com Fri Jan 12 13:48:56 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 12 Jan 2024 14:48:56 +0100 Subject: [External] : Re: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> Message-ID: Hi Kevin, Thanks for testing. With the latest version of the PR, all tests should pass on all platforms (I believe the PR is ready now). Excluding my last commit, the tests should fail on all platforms. However, they pass for me (and Martin) on M2, because the app does not get activated. - Johan On Fri, Jan 12, 2024 at 1:53?PM Kevin Rushforth wrote: > I ran the then latest version of the test from PR 1283 yesterday > afternoon, and for me it passed on both M1 and M2. I didn't try it on an > Intel Mac, but will do so this morning. > > I hadn't noticed any problems with our other tests when getting things > running on macOS 14 (beyond the bugs we already fixed related to > activation), but I'll take a closer look at them. It's certainly possible > we have other tests that are "passing" because they never get activated. > > -- Kevin > > > On 1/12/2024 12:40 AM, Johan Vos wrote: > > Hi Martin, > > Great analysis, and that sounds very well possible. Indeed, there is a > specific launch approach for the systemtests where the launch command is > created (in tests/system/src/test/java/test/util/Util). > It is still unclear to me why this would happen on M2 only (and not on M1 > or Intel), but maybe there is no causal relation. In any case, this means > that we have to rethink how to do the system tests, as people (including > me) can falsely assume that all tests passed correctly. > > - Johan > > On Thu, Jan 11, 2024 at 6:18?PM Martin Fox wrote: > >> Johan, >> >> I think I see what?s going on (maybe). When I run the test app from >> gradle it fails to activate. I suspect this is due to changes in macOS 14 >> that makes it harder for an application to come to the front and start >> grabbing keyboard input while the user is interacting with another app. >> Search for "macos cooperative activation? (I?m leery of adding a link since >> it might trigger a spam filter). >> >> When I run a JavaFX app from Terminal it allows the Java app to activate >> unless I have Terminal > Secure Keyboard Entry turned on in which case the >> app comes to the front but doesn?t activate. That setting doesn?t make a >> difference when running a test from Gradle. No idea why you would see >> different behavior on M2 vs Intel. >> >> I ran into this on Windows which has had this sort of protection for a >> long time. I was only having trouble when running a test app using Gradle >> and the msys2 shell (it worked with Cygwin). There?s a set of rules that >> govern the handoff but I could never figure out which one was failing. The >> solution there was to use a Robot to synthesize a mouse click on the window. >> >> This all suggests that gradle is spawning a background process and >> launching the JavaFX app from there. On both Windows and macOS 14 that >> could trigger this security/privacy feature. >> >> Martin >> >> On Jan 11, 2024, at 5:40?AM, Kevin Rushforth >> wrote: >> >> Hi Johan, >> >> I can also try this today, since I have an M1 laptop and have access to >> an M2 Mac Mini, both running macOS 14.x. >> >> -- Kevin >> >> >> On 1/11/2024 12:08 AM, Johan Vos wrote: >> >> Hi Martin, >> >> Thanks for testing this. Just to make sure: the fact that the >> systemtest pass, is the problem. It shouldn't pass. The change in PR 1283 >> caused regression that I didn't notice on the M2, but I heard the test >> correctly fails on M1, and I could confirm it correctly fails on Mac/Intel >> as well. >> Now that I know that this is not just my local M2 setup, I can have a >> look at the cause -- thanks for your useful feedback! >> >> - Johan >> >> >> On Wed, Jan 10, 2024 at 7:58?PM Martin Fox wrote: >> >>> Johan, >>> >>> Are you referring to PR 1283? And are you seeing test failures on Intel >>> or M2? >>> >>> I just grabbed PR 1283 and the system test works fine on my M2 Mac. As >>> for JDK-8089848 I recently looked into that and it was very specific to >>> changing the focus while processing windowDidResignKey (though I suppose it >>> could also happen if you changed focus while processing >>> windowDidBecomeKey). In that bug I didn?t see any cases where >>> windowDidBecomeKey wasn?t called, just cases where it was called on the >>> wrong window. I don?t see any obvious smoking guns in the SystemMenuBarTest >>> that would lead to the same condition. >>> >>> Martin >>> >>> On Jan 10, 2024, at 2:10?AM, Johan Vos wrote: >>> >>> I noticed different test results when running systemtests on a mac/intel >>> versus an M2. >>> when running systemtests from a command line using >>> >>> `sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest >>> :systemTests:test --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >>> >>> I traced it down to `windowDidBecomeKey` on `GlassWindow+Overrides.m` >>> not being called on the M2. That of course leads to different paths, hence >>> different test results. >>> >>> I wonder if this is somehow related to >>> https://bugs.openjdk.org/browse/JDK-8089848. Before looking into this, >>> is this something others observed as well? >>> >>> - Johan >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Jan 12 13:56:14 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jan 2024 05:56:14 -0800 Subject: [External] : Re: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> Message-ID: <05804f0a-fce7-4100-aa87-8cfbeac7a313@oracle.com> Yeah, I just realized that you had fixed it prior to my running the tests yesterday afternoon. I reverted your most recent commit and it now fails for me, as expected, on my Intel Mac running macOS 13. I'll try now on my M1 and M2. ?-- Kevin On 1/12/2024 5:48 AM, Johan Vos wrote: > Hi Kevin, > > Thanks for testing. > With the latest version of the PR, all tests should pass on all > platforms (I believe the PR is ready now). Excluding my last commit, > the tests should?fail on all platforms. However, they pass for me (and > Martin) on M2, because the app does not get activated. > > - Johan > > On Fri, Jan 12, 2024 at 1:53?PM Kevin Rushforth > wrote: > > I ran the then latest version of the test from PR?1283 yesterday > afternoon, and for me it passed on both M1 and M2. I didn't try it > on an Intel Mac, but will do so this morning. > > I hadn't noticed any problems with our other tests when getting > things running on macOS 14 (beyond the bugs we already fixed > related to activation), but I'll take a closer look at them. It's > certainly possible we have other tests that are "passing" because > they never get activated. > > -- Kevin > > > On 1/12/2024 12:40 AM, Johan Vos wrote: >> Hi Martin, >> >> Great analysis, and that sounds very well possible. Indeed, there >> is a specific launch approach for the systemtests?where the >> launch command is created (in >> tests/system/src/test/java/test/util/Util). >> It is still unclear to me why this would happen on M2 only (and >> not on M1 or Intel), but maybe there is no causal relation. In >> any case, this means that we have to rethink how to do the system >> tests, as people (including me) can falsely assume that all tests >> passed correctly. >> >> - Johan >> >> On Thu, Jan 11, 2024 at 6:18?PM Martin Fox >> wrote: >> >> Johan, >> >> I think I see what?s going on (maybe). When I run the test >> app from gradle it fails to activate. I suspect this is due >> to changes in macOS 14 that makes it harder for an >> application to come to the front and start grabbing keyboard >> input while the user is interacting with another app. Search >> for "macos cooperative activation? (I?m leery of adding a >> link since it might trigger a spam filter). >> >> When I run a JavaFX app from Terminal it allows the Java app >> to activate unless I have Terminal > Secure Keyboard Entry >> turned on in which case the app comes to the front but >> doesn?t activate. That setting doesn?t make a difference when >> running a test from Gradle. No idea why you would see >> different behavior on M2 vs Intel. >> >> I ran into this on Windows which has had this sort of >> protection for a long time. I was only having trouble when >> running a test app using Gradle and the msys2 shell (it >> worked with Cygwin). There?s a set of rules that govern the >> handoff but I could never figure out which one was failing. >> The solution there was to use a Robot to synthesize a mouse >> click on the window. >> >> This all suggests that gradle is spawning a background >> process and launching the JavaFX app from there. On both >> Windows and macOS 14 that could trigger this security/privacy >> feature. >> >> Martin >> >>> On Jan 11, 2024, at 5:40?AM, Kevin Rushforth >>> wrote: >>> >>> Hi Johan, >>> >>> I can also try this today, since I have an M1 laptop and >>> have access to an M2 Mac Mini, both running macOS 14.x. >>> >>> -- Kevin >>> >>> >>> On 1/11/2024 12:08 AM, Johan Vos wrote: >>>> Hi Martin, >>>> >>>> Thanks for testing this. Just to make sure: the fact that >>>> the systemtest?pass, is the problem. It shouldn't pass. The >>>> change in PR 1283 caused regression that I didn't notice on >>>> the M2, but I heard the test correctly fails on M1, and I >>>> could confirm it correctly fails on Mac/Intel as well. >>>> Now that I know that this is not just my local M2 setup, I >>>> can have a look at the cause -- thanks for your useful >>>> feedback! >>>> >>>> - Johan >>>> >>>> >>>> On Wed, Jan 10, 2024 at 7:58?PM Martin Fox >>>> wrote: >>>> >>>> Johan, >>>> >>>> Are you referring to PR 1283? And are you seeing test >>>> failures on Intel or M2? >>>> >>>> I just grabbed PR 1283 and the system test works fine >>>> on my M2 Mac. As for JDK-8089848 I recently looked into >>>> that and it was very specific to changing the focus >>>> while processing windowDidResignKey (though I suppose >>>> it could also happen if you changed focus while >>>> processing windowDidBecomeKey). In that bug I didn?t >>>> see any cases where windowDidBecomeKey wasn?t called, >>>> just cases where it was called on the wrong window. I >>>> don?t see any obvious smoking guns in the >>>> SystemMenuBarTest that would lead to the same condition. >>>> >>>> Martin >>>> >>>>> On Jan 10, 2024, at 2:10?AM, Johan Vos >>>>> wrote: >>>>> >>>>> I noticed different test results when running >>>>> systemtests on a mac/intel versus an M2. >>>>> when running systemtests from a command line using >>>>> >>>>> `sh gradlew --info -PFULL_TEST=true >>>>> ?:systemTests:cleanTest :systemTests:test >>>>> --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >>>>> >>>>> I traced it down to `windowDidBecomeKey` on >>>>> `GlassWindow+Overrides.m` not being called on the M2. >>>>> That of course leads to different paths, hence >>>>> different test results. >>>>> >>>>> I wonder if this is somehow related to >>>>> https://bugs.openjdk.org/browse/JDK-8089848. >>>>> Before?looking into this, is this something others >>>>> observed as well? >>>>> >>>>> - Johan >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri Jan 12 14:08:36 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 Jan 2024 14:08:36 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: <7pcrusrJnemJxKwFIYSlK6jLlgu01PFZSEJigdf-p98=.995a3cd0-4a90-40de-a2ae-6f56683c4c88@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <_AV4eI4AVTn-0m4KD3sEQ2QdTr8mwwwqYbiPq9tCZ0A=.3a897a04-2507-407b-8b63-fb7c00076636@github.com> <7pcrusrJnemJxKwFIYSlK6jLlgu01PFZSEJigdf-p98=.995a3cd0-4a90-40de-a2ae-6f56683c4c88@github.com> Message-ID: On Fri, 12 Jan 2024 12:20:22 GMT, Marius Hanl wrote: >> Thanks for having a look, it's good to have some more use cases from other applications! The sets are used both for the style classes on `Node`s but also the set of style classes in CSS selectors (multiple style classes in selectors are even more rare I think than multiple style classes on `Node`s). >> >> I think from a performance perspective, `Duo` and `Hashless` are likely very closely matched, but I can do some testing in that area. The reason I say this is that I only got a very minor boost from including `Duo`, but kept it because it is a bit more memory efficient. >> >> If you want, I'm also curious about how many styles are used in your application (you can see this by looking at the size of `StyleClassSet#styleClasses` after all styles are loaded). > > I see, thanks for checking that out. > > I checked the application, here is the result: > After starting the app: > ![image](https://github.com/openjdk/jfx/assets/66004280/623049ac-c525-4854-8f06-b9712de5d746) > > After using it a little bit: > ![image](https://github.com/openjdk/jfx/assets/66004280/cca4df47-829a-4d9b-b937-705b6c058172) > > --- > I also checked out Scenebuilder after using it a little bit: > ![image](https://github.com/openjdk/jfx/assets/66004280/0f8992b5-1073-4c77-b906-356b86c61389) Thanks, it looks like a bit less classes are in use when compared to JFXCentral (which has about 1000), but still quite a lot. With `BitSet` that means if style classes are referenced that happen to have a high bit set, it creates an array to hold 400 bits (using 8 longs). When few style classes are active, the sets provided by `FixedCapacitySet` will be often smaller and (due to the other optimizations as well) faster. 8 longs is sufficient to hold 8 or 16 style name references depending on the JVM (32/64 bit, compressed pointers y/n). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1450495992 From lkostyra at openjdk.org Fri Jan 12 14:15:55 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 12 Jan 2024 14:15:55 GMT Subject: RFR: 8260013: Snapshot does not work for nodes in a subscene Message-ID: Originally this issue showed the problem of Node being incorrectly rendered (clipped) when snapshotting, compared to a snapshot of the whole Scene. Later on there was another problem added - lights not being taken into account if they are added to a SubScene. As it later turned out, the original problem from this bug report is a problem with ParallelCamera incorrectly estimating near/far clipping planes, which just happened to reveal itself while snapshotting a Node. During testing I found out you can make the Node clip regardless of snapshot mechanism. Clipping issue was moved to a separate bug report and this PR only fixes the inconsistency in lights being gathered for a snapshot. `Scene.doSnapshot()` was expanded to also check if SubScene provided to it is non-null and to fetch lights assigned to it. Scenario was tested with added SnapshotLightsTest. Rest of the tests were checked and don't produce any noticeable regressions. ------------- Commit messages: - Move test out of robot tests, update copyrights - Add test for snapshot lights inconsistency - Include subscene lights in snapshot Changes: https://git.openjdk.org/jfx/pull/1332/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1332&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8260013 Stats: 184 lines in 4 files changed: 173 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1332.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1332/head:pull/1332 PR: https://git.openjdk.org/jfx/pull/1332 From kevin.rushforth at oracle.com Fri Jan 12 15:17:44 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jan 2024 07:17:44 -0800 Subject: [External] : Re: MacOS windowDidBecomeKey inconsistency In-Reply-To: <05804f0a-fce7-4100-aa87-8cfbeac7a313@oracle.com> References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> <05804f0a-fce7-4100-aa87-8cfbeac7a313@oracle.com> Message-ID: <7266a430-6885-4291-969b-2546fdbc2411@oracle.com> I ran the version of your fix+test from before yesterday's fix. It fails on most of the systems (meaning the window was activated), but passes unexpectedly on two of them, one Intel and one M2: Local systems: Intel MacBook macOS 13.6.3 -- test failed M1 MacBook macOS 14.2.1 -- test failed Jenkins CI systems: Intel MacBook macOS 13.x -- test failed Intel MacBook macOS 14.1 (*) -- test PASSED M2 MacBook macOS 13.x -- test failed M2 MacBook macOS 14.0 (*) -- test PASSED (*) Note the downrev version of Sonoma We know that Apple has fixed several OS bugs in 14.2, so I am going to get our lab systems updated to that version (I thought they were already running 14.2[.1] and don't want to be chasing down problems that turn out to be related to running an older version than expected). In the mean time, can you check the versions of the OS on your M1 and M2 systems? -- Kevin On 1/12/2024 5:56 AM, Kevin Rushforth wrote: > Yeah, I just realized that you had fixed it prior to my running the > tests yesterday afternoon. I reverted your most recent commit and it > now fails for me, as expected, on my Intel Mac running macOS 13. I'll > try now on my M1 and M2. > > ?-- Kevin > > On 1/12/2024 5:48 AM, Johan Vos wrote: >> Hi Kevin, >> >> Thanks for testing. >> With the latest version of the PR, all tests should pass on all >> platforms (I believe the PR is ready now). Excluding my last commit, >> the tests should?fail on all platforms. However, they pass for me >> (and Martin) on M2, because the app does not get activated. >> >> - Johan >> >> On Fri, Jan 12, 2024 at 1:53?PM Kevin Rushforth >> wrote: >> >> I ran the then latest version of the test from PR?1283 yesterday >> afternoon, and for me it passed on both M1 and M2. I didn't try >> it on an Intel Mac, but will do so this morning. >> >> I hadn't noticed any problems with our other tests when getting >> things running on macOS 14 (beyond the bugs we already fixed >> related to activation), but I'll take a closer look at them. It's >> certainly possible we have other tests that are "passing" because >> they never get activated. >> >> -- Kevin >> >> >> On 1/12/2024 12:40 AM, Johan Vos wrote: >>> Hi Martin, >>> >>> Great analysis, and that sounds very well possible. Indeed, >>> there is a specific launch approach for the systemtests?where >>> the launch command is created (in >>> tests/system/src/test/java/test/util/Util). >>> It is still unclear to me why this would happen on M2 only (and >>> not on M1 or Intel), but maybe there is no causal relation. In >>> any case, this means that we have to rethink how to do the >>> system tests, as people (including me) can falsely assume that >>> all tests passed correctly. >>> >>> - Johan >>> >>> On Thu, Jan 11, 2024 at 6:18?PM Martin Fox >>> wrote: >>> >>> Johan, >>> >>> I think I see what?s going on (maybe). When I run the test >>> app from gradle it fails to activate. I suspect this is due >>> to changes in macOS 14 that makes it harder for an >>> application to come to the front and start grabbing keyboard >>> input while the user is interacting with another app. Search >>> for "macos cooperative activation? (I?m leery of adding a >>> link since it might trigger a spam filter). >>> >>> When I run a JavaFX app from Terminal it allows the Java app >>> to activate unless I have Terminal > Secure Keyboard Entry >>> turned on in which case the app comes to the front but >>> doesn?t activate. That setting doesn?t make a difference >>> when running a test from Gradle. No idea why you would see >>> different behavior on M2 vs Intel. >>> >>> I ran into this on Windows which has had this sort of >>> protection for a long time. I was only having trouble when >>> running a test app using Gradle and the msys2 shell (it >>> worked with Cygwin). There?s a set of rules that govern the >>> handoff but I could never figure out which one was failing. >>> The solution there was to use a Robot to synthesize a mouse >>> click on the window. >>> >>> This all suggests that gradle is spawning a background >>> process and launching the JavaFX app from there. On both >>> Windows and macOS 14 that could trigger this >>> security/privacy feature. >>> >>> Martin >>> >>>> On Jan 11, 2024, at 5:40?AM, Kevin Rushforth >>>> wrote: >>>> >>>> Hi Johan, >>>> >>>> I can also try this today, since I have an M1 laptop and >>>> have access to an M2 Mac Mini, both running macOS 14.x. >>>> >>>> -- Kevin >>>> >>>> >>>> On 1/11/2024 12:08 AM, Johan Vos wrote: >>>>> Hi Martin, >>>>> >>>>> Thanks for testing this. Just to make sure: the fact that >>>>> the systemtest?pass, is the problem. It shouldn't pass. >>>>> The change in PR 1283 caused regression that I didn't >>>>> notice on the M2, but I heard the test correctly fails on >>>>> M1, and I could confirm it correctly fails on Mac/Intel as >>>>> well. >>>>> Now that I know that this is not just my local M2 setup, I >>>>> can have a look at the cause -- thanks for your useful >>>>> feedback! >>>>> >>>>> - Johan >>>>> >>>>> >>>>> On Wed, Jan 10, 2024 at 7:58?PM Martin Fox >>>>> wrote: >>>>> >>>>> Johan, >>>>> >>>>> Are you referring to PR 1283? And are you seeing test >>>>> failures on Intel or M2? >>>>> >>>>> I just grabbed PR 1283 and the system test works fine >>>>> on my M2 Mac. As for JDK-8089848 I recently looked >>>>> into that and it was very specific to changing the >>>>> focus while processing windowDidResignKey (though I >>>>> suppose it could also happen if you changed focus >>>>> while processing windowDidBecomeKey). In that bug I >>>>> didn?t see any cases where windowDidBecomeKey wasn?t >>>>> called, just cases where it was called on the wrong >>>>> window. I don?t see any obvious smoking guns in the >>>>> SystemMenuBarTest that would lead to the same condition. >>>>> >>>>> Martin >>>>> >>>>>> On Jan 10, 2024, at 2:10?AM, Johan Vos >>>>>> wrote: >>>>>> >>>>>> I noticed different test results when running >>>>>> systemtests on a mac/intel versus an M2. >>>>>> when running systemtests from a command line using >>>>>> >>>>>> `sh gradlew --info -PFULL_TEST=true >>>>>> ?:systemTests:cleanTest :systemTests:test >>>>>> --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >>>>>> >>>>>> I traced it down to `windowDidBecomeKey` on >>>>>> `GlassWindow+Overrides.m` not being called on the M2. >>>>>> That of course leads to different paths, hence >>>>>> different test results. >>>>>> >>>>>> I wonder if this is somehow related to >>>>>> https://bugs.openjdk.org/browse/JDK-8089848. >>>>>> Before?looking into this, is this something others >>>>>> observed as well? >>>>>> >>>>>> - Johan >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jan 12 15:53:30 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 15:53:30 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: <1lnciNH0HixCSCdLFHlb2JJnniid_WopcKFGE7hzLMk=.c1f02a45-a3ed-4491-b8b3-cfe4e6653063@github.com> On Fri, 12 Jan 2024 05:16:33 GMT, Karthik P K wrote: >> @karthikpandelu , the more I think about it, the less I like the idea of overloading (textRunStart and curRunStart). >> what if things will change in the future? >> >> I think it'll be much cleaner to pass a boolean forTextFlow (or forText) or some such. we have to compute such a boolean flag anyway, why not just pass it? > > Are you suggesting to pass boolean as parameter in addition to textRunStart and curRunStart? If that is the case then yes I think it would be better. that's right, something like this: public Hit getHitInfo(float x, float y, String text, int textRunStart, int curRunStart, boolean forTextFlow); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450629952 From angorya at openjdk.org Fri Jan 12 15:56:30 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 15:56:30 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 06:29:44 GMT, Karthik P K wrote: > Do you think it is better to address that issue after we complete JDK-8318095? I think the solution for JDK-8318095 is just to trigger a layout, so we could do all these in parallel (as long as we don't resize the container). I was hoping to finish this review today. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1889550371 From johan.vos at gluonhq.com Fri Jan 12 15:57:28 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 12 Jan 2024 16:57:28 +0100 Subject: [External] : Re: MacOS windowDidBecomeKey inconsistency In-Reply-To: <7266a430-6885-4291-969b-2546fdbc2411@oracle.com> References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> <05804f0a-fce7-4100-aa87-8cfbeac7a313@oracle.com> <7266a430-6885-4291-969b-2546fdbc2411@oracle.com> Message-ID: I updated (my M2) from 14.1 to 14.2.1 and now the test correctly fails (after reverting my last commit). Since it passed before (14.1) and failed after (14.2.1) updating, it is indeed more likely to be related to OS version rather than CPU arch (which I would find very weird). - Johan On Fri, Jan 12, 2024 at 4:18?PM Kevin Rushforth wrote: > I ran the version of your fix+test from before yesterday's fix. It fails > on most of the systems (meaning the window was activated), but passes > unexpectedly on two of them, one Intel and one M2: > > Local systems: > > Intel MacBook macOS 13.6.3 -- test failed > M1 MacBook macOS 14.2.1 -- test failed > > Jenkins CI systems: > > Intel MacBook macOS 13.x -- test failed > Intel MacBook macOS 14.1 (*) -- test PASSED > M2 MacBook macOS 13.x -- test failed > M2 MacBook macOS 14.0 (*) -- test PASSED > > (*) Note the downrev version of Sonoma > > We know that Apple has fixed several OS bugs in 14.2, so I am going to get > our lab systems updated to that version (I thought they were already > running 14.2[.1] and don't want to be chasing down problems that turn out > to be related to running an older version than expected). In the mean time, > can you check the versions of the OS on your M1 and M2 systems? > > -- Kevin > > > On 1/12/2024 5:56 AM, Kevin Rushforth wrote: > > Yeah, I just realized that you had fixed it prior to my running the tests > yesterday afternoon. I reverted your most recent commit and it now fails > for me, as expected, on my Intel Mac running macOS 13. I'll try now on my > M1 and M2. > > -- Kevin > > On 1/12/2024 5:48 AM, Johan Vos wrote: > > Hi Kevin, > > Thanks for testing. > With the latest version of the PR, all tests should pass on all platforms > (I believe the PR is ready now). Excluding my last commit, the tests > should fail on all platforms. However, they pass for me (and Martin) on M2, > because the app does not get activated. > > - Johan > > On Fri, Jan 12, 2024 at 1:53?PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I ran the then latest version of the test from PR 1283 yesterday >> afternoon, and for me it passed on both M1 and M2. I didn't try it on an >> Intel Mac, but will do so this morning. >> >> I hadn't noticed any problems with our other tests when getting things >> running on macOS 14 (beyond the bugs we already fixed related to >> activation), but I'll take a closer look at them. It's certainly possible >> we have other tests that are "passing" because they never get activated. >> >> -- Kevin >> >> >> On 1/12/2024 12:40 AM, Johan Vos wrote: >> >> Hi Martin, >> >> Great analysis, and that sounds very well possible. Indeed, there is a >> specific launch approach for the systemtests where the launch command is >> created (in tests/system/src/test/java/test/util/Util). >> It is still unclear to me why this would happen on M2 only (and not on M1 >> or Intel), but maybe there is no causal relation. In any case, this means >> that we have to rethink how to do the system tests, as people (including >> me) can falsely assume that all tests passed correctly. >> >> - Johan >> >> On Thu, Jan 11, 2024 at 6:18?PM Martin Fox wrote: >> >>> Johan, >>> >>> I think I see what?s going on (maybe). When I run the test app from >>> gradle it fails to activate. I suspect this is due to changes in macOS 14 >>> that makes it harder for an application to come to the front and start >>> grabbing keyboard input while the user is interacting with another app. >>> Search for "macos cooperative activation? (I?m leery of adding a link since >>> it might trigger a spam filter). >>> >>> When I run a JavaFX app from Terminal it allows the Java app to activate >>> unless I have Terminal > Secure Keyboard Entry turned on in which case the >>> app comes to the front but doesn?t activate. That setting doesn?t make a >>> difference when running a test from Gradle. No idea why you would see >>> different behavior on M2 vs Intel. >>> >>> I ran into this on Windows which has had this sort of protection for a >>> long time. I was only having trouble when running a test app using Gradle >>> and the msys2 shell (it worked with Cygwin). There?s a set of rules that >>> govern the handoff but I could never figure out which one was failing. The >>> solution there was to use a Robot to synthesize a mouse click on the window. >>> >>> This all suggests that gradle is spawning a background process and >>> launching the JavaFX app from there. On both Windows and macOS 14 that >>> could trigger this security/privacy feature. >>> >>> Martin >>> >>> On Jan 11, 2024, at 5:40?AM, Kevin Rushforth >>> wrote: >>> >>> Hi Johan, >>> >>> I can also try this today, since I have an M1 laptop and have access to >>> an M2 Mac Mini, both running macOS 14.x. >>> >>> -- Kevin >>> >>> >>> On 1/11/2024 12:08 AM, Johan Vos wrote: >>> >>> Hi Martin, >>> >>> Thanks for testing this. Just to make sure: the fact that the >>> systemtest pass, is the problem. It shouldn't pass. The change in PR 1283 >>> caused regression that I didn't notice on the M2, but I heard the test >>> correctly fails on M1, and I could confirm it correctly fails on Mac/Intel >>> as well. >>> Now that I know that this is not just my local M2 setup, I can have a >>> look at the cause -- thanks for your useful feedback! >>> >>> - Johan >>> >>> >>> On Wed, Jan 10, 2024 at 7:58?PM Martin Fox >>> wrote: >>> >>>> Johan, >>>> >>>> Are you referring to PR 1283? And are you seeing test failures on Intel >>>> or M2? >>>> >>>> I just grabbed PR 1283 and the system test works fine on my M2 Mac. As >>>> for JDK-8089848 I recently looked into that and it was very specific to >>>> changing the focus while processing windowDidResignKey (though I suppose it >>>> could also happen if you changed focus while processing >>>> windowDidBecomeKey). In that bug I didn?t see any cases where >>>> windowDidBecomeKey wasn?t called, just cases where it was called on the >>>> wrong window. I don?t see any obvious smoking guns in the SystemMenuBarTest >>>> that would lead to the same condition. >>>> >>>> Martin >>>> >>>> On Jan 10, 2024, at 2:10?AM, Johan Vos wrote: >>>> >>>> I noticed different test results when running systemtests on a >>>> mac/intel versus an M2. >>>> when running systemtests from a command line using >>>> >>>> `sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest >>>> :systemTests:test --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >>>> >>>> I traced it down to `windowDidBecomeKey` on `GlassWindow+Overrides.m` >>>> not being called on the M2. That of course leads to different paths, hence >>>> different test results. >>>> >>>> I wonder if this is somehow related to >>>> https://bugs.openjdk.org/browse/JDK-8089848. Before looking into this, >>>> is this something others observed as well? >>>> >>>> - Johan >>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Jan 12 16:25:09 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jan 2024 08:25:09 -0800 Subject: [External] : Re: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> <05804f0a-fce7-4100-aa87-8cfbeac7a313@oracle.com> <7266a430-6885-4291-969b-2546fdbc2411@oracle.com> Message-ID: So that does strongly suggest that this was an OS bug on earlier macOS 14.0.x and 14.1.x now fixed in 14.2. FYI, here are four Swing / AWT bugs that point to problems with native events, all of which are fixed in macOS 14.2: https://bugs.openjdk.org/browse/JDK-8320056 https://bugs.openjdk.org/browse/JDK-8320057 https://bugs.openjdk.org/browse/JDK-8320110 https://bugs.openjdk.org/browse/JDK-8320111 I'll report back after our two Jenkins systems are upgraded to macOS 14.2.1. -- Kevin On 1/12/2024 7:57 AM, Johan Vos wrote: > I updated (my M2) from 14.1 to 14.2.1 and now the test correctly fails > (after reverting my last commit). > Since it passed before (14.1) and failed after (14.2.1) updating, it > is indeed more likely to be related to OS version rather than CPU arch > (which I would find very weird). > > - Johan > > On Fri, Jan 12, 2024 at 4:18?PM Kevin Rushforth > wrote: > > I ran the version of your fix+test from before yesterday's fix. It > fails on most of the systems (meaning the window was activated), > but passes unexpectedly on two of them, one Intel and one M2: > > Local systems: > > Intel MacBook macOS 13.6.3 -- test failed > M1 MacBook macOS 14.2.1 -- test failed > > Jenkins CI systems: > > Intel MacBook macOS 13.x -- test failed > Intel MacBook macOS 14.1 (*) -- test PASSED > M2 MacBook macOS 13.x -- test failed > M2 MacBook macOS 14.0 (*) -- test PASSED > > (*) Note the downrev version of Sonoma > > We know that Apple has fixed several OS bugs in 14.2, so I am > going to get our lab systems updated to that version (I thought > they were already running 14.2[.1] and don't want to be chasing > down problems that turn out to be related to running an older > version than expected). In the mean time, can you check the > versions of the OS on your M1 and M2 systems? > > -- Kevin > > > On 1/12/2024 5:56 AM, Kevin Rushforth wrote: >> Yeah, I just realized that you had fixed it prior to my running >> the tests yesterday afternoon. I reverted your most recent commit >> and it now fails for me, as expected, on my Intel Mac running >> macOS 13. I'll try now on my M1 and M2. >> >> ?-- Kevin >> >> On 1/12/2024 5:48 AM, Johan Vos wrote: >>> Hi Kevin, >>> >>> Thanks for testing. >>> With the latest version of the PR, all tests should pass on all >>> platforms (I believe the PR is ready now). Excluding my last >>> commit, the tests should?fail on all platforms. However, they >>> pass for me (and Martin) on M2, because the app does not get >>> activated. >>> >>> - Johan >>> >>> On Fri, Jan 12, 2024 at 1:53?PM Kevin Rushforth >>> wrote: >>> >>> I ran the then latest version of the test from PR?1283 >>> yesterday afternoon, and for me it passed on both M1 and M2. >>> I didn't try it on an Intel Mac, but will do so this morning. >>> >>> I hadn't noticed any problems with our other tests when >>> getting things running on macOS 14 (beyond the bugs we >>> already fixed related to activation), but I'll take a closer >>> look at them. It's certainly possible we have other tests >>> that are "passing" because they never get activated. >>> >>> -- Kevin >>> >>> >>> On 1/12/2024 12:40 AM, Johan Vos wrote: >>>> Hi Martin, >>>> >>>> Great analysis, and that sounds very well possible. Indeed, >>>> there is a specific launch approach for the >>>> systemtests?where the launch command is created (in >>>> tests/system/src/test/java/test/util/Util). >>>> It is still unclear to me why this would happen on M2 only >>>> (and not on M1 or Intel), but maybe there is no causal >>>> relation. In any case, this means that we have to rethink >>>> how to do the system tests, as people (including me) can >>>> falsely assume that all tests passed correctly. >>>> >>>> - Johan >>>> >>>> On Thu, Jan 11, 2024 at 6:18?PM Martin Fox >>>> wrote: >>>> >>>> Johan, >>>> >>>> I think I see what?s going on (maybe). When I run the >>>> test app from gradle it fails to activate. I suspect >>>> this is due to changes in macOS 14 that makes it harder >>>> for an application to come to the front and start >>>> grabbing keyboard input while the user is interacting >>>> with another app. Search for "macos cooperative >>>> activation? (I?m leery of adding a link since it might >>>> trigger a spam filter). >>>> >>>> When I run a JavaFX app from Terminal it allows the >>>> Java app to activate unless I have Terminal > Secure >>>> Keyboard Entry turned on in which case the app comes to >>>> the front but doesn?t activate. That setting doesn?t >>>> make a difference when running a test from Gradle. No >>>> idea why you would see different behavior on M2 vs Intel. >>>> >>>> I ran into this on Windows which has had this sort of >>>> protection for a long time. I was only having trouble >>>> when running a test app using Gradle and the msys2 >>>> shell (it worked with Cygwin). There?s a set of rules >>>> that govern the handoff but I could never figure out >>>> which one was failing. The solution there was to use a >>>> Robot to synthesize a mouse click on the window. >>>> >>>> This all suggests that gradle is spawning a background >>>> process and launching the JavaFX app from there. On >>>> both Windows and macOS 14 that could trigger this >>>> security/privacy feature. >>>> >>>> Martin >>>> >>>>> On Jan 11, 2024, at 5:40?AM, Kevin Rushforth >>>>> wrote: >>>>> >>>>> Hi Johan, >>>>> >>>>> I can also try this today, since I have an M1 laptop >>>>> and have access to an M2 Mac Mini, both running macOS >>>>> 14.x. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 1/11/2024 12:08 AM, Johan Vos wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thanks for testing this. Just to make sure: the fact >>>>>> that the systemtest?pass, is the problem. It >>>>>> shouldn't pass. The change in PR 1283 caused >>>>>> regression that I didn't notice on the M2, but I >>>>>> heard the test correctly fails on M1, and I could >>>>>> confirm it correctly fails on Mac/Intel as well. >>>>>> Now that I know that this is not just my local M2 >>>>>> setup, I can have a look at the cause -- thanks for >>>>>> your useful feedback! >>>>>> >>>>>> - Johan >>>>>> >>>>>> >>>>>> On Wed, Jan 10, 2024 at 7:58?PM Martin Fox >>>>>> wrote: >>>>>> >>>>>> Johan, >>>>>> >>>>>> Are you referring to PR 1283? And are you seeing >>>>>> test failures on Intel or M2? >>>>>> >>>>>> I just grabbed PR 1283 and the system test works >>>>>> fine on my M2 Mac. As for JDK-8089848 I recently >>>>>> looked into that and it was very specific to >>>>>> changing the focus while processing >>>>>> windowDidResignKey (though I suppose it could >>>>>> also happen if you changed focus while processing >>>>>> windowDidBecomeKey). In that bug I didn?t see any >>>>>> cases where windowDidBecomeKey wasn?t called, >>>>>> just cases where it was called on the wrong >>>>>> window. I don?t see any obvious smoking guns in >>>>>> the SystemMenuBarTest that would lead to the same >>>>>> condition. >>>>>> >>>>>> Martin >>>>>> >>>>>>> On Jan 10, 2024, at 2:10?AM, Johan Vos >>>>>>> wrote: >>>>>>> >>>>>>> I noticed different test results when running >>>>>>> systemtests on a mac/intel versus an M2. >>>>>>> when running systemtests from a command line using >>>>>>> >>>>>>> `sh gradlew --info -PFULL_TEST=true >>>>>>> ?:systemTests:cleanTest :systemTests:test >>>>>>> --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >>>>>>> >>>>>>> I traced it down to `windowDidBecomeKey` on >>>>>>> `GlassWindow+Overrides.m` not being called on >>>>>>> the M2. That of course leads to different paths, >>>>>>> hence different test results. >>>>>>> >>>>>>> I wonder if this is somehow related to >>>>>>> https://bugs.openjdk.org/browse/JDK-8089848. >>>>>>> Before?looking into this, is this something >>>>>>> others observed as well? >>>>>>> >>>>>>> - Johan >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jan 12 16:56:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 16:56:35 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: <8DUTMaIYzZeOZ2YIgySKrYoJDJDmndlji-eKPxX3U9s=.f4838d60-32e3-4ab6-be96-d90d978eed1f@github.com> On Thu, 11 Jan 2024 10:15:01 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Code review changes modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 474: > 472: if (x < run.getWidth()) break; > 473: if (i + 1 < runs.length) { > 474: if (runs[i + 1].isLinebreak()) break; could we surround break; with { }'s here and on lines 461, 472, 474 please? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 480: > 478: } > 479: } else { > 480: // To calculate hit info of Text embedded in TextFlow the comments on lines 480 and 451 are a bit confusing: both refer to Text. could you please clarify? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 492: > 490: for (TextRun r: runs) { > 491: if (r.getStart() != curRunStart && r.getTextSpan().getText().equals(text)) { > 492: isMultiRunText = true; minor: we could reduce the scope of `isMultiRunText` by moving its declaration from line 427 to line 490 modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 524: > 522: break; > 523: } > 524: // For only English Text embedded in TextFlow in RTL orientation this comment seems misleading (by English you mean LTR, right?) would it be possible to re-phrase, explaining why? does it mean the RTL text has been handled by the previous code block and now we are dealing with LTR? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 562: > 560: charIndex += textWidthPrevLine; > 561: charIndex += relIndex; > 562: if (run.getLevel() % 2 != 0) { I wish there was an explanation of the meaning of `level` And since there are several places where it checks for it being odd, I wish there was a method in TextRun with a descriptive name rather than this computation (and bit logic might be faster): public boolean isLevelOdd() { // or whatever the meaning is return (level & 0x01) != 0; } modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1040: > 1038: > 1039: private int findRunIndex(double x, double y, GlyphList[] runs) { > 1040: int runIndex = 0; some general comment for this method: 1. there are many places where runs[runIndex] is repeated within the same code block, I wonder if it would make sense to create a local variable. It might be tricky because the runIndex changes mid-flight. 2. perhaps `runIndex` could be shortened to `ix` to make the lines shorter? tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 111: > 109: static Random random; > 110: static Robot robot; > 111: static Text textOne; maybe rename to 'text' since there is only one instance? or `control`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450655360 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450660028 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450676811 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450680153 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450687339 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450691638 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1450693272 From angorya at openjdk.org Fri Jan 12 17:01:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 17:01:31 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: <1C2tusDOHT88HmzpkwPyENHtAUr7TR3kUla2SITVSPU=.f2b16e15-09be-4edb-8ce6-be5aa37cdd2a@github.com> On Thu, 11 Jan 2024 10:15:01 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Code review changes There seems to be a weird problem with Text (tested on macOS) in the Monkey Tester. 'Writing Systems' is a multi-line text with a tricky font (which does not get rendered correctly in LTR mode for some reason, but does in RTL). So if you try to hover over Aramaic line, the hit test info does not get updated: ![Screenshot 2024-01-12 at 08 54 08](https://github.com/openjdk/jfx/assets/107069028/3f3e5fc1-809b-48ac-80c4-1a742e6c147b) hit test is also not updated over some other areas, so you may want to research this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1889648627 From angorya at openjdk.org Fri Jan 12 20:00:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 20:00:34 GMT Subject: RFR: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:13:09 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin when it is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install listener but is then rejected when setting it due to the `skinProperty` class constraint > -> `PopupControl` is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomSkin extends Skin { > public MyCustomSkin(C skinnable, boolean someFlag) { ... } > } > > Now if we would change the skin of the `PopupControl` two times like this: > > popup.setSkin(new MyCustomSkin(popup, true)); > popup.setSkin(new MyCustomSkin(popup, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. > > This is the same issue and fix as done for `Control` in [JDK-8276056](https://bugs.openjdk.org/browse/JDK-8276056) (PR: https://github.com/openjdk/jfx/pull/806) Marked as reviewed by angorya (Reviewer). I think the proposed fix is correct. I've tried to re-load skin via CSS (see https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/PopupControl_SetSkin_8323615.java ) and it does seem to reload correctly, as far as I can tell. Loading fails without the fix, as expected. Still, i would like a second pair of eyes to look at this, if possible. modules/javafx.controls/src/test/java/test/javafx/scene/control/PopupControlTest.java line 680: > 678: assertNotEquals("New skin was not set", oldSkin, newSkin); > 679: } > 680: minor: please remove extra newline, I'll reapprove if you choose to make the change ------------- PR Review: https://git.openjdk.org/jfx/pull/1331#pullrequestreview-1818950331 PR Comment: https://git.openjdk.org/jfx/pull/1331#issuecomment-1889873614 PR Review Comment: https://git.openjdk.org/jfx/pull/1331#discussion_r1450870863 From kevin.rushforth at oracle.com Fri Jan 12 22:49:40 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jan 2024 14:49:40 -0800 Subject: [External] : Re: MacOS windowDidBecomeKey inconsistency In-Reply-To: References: <396E7315-DF6E-4D26-8E6E-571B4229423A@sbcglobal.net> <069452a2-70ea-49b8-9e06-7078771dada5@oracle.com> <05804f0a-fce7-4100-aa87-8cfbeac7a313@oracle.com> <7266a430-6885-4291-969b-2546fdbc2411@oracle.com> Message-ID: <6ca6d40b-ab50-47cd-8fa8-de50a03823a3@oracle.com> Interesting. I reran our headful test job after updating to macOS 14.2.1 and it didn't make a difference -- the SystemMenuBarTest passes on both the Intel and M2 systems. Not sure what to make of this, but you might be right about there being an aspect of this that's timing related. I can take a closer look next week. -- Kevin On 1/12/2024 2:04 PM, Martin Fox wrote: > I think this is related to event ordering/timing. On my M2 Studio > running 14.2.1 the test app still failed to activate. Well, unless I > rebooted my system. In that case it activated only on the first test > run. From there on out it failed to activate. > > I?m seeing a puzzling difference. If I run an app from the command > line the [NSApp activate] call occurs before the window is made > visible but from Gradle it occurs after. To get the app to > consistently activate when run from Gradle I had to add > windowDidChangeScreen to the delegate and call [NSApp activate] from > there. This moves the activation call to an earlier point when we run > from Gradle but to a later point when running a JavaFX app directly. > > In any case I don?t think this is an issue with cooperative > activation, it seems a Gradle run changes the order of events in a > surprising way that can interfere with activation. Sometimes. > > Martin > >> On Jan 12, 2024, at 8:25?AM, Kevin Rushforth >> wrote: >> >> So that does strongly suggest that this was an OS bug on earlier >> macOS 14.0.x and 14.1.x now fixed in 14.2. FYI, here are four Swing / >> AWT bugs that point to problems with native events, all of which are >> fixed in macOS 14.2: >> >> https://bugs.openjdk.org/browse/JDK-8320056 >> https://bugs.openjdk.org/browse/JDK-8320057 >> https://bugs.openjdk.org/browse/JDK-8320110 >> https://bugs.openjdk.org/browse/JDK-8320111 >> >> I'll report back after our two Jenkins systems are upgraded to macOS >> 14.2.1. >> >> -- Kevin >> >> >> On 1/12/2024 7:57 AM, Johan Vos wrote: >>> I updated (my M2) from 14.1 to 14.2.1 and now the test correctly >>> fails (after reverting my last commit). >>> Since it passed before (14.1) and failed after (14.2.1) updating, it >>> is indeed more likely to be related to OS version rather than CPU >>> arch (which I would find very weird). >>> >>> - Johan >>> >>> On Fri, Jan 12, 2024 at 4:18?PM Kevin Rushforth >>> wrote: >>> >>> I ran the version of your fix+test from before yesterday's fix. >>> It fails on most of the systems (meaning the window was >>> activated), but passes unexpectedly on two of them, one Intel >>> and one M2: >>> >>> Local systems: >>> >>> Intel MacBook macOS 13.6.3 -- test failed >>> M1 MacBook macOS 14.2.1 -- test failed >>> >>> Jenkins CI systems: >>> >>> Intel MacBook macOS 13.x -- test failed >>> Intel MacBook macOS 14.1 (*) -- test PASSED >>> M2 MacBook macOS 13.x -- test failed >>> M2 MacBook macOS 14.0 (*) -- test PASSED >>> >>> (*) Note the downrev version of Sonoma >>> >>> We know that Apple has fixed several OS bugs in 14.2, so I am >>> going to get our lab systems updated to that version (I thought >>> they were already running 14.2[.1] and don't want to be chasing >>> down problems that turn out to be related to running an older >>> version than expected). In the mean time, can you check the >>> versions of the OS on your M1 and M2 systems? >>> >>> -- Kevin >>> >>> >>> On 1/12/2024 5:56 AM, Kevin Rushforth wrote: >>>> Yeah, I just realized that you had fixed it prior to my running >>>> the tests yesterday afternoon. I reverted your most recent >>>> commit and it now fails for me, as expected, on my Intel Mac >>>> running macOS 13. I'll try now on my M1 and M2. >>>> >>>> ?-- Kevin >>>> >>>> On 1/12/2024 5:48 AM, Johan Vos wrote: >>>>> Hi Kevin, >>>>> >>>>> Thanks for testing. >>>>> With the latest version of the PR, all tests should pass on >>>>> all platforms (I believe the PR is ready now). Excluding my >>>>> last commit, the tests should?fail on all platforms. However, >>>>> they pass for me (and Martin) on M2, because the app does not >>>>> get activated. >>>>> >>>>> - Johan >>>>> >>>>> On Fri, Jan 12, 2024 at 1:53?PM Kevin Rushforth >>>>> wrote: >>>>> >>>>> I ran the then latest version of the test from PR?1283 >>>>> yesterday afternoon, and for me it passed on both M1 and >>>>> M2. I didn't try it on an Intel Mac, but will do so this >>>>> morning. >>>>> >>>>> I hadn't noticed any problems with our other tests when >>>>> getting things running on macOS 14 (beyond the bugs we >>>>> already fixed related to activation), but I'll take a >>>>> closer look at them. It's certainly possible we have other >>>>> tests that are "passing" because they never get activated. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 1/12/2024 12:40 AM, Johan Vos wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Great analysis, and that sounds very well possible. >>>>>> Indeed, there is a specific launch approach for the >>>>>> systemtests?where the launch command is created (in >>>>>> tests/system/src/test/java/test/util/Util). >>>>>> It is still unclear to me why this would happen on M2 >>>>>> only (and not on M1 or Intel), but maybe there is no >>>>>> causal relation. In any case, this means that we have to >>>>>> rethink how to do the system tests, as people (including >>>>>> me) can falsely assume that all tests passed correctly. >>>>>> >>>>>> - Johan >>>>>> >>>>>> On Thu, Jan 11, 2024 at 6:18?PM Martin Fox >>>>>> wrote: >>>>>> >>>>>> Johan, >>>>>> >>>>>> I think I see what?s going on (maybe). When I run the >>>>>> test app from gradle it fails to activate. I suspect >>>>>> this is due to changes in macOS 14 that makes it >>>>>> harder for an application to come to the front and >>>>>> start grabbing keyboard input while the user is >>>>>> interacting with another app. Search for "macos >>>>>> cooperative activation? (I?m leery of adding a link >>>>>> since it might trigger a spam filter). >>>>>> >>>>>> When I run a JavaFX app from Terminal it allows the >>>>>> Java app to activate unless I have Terminal > Secure >>>>>> Keyboard Entry turned on in which case the app comes >>>>>> to the front but doesn?t activate. That setting >>>>>> doesn?t make a difference when running a test from >>>>>> Gradle. No idea why you would see different behavior >>>>>> on M2 vs Intel. >>>>>> >>>>>> I ran into this on Windows which has had this sort of >>>>>> protection for a long time. I was only having trouble >>>>>> when running a test app using Gradle and the msys2 >>>>>> shell (it worked with Cygwin). There?s a set of rules >>>>>> that govern the handoff but I could never figure out >>>>>> which one was failing. The solution there was to use >>>>>> a Robot to synthesize a mouse click on the window. >>>>>> >>>>>> This all suggests that gradle is spawning a >>>>>> background process and launching the JavaFX app from >>>>>> there. On both Windows and macOS 14 that could >>>>>> trigger this security/privacy feature. >>>>>> >>>>>> Martin >>>>>> >>>>>>> On Jan 11, 2024, at 5:40?AM, Kevin Rushforth >>>>>>> wrote: >>>>>>> >>>>>>> Hi Johan, >>>>>>> >>>>>>> I can also try this today, since I have an M1 laptop >>>>>>> and have access to an M2 Mac Mini, both running >>>>>>> macOS 14.x. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 1/11/2024 12:08 AM, Johan Vos wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Thanks for testing this. Just to make sure: the >>>>>>>> fact that the systemtest?pass, is the problem. It >>>>>>>> shouldn't pass. The change in PR 1283 caused >>>>>>>> regression that I didn't notice on the M2, but I >>>>>>>> heard the test correctly fails on M1, and I could >>>>>>>> confirm it correctly fails on Mac/Intel as well. >>>>>>>> Now that I know that this is not just my local M2 >>>>>>>> setup, I can have a look at the cause -- thanks for >>>>>>>> your useful feedback! >>>>>>>> >>>>>>>> - Johan >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jan 10, 2024 at 7:58?PM Martin Fox >>>>>>>> wrote: >>>>>>>> >>>>>>>> Johan, >>>>>>>> >>>>>>>> Are you referring to PR 1283? And are you >>>>>>>> seeing test failures on Intel or M2? >>>>>>>> >>>>>>>> I just grabbed PR 1283 and the system test >>>>>>>> works fine on my M2 Mac. As for JDK-8089848 I >>>>>>>> recently looked into that and it was very >>>>>>>> specific to changing the focus while processing >>>>>>>> windowDidResignKey (though I suppose it could >>>>>>>> also happen if you changed focus while >>>>>>>> processing windowDidBecomeKey). In that bug I >>>>>>>> didn?t see any cases where windowDidBecomeKey >>>>>>>> wasn?t called, just cases where it was called >>>>>>>> on the wrong window. I don?t see any obvious >>>>>>>> smoking guns in the SystemMenuBarTest that >>>>>>>> would lead to the same condition. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>>> On Jan 10, 2024, at 2:10?AM, Johan Vos >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I noticed different test results when running >>>>>>>>> systemtests on a mac/intel versus an M2. >>>>>>>>> when running systemtests from a command line >>>>>>>>> using >>>>>>>>> >>>>>>>>> `sh gradlew --info -PFULL_TEST=true >>>>>>>>> ?:systemTests:cleanTest :systemTests:test >>>>>>>>> --tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest` >>>>>>>>> >>>>>>>>> I traced it down to `windowDidBecomeKey` on >>>>>>>>> `GlassWindow+Overrides.m` not being called on >>>>>>>>> the M2. That of course leads to different >>>>>>>>> paths, hence different test results. >>>>>>>>> >>>>>>>>> I wonder if this is somehow related to >>>>>>>>> https://bugs.openjdk.org/browse/JDK-8089848. >>>>>>>>> Before?looking into this, is this something >>>>>>>>> others observed as well? >>>>>>>>> >>>>>>>>> - Johan >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jan 12 23:47:30 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jan 2024 23:47:30 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 12:31:20 GMT, Florian Kirmaier wrote: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Tested on macOS 14.1.2 with ListView, fixed and variable cell height, using MonkeyTester https://github.com/andy-goryachev-oracle/MonkeyTest I do see two problems: 1. With variable height cells: if I click below the scrollbar thumb, followed by a click above the thumb, I expect the view to go back to the same position exactly, but it does not (see the screenshots). I think I've mentioned this problem before in some other PR. initial condition: ![Screenshot 2024-01-12 at 15 39 13](https://github.com/openjdk/jfx/assets/107069028/33f9f494-5605-4297-9a9f-b38e1c67ba0c) clicked below the thumb: ![Screenshot 2024-01-12 at 15 39 17](https://github.com/openjdk/jfx/assets/107069028/27f3bf28-1d2d-48b7-91e0-96e99dd82758) clicked above the thumb: ![Screenshot 2024-01-12 at 15 39 22](https://github.com/openjdk/jfx/assets/107069028/149449bd-6b7b-49c2-b4cd-dc2e540856fb) 2. this one is more serious. sometimes it gets into state when clicking below the thumb does not move the scroll bar at all, here is the screenshot: ![Screenshot 2024-01-12 at 15 38 44](https://github.com/openjdk/jfx/assets/107069028/672a1c8a-4239-481a-822e-f7e77c119867) It seems to happen when the cell height exceeds the viewport height AND the cell is positioned exactly at the top of the viewport. Can you see it? modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1548: > 1546: > 1547: // will return true if scroll is successful > 1548: private boolean tryScrollOneCell(int targetIndex, boolean downOrRight) { please revert indentation change ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1890149894 PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1451024141 From kcr at openjdk.org Sat Jan 13 00:49:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 13 Jan 2024 00:49:31 GMT Subject: [jfx22u] Integrated: 8323555: Change JavaFX release version to 22.0.1 in jfx22u In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 23:11:12 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 22.0.1 release. This pull request has now been integrated. Changeset: 5817ac0d Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/5817ac0d6b1abc8bac9e2e8c14f1cc0f3cbaf06f Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8323555: Change JavaFX release version to 22.0.1 in jfx22u Reviewed-by: jvos, arapte ------------- PR: https://git.openjdk.org/jfx22u/pull/1 From jvos at openjdk.org Sat Jan 13 08:59:31 2024 From: jvos at openjdk.org (Johan Vos) Date: Sat, 13 Jan 2024 08:59:31 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels In-Reply-To: References: Message-ID: <3ms8rNvSoi2rrvVKEi-f4mqIm4luVt6xFUBiA1OWMuU=.2efd9212-4965-4bde-80a6-56ddf55f1c92@github.com> On Fri, 12 Jan 2024 23:44:14 GMT, Andy Goryachev wrote: > 1. With variable height cells: if I click below the scrollbar thumb, followed by a click above the thumb, I expect the view to go back to the same position exactly, but it does not (see the screenshots). I think I've mentioned this problem before in some other PR. This is one of the major difficulties with the VirtualFlow. The word "expect" is very context-dependent. Different scenario's have different expectations. As long as there is nothing specified in the JavaDoc, I don't think one can expect anything. In this particular case, for example, I can think of a number of reasons why you will not go back to the exact same position. * a cell has been added (outside the viewport). * the contents of a cell (outside the viewport) have changed, leading to different sizes * the estimates for cell dimensions have been updated The location of the scrollbar thumb does not depend on previous actions, but on the current estimated position in the total sheet, which may vary for a number of reasons. We have the implicit restriction that even though the estimated position may change intermediately, we will not reposition the scrollbar thumb unless there is an explicit user action (scrolling or jumping etc). For some time, we have been going back and forth to patch VirtualFlow in order to match particular expectations. By making a change, it is often very likely that the expectations in some scenario are violated -- although no contract is violated, hence no bug is introduced. With the changes in VirtualFlow over the past years, we implicitly specify the expectations by adding regression tests. In the end, it would be good to somehow have an exhaustive specification document. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1890386099 From mhanl at openjdk.org Sat Jan 13 11:07:32 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 Jan 2024 11:07:32 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v5] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:10:19 GMT, Andy Goryachev wrote: > I think the problem is that we are trying to address two issues in one PR - the fix and migration to junit5. It might be better to go back one commit (but keep the most recent changes on a separate branch), convert the fix to use junit4 and submit the fix in this PR. Sure, just FYI that there is nothing like `assertDoesNotThrow` for JUnit4. What I did in the past is to at least write a comment, so we can easily add/convert that later on. See also my PR in the past: https://github.com/openjdk/jfx/pull/557 More specific: https://github.com/openjdk/jfx/pull/557/files#diff-ea6f98c080f3abde83c8de64cd1b026b727bd5998cf6e0e57dde857f0e3e541eR353 cc @EstelonAgarwaen, I would recommend doing it the same way I did above and stash the JUnit 5 migration, as @andy-goryachev-oracle mentioned. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1890418941 From serb at openjdk.org Sat Jan 13 19:39:31 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 13 Jan 2024 19:39:31 GMT Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 23:54:13 GMT, Kevin Rushforth wrote: >> As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. >> >> This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. >> >> This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. >> >> The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). >> >> A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. >> >> Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. >> >> NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. >> >> Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWa... > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove reference to JBS bug ID Marked as reviewed by serb (no project role). ------------- PR Review: https://git.openjdk.org/jfx/pull/1327#pullrequestreview-1820087583 From mstrauss at openjdk.org Sun Jan 14 04:23:31 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 14 Jan 2024 04:23:31 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Fri, 5 Jan 2024 01:32:04 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 81: >> >>> 79: * @deprecated for future removal, use {@link #getStyleClassNames()} instead >>> 80: */ >>> 81: public List getStyleClasses() { >> >> Have you considered keeping this method (instead of adding a new `getStyleClassNames`), and have `FixedCapacitySet` implement `List` to make it work? > > This is possible, although `List#get` would not perform too well when it is implemented for `FixedCapacitySet.OpenAddressed` as the array used as hash table in this class can have gaps (so we'd need to iterate to find the index). > > However, I am very sure this method is not used anywhere (not even in 3rd party code as it requires casting to access), and I wouldn't encourage its use, so I'd be more inclined to remove it completely. If this method is not used anywhere, why do we need to expose `getStyleClassNames()` as new API to replace this one? I'm a bit puzzled by that, especially since you're saying that the API shouldn't be used. Why create something that shouldn't be used? I'd rather just document that you shouldn't expect great performance from this method, and be done with it. Changing API in a performance optimization PR seems out of scope. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1451652964 From mstrauss at openjdk.org Sun Jan 14 04:41:31 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 14 Jan 2024 04:41:31 GMT Subject: RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 17:31:57 GMT, Martin Fox wrote: > When a Stage is closed while processing an OS message the glass peer object is deleted immediately even if it's still executing member functions. As glass unwinds the stack and executes cleanup code it's referencing freed memory. > > There are cases where glass generates JavaFX events back-to-back. For example, when handling the Delete key glass sends a PRESSED and TYPED event in the same routine. If the Stage is closed during the PRESSED event the code that sends the TYPED event is running inside an object that has already been deleted. > > When the Stage is closed glass calls the OS routine ::DestroyWindow on the HWND causing a WM_NCDESTROY message to be sent. Currently the BaseWnd object is deleted when processing this message. This PR defers the destruction until all messages have been processed. This is the same approach used in the Linux code. Looks good! I've left a comment inline. modules/javafx.graphics/src/main/native-glass/win/BaseWnd.h line 88: > 86: HCURSOR m_hCursor; > 87: > 88: LONG m_message_count; Minor: the naming scheme in this class would be `m_messageCount`. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1309#pullrequestreview-1820145372 PR Review Comment: https://git.openjdk.org/jfx/pull/1309#discussion_r1451654273 From jhendrikx at openjdk.org Sun Jan 14 05:03:31 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 14 Jan 2024 05:03:31 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Sun, 14 Jan 2024 04:20:56 GMT, Michael Strau? wrote: >> This is possible, although `List#get` would not perform too well when it is implemented for `FixedCapacitySet.OpenAddressed` as the array used as hash table in this class can have gaps (so we'd need to iterate to find the index). >> >> However, I am very sure this method is not used anywhere (not even in 3rd party code as it requires casting to access), and I wouldn't encourage its use, so I'd be more inclined to remove it completely. > > If this method is not used anywhere, why do we need to expose `getStyleClassNames()` as new API to replace this one? I'm a bit puzzled by that, especially since you're saying that the API shouldn't be used. Why create something that shouldn't be used? > > I'd rather just document that you shouldn't expect great performance from this method, and be done with it. Changing API in a performance optimization PR seems out of scope. You were talking about `List getStyleClasses()`. This is not used by FX, and unlikely to be used anywhere by 3rd parties (see reasoning in other comment). Then there is a 2nd method: `Set getStyleClassSet()`. This is/was called by `SelectorPartitioning`, an internal FX class. However, this method makes use of the `StyleClass` wrapper that is hurting performance. To ensure `SelectorPartitioning` has a fast way to access the styles, I needed a new method: `Set getStyleClassNames`. As it is called from outside the `javafx.css` package, it has to be `public`. **Now perhaps you were eluding to something else:** Would `SelectorPartitioning` mind if the styles were provided as `List` or `Collection`? Looking at that code, I think it doesn't really care. It just uses the set as a key, and calls `containsAll` on it. So perhaps we don't need to deprecate `List getStyleClasses()` then, and we don't need a new API. Instead I'll have `SelectorPartitioning` be happy with a `Collection` so I also don't have to make make a set implement a `List` (which you can't do without violating the contract of either `List` or `Set` as `hashCode` is defined differently). Edit: it would still need to be a `List` as I can't return a `Set` from a method that returns `List`... that means either change that method to return `Collection`, so still need an API change, or store everything as `List`... The only thing that may land us into trouble here (reusing `List getStyleClasses()`) is that there may be an expectation that it still contains duplicates, and retains the original order with which `SimpleSelector` was created. This is already not the case (as it is based on the old `BitSet` that was created) -- it is deduplicated, and its order is changed (whether that was the intention is unclear, but that's what it does right now). Then again, the method is currently not in use... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1451656563 From jhendrikx at openjdk.org Sun Jan 14 14:01:28 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 14 Jan 2024 14:01:28 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v2] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <4aDGVsXOXLNLFXznCOkCoGzh5dUA3ku4kT9HkD86UU8=.927f6ae9-2720-483a-98d2-375e13ff7eae@github.com> On Sun, 14 Jan 2024 04:58:35 GMT, John Hendrikx wrote: >> If this method is not used anywhere, why do we need to expose `getStyleClassNames()` as new API to replace this one? I'm a bit puzzled by that, especially since you're saying that the API shouldn't be used. Why create something that shouldn't be used? >> >> I'd rather just document that you shouldn't expect great performance from this method, and be done with it. Changing API in a performance optimization PR seems out of scope. > > You were talking about `List getStyleClasses()`. This is not used by FX, and unlikely to be used anywhere by 3rd parties (see reasoning in other comment). > > Then there is a 2nd method: `Set getStyleClassSet()`. This is/was called by `SelectorPartitioning`, an internal FX class. However, this method makes use of the `StyleClass` wrapper that is hurting performance. > > To ensure `SelectorPartitioning` has a fast way to access the styles, I needed a new method: `Set getStyleClassNames`. As it is called from outside the `javafx.css` package, it has to be `public`. > > **Now perhaps you were eluding to something else:** > > Would `SelectorPartitioning` mind if the styles were provided as `List` or `Collection`? Looking at that code, I think it doesn't really care. It just uses the set as a key, and calls `containsAll` on it. So perhaps we don't need to deprecate `List getStyleClasses()` then, and we don't need a new API. Instead I'll have `SelectorPartitioning` be happy with a `Collection` so I also don't have to make make a set implement a `List` (which you can't do without violating the contract of either `List` or `Set` as `hashCode` is defined differently). > > Edit: it would still need to be a `List` as I can't return a `Set` from a method that returns `List`... that means either change that method to return `Collection`, so still need an API change, or store everything as `List`... > > The only thing that may land us into trouble here (reusing `List getStyleClasses()`) is that there may be an expectation that it still contains duplicates, and retains the original order with which `SimpleSelector` was created. This is already not the case (as it is based on the old `BitSet` that was created) -- it is deduplicated, and its order is changed (whether that was the intention is unclear, but that's what it does right now). Then again, the method is currently not in use... I took another look, and I don't see a better option here than introducing a new method. Things I looked at: 1. Reuse `List getStyles()` by having the sets implement `List` as well as `Set` - this is impossible as the two specify different `equals` and `hashCode` 2. Reuse `List getStyles()` by having the sets implement only `List` but still eliminate duplicates - this would violate `List` contract (can't eliminate duplicates) - still need fast `containsAll` performance in the rare case we may have a large number of styles in the set... 3. Moving `SimpleSelector` and `CompoundSelector` out of `javafx.css`: - arguably, they never should have been there (we ran into this before) but moving them is still an API break (albeit a minor one as they're only accessible by casting) -- we could start this process though, so any public methods we add now will be of no consequence once moved 4. Moving a ton of internal CSS classes to `javafx.css` (but keep most package private) and introduce a package private `getStyleClassNames`: - this runs into an issue that **something** eventually needs to be `public` to make use of the CSS engine, and that would be new API then Of the above options **3** is by far the best. I've looked further into how this can be achieved, and it requires the following: **Minor API break** - Move `SimpleSelector` and `CompoundSelector` out of `javafx.css` and into a non-public package -- this is a minor API break as these classes were accessible before if you cast `Selector` to either of these. You could not construct them however. This options was discussed before when it was determined these classes should probably never have been made public. They can't be easily moved though because they use package private methods of the abstract base class `Selector`. However... nowadays we can **seal** classes, see below: **Fully compatible changes** - Make `Selector` `sealed`, only allowing `CompoundSelector` and `SimpleSelector` -- this is compatible because `Selector` does not allow arbitrary subclasses (it has a package private constructor) - Change `Selector`s constructor to be `protected` and also one of its static methods needs to be `protected`. This does not create new public API as `protected` methods are only accessible by subclasses, and it is now sealed. - Implement `createMatch` directly in `Selector` (it is `abstract` now) and make it `final` for good measure. All the information required is already available via `public` accessible methods of its sealed sub types. This avoids having to access package private fields in `Match` by `CompoundSelector` which will no longer be in the same package. This is fully compatible. - Change some internal classes imports to the new location of `CompoundSelector` and `SimpleSelector`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1451738916 From jhendrikx at openjdk.org Sun Jan 14 14:32:49 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 14 Jan 2024 14:32:49 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix wrong exception name in javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/6c3271b0..5201cd2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From jhendrikx at openjdk.org Sun Jan 14 15:14:42 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 14 Jan 2024 15:14:42 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages Message-ID: Moves `SimpleSelector` and `CompoundSelector` to internal packages. This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` - No need anymore for the `SimpleSelectorShim` ------------- Commit messages: - Move SimpleSelector and CompoundSelector to private classes Changes: https://git.openjdk.org/jfx/pull/1333/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323706 Stats: 169 lines in 10 files changed: 46 ins; 86 del; 37 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From jhendrikx at openjdk.org Sun Jan 14 15:17:32 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 14 Jan 2024 15:17:32 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Sun, 14 Jan 2024 04:20:56 GMT, Michael Strau? wrote: >> This is possible, although `List#get` would not perform too well when it is implemented for `FixedCapacitySet.OpenAddressed` as the array used as hash table in this class can have gaps (so we'd need to iterate to find the index). >> >> However, I am very sure this method is not used anywhere (not even in 3rd party code as it requires casting to access), and I wouldn't encourage its use, so I'd be more inclined to remove it completely. > > If this method is not used anywhere, why do we need to expose `getStyleClassNames()` as new API to replace this one? I'm a bit puzzled by that, especially since you're saying that the API shouldn't be used. Why create something that shouldn't be used? > > I'd rather just document that you shouldn't expect great performance from this method, and be done with it. Changing API in a performance optimization PR seems out of scope. @mstr2 I've created #1333 to show how it would look when we move `SimpleSelector` and `CompoundSelector` to internal packages. I think that should alleviate most concerns, and we can either integrate this first with a new public method, which will later be internal anyway, or integrate the other change first. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1451751294 From duke at openjdk.org Sun Jan 14 16:06:42 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sun, 14 Jan 2024 16:06:42 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: > This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. Carl D?bbelin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8323543: change tests to JUnit4 for compatibility ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1329/files - new: https://git.openjdk.org/jfx/pull/1329/files/6bd6e18c..20cc6320 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1329&range=04-05 Stats: 691 lines in 2 files changed: 12 ins; 290 del; 389 mod Patch: https://git.openjdk.org/jfx/pull/1329.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1329/head:pull/1329 PR: https://git.openjdk.org/jfx/pull/1329 From fkirmaier at openjdk.org Mon Jan 15 08:31:59 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Mon, 15 Jan 2024 08:31:59 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511 reverted accidental indentation chang ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/cbcaefec..29d610fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From fkirmaier at openjdk.org Mon Jan 15 08:32:00 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Mon, 15 Jan 2024 08:32:00 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 23:24:19 GMT, Andy Goryachev wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511 >> reverted accidental indentation chang > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1548: > >> 1546: >> 1547: // will return true if scroll is successful >> 1548: private boolean tryScrollOneCell(int targetIndex, boolean downOrRight) { > > please revert indentation change removed it! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1452054742 From kcr at openjdk.org Mon Jan 15 15:36:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jan 2024 15:36:35 GMT Subject: Integrated: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 14:54:47 GMT, Kevin Rushforth wrote: > As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel. > > This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread. > > This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls. > > The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703). > > A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView. > > Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`. > > NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode. > > Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWait` allows them to run when in... This pull request has now been integrated. Changeset: 90cbc663 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/90cbc66305d0a1380cf3a8cd99ad40db240e554c Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Reviewed-by: prr, psadhukhan, serb ------------- PR: https://git.openjdk.org/jfx/pull/1327 From kcr at openjdk.org Mon Jan 15 16:17:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jan 2024 16:17:40 GMT Subject: [jfx22] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Message-ID: <4bEdb9dpO8j0FwaKnCH11-ldp7nEQCdNFKrXRc24p4g=.286b23fb-c7b6-4048-bcdf-4207c1ef9245@github.com> Clean backport of a safe fix for this critical deadlock bug to the jfx22 stabilization branch during RDP1. ------------- Commit messages: - Backport 90cbc66305d0a1380cf3a8cd99ad40db240e554c Changes: https://git.openjdk.org/jfx/pull/1334/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1334&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8221261 Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1334.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1334/head:pull/1334 PR: https://git.openjdk.org/jfx/pull/1334 From kcr at openjdk.org Mon Jan 15 16:17:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jan 2024 16:17:41 GMT Subject: [jfx22] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: <4bEdb9dpO8j0FwaKnCH11-ldp7nEQCdNFKrXRc24p4g=.286b23fb-c7b6-4048-bcdf-4207c1ef9245@github.com> References: <4bEdb9dpO8j0FwaKnCH11-ldp7nEQCdNFKrXRc24p4g=.286b23fb-c7b6-4048-bcdf-4207c1ef9245@github.com> Message-ID: On Mon, 15 Jan 2024 16:11:08 GMT, Kevin Rushforth wrote: > Clean backport of a safe fix for this critical deadlock bug to the jfx22 stabilization branch during RDP1. Reviewer: @prrace or @prsadhuk ------------- PR Comment: https://git.openjdk.org/jfx/pull/1334#issuecomment-1892451896 From kcr at openjdk.org Mon Jan 15 16:47:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jan 2024 16:47:35 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 14:54:36 GMT, John Hendrikx wrote: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` I'll take a closer look tomorrow, but this will very likely need to be done in two steps. Step 1 would be to terminally deprecate the existing public classes in an exported package. Step 2 would then be to remove them from the public API by moving them to a non-exported package. Given that we are still in RDP1 for JavaFX 22, we could do the first step (terminal deprecation) in 22 paving the way for removal in 23, so the net result would be the same, but it would give a clear warning to anyone using JavaFX 22 that this removal is pending. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1892500082 From mstrauss at openjdk.org Mon Jan 15 20:51:31 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 15 Jan 2024 20:51:31 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Sun, 14 Jan 2024 15:14:36 GMT, John Hendrikx wrote: >> If this method is not used anywhere, why do we need to expose `getStyleClassNames()` as new API to replace this one? I'm a bit puzzled by that, especially since you're saying that the API shouldn't be used. Why create something that shouldn't be used? >> >> I'd rather just document that you shouldn't expect great performance from this method, and be done with it. Changing API in a performance optimization PR seems out of scope. > > @mstr2 I've created #1333 to show how it would look when we move `SimpleSelector` and `CompoundSelector` to internal packages. I think that should alleviate most concerns, and we can either integrate this first with a new public method, which will later be internal anyway, or integrate the other change first. Thanks for the detailed explanation. I agree that moving `SimpleSelector` and `CompoundSelector` to an internal package would be the best choice, and would also make the question of new API a non-issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1452732188 From mstrauss at openjdk.org Mon Jan 15 21:28:30 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 15 Jan 2024 21:28:30 GMT Subject: RFR: 8260013: Snapshot does not work for nodes in a subscene In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 14:11:14 GMT, Lukasz Kostyra wrote: > Originally this issue showed the problem of Node being incorrectly rendered (clipped) when snapshotting, compared to a snapshot of the whole Scene. Later on there was another problem added - lights not being taken into account if they are added to a SubScene. > > As it later turned out, the original problem from this bug report is a problem with ParallelCamera incorrectly estimating near/far clipping planes, which just happened to reveal itself while snapshotting a Node. During testing I found out you can make the Node clip regardless of snapshot mechanism. Clipping issue was moved to a separate bug report and this PR only fixes the inconsistency in lights being gathered for a snapshot. > > `Scene.doSnapshot()` was expanded to also check if SubScene provided to it is non-null and to fetch lights assigned to it. Scenario was tested with added SnapshotLightsTest. > > Rest of the tests were checked and don't produce any noticeable regressions. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1364: > 1362: // Grab the lights from the scene and/or subscene > 1363: context.lights = null; > 1364: int totalLightCount = 0; Here's a suggestion: you might be able to replace all of the new code, including the `accumulateLightsForSnapshot` method, with the following shorter code: Stream lights = Stream.concat( Optional.ofNullable(scene).stream().flatMap(s -> s.lights.stream()).map(LightBase::getPeer), Optional.ofNullable(subScene).stream().flatMap(s -> s.getLights().stream()).map(LightBase::getPeer)); context.lights = lights.toArray(NGLightBase[]::new); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1332#discussion_r1452752285 From psadhukhan at openjdk.org Tue Jan 16 06:25:33 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 16 Jan 2024 06:25:33 GMT Subject: [jfx22] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: <4bEdb9dpO8j0FwaKnCH11-ldp7nEQCdNFKrXRc24p4g=.286b23fb-c7b6-4048-bcdf-4207c1ef9245@github.com> References: <4bEdb9dpO8j0FwaKnCH11-ldp7nEQCdNFKrXRc24p4g=.286b23fb-c7b6-4048-bcdf-4207c1ef9245@github.com> Message-ID: On Mon, 15 Jan 2024 16:11:08 GMT, Kevin Rushforth wrote: > Clean backport of a safe fix for this critical deadlock bug to the jfx22 stabilization branch during RDP1. Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1334#pullrequestreview-1822594206 From mhanl at openjdk.org Tue Jan 16 09:51:35 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 16 Jan 2024 09:51:35 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: <9-9qTatW5LE3M24BWW8pFit3skSudHcZjLBi1T7w-3g=.66ad1a9f-babf-4a1b-b80e-91e57551b599@github.com> On Sun, 14 Jan 2024 16:06:42 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8323543: change tests to JUnit4 for compatibility Looks good. Can confirm that this fixes the NPE. I can file a ticket after this one is merged to migrate the tests to JUnit5. I think this makes sense here. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1329#pullrequestreview-1822928945 From fkirmaier at openjdk.org Tue Jan 16 10:18:37 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 16 Jan 2024 10:18:37 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v8] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 14:04:36 GMT, Johan Vos wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert some of the conditional bindings. >> Clear menu construction when an menuitem that is a menu needs to be removed >> Add a test for the latter > > A few things about the latest commit: > > 1. The usage of the `active` property caused regression: the memoryLeak test that was introduced in the fix for JDK-8318841 now failed. A number of listeners were hard referenced from the `active` property. > The complexity is that there are different entry points by which a listener should be removed. What we try to do in this PR, is making sure we remove listeners after a defocus/focus operation that would otherwise stay referenced. A focus operation will result in GlassSystemMenu.setMenus() being called. > I reverted some of the dependencies on the `active` property, and kept those that were directly created as a consequence of the setMenus call. > > 2. I added a test that demonstrates the issue when not removing menu's completely inside the listener, as reported by @jperedadnr and this issue is fixed as well now. > > 3. All tests now pass, but I noticed that in some cases, the systemtests do not correctly work with the application lifecycle management (see https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044516.html). For now, I consider this anomaly to be independent from JDK-8319779 @johanvos **ticket** We found a bug, which is also fixed by this PR. This is the ticket: https://bugs.openjdk.org/browse/JDK-8323787 It's an IndexOutOfBounds exception, related to the visible flag/listeners. **unittest** We wrote a unit test, which goes green with this PR. Can you do us a favor, and add the test from the ticket to your PR? Then we can be sure, that this issue will be solved and never reappears. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1893444554 From kpk at openjdk.org Tue Jan 16 10:39:50 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 16 Jan 2024 10:39:50 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: <8DUTMaIYzZeOZ2YIgySKrYoJDJDmndlji-eKPxX3U9s=.f4838d60-32e3-4ab6-be96-d90d978eed1f@github.com> References: <8DUTMaIYzZeOZ2YIgySKrYoJDJDmndlji-eKPxX3U9s=.f4838d60-32e3-4ab6-be96-d90d978eed1f@github.com> Message-ID: On Fri, 12 Jan 2024 16:14:20 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Code review changes > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 480: > >> 478: } >> 479: } else { >> 480: // To calculate hit info of Text embedded in TextFlow > > the comments on lines 480 and 451 are a bit confusing: both refer to Text. could you please clarify? The first code branch is used to calculate hit info of Text node which are not embedded in TextFlow and hit info requested on TextFlow, where as the second code branch is used to calculate hit info of Text node embedded in TextFlow. Updated the comments. > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 524: > >> 522: break; >> 523: } >> 524: // For only English Text embedded in TextFlow in RTL orientation > > this comment seems misleading (by English you mean LTR, right?) > would it be possible to re-phrase, explaining why? > does it mean the RTL text has been handled by the previous code block and now we are dealing with LTR? Yes, it handles the LTR text present in RTL mode. Rephrased the comment. > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 562: > >> 560: charIndex += textWidthPrevLine; >> 561: charIndex += relIndex; >> 562: if (run.getLevel() % 2 != 0) { > > I wish there was an explanation of the meaning of `level` > And since there are several places where it checks for it being odd, I wish there was a method in TextRun with a descriptive name rather than this computation (and bit logic might be faster): > > > public boolean isLevelOdd() { // or whatever the meaning is > return (level & 0x01) != 0; > } Added comment and used bit logic in the condition. Do you think we should create a method in TextRun? I believe it is out of scope of this PR as it will be used in other functions as well. > modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1040: > >> 1038: >> 1039: private int findRunIndex(double x, double y, GlyphList[] runs) { >> 1040: int runIndex = 0; > > some general comment for this method: > 1. there are many places where runs[runIndex] is repeated within the same code block, I wonder if it would make sense to create a local variable. It might be tricky because the runIndex changes mid-flight. > 2. perhaps `runIndex` could be shortened to `ix` to make the lines shorter? Refactored the function. Changed `runIndex` to `ix`. I could remove some repetition of `runs[runIndex]`. Had to keep some instances since previous or next runs are used in some cases. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1453234155 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1453235252 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1453237200 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1453239916 From kpk at openjdk.org Tue Jan 16 10:39:51 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 16 Jan 2024 10:39:51 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v3] In-Reply-To: <1lnciNH0HixCSCdLFHlb2JJnniid_WopcKFGE7hzLMk=.c1f02a45-a3ed-4491-b8b3-cfe4e6653063@github.com> References: <1lnciNH0HixCSCdLFHlb2JJnniid_WopcKFGE7hzLMk=.c1f02a45-a3ed-4491-b8b3-cfe4e6653063@github.com> Message-ID: On Fri, 12 Jan 2024 15:50:24 GMT, Andy Goryachev wrote: >> Are you suggesting to pass boolean as parameter in addition to textRunStart and curRunStart? If that is the case then yes I think it would be better. > > that's right, something like this: > > > public Hit getHitInfo(float x, float y, String text, int textRunStart, int curRunStart, boolean forTextFlow); Added boolean parameter ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1453231450 From kpk at openjdk.org Tue Jan 16 10:39:47 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 16 Jan 2024 10:39:47 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v3] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Code review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/b23e4910..cd270e16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=01-02 Stats: 119 lines in 6 files changed: 33 ins; 16 del; 70 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From fkirmaier at openjdk.org Tue Jan 16 11:09:29 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 16 Jan 2024 11:09:29 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 12:57:01 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes I tried out a bit, by removing the clipping area in my test program. I added the changed program to the ticket. Didn't notice anything wrong. There are probably many ways to test for regressions. Can't guarantee that there are no other cases that go wrong - but if something doesn't work, then it happens more rarely than this one. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-1893526950 From kpk at openjdk.org Tue Jan 16 12:53:34 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 16 Jan 2024 12:53:34 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: <1C2tusDOHT88HmzpkwPyENHtAUr7TR3kUla2SITVSPU=.f2b16e15-09be-4edb-8ce6-be5aa37cdd2a@github.com> References: <1C2tusDOHT88HmzpkwPyENHtAUr7TR3kUla2SITVSPU=.f2b16e15-09be-4edb-8ce6-be5aa37cdd2a@github.com> Message-ID: On Fri, 12 Jan 2024 16:58:55 GMT, Andy Goryachev wrote: > There seems to be a weird problem with Text (tested on macOS) in the Monkey Tester. 'Writing Systems' is a multi-line text with a tricky font (which does not get rendered correctly in LTR mode for some reason, but does in RTL). So if you try to hover over Aramaic line, the hit test info does not get updated: > I see this problem when I tested in a separate app as well. I will check on this issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1893679318 From kcr at openjdk.org Tue Jan 16 13:54:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 13:54:00 GMT Subject: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS [v2] In-Reply-To: References: Message-ID: <8k18knTmdYfllJkc30d46q_VT1moeefIASE1_a_TGuA=.ef0b6f1b-1638-449f-a1e5-966235878398@github.com> > As noted in the JBS bug, this is a follow-on to [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered while testing the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the IME code when using WebView in a JFXPanel on macOS). > > I have tested this in connection with with the proposed fix for JDK-8221261, although it is a valid fix regardless. > > This expands the fix done in [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the WebKit methods on the right thread. Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8322703-webkit-ime-crash - 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1321/files - new: https://git.openjdk.org/jfx/pull/1321/files/bd5a05fa..c5ce4a7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1321&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1321&range=00-01 Stats: 55 lines in 8 files changed: 44 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1321.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1321/head:pull/1321 PR: https://git.openjdk.org/jfx/pull/1321 From hmeda at openjdk.org Tue Jan 16 14:18:37 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 16 Jan 2024 14:18:37 GMT Subject: Integrated: 8318614: Update WebKit to 617.1 In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 17:53:46 GMT, Hima Bindu Meda wrote: > This PR updates webkit to v617.1. Verified build on Mac,Windows and linux. > Sanity testing looks fine. No issues observed in HelloWebView as well This pull request has now been integrated. Changeset: ba79e081 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/ba79e081547b7f15697bfaaac42ec2de1971935a Stats: 289254 lines in 6439 files changed: 170206 ins; 83308 del; 35740 mod 8318614: Update WebKit to 617.1 Co-authored-by: Jay Bhaskar Reviewed-by: sykora, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1328 From kcr at openjdk.org Tue Jan 16 14:20:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 14:20:31 GMT Subject: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS [v2] In-Reply-To: <8k18knTmdYfllJkc30d46q_VT1moeefIASE1_a_TGuA=.ef0b6f1b-1638-449f-a1e5-966235878398@github.com> References: <8k18knTmdYfllJkc30d46q_VT1moeefIASE1_a_TGuA=.ef0b6f1b-1638-449f-a1e5-966235878398@github.com> Message-ID: On Tue, 16 Jan 2024 13:54:00 GMT, Kevin Rushforth wrote: >> As noted in the JBS bug, this is a follow-on to [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered while testing the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the IME code when using WebView in a JFXPanel on macOS). >> >> I have tested this in connection with with the proposed fix for JDK-8221261, although it is a valid fix regardless. >> >> This expands the fix done in [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the WebKit methods on the right thread. Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8322703-webkit-ime-crash > - 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Now that [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) is integrated you can just fetch this branch and no longer worry about the deadlock. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1321#issuecomment-1893836824 From angorya at openjdk.org Tue Jan 16 15:45:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jan 2024 15:45:34 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: <8DUTMaIYzZeOZ2YIgySKrYoJDJDmndlji-eKPxX3U9s=.f4838d60-32e3-4ab6-be96-d90d978eed1f@github.com> Message-ID: On Tue, 16 Jan 2024 10:34:42 GMT, Karthik P K wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 562: >> >>> 560: charIndex += textWidthPrevLine; >>> 561: charIndex += relIndex; >>> 562: if (run.getLevel() % 2 != 0) { >> >> I wish there was an explanation of the meaning of `level` >> And since there are several places where it checks for it being odd, I wish there was a method in TextRun with a descriptive name rather than this computation (and bit logic might be faster): >> >> >> public boolean isLevelOdd() { // or whatever the meaning is >> return (level & 0x01) != 0; >> } > > Added comment and used bit logic in the condition. > Do you think we should create a method in TextRun? I believe it is out of scope of this PR as it will be used in other functions as well. Yes, creating such a new method in TextRun might be out of scope for this, unless we touch all the places where the bit logic is used. Up to you, it's just a suggestion. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1453612702 From kcr at openjdk.org Tue Jan 16 15:50:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 15:50:35 GMT Subject: [jfx22] RFR: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a Message-ID: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> Merge the just-release CPU content for the January 2024 CPU release into the `jfx22` branch for JavaFX 22. ------------- Commit messages: - Merge branch 'jfx22-cpu-2401' into merge-jfx22-cpu-2401 - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8313105: Improved media framing - ... and 2 more: https://git.openjdk.org/jfx/compare/5b1fce55...6fd70d48 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/1336/files Stats: 769 lines in 17 files changed: 406 ins; 157 del; 206 mod Patch: https://git.openjdk.org/jfx/pull/1336.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1336/head:pull/1336 PR: https://git.openjdk.org/jfx/pull/1336 From kcr at openjdk.org Tue Jan 16 15:50:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 15:50:36 GMT Subject: [jfx22] RFR: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a In-Reply-To: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> References: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> Message-ID: On Tue, 16 Jan 2024 15:45:27 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `jfx22` branch for JavaFX 22. Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1336#issuecomment-1894011010 From kcr at openjdk.org Tue Jan 16 15:50:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 15:50:38 GMT Subject: RFR: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a Message-ID: Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 23. ------------- Commit messages: - Merge branch 'jfx23-cpu-2401' into merge-jfx23-cpu-2401 - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8313105: Improved media framing - ... and 2 more: https://git.openjdk.org/jfx/compare/caba6788...43e29d4f The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/1335/files Stats: 769 lines in 17 files changed: 406 ins; 157 del; 206 mod Patch: https://git.openjdk.org/jfx/pull/1335.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1335/head:pull/1335 PR: https://git.openjdk.org/jfx/pull/1335 From kcr at openjdk.org Tue Jan 16 15:50:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 15:50:39 GMT Subject: RFR: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 15:44:19 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 23. Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1335#issuecomment-1894009626 From kcr at openjdk.org Tue Jan 16 15:51:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 15:51:35 GMT Subject: [jfx21u] RFR: Merge 07674d9f075a1407be3b8c419c855e937303f92f Message-ID: Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 21.0.2. ------------- Commit messages: - Merge branch 'jfx21.0.2' into merge-jfx21.0.2 - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8313105: Improved media framing - 8313048: Better Glyph handling - ... and 6 more: https://git.openjdk.org/jfx21u/compare/a993b200...8169edea The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx21u/pull/40/files Stats: 769 lines in 17 files changed: 406 ins; 157 del; 206 mod Patch: https://git.openjdk.org/jfx21u/pull/40.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/40/head:pull/40 PR: https://git.openjdk.org/jfx21u/pull/40 From kcr at openjdk.org Tue Jan 16 15:51:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 15:51:35 GMT Subject: [jfx21u] RFR: Merge 07674d9f075a1407be3b8c419c855e937303f92f In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 15:45:54 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 21.0.2. Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/40#issuecomment-1894011870 From angorya at openjdk.org Tue Jan 16 16:03:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jan 2024 16:03:34 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: <6fsPjrXlP7M_ZKc8ZYM3QcLHaDx_LALjFxRdg_LOj_A=.e93bc897-fa08-40ed-ba9a-5dd04760dd45@github.com> On Sun, 14 Jan 2024 16:06:42 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8323543: change tests to JUnit4 for compatibility looks good now, thanks! should the fix be backported to jfx22? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1329#pullrequestreview-1823917284 From jvos at openjdk.org Tue Jan 16 16:52:30 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Jan 2024 16:52:30 GMT Subject: RFR: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 15:44:19 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 23. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1335#pullrequestreview-1824157139 From jvos at openjdk.org Tue Jan 16 16:53:34 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Jan 2024 16:53:34 GMT Subject: [jfx21u] RFR: Merge 07674d9f075a1407be3b8c419c855e937303f92f In-Reply-To: References: Message-ID: <4B6aDaOvUZ7NTnIAiPkdSoQbh2ENsDQKE94m727mTJI=.a34adc26-5e28-4063-be2d-705411c05854@github.com> On Tue, 16 Jan 2024 15:45:54 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 21.0.2. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/40#pullrequestreview-1824159074 From jvos at openjdk.org Tue Jan 16 17:01:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Jan 2024 17:01:33 GMT Subject: [jfx22] RFR: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a In-Reply-To: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> References: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> Message-ID: On Tue, 16 Jan 2024 15:45:27 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `jfx22` branch for JavaFX 22. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1336#pullrequestreview-1824196122 From kcr at openjdk.org Tue Jan 16 17:29:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 17:29:00 GMT Subject: [jfx21u] RFR: 8323221: Create release notes for JavaFX 21.0.2 Message-ID: Release notes for JavaFX 21.0.2. Notes to reviewers: I used the following filter to pick the issues: https://bugs.openjdk.org/issues/?filter=45268 The original filter, with the backport IDs, is here: https://bugs.openjdk.org/issues/?filter=45267 As usual, I excluded test bugs, cleanup bugs, etc. NOTE: Once the CPU release ships on 2023-01-16 (tomorrow), I will add any security bugs and make this PR `rfr`. ------------- Commit messages: - add CPU content - 8323221: Create release notes for JavaFX 21.0.2 Changes: https://git.openjdk.org/jfx21u/pull/39/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=39&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323221 Stats: 34 lines in 1 file changed: 34 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/39.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/39/head:pull/39 PR: https://git.openjdk.org/jfx21u/pull/39 From kcr at openjdk.org Tue Jan 16 17:29:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 17:29:00 GMT Subject: [jfx21u] RFR: 8323221: Create release notes for JavaFX 21.0.2 In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 15:09:45 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45268 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45267 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2023-01-16 (tomorrow), I will add any security bugs and make this PR `rfr`. Reviewers: @johanvos @abhinayagarwal This is now ready for review. @johanvos in addition to review I need maintainer approval. ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/39#issuecomment-1892351818 PR Comment: https://git.openjdk.org/jfx21u/pull/39#issuecomment-1894165327 From duke at openjdk.org Tue Jan 16 17:29:00 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Tue, 16 Jan 2024 17:29:00 GMT Subject: [jfx21u] RFR: 8323221: Create release notes for JavaFX 21.0.2 In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 15:09:45 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45268 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45267 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2023-01-16 (tomorrow), I will add any security bugs and make this PR `rfr`. Looks good. I will review this again once the PR has been labelled as `rfr`. ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/39#issuecomment-1893485911 From mfox at openjdk.org Tue Jan 16 18:11:52 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 16 Jan 2024 18:11:52 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread Message-ID: On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. ------------- Commit messages: - InputMethodRequests in a JFXPanel are now moved to the JFX thread Changes: https://git.openjdk.org/jfx/pull/1337/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322784 Stats: 45 lines in 2 files changed: 29 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1337.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1337/head:pull/1337 PR: https://git.openjdk.org/jfx/pull/1337 From kcr at openjdk.org Tue Jan 16 18:13:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 18:13:56 GMT Subject: [jfx22] RFR: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a [v2] In-Reply-To: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> References: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> Message-ID: > Merge the just-release CPU content for the January 2024 CPU release into the `jfx22` branch for JavaFX 22. Kevin Rushforth 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 one additional commit since the last revision: Merge branch 'jfx22-cpu-2401' into merge-jfx22-cpu-2401 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1336/files - new: https://git.openjdk.org/jfx/pull/1336/files/6fd70d48..6fd70d48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1336&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1336&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1336.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1336/head:pull/1336 PR: https://git.openjdk.org/jfx/pull/1336 From kcr at openjdk.org Tue Jan 16 18:13:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 18:13:56 GMT Subject: [jfx22] Integrated: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a In-Reply-To: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> References: <5L-6MqeRJmnCysJwNYGNppbnaugvzqJN9WKN7b04f3I=.d02d729e-19b9-4f8f-9974-6b881821d9e0@github.com> Message-ID: <1Lngw8MbSNA71NVIl1BanM3wO0RHPD9rx6Wkvul9Fsc=.7a9901ca-bfa9-4e7e-b696-0d9e9f785e78@github.com> On Tue, 16 Jan 2024 15:45:27 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `jfx22` branch for JavaFX 22. This pull request has now been integrated. Changeset: c0f8fe66 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/c0f8fe66e14841d6d08c986302abe0e2ad2c144e Stats: 769 lines in 17 files changed: 406 ins; 157 del; 206 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/1336 From kcr at openjdk.org Tue Jan 16 18:15:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 18:15:31 GMT Subject: Integrated: Merge ce3eacef077dbb2cb4db96d8320e130d35babe5a In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 15:44:19 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 23. This pull request has now been integrated. Changeset: e2bc52da Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e2bc52da0c0d8a701cab06af4a7ae9b05266966e Stats: 769 lines in 17 files changed: 406 ins; 157 del; 206 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/1335 From kcr at openjdk.org Tue Jan 16 18:21:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 18:21:46 GMT Subject: [jfx21u] RFR: Merge 07674d9f075a1407be3b8c419c855e937303f92f [v2] In-Reply-To: References: Message-ID: > Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 21.0.2. Kevin Rushforth 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 one additional commit since the last revision: Merge branch 'jfx21.0.2' into merge-jfx21.0.2 ------------- Changes: - all: https://git.openjdk.org/jfx21u/pull/40/files - new: https://git.openjdk.org/jfx21u/pull/40/files/8169edea..8169edea Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx21u&pr=40&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx21u&pr=40&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/40.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/40/head:pull/40 PR: https://git.openjdk.org/jfx21u/pull/40 From kcr at openjdk.org Tue Jan 16 18:21:48 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 18:21:48 GMT Subject: [jfx21u] Integrated: Merge 07674d9f075a1407be3b8c419c855e937303f92f In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 15:45:54 GMT, Kevin Rushforth wrote: > Merge the just-release CPU content for the January 2024 CPU release into the `master` branch for JavaFX 21.0.2. This pull request has now been integrated. Changeset: e6bad3fd Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/e6bad3fd8dee893565dbe2f6c6d2d57285e149ee Stats: 769 lines in 17 files changed: 406 ins; 157 del; 206 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx21u/pull/40 From kcr at openjdk.org Tue Jan 16 19:48:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 19:48:12 GMT Subject: [jfx22] Integrated: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: <4bEdb9dpO8j0FwaKnCH11-ldp7nEQCdNFKrXRc24p4g=.286b23fb-c7b6-4048-bcdf-4207c1ef9245@github.com> References: <4bEdb9dpO8j0FwaKnCH11-ldp7nEQCdNFKrXRc24p4g=.286b23fb-c7b6-4048-bcdf-4207c1ef9245@github.com> Message-ID: On Mon, 15 Jan 2024 16:11:08 GMT, Kevin Rushforth wrote: > Clean backport of a safe fix for this critical deadlock bug to the jfx22 stabilization branch during RDP1. This pull request has now been integrated. Changeset: 0a566990 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0a566990a8bd9d0a7329b1d8fed4326128c48cd3 Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Reviewed-by: psadhukhan Backport-of: 90cbc66305d0a1380cf3a8cd99ad40db240e554c ------------- PR: https://git.openjdk.org/jfx/pull/1334 From kcr at openjdk.org Tue Jan 16 19:50:19 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 19:50:19 GMT Subject: [jfx22u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 00:00:43 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 jfx21u. The second is a simple substitution changing 21 to 22 in the two files. This pull request has now been integrated. Changeset: 632792d4 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/632792d4e7a6399c156df99b1cf69faba476a8c6 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: d689dc12751660c14e558c37e82f8dc71d9a8037 ------------- PR: https://git.openjdk.org/jfx22u/pull/2 From jvos at openjdk.org Tue Jan 16 20:35:37 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Jan 2024 20:35:37 GMT Subject: [jfx17u] RFR: 8323829: Change javaFX release version to 17.0.11 in jfx17u Message-ID: Increase the release version to JavaFX 17.0.11 ------------- Commit messages: - Increase version to 17.0.11 Changes: https://git.openjdk.org/jfx17u/pull/176/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=176&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323829 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/176.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/176/head:pull/176 PR: https://git.openjdk.org/jfx17u/pull/176 From jvos at openjdk.org Tue Jan 16 20:36:47 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Jan 2024 20:36:47 GMT Subject: [jfx21u] RFR: 8323830: Change JavaFX release version to 21.0.3 in jfx21u Message-ID: <68DjyV9aWvLzh2bG_96omW2ovaxxmfvSugdN3AfQLso=.f92c7d64-caaf-482a-8180-3968f177369e@github.com> Start work on 21.0.3 ------------- Commit messages: - Increase JavaFX version to 21.0.3 before any other commits go in. Changes: https://git.openjdk.org/jfx21u/pull/41/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=41&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323830 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/41.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/41/head:pull/41 PR: https://git.openjdk.org/jfx21u/pull/41 From kcr at openjdk.org Tue Jan 16 20:55:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 20:55:04 GMT Subject: [jfx21u] RFR: 8323830: Change JavaFX release version to 21.0.3 in jfx21u In-Reply-To: <68DjyV9aWvLzh2bG_96omW2ovaxxmfvSugdN3AfQLso=.f92c7d64-caaf-482a-8180-3968f177369e@github.com> References: <68DjyV9aWvLzh2bG_96omW2ovaxxmfvSugdN3AfQLso=.f92c7d64-caaf-482a-8180-3968f177369e@github.com> Message-ID: On Tue, 16 Jan 2024 20:30:01 GMT, Johan Vos wrote: > Start work on 21.0.3 Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/41#pullrequestreview-1824990450 From kcr at openjdk.org Tue Jan 16 22:35:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 22:35:02 GMT Subject: [jfx22u] RFR: Merge jfx:jfx22 Message-ID: <43rrdnWWzDBfn133wvn0r4G3ebQuLi-vuucmo6r6r34=.a8726dc9-e46b-4edc-b511-32dd591e83c0@github.com> Merge changes from `jfx:jfx22` --> `jfx22u`. ------------- Commit messages: - Merge remote-tracking branch 'jfx/jfx22' into merge-jfx22-2024-01-16 - 8221261: Deadlock on macOS in JFXPanel app when handling IME calls - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - ... and 4 more: https://git.openjdk.org/jfx22u/compare/632792d4...150cfb63 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx22u/pull/3/files Stats: 799 lines in 18 files changed: 434 ins; 157 del; 208 mod Patch: https://git.openjdk.org/jfx22u/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx22u/pull/3 From kcr at openjdk.org Tue Jan 16 22:44:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jan 2024 22:44:04 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 In-Reply-To: <43rrdnWWzDBfn133wvn0r4G3ebQuLi-vuucmo6r6r34=.a8726dc9-e46b-4edc-b511-32dd591e83c0@github.com> References: <43rrdnWWzDBfn133wvn0r4G3ebQuLi-vuucmo6r6r34=.a8726dc9-e46b-4edc-b511-32dd591e83c0@github.com> Message-ID: On Tue, 16 Jan 2024 22:29:01 GMT, Kevin Rushforth wrote: > Merge changes from `jfx:jfx22` --> `jfx22u`. This pull request has now been integrated. Changeset: dcf4e6a2 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/dcf4e6a2417b72050baa831ade2931a3b18915c7 Stats: 799 lines in 18 files changed: 434 ins; 157 del; 208 mod Merge ------------- PR: https://git.openjdk.org/jfx22u/pull/3 From duke at openjdk.org Wed Jan 17 03:15:03 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Wed, 17 Jan 2024 03:15:03 GMT Subject: [jfx21u] RFR: 8323221: Create release notes for JavaFX 21.0.2 In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 15:09:45 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45268 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45267 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2023-01-16 (tomorrow), I will add any security bugs and make this PR `rfr`. Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/39#pullrequestreview-1826402258 From kpk at openjdk.org Wed Jan 17 04:58:00 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 17 Jan 2024 04:58:00 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: <8DUTMaIYzZeOZ2YIgySKrYoJDJDmndlji-eKPxX3U9s=.f4838d60-32e3-4ab6-be96-d90d978eed1f@github.com> Message-ID: On Tue, 16 Jan 2024 15:42:28 GMT, Andy Goryachev wrote: >> Added comment and used bit logic in the condition. >> Do you think we should create a method in TextRun? I believe it is out of scope of this PR as it will be used in other functions as well. > > Yes, creating such a new method in TextRun might be out of scope for this, unless we touch all the places where the bit logic is used. Up to you, it's just a suggestion. I would prefer not to make this change in this PR. So I will keep this as it is for now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1454584637 From psadhukhan at openjdk.org Wed Jan 17 08:57:00 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 17 Jan 2024 08:57:00 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. Works ok in windows11 as per my testing...BTW, did your testing on mac works as deadlock was seen as per JBS comment? probably should have been solved by [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1895360310 From kpk at openjdk.org Wed Jan 17 10:54:46 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 17 Jan 2024 10:54:46 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v4] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix multiline text insertion index calculation issue ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/cd270e16..87255aa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=02-03 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Wed Jan 17 11:00:01 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 17 Jan 2024 11:00:01 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: <1C2tusDOHT88HmzpkwPyENHtAUr7TR3kUla2SITVSPU=.f2b16e15-09be-4edb-8ce6-be5aa37cdd2a@github.com> Message-ID: On Tue, 16 Jan 2024 12:50:59 GMT, Karthik P K wrote: > There seems to be a weird problem with Text (tested on macOS) in the Monkey Tester. Fixed this issue. Please check. I observed one more issue. When I scroll the Text window around 70% or more with Writing Systems selected and then hover over the text, flickering is observed. Attaching the video for reference. https://github.com/openjdk/jfx/assets/26969459/601aac43-c8d8-4402-9f15-bc23e63572f9 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1895571801 From mhanl at openjdk.org Wed Jan 17 12:33:06 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 17 Jan 2024 12:33:06 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: <6fsPjrXlP7M_ZKc8ZYM3QcLHaDx_LALjFxRdg_LOj_A=.e93bc897-fa08-40ed-ba9a-5dd04760dd45@github.com> References: <6fsPjrXlP7M_ZKc8ZYM3QcLHaDx_LALjFxRdg_LOj_A=.e93bc897-fa08-40ed-ba9a-5dd04760dd45@github.com> Message-ID: On Tue, 16 Jan 2024 16:00:28 GMT, Andy Goryachev wrote: > looks good now, thanks! should the fix be backported to jfx22? Sounds good. I can do that, just need to find the instructions again. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1895711865 From duke at openjdk.org Wed Jan 17 12:33:07 2024 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Wed, 17 Jan 2024 12:33:07 GMT Subject: Integrated: JDK-8323543: NPE when table items are set to null In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 18:53:02 GMT, Carl D?bbelin wrote: > This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. This pull request has now been integrated. Changeset: 872dbc8a Author: Carl D?bbelin Committer: Marius Hanl URL: https://git.openjdk.org/jfx/commit/872dbc8a2d254cba4df33fcc778b15b1a3c9b69f Stats: 60 lines in 5 files changed: 47 ins; 11 del; 2 mod 8323543: NPE when table items are set to null Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1329 From kcr at openjdk.org Wed Jan 17 12:57:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Jan 2024 12:57:22 GMT Subject: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS [v3] In-Reply-To: References: Message-ID: > As noted in the JBS bug, this is a follow-on to [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered while testing the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the IME code when using WebView in a JFXPanel on macOS). > > I have tested this in connection with with the proposed fix for JDK-8221261, although it is a valid fix regardless. > > This expands the fix done in [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the WebKit methods on the right thread. Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Revert change to log message when exception occurs - Merge branch 'master' into 8322703-webkit-ime-crash - Merge remote-tracking branch 'upstream/master' into 8322703-webkit-ime-crash - 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1321/files - new: https://git.openjdk.org/jfx/pull/1321/files/c5ce4a7f..bfca6a9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1321&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1321&range=01-02 Stats: 290025 lines in 6457 files changed: 170612 ins; 83465 del; 35948 mod Patch: https://git.openjdk.org/jfx/pull/1321.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1321/head:pull/1321 PR: https://git.openjdk.org/jfx/pull/1321 From kcr at openjdk.org Wed Jan 17 12:57:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Jan 2024 12:57:24 GMT Subject: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS [v2] In-Reply-To: <8k18knTmdYfllJkc30d46q_VT1moeefIASE1_a_TGuA=.ef0b6f1b-1638-449f-a1e5-966235878398@github.com> References: <8k18knTmdYfllJkc30d46q_VT1moeefIASE1_a_TGuA=.ef0b6f1b-1638-449f-a1e5-966235878398@github.com> Message-ID: On Tue, 16 Jan 2024 13:54:00 GMT, Kevin Rushforth wrote: >> As noted in the JBS bug, this is a follow-on to [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered while testing the fix for [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the IME code when using WebView in a JFXPanel on macOS). >> >> I have tested this in connection with with the proposed fix for JDK-8221261, although it is a valid fix regardless. >> >> This expands the fix done in [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the WebKit methods on the right thread. Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8322703-webkit-ime-crash > - 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS > Additionally, we sometimes see spurious exceptions where the committed text is coming back as null, so I changed the log level to "fine" rather than "severe" for those exceptions. I'll file a follow-up bug to see if any of these are real problems or not. I decided to revert this change to the log level so as not to hide exceptions that might occur. They don't happen often, and we should report them when they do. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1321#issuecomment-1895753776 From angorya at openjdk.org Wed Jan 17 15:31:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jan 2024 15:31:10 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 16:06:42 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8323543: change tests to JUnit4 for compatibility backport instructions: https://openjdk.org/guide/#working-with-backports-in-jbs @kevinrushforth there is still time to backport, right? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1896049195 From kcr at openjdk.org Wed Jan 17 15:39:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Jan 2024 15:39:11 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 15:28:53 GMT, Andy Goryachev wrote: > backport instructions: https://openjdk.org/guide/#working-with-backports-in-jbs See also https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044529.html which has additional information. > @kevinrushforth there is still time to backport, right? Yes. JavaFX 22 is in RDP1 for another 3 weeks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1896065334 From mfox at openjdk.org Wed Jan 17 15:48:03 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 17 Jan 2024 15:48:03 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. Tested on Mac, worked fine with no deadlock. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1896082242 From kevin.rushforth at oracle.com Wed Jan 17 16:01:36 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jan 2024 08:01:36 -0800 Subject: jfx22u open for JavaFX 22.0.1 backports Message-ID: <0cbcc876-c400-4b56-8ce3-c98f1d9dccac@oracle.com> All, The jfx22u repo [1] is now open for JavaFX 22.0.1 backports (the April 2024 CPU release), with prior approval. The general criteria is that we want to backport fixes for regressions introduced in JavaFX 22, third-party library updates, and a limited number of other important bug fixes. In most cases we'd like to see the fix "bake" in the mainline for a while before being backported to jfx22u. NOTE: Only those fixes that will NOT be backported to the jfx22 [2] stabilization branch are candidates for backporting to jfx22u. A backport intended for the JavaFX 22 code line will go into either the jfx22 branch or the jfx22u repo, not both. We use a similar procedure for making the request and noting the approval as is used by the JDK updates releases -- by using JBS labels to request a backport and indicate approval or rejection. Here is the procedure: 1. A developer makes the request by adding the "jfx22u-fix-request" label to the main bug in JBS (not the backport record, even presuming one exists), with a comment indicating that you would like to backport it, along with a justification and risk assessment, if needed. 2. One of the JavaFX projects leads, either Johan Vos or myself, will add a "jfx22u-fix-yes" label to approve or "jfx22u-fix-no" label to reject the request, along with a comment. In either case, the jfx22u-request label is left in place. 3. Create the backport PR for jfx22u, either manually or using the "/backport" command. If you have good reason to believe that that this bug is a good candidate for jfx22u, then you can do this step first and use Skara's "/approval" command to request approval. Let Johan or me know if you have any questions. Thanks. -- Kevin [1] https://github.com/openjdk/jfx22u [2] https://github.com/openjdk/jfx/tree/jfx22 From angorya at openjdk.org Wed Jan 17 16:23:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jan 2024 16:23:08 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v2] In-Reply-To: References: <1C2tusDOHT88HmzpkwPyENHtAUr7TR3kUla2SITVSPU=.f2b16e15-09be-4edb-8ce6-be5aa37cdd2a@github.com> Message-ID: <_onfVDrOfGUHvehwyarak6I0jj2XhyuPG97qBZeERu0=.808d371d-5288-47ee-bd89-95a71b22b2f9@github.com> On Wed, 17 Jan 2024 10:57:44 GMT, Karthik P K wrote: > flickering is observed This is not an issue: the hit info label gets wider than available space, causing a layout (there is no scroll bar). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1896149715 From tsayao at openjdk.org Wed Jan 17 16:29:24 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 17 Jan 2024 16:29:24 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v18] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 92 commits: - Merge branch 'master' into new_ime # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp - Add check for jview - - Fix comment path - - Fix double keyrelease - - Use a work-around to relative positioning (until wayland is not officially supported) - Unref pango attr list - Merge branch 'master' into new_ime - Account the case of !filtered - Fix change of focus when on preedit + add filter on key release - Merge branch 'master' into new_ime - Remove unused include - ... and 82 more: https://git.openjdk.org/jfx/compare/872dbc8a...2fde93b6 ------------- Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=17 Stats: 464 lines in 7 files changed: 74 ins; 291 del; 99 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From mfox at openjdk.org Wed Jan 17 16:43:23 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 17 Jan 2024 16:43:23 GMT Subject: RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory [v2] In-Reply-To: References: Message-ID: > When a Stage is closed while processing an OS message the glass peer object is deleted immediately even if it's still executing member functions. As glass unwinds the stack and executes cleanup code it's referencing freed memory. > > There are cases where glass generates JavaFX events back-to-back. For example, when handling the Delete key glass sends a PRESSED and TYPED event in the same routine. If the Stage is closed during the PRESSED event the code that sends the TYPED event is running inside an object that has already been deleted. > > When the Stage is closed glass calls the OS routine ::DestroyWindow on the HWND causing a WM_NCDESTROY message to be sent. Currently the BaseWnd object is deleted when processing this message. This PR defers the destruction until all messages have been processed. This is the same approach used in the Linux code. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Updated to match existing naming conventions ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1309/files - new: https://git.openjdk.org/jfx/pull/1309/files/0eb0f985..eaae9963 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1309&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1309&range=00-01 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1309.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1309/head:pull/1309 PR: https://git.openjdk.org/jfx/pull/1309 From tsayao at openjdk.org Wed Jan 17 17:10:24 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 17 Jan 2024 17:10:24 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v19] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add signals to avoid warnings ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/2fde93b6..5150e2ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=17-18 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Wed Jan 17 17:16:09 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 17 Jan 2024 17:16:09 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v17] In-Reply-To: References: <_TxY4SdwrrDUcS3GiT7rcYuukW81kRIueh-8jLUG9S0=.118128fe-88ef-48de-a13b-7353bea92fa5@github.com> Message-ID: On Tue, 2 Jan 2024 16:58:10 GMT, Martin Fox wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add check for jview > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 163: > >> 161: g_signal_connect(im_ctx.ctx, "preedit-changed", G_CALLBACK(on_preedit_changed), this); >> 162: g_signal_connect(im_ctx.ctx, "preedit-end", G_CALLBACK(on_preedit_end), this); >> 163: g_signal_connect(im_ctx.ctx, "commit", G_CALLBACK(on_commit), this); > > On Ubuntu 22.04 using the Japanese (Mozc) input method I get a bunch of debug output from IBus. The message reads > > `IBUS-WARNING **: 08:50:12.994: java has no capability of surrounding-text feature` > > I was able to silence this by connecting to the surrounding text signal and simply returning TRUE from the callback. Fixed, although JavaFX does not support it, so the warning is true. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1456112054 From mstrauss at openjdk.org Wed Jan 17 17:28:04 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 17 Jan 2024 17:28:04 GMT Subject: RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory [v2] In-Reply-To: References: Message-ID: <_zgrTL5-4r7_o--uYPCnz0EJI3BXENR3VY1Zgh_cbck=.eaa48220-078a-4eaa-b861-269faff38548@github.com> On Wed, 17 Jan 2024 16:43:23 GMT, Martin Fox wrote: >> When a Stage is closed while processing an OS message the glass peer object is deleted immediately even if it's still executing member functions. As glass unwinds the stack and executes cleanup code it's referencing freed memory. >> >> There are cases where glass generates JavaFX events back-to-back. For example, when handling the Delete key glass sends a PRESSED and TYPED event in the same routine. If the Stage is closed during the PRESSED event the code that sends the TYPED event is running inside an object that has already been deleted. >> >> When the Stage is closed glass calls the OS routine ::DestroyWindow on the HWND causing a WM_NCDESTROY message to be sent. Currently the BaseWnd object is deleted when processing this message. This PR defers the destruction until all messages have been processed. This is the same approach used in the Linux code. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Updated to match existing naming conventions Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1309#pullrequestreview-1827813361 From angorya at openjdk.org Wed Jan 17 19:48:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jan 2024 19:48:10 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v4] In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 10:54:46 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix multiline text insertion index calculation issue Noticed a problem - on Windows 11 and on macOS 14.2.1 hit into shows different values for Text and TextFlow. This issue can be seen with pretty much every text, even "aaa\nbbb\ncccc". In this screenshot, the line corresponds to the mouse position: ![Screenshot 2024-01-17 at 11 42 03](https://github.com/openjdk/jfx/assets/107069028/36680d90-520f-4899-aa08-ba93d524da8f) modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 213: > 211: * @param textRunStart Start position of first Text run where hit info is requested. > 212: * @param curRunStart Start position of text run where hit info is requested. > 213: * @param forTextFlow Indicates if the hit info is requested for TextFlow or Text node. True for TextFlow and False for Text node. technically, it's "true" and "false", e.g. `{@code true}` modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 430: > 428: int insertionIndex = -1; > 429: int relIndex = 0; > 430: int LTRIndex = 0; minor: it's a bit confusing to have a local var start with an uppercase letter. maybe 'ltrIndex' ? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 453: > 451: if (isMirrored) { > 452: int runIndex = -1; > 453: for (int i = runs.length - 1; i >=0; i--) { please add a space after `i >= ` modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 510: > 508: if (run.getTextSpan() != null && run.getTextSpan().getText().equals(text)) { > 509: if ((x > run.getWidth() && !isMultiRunText) || textWidthPrevLine > 0) { > 510: BaseBounds textBounds = new BoxBounds(); here (and on line 544) we allocate `textBounds` inside the for loop. Maybe we should allocate one before line 494 and use that instance in both for loops to avoid gc pressure? The downside is that in some cases it may not be used, but I feel it'll better since alloc is cheap. modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 521: > 519: } > 520: for (int j = runs.length - 1; j >= 0; j--) { > 521: if (runs[j].getTextSpan().getText().equals(text) && runs[j].getStart() != curRunStart) { minor optimization: do the int comparison first, equals second modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1062: > 1060: } else { > 1061: double ptX = localToParent(x, y).getX(); > 1062: double ptY = localToParent(x, y).getY(); localToParent(x, y) computed twice, could we avoid that? tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 274: > 272: while (x > X_LEADING_OFFSET) { > 273: moveMouseOverTextFlow(x, Y_OFFSET); > 274: if (isLeading) { indentation? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1896553605 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1456279189 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1456284396 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1456341154 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1456297979 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1456299608 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1456305703 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1456326090 From mfox at openjdk.org Wed Jan 17 22:52:02 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 17 Jan 2024 22:52:02 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: <4Q3MjqzqcsfPp-mdkJx0ExWg3yqwj6ENzAooLPFprb0=.97144014-3931-4f3f-9c98-9d1a77aaa208@github.com> On Fri, 17 Nov 2023 20:05:09 GMT, Martin Fox wrote: > On Windows a common shortcut like Ctrl+'+' could only be invoked from the main keyboard and not the numeric keypad. Toolkit.getKeyCodeForChar did not have enough context to know whether it should return a result from the main keyboard or the keypad. > > This PR alters getKeyCodeForChar to pass in the code of the key the system is trying to match against. Only the Windows platform actually uses this additional information. > > On the Mac the numeric keypad has always worked due to the odd way getKeyCodeForChar is implemented (until PR #1209 the keypad worked more reliably than the main keyboard). On Linux getKeyCodeForChar is a mess; neither the main keyboard or the numeric keypad work reliably. I have an upcoming PR which should make both work correctly. Comment to keep the bot at bay ------------- PR Comment: https://git.openjdk.org/jfx/pull/1289#issuecomment-1897258715 From jbhaskar at openjdk.org Thu Jan 18 03:35:26 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 18 Jan 2024 03:35:26 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Message-ID: Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. Solution: copy the old path to the current path constructor ------------- Commit messages: - 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Changes: https://git.openjdk.org/jfx/pull/1338/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323879 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1338.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1338/head:pull/1338 PR: https://git.openjdk.org/jfx/pull/1338 From jbhaskar at openjdk.org Thu Jan 18 03:39:37 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 18 Jan 2024 03:39:37 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html [v2] In-Reply-To: References: Message-ID: <4vGK9ST8gkz64zVaTZQBc4tqcjd1eZZ0Aa1gNLQFjnA=.bca2f162-8978-41f1-ba73-3cb3c6d94dd1@github.com> > Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. > Solution: copy the old path to the current path constructor Jay Bhaskar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1338/files - new: https://git.openjdk.org/jfx/pull/1338/files/3924e755..872dbc8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1338&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1338&range=00-01 Stats: 73 lines in 2 files changed: 0 ins; 72 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1338.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1338/head:pull/1338 PR: https://git.openjdk.org/jfx/pull/1338 From jbhaskar at openjdk.org Thu Jan 18 03:39:37 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 18 Jan 2024 03:39:37 GMT Subject: Withdrawn: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 03:30:21 GMT, Jay Bhaskar wrote: > Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. > Solution: copy the old path to the current path constructor This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1338 From jbhaskar at openjdk.org Thu Jan 18 03:56:28 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 18 Jan 2024 03:56:28 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Message-ID: Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. ------------- Commit messages: - 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Changes: https://git.openjdk.org/jfx/pull/1339/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1339&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323879 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1339.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1339/head:pull/1339 PR: https://git.openjdk.org/jfx/pull/1339 From psadhukhan at openjdk.org Thu Jan 18 07:32:25 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 18 Jan 2024 07:32:25 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 106: > 104: }); > 105: } > 106: if (stringValue == null) stringValue = ""; Not sure of FX coding guidelines but in JDK, even for a single statement, we need to put in braces ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1457032565 From psadhukhan at openjdk.org Thu Jan 18 07:32:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 18 Jan 2024 07:32:26 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 07:28:57 GMT, Prasanta Sadhukhan wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 106: > >> 104: }); >> 105: } >> 106: if (stringValue == null) stringValue = ""; > > Not sure of FX coding guidelines but in JDK, even for a single statement, we need to put in braces I guess this should add [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) through "/issue add" command ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1457033444 From kpk at openjdk.org Thu Jan 18 07:53:42 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 18 Jan 2024 07:53:42 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v5] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/87255aa9..b08de73c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=03-04 Stats: 13 lines in 4 files changed: 2 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Thu Jan 18 07:53:43 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 18 Jan 2024 07:53:43 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v4] In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 19:45:51 GMT, Andy Goryachev wrote: > Noticed a problem - on Windows 11 and on macOS 14.2.1 hit into shows different values for Text and TextFlow. This issue can be seen with pretty much every text, even "aaa\nbbb\ncccc". In this screenshot, the line corresponds to the mouse position: > I see this problem as well. I will check on this issue. > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 430: > >> 428: int insertionIndex = -1; >> 429: int relIndex = 0; >> 430: int LTRIndex = 0; > > minor: it's a bit confusing to have a local var start with an uppercase letter. maybe 'ltrIndex' ? Changed to `ltrIndex` > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 510: > >> 508: if (run.getTextSpan() != null && run.getTextSpan().getText().equals(text)) { >> 509: if ((x > run.getWidth() && !isMultiRunText) || textWidthPrevLine > 0) { >> 510: BaseBounds textBounds = new BoxBounds(); > > here (and on line 544) we allocate `textBounds` inside the for loop. > Maybe we should allocate one before line 494 and use that instance in both for loops to avoid gc pressure? > The downside is that in some cases it may not be used, but I feel it'll better since alloc is cheap. Agreed. I think allocating the `textBounds` before line 494 is better. Made this change > modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1062: > >> 1060: } else { >> 1061: double ptX = localToParent(x, y).getX(); >> 1062: double ptY = localToParent(x, y).getY(); > > localToParent(x, y) computed twice, could we avoid that? Created local variable to get Point2D value > tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 274: > >> 272: while (x > X_LEADING_OFFSET) { >> 273: moveMouseOverTextFlow(x, Y_OFFSET); >> 274: if (isLeading) { > > indentation? Corrected indentation ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1897964532 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1457049491 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1457049303 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1457047727 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1457047377 From kcr at openjdk.org Thu Jan 18 13:21:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jan 2024 13:21:26 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 03:51:28 GMT, Jay Bhaskar wrote: > Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. > Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. Reviewers: @HimaBinduMeda @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1339#issuecomment-1898466352 From kcr at openjdk.org Thu Jan 18 13:50:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jan 2024 13:50:26 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. This generally looks good. I left a couple comments inline. modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 63: > 61: private Point2D pointValue; > 62: private int intValue; > 63: private String stringValue; Using instance fields like this is not thread-safe in general (although unlikely to cause problems in practice for this specific case). I recommend either creating a utility method that returns the result of a `Future` (see PR #1321 ) or changing these to local `AtomicObject` / `AtomicInteger` (or `Type[]` `int[]`) variables. ------------- PR Review: https://git.openjdk.org/jfx/pull/1337#pullrequestreview-1829689559 PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1457447528 From kcr at openjdk.org Thu Jan 18 13:50:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jan 2024 13:50:28 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: <6HSStfWF3VSQzmP8m7_VjDLrB2s7cQDADiCFsVH1yAo=.2dc29463-42b4-4ea3-9c07-d1406a694dbf@github.com> On Thu, 18 Jan 2024 07:30:05 GMT, Prasanta Sadhukhan wrote: >> modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 106: >> >>> 104: }); >>> 105: } >>> 106: if (stringValue == null) stringValue = ""; >> >> Not sure of FX coding guidelines but in JDK, even for a single statement, we need to put in braces > > I guess this should add [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) through "/issue add" command Regarding FX coding style, the one place where braces are not needed is when everything is all on one line. Regarding [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267), should the call to `getInputMethodRequests` added to [JFXPanel line 1028](https://github.com/openjdk/jfx/pull/1169/files#diff-e6f5782dba36f256cceb649ce526ed1f7a8f6704d3a32bd8bd17cef42621d99cR1028) by PR #1169 be added to this PR as well? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1457453171 From lkostyra at openjdk.org Thu Jan 18 15:33:49 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 18 Jan 2024 15:33:49 GMT Subject: RFR: 8260013: Snapshot does not work for nodes in a subscene [v2] In-Reply-To: References: Message-ID: > Originally this issue showed the problem of Node being incorrectly rendered (clipped) when snapshotting, compared to a snapshot of the whole Scene. Later on there was another problem added - lights not being taken into account if they are added to a SubScene. > > As it later turned out, the original problem from this bug report is a problem with ParallelCamera incorrectly estimating near/far clipping planes, which just happened to reveal itself while snapshotting a Node. During testing I found out you can make the Node clip regardless of snapshot mechanism. Clipping issue was moved to a separate bug report and this PR only fixes the inconsistency in lights being gathered for a snapshot. > > `Scene.doSnapshot()` was expanded to also check if SubScene provided to it is non-null and to fetch lights assigned to it. Scenario was tested with added SnapshotLightsTest. > > Rest of the tests were checked and don't produce any noticeable regressions. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: doSnapshot: Replace light accumulation code Uses suggested simpler implementation using Java's Streams. Needed an additional check in NGShape3D, otherwise IndexOutOfBounds was thrown ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1332/files - new: https://git.openjdk.org/jfx/pull/1332/files/2a2da5ec..49782ee8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1332&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1332&range=00-01 Stats: 44 lines in 2 files changed: 3 ins; 37 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1332.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1332/head:pull/1332 PR: https://git.openjdk.org/jfx/pull/1332 From lkostyra at openjdk.org Thu Jan 18 15:33:52 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 18 Jan 2024 15:33:52 GMT Subject: RFR: 8260013: Snapshot does not work for nodes in a subscene [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 21:25:57 GMT, Michael Strau? wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> doSnapshot: Replace light accumulation code >> >> Uses suggested simpler implementation using Java's Streams. >> >> Needed an additional check in NGShape3D, otherwise IndexOutOfBounds was >> thrown > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1364: > >> 1362: // Grab the lights from the scene and/or subscene >> 1363: context.lights = null; >> 1364: int totalLightCount = 0; > > Here's a suggestion: you might be able to replace all of the new code, including the `accumulateLightsForSnapshot` method, with the following shorter code: > > > Stream lights = Stream.concat( > Optional.ofNullable(scene).stream().flatMap(s -> s.lights.stream()).map(LightBase::getPeer), > Optional.ofNullable(subScene).stream().flatMap(s -> s.getLights().stream()).map(LightBase::getPeer)); > > context.lights = lights.toArray(NGLightBase[]::new); I changed the code as suggested. After that Snapshot3DTest code started showing some failures, this was due to NGShape3D code not checking if it gets an empty (length == 0) array and throwing `IndexOutOfBoundsException`. I patched that as well and didn't see any regressions in tests afterwards. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1332#discussion_r1457610923 From kcr at openjdk.org Thu Jan 18 16:33:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jan 2024 16:33:28 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 03:51:28 GMT, Jay Bhaskar wrote: > Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. > Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. The fix looks reasonable, although there is now an unused variable, and I have a suggestion for making it clearer. I verified that the test fails on Windows without your fix. I will rebuild WebKit and verify that it passes with your fix. modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/PathJava.cpp line 123: > 121: auto platformPathCopy = createEmptyPath(); > 122: > 123: RefPtr pathCopy(copyPath(platformPath())); The `platformPathCopy` local variable is now unused and can be removed. Better still, you could make the following change and then revert the name change in the `create` method where it is used. RefPtr platformPathCopy(copyPath(platformPath())); ------------- PR Review: https://git.openjdk.org/jfx/pull/1339#pullrequestreview-1830100123 PR Review Comment: https://git.openjdk.org/jfx/pull/1339#discussion_r1457695482 From kcr at openjdk.org Thu Jan 18 16:44:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jan 2024 16:44:28 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 16:06:42 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8323543: change tests to JUnit4 for compatibility > /backport jfx22u @Maran23 That will target jfx22u for JavaFX 22.0.1, which would probably be OK, but as I mentioned above, since we are still in RDP1 for JavaFX 22, this is a good candidate for JavaFX 22. So I recommend abandoning the above PR and instead target the jfx22 branch of the jfx repo: `/backport jfx jfx22` instead. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1898837148 From mfox at openjdk.org Thu Jan 18 16:52:22 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 18 Jan 2024 16:52:22 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: <_c9_GTJ8O0y79hbl8QbKZ6c1u5nzkyDz5V8B2kzYrdY=.a017ca9d-8059-407a-ad1d-48f607b53a73@github.com> On Thu, 18 Jan 2024 13:33:22 GMT, Kevin Rushforth wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 63: > >> 61: private Point2D pointValue; >> 62: private int intValue; >> 63: private String stringValue; > > Using instance fields like this is not thread-safe in general (although unlikely to cause problems in practice for this specific case). I recommend either creating a utility method that returns the result of a `Future` (see PR #1321 ) or changing these to local `AtomicObject` / `AtomicInteger` (or `Type[]` `int[]`) variables. Using instance fields here does look clunky. There's no thread-safety issue because the JFXPanel code creates a new adapter for every request so I decided to avoid the overhead of creating local arrays (apologies for the micro-optimizing). I will switch to local array variables if you want. For the same reason I don't think the `getInputMethodRequests` call added to line 1028 in PR #1169 is necessary. The adapter it creates is discarded so the only side-effect is calling the scene's `getInputMethodRequests` before the requests are needed. I can't think of any reason this front-loading would be necessary. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1457726480 From kcr at openjdk.org Thu Jan 18 20:59:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jan 2024 20:59:24 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html In-Reply-To: References: Message-ID: <4Nfwp85Ck811T2n4GJtIGNRSC6MvwOUTC5lh1kq33vk=.8a74cb71-3478-41c4-b8c0-5085765b231b@github.com> On Thu, 18 Jan 2024 03:51:28 GMT, Jay Bhaskar wrote: > Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. > Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. The test passes with your fix. There are a few unused imports in the test that you can remove. modules/javafx.web/src/test/java/test/javafx/scene/web/PathContructorTest.java line 33: > 31: import java.awt.image.BufferedImage; > 32: import java.util.Base64; > 33: import javafx.scene.web.WebEngineShim; All of these imports are unused and can be removed. modules/javafx.web/src/test/java/test/javafx/scene/web/PathContructorTest.java line 36: > 34: > 35: > 36: import org.junit.After; Unused import. ------------- PR Review: https://git.openjdk.org/jfx/pull/1339#pullrequestreview-1830534336 PR Review Comment: https://git.openjdk.org/jfx/pull/1339#discussion_r1457964551 PR Review Comment: https://git.openjdk.org/jfx/pull/1339#discussion_r1457964890 From kcr at openjdk.org Fri Jan 19 00:16:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 00:16:42 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 14:54:36 GMT, John Hendrikx wrote: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` This seems like a reasonable thing to do. As I mentioned above, the first step is to file a new enhancement to deprecate these two classes for removal, with the idea being to get them into jfx22 via a late enhancement request. This will need to be done quickly, since we have only 2 weeks before RDP2. In parallel with that, discussion on openjfx-dev with a new subject indicating that you propose to remove these two classes from the public API by deprecating them for removal in JavaFX 22 and removing them in 23. I left a few inline comments, but nothing that would call the overall proposal into question. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 46: > 44: * @since 9 > 45: */ > 46: public abstract sealed class Selector permits SimpleSelector, CompoundSelector { This seems like a reasonable use of sealed. In order to move the only two implementations of this abstract class out of this package, the constructor must be made public (or protected, which for an abstract class has the same semantics). By making it sealed, you don't then open it up to extending by arbitrary classes. However, it is an anti-pattern to have an implicitly-defined constructor -- see [JDK-8250558](https://bugs.openjdk.org/browse/JDK-8250558) -- so you will need to add an explicit constructor with an `@since 23`. I recommend making it protected to reinforce that this class is not to be instantiated directly. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 96: > 94: * @return a match, never {@code null} > 95: */ > 96: public final Match createMatch() { This is a compatible change only because this class is sealed. I do have a question, though, about whether it should remain abstract. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 102: > 100: > 101: return new Match(this, s.getPseudoClassStates(), idCount, styleClassCount); > 102: } I presume you are moving the implementations to this base class because some of the types, constructors (e.g., Match), or methods only have package visibility? Using the accessor pattern via a Helper class is usually how we deal with this. Have you considered that? It would allow the implementation to remain in the subclasses. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 179: > 177: * @throws IOException if reading from {@code DataInputStream} fails > 178: */ > 179: protected static Selector readBinary(int bssVersion, DataInputStream is, String[] strings) This is an API addition, so will need an `@since 23`. Since you are adding new API here, should it be an instance method rather than a static method? Or is is called without having an instance of Selector in some cases? ------------- PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-1830758962 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1458108202 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1458108802 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1458109403 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1458110482 From angorya at openjdk.org Fri Jan 19 00:45:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 00:45:36 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 14:54:36 GMT, John Hendrikx wrote: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` Maybe @jperedadnr could check whether the ScenicView tools uses either SimpleSelector or CompoundSelector? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1899451079 From jbhaskar at openjdk.org Fri Jan 19 01:06:50 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 19 Jan 2024 01:06:50 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html [v2] In-Reply-To: References: Message-ID: > Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. > Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: remove unused variable and imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1339/files - new: https://git.openjdk.org/jfx/pull/1339/files/f6538019..7516c0f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1339&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1339&range=00-01 Stats: 13 lines in 2 files changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1339.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1339/head:pull/1339 PR: https://git.openjdk.org/jfx/pull/1339 From jbhaskar at openjdk.org Fri Jan 19 01:06:52 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 19 Jan 2024 01:06:52 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html [v2] In-Reply-To: <4Nfwp85Ck811T2n4GJtIGNRSC6MvwOUTC5lh1kq33vk=.8a74cb71-3478-41c4-b8c0-5085765b231b@github.com> References: <4Nfwp85Ck811T2n4GJtIGNRSC6MvwOUTC5lh1kq33vk=.8a74cb71-3478-41c4-b8c0-5085765b231b@github.com> Message-ID: On Thu, 18 Jan 2024 20:51:05 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused variable and imports > > modules/javafx.web/src/test/java/test/javafx/scene/web/PathContructorTest.java line 33: > >> 31: import java.awt.image.BufferedImage; >> 32: import java.util.Base64; >> 33: import javafx.scene.web.WebEngineShim; > > All of these imports are unused and can be removed. done > modules/javafx.web/src/test/java/test/javafx/scene/web/PathContructorTest.java line 36: > >> 34: >> 35: >> 36: import org.junit.After; > > Unused import. done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1339#discussion_r1458162283 PR Review Comment: https://git.openjdk.org/jfx/pull/1339#discussion_r1458162444 From jvos at openjdk.org Fri Jan 19 09:17:42 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 19 Jan 2024 09:17:42 GMT Subject: [jfx21u] RFR: 8323221: Create release notes for JavaFX 21.0.2 In-Reply-To: References: Message-ID: <-MAaOjpXxdT9CGDvKLGBtcPgGfpMUCZh_TeJ7uSHPoU=.50826fed-cedb-478d-80ed-680e04047c67@github.com> On Mon, 15 Jan 2024 15:09:45 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45268 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45267 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2023-01-16 (tomorrow), I will add any security bugs and make this PR `rfr`. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/39#pullrequestreview-1831953507 From jpereda at openjdk.org Fri Jan 19 09:22:42 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 19 Jan 2024 09:22:42 GMT Subject: [jfx17u] RFR: 8323829: Change javaFX release version to 17.0.11 in jfx17u In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 20:26:40 GMT, Johan Vos wrote: > Increase the release version to JavaFX 17.0.11 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/176#pullrequestreview-1831961532 From jvos at openjdk.org Fri Jan 19 09:25:42 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 19 Jan 2024 09:25:42 GMT Subject: [jfx17u] Integrated: 8323829: Change javaFX release version to 17.0.11 in jfx17u In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 20:26:40 GMT, Johan Vos wrote: > Increase the release version to JavaFX 17.0.11 This pull request has now been integrated. Changeset: 31c4308b Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/31c4308b9218f397f4d86855affdbeb2253c566f Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8323829: Change javaFX release version to 17.0.11 in jfx17u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx17u/pull/176 From jhendrikx at openjdk.org Fri Jan 19 09:35:44 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 09:35:44 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 23:58:17 GMT, Kevin Rushforth wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 102: > >> 100: >> 101: return new Match(this, s.getPseudoClassStates(), idCount, styleClassCount); >> 102: } > > I presume you are moving the implementations to this base class because some of the types, constructors (e.g., Match), or methods only have package visibility? Using the accessor pattern via a Helper class is usually how we deal with this. Have you considered that? It would allow the implementation to remain in the subclasses. Yes, correct, `CompoundSelector` accesses the package private fields `idCount` and `styleClassCount` of `Match` directly, which it can't do anymore after being moved to a different package; these lines: idCount += match.idCount; styleClassCount += match.styleClassCount; I'm aware of the Helper classes, but I feel that they are a much more invasive concept (and also harder to follow) to achieve this than doing a pattern match with `instanceof` (which can be replaced with pattern matches for switch once we can use Java 21). However, if you think this is a requirement, I'm happy to change it -- that said, we're not locked in either choice as far as I can see. Alternatively, with everything needed in `Selector` being publicly accessible, I'm not sure if the match creation really needed to be in `Selector` or its subtypes at all. It feels like more a job for an external type to handle (like how you don't write serialization logic for JSON or XML in each subtype). If it were up to me, I'd probably create a static method in `Match` which given a `Selector` creates the match. That way, no `Match` internals need exposing at all. I could still do this, as the method needed could be package private, and then all the match fields can be made fully private. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1458660294 From jvos at openjdk.org Fri Jan 19 09:36:51 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 19 Jan 2024 09:36:51 GMT Subject: [jfx17u] RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted Message-ID: almost clean Backport (apart from a (c) date change) of 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted Reviewed-by: angorya, mstrauss, kcr ------------- Commit messages: - 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted Changes: https://git.openjdk.org/jfx17u/pull/177/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321722 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx17u/pull/177.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/177/head:pull/177 PR: https://git.openjdk.org/jfx17u/pull/177 From jpereda at openjdk.org Fri Jan 19 09:54:41 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 19 Jan 2024 09:54:41 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 00:43:20 GMT, Andy Goryachev wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > Maybe @jperedadnr could check whether the ScenicView tools uses either SimpleSelector or CompoundSelector? @andy-goryachev-oracle Scenic View source code doesn't use neither of them. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900085510 From jhendrikx at openjdk.org Fri Jan 19 09:54:43 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 09:54:43 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 00:00:32 GMT, Kevin Rushforth wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 179: > >> 177: * @throws IOException if reading from {@code DataInputStream} fails >> 178: */ >> 179: protected static Selector readBinary(int bssVersion, DataInputStream is, String[] strings) > > This is an API addition, so will need an `@since 23`. Since you are adding new API here, should it be an instance method rather than a static method? Or is is called without having an instance of Selector in some cases? I'll add the `@since 23`, however it can't be called by anyone except FX itself. Some background: the readBinary/writeBinary methods are ultimately called via the publicly accessible methods `loadBinary` and `saveBinary` in `javafx.css.Stylesheet`. The reason it needs to be `protected` now is because `CompoundSelector` is using this (but IMHO, it shouldn't have). Why I say it shouldn't? That's because it already knows what it will be reading will all be `SimpleSelector`s, as it stores a counter (a `short`) and then loads that many `SimpleSelector`s. However, by not taking the direct route of using `SimpleSelector#readBinary` (and the corresponding `SimpleSelector#writeBinary`) there is an additional `byte` prefix indicating the type of selector -- this isn't needed and wastes some space in the binary format. Changing that now however would make the binary format incompatible with earlier versions, so I think making this `protected` is a reasonable solution. It also mirrors the `writeBinary` method then, which was already `protected`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1458688819 From jvos at openjdk.org Fri Jan 19 09:56:45 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 19 Jan 2024 09:56:45 GMT Subject: [jfx17u] Integrated: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: <072BMf9JjBa_lc4ccFU28WpLpCv2utHa_NG6-twehqU=.3c42c84b-f49c-47de-8b91-7264d5b5b5c0@github.com> On Fri, 19 Jan 2024 09:31:31 GMT, Johan Vos wrote: > almost clean Backport (apart from a (c) date change) of > 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted > > Reviewed-by: angorya, mstrauss, kcr This pull request has now been integrated. Changeset: 67b05974 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/67b0597410674fc016d726242f44be5660b983e6 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted Backport-of: a20f4bcd54c5ae2a3e19324e51ce1f4cc172e32f ------------- PR: https://git.openjdk.org/jfx17u/pull/177 From jhendrikx at openjdk.org Fri Jan 19 09:57:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 09:57:38 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 23:55:56 GMT, Kevin Rushforth wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 46: > >> 44: * @since 9 >> 45: */ >> 46: public abstract sealed class Selector permits SimpleSelector, CompoundSelector { > > This seems like a reasonable use of sealed. In order to move the only two implementations of this abstract class out of this package, the constructor must be made public (or protected, which for an abstract class has the same semantics). By making it sealed, you don't then open it up to extending by arbitrary classes. > > However, it is an anti-pattern to have an implicitly-defined constructor -- see [JDK-8250558](https://bugs.openjdk.org/browse/JDK-8250558) -- so you will need to add an explicit constructor with an `@since 23`. I recommend making it protected to reinforce that this class is not to be instantiated directly. Clear, I'll add it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1458692961 From jhendrikx at openjdk.org Fri Jan 19 10:08:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 10:08:39 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes Message-ID: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. ------------- Commit messages: - Deprecate for removal SimpleSelector and CompoundSelector Changes: https://git.openjdk.org/jfx/pull/1340/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324182 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1340.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1340/head:pull/1340 PR: https://git.openjdk.org/jfx/pull/1340 From jhendrikx at openjdk.org Fri Jan 19 10:21:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 10:21:05 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add since tags ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1333/files - new: https://git.openjdk.org/jfx/pull/1333/files/2909af46..e02d84c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=00-01 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From jhendrikx at openjdk.org Fri Jan 19 10:39:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 10:39:38 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 09:52:23 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 179: >> >>> 177: * @throws IOException if reading from {@code DataInputStream} fails >>> 178: */ >>> 179: protected static Selector readBinary(int bssVersion, DataInputStream is, String[] strings) >> >> This is an API addition, so will need an `@since 23`. Since you are adding new API here, should it be an instance method rather than a static method? Or is is called without having an instance of Selector in some cases? > > I'll add the `@since 23`, however it can't be called by anyone except FX itself. > > Some background: the readBinary/writeBinary methods are ultimately called via the publicly accessible methods `loadBinary` and `saveBinary` in `javafx.css.Stylesheet`. > > The reason it needs to be `protected` now is because `CompoundSelector` is using this (but IMHO, it shouldn't have). Why I say it shouldn't? That's because it already knows what it will be reading will all be `SimpleSelector`s, as it stores a counter (a `short`) and then loads that many `SimpleSelector`s. However, by not taking the direct route of using `SimpleSelector#readBinary` (and the corresponding `SimpleSelector#writeBinary`) there is an additional `byte` prefix indicating the type of selector -- this isn't needed and wastes some space in the binary format. > > Changing that now however would make the binary format incompatible with earlier versions, so I think making this `protected` is a reasonable solution. It also mirrors the `writeBinary` method then, which was already `protected`. I missed something in my above evaluation. The counterpart method `writeBinary` is not `static`. Although that makes sense as in that case you do have an instance you wish to write, it does make the read/write API asymmetric. It's not possible to make `readBinary` an instance method though as it is the method that is creating those instances. The other way around is possible (make `writeBinary` static), but it would then again need a pattern match to determine the correct static `writeBinary` to call when writing an arbitrary `Selector`. However, this would have allowed `CompoundSelector` to call a static version of `SimpleSelector#writeBinary` and `readBinary`, avoiding the extra identifying byte in the binary format, and avoiding the cast when reading it back. The read/write loops below: + final int nSelectors = is.readShort(); final List selectors = new ArrayList<>(); for (int n=0; n selectors = new ArrayList<>(); for (int n=0; n References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 10:02:19 GMT, John Hendrikx wrote: > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1340#pullrequestreview-1832235635 From jhendrikx at openjdk.org Fri Jan 19 11:47:42 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 11:47:42 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes In-Reply-To: <8qoKwIYXeN5008SCBWo--udTjTIQ5P2Dx70Tpf7zLSQ=.4e7b00a8-1cae-4453-b9b8-fc088b3edb50@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <8qoKwIYXeN5008SCBWo--udTjTIQ5P2Dx70Tpf7zLSQ=.4e7b00a8-1cae-4453-b9b8-fc088b3edb50@github.com> Message-ID: On Fri, 19 Jan 2024 11:40:27 GMT, Nir Lisker wrote: > Should this deprecation happen in 22 already so that they can be removed in 23? That's the idea, but it needs to go in 23 first so it can be backported to 22 (Kevin mentioned as much in the linked ticket) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900265405 From nlisker at openjdk.org Fri Jan 19 11:42:41 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 19 Jan 2024 11:42:41 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <8qoKwIYXeN5008SCBWo--udTjTIQ5P2Dx70Tpf7zLSQ=.4e7b00a8-1cae-4453-b9b8-fc088b3edb50@github.com> On Fri, 19 Jan 2024 10:02:19 GMT, John Hendrikx wrote: > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. Should this deprecation happen in 22 already so that they can be removed in 23? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900258347 From javafx at ivoryemr.co.za Fri Jan 19 12:06:19 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Fri, 19 Jan 2024 14:06:19 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: Message-ID: Hi Kevin I was hoping that others would way in on this fix (PR #1167), but now that we're in RDP1 with no other input coming in I decided to looked into this matter again and have found that this is not the correct solution for the following two reasons: 1. The current solution doesn't actually fix the bug, but merely avoids it: Specifically with regards to bug JDK-8159048 which reports a NPE occuring under some conditions in AbstractMasterTimer (subsequently renamed to AbstractPrimaryTimer). The reporter suggests that this is as a result of some concurrent modification occurring and suggests a workaround of wrapping the start/stop animation code in a Platform.runLater() call. Looking at the AbstractPrimaryTimer code it is apparent that the original author made an effort to isolate array modifications from array access. However this code has a bug in it which then manifests as a NPE under the right timing conditions. So the correct solution is to make the array modification code more robust, as apposed to forcing changes to occur on a single thread. The safest (and proper) solution is to convert the two arrays ("receivers" and "animationTimers") to be CopyOnWriteArrayList(s) which is an ideal JDK data structure for this use case as it replicates the intended behavior of the current implementation. (I've tried this out and it does solve the NPE problem.) 2. The current solution is based on the misconception that start, stop, and pause must occur on the FX thread: Specifically with regards to the CSR JDK-8313378 which makes this claim. Firstly the Animation API says explicitly that these methods are asynchronous, which means that the thread that invokes these methods and the actual execution of the animation occurs on different threads, and looking at AbstractPrimaryTimer code it can be seen that this is indeed the case. Secondly JavaFX had tests, as noted in JDK-8314266, that have run reliably for years without invoking these methods on the FX thread. FWIW I've also had code and used libraries for years now, where these methods have been invoked on a background thread (for example while loading FXML) without issue. In conclusion then I request permission to submit a new PR containing the following changes: 1. Revert PR #1167 (if this is the appropriate place, however the test case will require it) 2. Changing the arrays in AbstractPrimaryTimer to be CopyOnWriteArrayList(s) and removing previously supporting array code. 3. Adding a test based on the one supplied in JDK-8159048 to check that a NPE isn't thrown anymore. Hope this meets with your approval. Regards, Jurgen > On 8/18/2023 4:17 PM, Kevin Rushforth wrote: > As a heads-up for app developers who use JavaFX animation (including > Animation, along with any subclasses, and AnimationTimer), a change went > into the JavaFX 22+5 build to enforce that the play, pause, and stop > methods must be called on the JavaFX Application thread. Applications > should have been doing that all along (else they would have been subject > to unpredictable errors), but for those who aren't sure, you might want > to take 22+5 for a spin and see if you have any problems with your > application. Please report them on the list if you do. > > See JDK-8159048 [1] and CSR JDK-8313378 [2] for more information on this > change. > > Thanks. > > -- Kevin > > [1] https://bugs.openjdk.org/browse/JDK-8159048 > [2] https://bugs.openjdk.org/browse/JDK-8313378 From mhanl at openjdk.org Fri Jan 19 12:40:43 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 19 Jan 2024 12:40:43 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 16:41:31 GMT, Kevin Rushforth wrote: > So I recommend abandoning the above PR and instead target the jfx22 branch of the jfx repo: `/backport jfx jfx22` instead. Ahh, makes sense, thanks. First time backporting. :) I deleted the backport branch in jfx22u. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1900341049 From mhanl at openjdk.org Fri Jan 19 12:51:43 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 19 Jan 2024 12:51:43 GMT Subject: [jfx22] RFR: 8323543: NPE when table items are set to null Message-ID: This pull request contains a (clean) backport of commit [872dbc8a](https://github.com/openjdk/jfx/commit/872dbc8a2d254cba4df33fcc778b15b1a3c9b69f) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. Target branch is **jfx22**. ------------- Commit messages: - Backport 872dbc8a2d254cba4df33fcc778b15b1a3c9b69f Changes: https://git.openjdk.org/jfx/pull/1341/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323543 Stats: 60 lines in 5 files changed: 47 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1341.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1341/head:pull/1341 PR: https://git.openjdk.org/jfx/pull/1341 From kcr at openjdk.org Fri Jan 19 12:54:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 12:54:37 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 01:06:50 GMT, Jay Bhaskar wrote: >> Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. >> Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove unused variable and imports Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1339#pullrequestreview-1832471420 From kcr at openjdk.org Fri Jan 19 13:04:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 13:04:41 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 10:02:19 GMT, John Hendrikx wrote: > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. Add the `since` parameter to the Deprecation annotation, but otherwise good. modules/javafx.graphics/src/main/java/javafx/css/CompoundSelector.java line 65: > 63: * @deprecated This class was exposed erroneously and will be removed in a future version > 64: */ > 65: @Deprecated(forRemoval = true) You also need the `since` parameter: @Deprecated(since = "22", forRemoval = true) modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 54: > 52: * @deprecated This class was exposed erroneously and will be removed in a future version > 53: */ > 54: @Deprecated(forRemoval = true) @Deprecated(since = "22", forRemoval = true) ------------- PR Review: https://git.openjdk.org/jfx/pull/1340#pullrequestreview-1832492961 PR Review Comment: https://git.openjdk.org/jfx/pull/1340#discussion_r1458970180 PR Review Comment: https://git.openjdk.org/jfx/pull/1340#discussion_r1458970684 From kcr at openjdk.org Fri Jan 19 13:09:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 13:09:38 GMT Subject: [jfx22] RFR: 8323543: NPE when table items are set to null In-Reply-To: References: Message-ID: <4CzlGAMm3oLMMARz305k8UYVxdsCXXTeS-6Mlb8-J1I=.24daa704-3f0c-45a4-91d7-b3d887fa998b@github.com> On Fri, 19 Jan 2024 12:47:29 GMT, Marius Hanl wrote: > This pull request contains a (clean) backport of commit [872dbc8a](https://github.com/openjdk/jfx/commit/872dbc8a2d254cba4df33fcc778b15b1a3c9b69f) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > Target branch is **jfx22**. Approved. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1341#pullrequestreview-1832513249 From kcr at openjdk.org Fri Jan 19 13:13:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 13:13:43 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 12:37:48 GMT, Marius Hanl wrote: > Ahh, makes sense, thanks. First time backporting. :) Yeah, and it's somewhat confusing to have jfx22u active during RDP1 of JavaFX 22 where most fixes that go back into the 22 code line will want to go into 22 GA rather than 22.0.1. I had considered delaying the announcement of jfx22u being open, but we need it to backport the WebKit update (which we explicitly do not want in JavaFX 22 GA, but in 22.0.1). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1900403997 From kcr at openjdk.org Fri Jan 19 13:15:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 13:15:38 GMT Subject: [jfx22] RFR: 8323543: NPE when table items are set to null In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 12:47:29 GMT, Marius Hanl wrote: > This pull request contains a (clean) backport of commit [872dbc8a](https://github.com/openjdk/jfx/commit/872dbc8a2d254cba4df33fcc778b15b1a3c9b69f) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > Target branch is **jfx22**. @Maran23 since this is a clean backport of an already integrated fix, a single reviewer will suffice. You can integrate when ready. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1341#issuecomment-1900405921 From kcr at openjdk.org Fri Jan 19 13:35:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 13:35:36 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > /issue add JDK-8090267 Alternatively, you could close JDK-8090267 as a duplicate. Either is fine with me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1900435959 From jvos at openjdk.org Fri Jan 19 14:00:50 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 19 Jan 2024 14:00:50 GMT Subject: [jfx21u] Integrated: 8323830: Change JavaFX release version to 21.0.3 in jfx21u In-Reply-To: <68DjyV9aWvLzh2bG_96omW2ovaxxmfvSugdN3AfQLso=.f92c7d64-caaf-482a-8180-3968f177369e@github.com> References: <68DjyV9aWvLzh2bG_96omW2ovaxxmfvSugdN3AfQLso=.f92c7d64-caaf-482a-8180-3968f177369e@github.com> Message-ID: On Tue, 16 Jan 2024 20:30:01 GMT, Johan Vos wrote: > Start work on 21.0.3 This pull request has now been integrated. Changeset: 6893bb38 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/6893bb3878b311270fee367451c31467780320dd Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8323830: Change JavaFX release version to 21.0.3 in jfx21u Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx21u/pull/41 From kcr at openjdk.org Fri Jan 19 14:05:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 14:05:44 GMT Subject: [jfx21u] Integrated: 8323221: Create release notes for JavaFX 21.0.2 In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 15:09:45 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45268 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45267 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2023-01-16 (tomorrow), I will add any security bugs and make this PR `rfr`. This pull request has now been integrated. Changeset: 6724ee6a Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/6724ee6a03c508b709b6f14ee228001110667230 Stats: 34 lines in 1 file changed: 34 ins; 0 del; 0 mod 8323221: Create release notes for JavaFX 21.0.2 Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx21u/pull/39 From angorya at openjdk.org Fri Jan 19 15:40:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 15:40:37 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 09:50:44 GMT, Jose Pereda wrote: > However, Scene Builder does: Thank you, @jperedadnr ! Does this mean that we ought to add a public method to Selector? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900643988 From angorya at openjdk.org Fri Jan 19 15:44:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 15:44:38 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 10:02:19 GMT, John Hendrikx wrote: > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. Should this change also introduce a public method `Selector.getStyleClasses()` and/or `Selector.getStyleClassesSet()` due to https://github.com/openjdk/jfx/pull/1333#issuecomment-1900085510 ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900651274 From jhendrikx at openjdk.org Fri Jan 19 16:00:49 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 16:00:49 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add since parameter to deprecation annotation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1340/files - new: https://git.openjdk.org/jfx/pull/1340/files/6c2a9265..31088037 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1340.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1340/head:pull/1340 PR: https://git.openjdk.org/jfx/pull/1340 From jhendrikx at openjdk.org Fri Jan 19 16:13:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 16:13:37 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages In-Reply-To: References: Message-ID: <9eOPoCDbxoN-QArM-uZHjHM5u5dZJ6lSy7pQlonEKUg=.2e79d86d-3566-4f9b-a41d-81a8695d7128@github.com> On Fri, 19 Jan 2024 15:37:33 GMT, Andy Goryachev wrote: >> @andy-goryachev-oracle Scenic View source code doesn't use neither of them. >> >> However, Scene Builder does: https://github.com/gluonhq/scenebuilder/blob/master/kit/src/main/java/com/oracle/javafx/scenebuilder/kit/util/CssInternal.java#L251 >> >> I guess it can be used a quick test of this PR? > >> However, Scene Builder does: > > Thank you, @jperedadnr ! > Does this mean that we ought to add a public method to Selector? > @andy-goryachev-oracle Scenic View source code doesn't use neither of them. > > However, Scene Builder does: https://github.com/gluonhq/scenebuilder/blob/master/kit/src/main/java/com/oracle/javafx/scenebuilder/kit/util/CssInternal.java#L251 > > I guess it can be used a quick test of this PR? Well, because those classes are moved, SceneBuilder would no longer work (probably something like a class not found exception will occur). Is SceneBuilder tied to JavaFX releases? Otherwise we may need to take more action. I see that SceneBuilder is using these classes to obtain a list of all style classes that are part of a style sheet. Such functionality could be offered in several places, either on `Stylesheet`, which gathers all the style classes, a public method on `Rule` which gets all style classes that the rule uses, or a public method on `Selector` which returns all style classes that the selector uses. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900697708 From mstrauss at openjdk.org Fri Jan 19 16:14:02 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 19 Jan 2024 16:14:02 GMT Subject: RFR: 8324219: Remove incorrect documentation from Animation methods Message-ID: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> The `Animation` class states in the documentation of various methods that the method call would be asynchronous, using language similar to: {@code stop()} is an asynchronous call, the {@code Animation} may not stop immediately. This is factually wrong, there are no asynchronous calls. In fact, the methods in question can only be called synchronously on the JavaFX Application thread, and the state of the animation is changed immediately. For example, when `stop()` is called, the animation transitions to the stopped state instantly, without waiting for the next animation pulse. ------------- Commit messages: - Remove incorrect documentation for several Animation methods Changes: https://git.openjdk.org/jfx/pull/1342/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324219 Stats: 29 lines in 1 file changed: 4 ins; 15 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1342.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1342/head:pull/1342 PR: https://git.openjdk.org/jfx/pull/1342 From mstrauss at openjdk.org Fri Jan 19 16:14:02 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 19 Jan 2024 16:14:02 GMT Subject: RFR: 8324219: Remove incorrect documentation from Animation methods In-Reply-To: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> References: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> Message-ID: On Fri, 19 Jan 2024 16:07:31 GMT, Michael Strau? wrote: > The `Animation` class states in the documentation of various methods that the method call would be asynchronous, using language similar to: > > > {@code stop()} is an asynchronous call, the {@code Animation} may not stop immediately. > > > This is factually wrong, there are no asynchronous calls. In fact, the methods in question can only be called synchronously on the JavaFX Application thread, and the state of the animation is changed immediately. For example, when `stop()` is called, the animation transitions to the stopped state instantly, without waiting for the next animation pulse. Since this is a documentation-only change, it might also go into jfx22. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1342#issuecomment-1900697998 From mfox at openjdk.org Fri Jan 19 16:15:10 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 19 Jan 2024 16:15:10 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: Message-ID: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Switched to local array variables ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1337/files - new: https://git.openjdk.org/jfx/pull/1337/files/97c910a7..17609f6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1337&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1337&range=00-01 Stats: 24 lines in 1 file changed: 0 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1337.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1337/head:pull/1337 PR: https://git.openjdk.org/jfx/pull/1337 From angorya at openjdk.org Fri Jan 19 16:22:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 16:22:38 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 10:21:05 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since tags In my opinion, Selector might be the most logical place to add the new methods. This is a breaking change, so I think we should talk about adding these methods at the same time as deprecating the classes, to give the tools developers time to switch to the new implementation and possibly re-packaging their app in a multi-release jar (it's always fun to make changes to the build scripts!). Will there be enough time for a complete review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900711359 From jhendrikx at openjdk.org Fri Jan 19 16:24:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 16:24:37 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since parameter to deprecation annotation > Should this change also introduce a public method `Selector.getStyleClasses()` and/or `Selector.getStyleClassesSet()` due to [#1333 (comment)](https://github.com/openjdk/jfx/pull/1333#issuecomment-1900085510) ? Maybe yes, it depends on how important it is that SceneBuilder keeps working with newer and older FX releases 1. If SceneBuilder is tied to the same FX release, it just needs to be updated at the same time 2. If an older SceneBuilder must keep working with JavaFX 23, then we can't move those classes ever 3. If the requirement is only that it is compatible with one older version, then I guess we can introduce a new public method in 22. It would mean that the updated SceneBuilder would no longer work with JavaFX 21 or older versions. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900712837 From angorya at openjdk.org Fri Jan 19 16:27:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 16:27:37 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since parameter to deprecation annotation > 3. the updated SceneBuilder would no longer work with JavaFX 21 or older versions. or they (and other tools' developers) could use a multi-release jar https://openjdk.org/jeps/238 In any case, this change seems to have a greater impact than we thought originally. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900717798 From hmeda at openjdk.org Fri Jan 19 17:08:39 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 19 Jan 2024 17:08:39 GMT Subject: RFR: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 01:06:50 GMT, Jay Bhaskar wrote: >> Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. >> Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove unused variable and imports Verified the changes. Testing is green ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/1339#pullrequestreview-1833275708 From jpereda at openjdk.org Fri Jan 19 17:56:36 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 19 Jan 2024 17:56:36 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since parameter to deprecation annotation Scene Builder releases are always tight to the JavaFX version (i.e, SB 21 uses JavaFX 21), so once JavaFX 23 is out with this change (or if we start testing 23-ea before the release of SB 23), we'll just have to modify the `CSSInternal` class as needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900843857 From angorya at openjdk.org Fri Jan 19 17:56:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 17:56:36 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 17:52:31 GMT, Jose Pereda wrote: > Scene Builder releases are always tight to the JavaFX version Thank you for clarification! Still, there might be other tools out there that we don't know of. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900846051 From kcr at openjdk.org Fri Jan 19 18:08:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 18:08:38 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 10:21:05 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since tags Hmm. This suggests taking a step back. I think there are only two choices that make sense (there are a couple others, but I don't think they are useful). 1. Abandon the notion of making an incompatible change to `SimpleSelector` and `CompoundSelector`. This means that PR #1316 will need to preserve the existing `SimpleSelector` method `List getStyleClasses()` and `Set getStyleClassSet()`, deprecating them with simple deprecation (not for removal). 2. Make an incompatible change, meaning that at some point, the existing SceneBuilder binaries will break. We could make the transition a little less painful by providing replacement API in a release that still has the existing API (in fact, I think if we go with this option, then we _must_ do that), but the fact remains that there will then be no way to have a single binary that runs on JavaFX 21 and JavaFX 23 short of a multi-release jar file, which really isn't a good solution for this sort of problem. Preserving the existing `SimpleSelector` methods is fairly easy and already done. So, is there any real drawback to doing this? I can't think of any. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900861894 From kcr at openjdk.org Fri Jan 19 18:14:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 18:14:43 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 10:21:05 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since tags I note that we could still consider deprecating the `SimpleSelector` and `CompoundSelector` classes for _eventual_ removal, but it wouldn't have to be done in such a rush. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900873687 From angorya at openjdk.org Fri Jan 19 18:19:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 18:19:42 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: <2Mlasn9_ff42SgxIx5abueAiTAuF1K2yRWICVnNZ-h8=.81901fee-29d4-49eb-8bc8-5c6f326c6d65@github.com> On Fri, 19 Jan 2024 18:12:26 GMT, Kevin Rushforth wrote: > I note that we could still consider deprecating the `SimpleSelector` and `CompoundSelector` classes for _eventual_ removal I like the idea of deprecating with the following removal, coupled with adding the "missing" APIs to Selector. I think the lack of this method in the base class was an unfortunate oversight, and we should fix that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900883755 From jhendrikx at openjdk.org Fri Jan 19 19:01:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 19:01:40 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 10:21:05 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since tags > Hmm. This suggests taking a step back. I think there are only two choices that make sense (there are a couple others, but I don't think they are useful). > > 1. Abandon the notion of making an incompatible change to `SimpleSelector` and `CompoundSelector`. This means that PR [JDK-8322964 Optimize performance of CSS selector matching?#1316](https://github.com/openjdk/jfx/pull/1316) will need to preserve the existing `SimpleSelector` method `List getStyleClasses()` and `Set getStyleClassSet()`, deprecating them with simple deprecation (not for removal). > 2. Make an incompatible change, meaning that at some point, the existing SceneBuilder binaries will break. We could make the transition a little less painful by providing replacement API in a release that still has the existing API (in fact, I think if we go with this option, then we _must_ do that), but the fact remains that there will then be no way to have a single binary that runs on JavaFX 21 and JavaFX 23 short of a multi-release jar file, which really isn't a good solution for this sort of problem. > > Preserving the existing `SimpleSelector` methods is fairly easy and already done. So, is there any real drawback to doing this? I can't think of any. Does the comment from Jos? Pereda here https://github.com/openjdk/jfx/pull/1340#issuecomment-1900843857 make any difference in that regard? If scene builder is always tied to a specific FX release, then I would think we could still go ahead. The drawback might be that more code may start relying on these classes, or that it will be harder to evolve the CSS API if more than just Simple/CompoundSelector are needed at some point. The API still seems to have been designed with the idea that `Selector` is the only public class. I think regardless adding a public API to get the style classes is a good idea, it seems to round out the API a bit, and it would make Scene Builder less dependent on what we consider internals in the future. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900949541 From jhendrikx at openjdk.org Fri Jan 19 19:05:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 19:05:38 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 18:12:26 GMT, Kevin Rushforth wrote: > I note that we could still consider deprecating the `SimpleSelector` and `CompoundSelector` classes for _eventual_ removal, but it wouldn't have to be done in such a rush. That's certainly true, the only reason we wanted to do a quick deprecation is to avoid adding a new public method to `SimpleSelector` for the performance improvement PR. However, I think everyone will be able to live with adding such a method for now if that method will eventually become part of a non-exported package. Still would have almost 6 months to make up our minds about that if we'd really want to move those classes in FX 23 or not. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1900953169 From jhendrikx at openjdk.org Fri Jan 19 19:10:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 19:10:38 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <9ME4qfZCZlZYxfiHuMUakOp_t6oNxEU06iABzR-qkyM=.62554bcc-b57c-4fec-9598-aec7c634fbed@github.com> On Fri, 19 Jan 2024 17:54:17 GMT, Andy Goryachev wrote: > > Scene Builder releases are always tight to the JavaFX version > > Thank you for clarification! Still, there might be other tools out there that we don't know of. That's always possible. I couldn't find anything with an internet search, but closed source tools will not be found. I missed Scene Builder, but only because I dismissed it too quickly since it had `com.oracle.*` packages and thought it was part of FX. I can't find anything else. These classes are not accepted as parameters anywhere, or returned as types anywhere, nor can they be constructed by 3rd parties. The only way to get at their methods is with an explicit cast, like Scene Builder does. At a minimum we need to warn people not to use these. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1900961159 From kevin.rushforth at oracle.com Fri Jan 19 19:32:40 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Jan 2024 11:32:40 -0800 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: Message-ID: <4122a755-99d4-482c-b6c3-1f6fb6394c8f@oracle.com> Hi Jurgen, There is a very short window for making any changes like this that require a CSR in JavaFX 22. If we were to do what you suggest, we would need to: 1. File a new Enhancement request to: -- revert JDK-8159048 (except for the doc changes about Animation being run on the FX application thread, which is correct and useful even after the revert) -- update the documentation to indicate that the?play/pause/stop methods may be called on any thread -- fix the implementation to wrap the implementation of play/pause/stop in Platform.runLater, if not on the FX app thread -- we may or may not also want to make the additional fix you suggest in?AbstractPrimaryTimer, but this might not be needed if we wrap the call in a runLater, which I think should be done anyway 2. File a CSR? for the spec changes for the above All of this would need to be agreed upon and proposed within the next few days to allow time for the CSR to be considered and approved while we are still in RDP1. I would not consider such a change once we hit RDP2 on Feb 1. Before even considering this, I'd like to hear from Johan Vos, Jose Pereda (who implemented JDK-8159048), Nir Lisker (who has done a lot of work on animation), and Michael Strau? (who has proposed in JDK-8324219 to update the documentation to remove the reference to the fact that stop is asynchronous), and any others who might have an interest. Note that if we go down the route of reverting JDK-8159048, then we will close JDK-8324219 as "not an issue". If there is general agreement, then it would seem reasonable to shoot for JavaFX 22. I note that it would be a low- risk change -- basically going back to the behavior we have in JavaFX 21, which is the latest GA release. -- Kevin On 1/19/2024 4:06 AM, Jurgen Doll wrote: > Hi Kevin > > I was hoping that others would way in on this fix (PR #1167), but now > that we're in RDP1 with no other input coming in I decided to looked > into this matter again and have found that this is not the correct > solution for the following two reasons: > > 1. The current solution doesn't actually fix the bug, but merely > avoids it: > > Specifically with regards to bug JDK-8159048 which reports a NPE > occuring under some conditions in AbstractMasterTimer (subsequently > renamed to AbstractPrimaryTimer). The reporter suggests that this is > as a result of some concurrent modification occurring and suggests a > workaround of wrapping the start/stop animation code in a > Platform.runLater() call. > > Looking at the AbstractPrimaryTimer code it is apparent that the > original author made an effort to isolate array modifications from? > array access. However this code has a bug in it which then manifests > as a NPE under the right timing conditions. So the correct solution is > to make the array modification code more robust, as apposed to forcing > changes to occur on a single thread. > > The safest (and proper) solution is to convert the two arrays > ("receivers" and "animationTimers") to be CopyOnWriteArrayList(s) > which is an ideal JDK data structure for this use case as it > replicates the intended behavior of the current implementation. (I've > tried this out and it does solve the NPE problem.) > > 2. The current solution is based on the misconception that start, > stop, and pause must occur on the FX thread: > > Specifically with regards to the CSR JDK-8313378 which makes this claim. > > Firstly the Animation API says explicitly that these methods are > asynchronous, which means that the thread that invokes these methods > and the actual execution of the animation occurs on different threads, > and looking at AbstractPrimaryTimer code it can be seen that this is > indeed the case. > > Secondly JavaFX had tests, as noted in JDK-8314266, that have run > reliably for years without invoking these methods on the FX thread. > FWIW I've also had code and used libraries for years now, where these > methods have been invoked on a background thread (for example while > loading FXML) without issue. > > > In conclusion then I request permission to submit a new PR containing > the following changes: > > 1. Revert PR #1167 (if this is the appropriate place, however the test > case will require it) > 2. Changing the arrays in AbstractPrimaryTimer to be > CopyOnWriteArrayList(s) and removing previously supporting array code. > 3. Adding a test based on the one supplied in JDK-8159048 to check > that a NPE isn't thrown anymore. > > Hope this meets with your approval. > Regards, > Jurgen > > >> ? On 8/18/2023 4:17 PM, Kevin Rushforth wrote: >> As a heads-up for app developers who use JavaFX animation (including >> Animation, along with any subclasses, and AnimationTimer), a change >> went into the JavaFX 22+5 build to enforce that the play, pause, and >> stop methods must be called on the JavaFX Application thread. >> Applications should have been doing that all along (else they would >> have been subject to unpredictable errors), but for those who aren't >> sure, you might want to take 22+5 for a spin and see if you have any >> problems with your application. Please report them on the list if you >> do. >> >> See JDK-8159048 [1] and CSR JDK-8313378 [2] for more information on >> this change. >> >> Thanks. >> >> -- Kevin >> >> [1] https://bugs.openjdk.org/browse/JDK-8159048 >> [2] https://bugs.openjdk.org/browse/JDK-8313378 From kcr at openjdk.org Fri Jan 19 19:57:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jan 2024 19:57:37 GMT Subject: RFR: 8324219: Remove incorrect documentation from Animation methods In-Reply-To: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> References: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> Message-ID: On Fri, 19 Jan 2024 16:07:31 GMT, Michael Strau? wrote: > The `Animation` class states in the documentation of various methods that the method call would be asynchronous, using language similar to: > > > {@code stop()} is an asynchronous call, the {@code Animation} may not stop immediately. > > > This is factually wrong, there are no asynchronous calls. In fact, the methods in question can only be called synchronously on the JavaFX Application thread, and the state of the animation is changed immediately. For example, when `stop()` is called, the animation transitions to the stopped state instantly, without waiting for the next animation pulse. We need to resolve [this mailing list discussion thread](https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044734.html) before deciding whether to proceed with this or not. If we keep the change to require animation to be done on the JavaFX application thread (meaning we reject the proposal put forward in that mailing list thread), then I agree that this doc change should be done, and backported to JavaFX 22. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1342#issuecomment-1901022687 From mhanl at openjdk.org Fri Jan 19 20:19:36 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 19 Jan 2024 20:19:36 GMT Subject: [jfx22] Integrated: 8323543: NPE when table items are set to null In-Reply-To: References: Message-ID: <5X31sZfrfh0f9QRCx4o2S8hlqt8tpc3ByIwC1T3snZA=.ef3f4fcf-bac7-489b-8c98-ffc1e7a1a51f@github.com> On Fri, 19 Jan 2024 12:47:29 GMT, Marius Hanl wrote: > This pull request contains a (clean) backport of commit [872dbc8a](https://github.com/openjdk/jfx/commit/872dbc8a2d254cba4df33fcc778b15b1a3c9b69f) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > Target branch is **jfx22**. This pull request has now been integrated. Changeset: 9587f51e Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/9587f51e97200d886721ea0ea960a694201e6317 Stats: 60 lines in 5 files changed: 47 ins; 11 del; 2 mod 8323543: NPE when table items are set to null Reviewed-by: kcr Backport-of: 872dbc8a2d254cba4df33fcc778b15b1a3c9b69f ------------- PR: https://git.openjdk.org/jfx/pull/1341 From mhanl at openjdk.org Fri Jan 19 20:29:43 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 19 Jan 2024 20:29:43 GMT Subject: RFR: JDK-8323543: NPE when table items are set to null [v6] In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 16:06:42 GMT, Carl D?bbelin wrote: >> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables items were null. > > Carl D?bbelin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8323543: change tests to JUnit4 for compatibility > Yeah, and it's somewhat confusing to have jfx22u ..., but we need it to backport the WebKit update (which we explicitly do not want in JavaFX 22 GA, but in 22.0.1). Thanks for the clarification! I totally forgot/missed that we have a branch for every GA release in this repository, while every backport after is done in the jfx..u repository. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1901065972 From michaelstrau2 at gmail.com Fri Jan 19 21:52:51 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 19 Jan 2024 22:52:51 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: Message-ID: Hi Jurgen, the start, stop, pause, etc. methods on the Animation class cannot reasonably work in the way you suggest. While it is generally possible to construct a JavaFX object graph on a thread other than the JavaFX application thread, this relies on the fact that JavaFX will not interfere with your newly constructed object graph unless you attach it to a scene. An object graph is fundamentally single-threaded, which means that if you don't provide external synchronization, you're going to have undefined behavior under concurrent access. But that's exactly what would happen if we were to allow calling animation methods on a background thread. Wrapping the call in Platform.runLater doesn't help, because as soon as the animation call is dispatched to the FX thread, the animation can affect your scene graph in all sorts of unpredictable ways. Every attempt to access or modify a node after calling an animation method is an access under potential race, and you can't provide any external synchronization to make the FX thread wait until you're finished doing whatever needs to be done on the background thread. The fact that this sometimes seems to work when concurrent modifications of the node are truly orthogonal in their effects doesn't mean that it can work in general, and there's no way we can make it work in general. There isn't even a known set of preconditions where we are sure that concurrent modifications are okay, so we can't include documentation to that effect. Since we can't make it work in general, and we can't know the preconditions that may allow it to work in some cases, I think the best course of action is to disallow this dangerous and unpredictable use of this API entirely. On Fri, Jan 19, 2024 at 1:06?PM Jurgen Doll wrote: > > Hi Kevin > > I was hoping that others would way in on this fix (PR #1167), but now that > we're in RDP1 with no other input coming in I decided to looked into this > matter again and have found that this is not the correct solution for the > following two reasons: > > 1. The current solution doesn't actually fix the bug, but merely avoids it: > > Specifically with regards to bug JDK-8159048 which reports a NPE occuring > under some conditions in AbstractMasterTimer (subsequently renamed to > AbstractPrimaryTimer). The reporter suggests that this is as a result of > some concurrent modification occurring and suggests a workaround of > wrapping the start/stop animation code in a Platform.runLater() call. > > Looking at the AbstractPrimaryTimer code it is apparent that the original > author made an effort to isolate array modifications from array access. > However this code has a bug in it which then manifests as a NPE under the > right timing conditions. So the correct solution is to make the array > modification code more robust, as apposed to forcing changes to occur on a > single thread. > > The safest (and proper) solution is to convert the two arrays ("receivers" > and "animationTimers") to be CopyOnWriteArrayList(s) which is an ideal JDK > data structure for this use case as it replicates the intended behavior of > the current implementation. (I've tried this out and it does solve the NPE > problem.) > > 2. The current solution is based on the misconception that start, stop, > and pause must occur on the FX thread: > > Specifically with regards to the CSR JDK-8313378 which makes this claim. > > Firstly the Animation API says explicitly that these methods are > asynchronous, which means that the thread that invokes these methods and > the actual execution of the animation occurs on different threads, and > looking at AbstractPrimaryTimer code it can be seen that this is indeed > the case. > > Secondly JavaFX had tests, as noted in JDK-8314266, that have run reliably > for years without invoking these methods on the FX thread. FWIW I've also > had code and used libraries for years now, where these methods have been > invoked on a background thread (for example while loading FXML) without > issue. > > > In conclusion then I request permission to submit a new PR containing the > following changes: > > 1. Revert PR #1167 (if this is the appropriate place, however the test > case will require it) > 2. Changing the arrays in AbstractPrimaryTimer to be > CopyOnWriteArrayList(s) and removing previously supporting array code. > 3. Adding a test based on the one supplied in JDK-8159048 to check that a > NPE isn't thrown anymore. > > Hope this meets with your approval. > Regards, > Jurgen > From nlisker at openjdk.org Fri Jan 19 21:56:47 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 19 Jan 2024 21:56:47 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <2n1dDIjPXMVfNItgZIG1PGt5WYxgWhAFgeSUG9Vc3pI=.5a3ad949-1f62-4eae-b6b7-21a235733244@github.com> On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since parameter to deprecation annotation Maybe *Scenic View*, as it does a lot of introspecting? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1901167039 From jhendrikx at openjdk.org Fri Jan 19 21:56:48 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 19 Jan 2024 21:56:48 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since parameter to deprecation annotation > Maybe _Scenic View_, as it does a lot of introspecting? I just checked, no mention of `Selector` or `SimpleSelector` or `CompoundSelector` :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1901169843 From nlisker at gmail.com Fri Jan 19 22:06:16 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 20 Jan 2024 00:06:16 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: <4122a755-99d4-482c-b6c3-1f6fb6394c8f@oracle.com> References: <4122a755-99d4-482c-b6c3-1f6fb6394c8f@oracle.com> Message-ID: I will look at this tomorrow due to the short time window. Haven't kept up with this thread. On Fri, Jan 19, 2024 at 10:34?PM Kevin Rushforth wrote: > Hi Jurgen, > > There is a very short window for making any changes like this that > require a CSR in JavaFX 22. If we were to do what you suggest, we would > need to: > > 1. File a new Enhancement request to: > -- revert JDK-8159048 (except for the doc changes about Animation being > run on the FX application thread, which is correct and useful even after > the revert) > -- update the documentation to indicate that the play/pause/stop methods > may be called on any thread > -- fix the implementation to wrap the implementation of play/pause/stop > in Platform.runLater, if not on the FX app thread > -- we may or may not also want to make the additional fix you suggest > in AbstractPrimaryTimer, but this might not be needed if we wrap the > call in a runLater, which I think should be done anyway > > 2. File a CSR for the spec changes for the above > > All of this would need to be agreed upon and proposed within the next > few days to allow time for the CSR to be considered and approved while > we are still in RDP1. I would not consider such a change once we hit > RDP2 on Feb 1. > > Before even considering this, I'd like to hear from Johan Vos, Jose > Pereda (who implemented JDK-8159048), Nir Lisker (who has done a lot of > work on animation), and Michael Strau? (who has proposed in JDK-8324219 > to update the documentation to remove the reference to the fact that > stop is asynchronous), and any others who might have an interest. Note > that if we go down the route of reverting JDK-8159048, then we will > close JDK-8324219 as "not an issue". > > If there is general agreement, then it would seem reasonable to shoot > for JavaFX 22. I note that it would be a low- risk change -- basically > going back to the behavior we have in JavaFX 21, which is the latest GA > release. > > -- Kevin > > > On 1/19/2024 4:06 AM, Jurgen Doll wrote: > > Hi Kevin > > > > I was hoping that others would way in on this fix (PR #1167), but now > > that we're in RDP1 with no other input coming in I decided to looked > > into this matter again and have found that this is not the correct > > solution for the following two reasons: > > > > 1. The current solution doesn't actually fix the bug, but merely > > avoids it: > > > > Specifically with regards to bug JDK-8159048 which reports a NPE > > occuring under some conditions in AbstractMasterTimer (subsequently > > renamed to AbstractPrimaryTimer). The reporter suggests that this is > > as a result of some concurrent modification occurring and suggests a > > workaround of wrapping the start/stop animation code in a > > Platform.runLater() call. > > > > Looking at the AbstractPrimaryTimer code it is apparent that the > > original author made an effort to isolate array modifications from > > array access. However this code has a bug in it which then manifests > > as a NPE under the right timing conditions. So the correct solution is > > to make the array modification code more robust, as apposed to forcing > > changes to occur on a single thread. > > > > The safest (and proper) solution is to convert the two arrays > > ("receivers" and "animationTimers") to be CopyOnWriteArrayList(s) > > which is an ideal JDK data structure for this use case as it > > replicates the intended behavior of the current implementation. (I've > > tried this out and it does solve the NPE problem.) > > > > 2. The current solution is based on the misconception that start, > > stop, and pause must occur on the FX thread: > > > > Specifically with regards to the CSR JDK-8313378 which makes this claim. > > > > Firstly the Animation API says explicitly that these methods are > > asynchronous, which means that the thread that invokes these methods > > and the actual execution of the animation occurs on different threads, > > and looking at AbstractPrimaryTimer code it can be seen that this is > > indeed the case. > > > > Secondly JavaFX had tests, as noted in JDK-8314266, that have run > > reliably for years without invoking these methods on the FX thread. > > FWIW I've also had code and used libraries for years now, where these > > methods have been invoked on a background thread (for example while > > loading FXML) without issue. > > > > > > In conclusion then I request permission to submit a new PR containing > > the following changes: > > > > 1. Revert PR #1167 (if this is the appropriate place, however the test > > case will require it) > > 2. Changing the arrays in AbstractPrimaryTimer to be > > CopyOnWriteArrayList(s) and removing previously supporting array code. > > 3. Adding a test based on the one supplied in JDK-8159048 to check > > that a NPE isn't thrown anymore. > > > > Hope this meets with your approval. > > Regards, > > Jurgen > > > > > >> On 8/18/2023 4:17 PM, Kevin Rushforth wrote: > >> As a heads-up for app developers who use JavaFX animation (including > >> Animation, along with any subclasses, and AnimationTimer), a change > >> went into the JavaFX 22+5 build to enforce that the play, pause, and > >> stop methods must be called on the JavaFX Application thread. > >> Applications should have been doing that all along (else they would > >> have been subject to unpredictable errors), but for those who aren't > >> sure, you might want to take 22+5 for a spin and see if you have any > >> problems with your application. Please report them on the list if you > >> do. > >> > >> See JDK-8159048 [1] and CSR JDK-8313378 [2] for more information on > >> this change. > >> > >> Thanks. > >> > >> -- Kevin > >> > >> [1] https://bugs.openjdk.org/browse/JDK-8159048 > >> [2] https://bugs.openjdk.org/browse/JDK-8313378 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Jan 19 22:07:40 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Jan 2024 14:07:40 -0800 Subject: JBS bugs moved to jfx23 Message-ID: <0e87bf89-5454-4114-8f46-a884a5c19895@oracle.com> There are several issues (bugs and enhancements) still targeted to jfx22 in JBS. Given that we are in rampdown for JavaFX 22, and that fixes first go into the master branch for jfx23, I will bulk moved all of them to jfx23 shortly. Once they are fixed and integrated into master for jfx23, they might be candidates to backport to jfx22 depending on the policies for the then-current rampdown phase. In that case, Skara will create a jfx22 backport so there is generally no need to do anything ahead of time. -- Kevin From kevin.rushforth at oracle.com Fri Jan 19 22:10:03 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Jan 2024 14:10:03 -0800 Subject: [External] : Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: <4122a755-99d4-482c-b6c3-1f6fb6394c8f@oracle.com> Message-ID: <5509ceec-95fb-4a60-be0e-18b7dce52b11@oracle.com> Thanks, Nir. I see that Michael replied to this thread a short time ago with a pretty convincing argument for letting the change make in JDK-8159048 stand. -- Kevin On 1/19/2024 2:06 PM, Nir Lisker wrote: > I will look at this tomorrow due to the short time window. Haven't > kept up with this thread. > > On Fri, Jan 19, 2024 at 10:34?PM Kevin Rushforth > wrote: > > Hi Jurgen, > > There is a very short window for making any changes like this that > require a CSR in JavaFX 22. If we were to do what you suggest, we > would > need to: > > 1. File a new Enhancement request to: > -- revert JDK-8159048 (except for the doc changes about Animation > being > run on the FX application thread, which is correct and useful even > after > the revert) > -- update the documentation to indicate that the?play/pause/stop > methods > may be called on any thread > -- fix the implementation to wrap the implementation of > play/pause/stop > in Platform.runLater, if not on the FX app thread > -- we may or may not also want to make the additional fix you suggest > in?AbstractPrimaryTimer, but this might not be needed if we wrap the > call in a runLater, which I think should be done anyway > > 2. File a CSR? for the spec changes for the above > > All of this would need to be agreed upon and proposed within the next > few days to allow time for the CSR to be considered and approved > while > we are still in RDP1. I would not consider such a change once we hit > RDP2 on Feb 1. > > Before even considering this, I'd like to hear from Johan Vos, Jose > Pereda (who implemented JDK-8159048), Nir Lisker (who has done a > lot of > work on animation), and Michael Strau? (who has proposed in > JDK-8324219 > to update the documentation to remove the reference to the fact that > stop is asynchronous), and any others who might have an interest. > Note > that if we go down the route of reverting JDK-8159048, then we will > close JDK-8324219 as "not an issue". > > If there is general agreement, then it would seem reasonable to shoot > for JavaFX 22. I note that it would be a low- risk change -- > basically > going back to the behavior we have in JavaFX 21, which is the > latest GA > release. > > -- Kevin > > > On 1/19/2024 4:06 AM, Jurgen Doll wrote: > > Hi Kevin > > > > I was hoping that others would way in on this fix (PR #1167), > but now > > that we're in RDP1 with no other input coming in I decided to > looked > > into this matter again and have found that this is not the correct > > solution for the following two reasons: > > > > 1. The current solution doesn't actually fix the bug, but merely > > avoids it: > > > > Specifically with regards to bug JDK-8159048 which reports a NPE > > occuring under some conditions in AbstractMasterTimer (subsequently > > renamed to AbstractPrimaryTimer). The reporter suggests that > this is > > as a result of some concurrent modification occurring and > suggests a > > workaround of wrapping the start/stop animation code in a > > Platform.runLater() call. > > > > Looking at the AbstractPrimaryTimer code it is apparent that the > > original author made an effort to isolate array modifications from > > array access. However this code has a bug in it which then > manifests > > as a NPE under the right timing conditions. So the correct > solution is > > to make the array modification code more robust, as apposed to > forcing > > changes to occur on a single thread. > > > > The safest (and proper) solution is to convert the two arrays > > ("receivers" and "animationTimers") to be CopyOnWriteArrayList(s) > > which is an ideal JDK data structure for this use case as it > > replicates the intended behavior of the current implementation. > (I've > > tried this out and it does solve the NPE problem.) > > > > 2. The current solution is based on the misconception that start, > > stop, and pause must occur on the FX thread: > > > > Specifically with regards to the CSR JDK-8313378 which makes > this claim. > > > > Firstly the Animation API says explicitly that these methods are > > asynchronous, which means that the thread that invokes these > methods > > and the actual execution of the animation occurs on different > threads, > > and looking at AbstractPrimaryTimer code it can be seen that > this is > > indeed the case. > > > > Secondly JavaFX had tests, as noted in JDK-8314266, that have run > > reliably for years without invoking these methods on the FX thread. > > FWIW I've also had code and used libraries for years now, where > these > > methods have been invoked on a background thread (for example while > > loading FXML) without issue. > > > > > > In conclusion then I request permission to submit a new PR > containing > > the following changes: > > > > 1. Revert PR #1167 (if this is the appropriate place, however > the test > > case will require it) > > 2. Changing the arrays in AbstractPrimaryTimer to be > > CopyOnWriteArrayList(s) and removing previously supporting array > code. > > 3. Adding a test based on the one supplied in JDK-8159048 to check > > that a NPE isn't thrown anymore. > > > > Hope this meets with your approval. > > Regards, > > Jurgen > > > > > >> ? On 8/18/2023 4:17 PM, Kevin Rushforth wrote: > >> As a heads-up for app developers who use JavaFX animation > (including > >> Animation, along with any subclasses, and AnimationTimer), a > change > >> went into the JavaFX 22+5 build to enforce that the play, > pause, and > >> stop methods must be called on the JavaFX Application thread. > >> Applications should have been doing that all along (else they > would > >> have been subject to unpredictable errors), but for those who > aren't > >> sure, you might want to take 22+5 for a spin and see if you > have any > >> problems with your application. Please report them on the list > if you > >> do. > >> > >> See JDK-8159048 [1] and CSR JDK-8313378 [2] for more > information on > >> this change. > >> > >> Thanks. > >> > >> -- Kevin > >> > >> [1] https://bugs.openjdk.org/browse/JDK-8159048 > >> [2] https://bugs.openjdk.org/browse/JDK-8313378 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jan 19 23:00:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 23:00:43 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Switched to local array variables modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 125: > 123: @Override > 124: public AttributedCharacterIterator getSelectedText(AttributedCharacterIterator.Attribute[] attributes) { > 125: String[] selected = { null }; Would AtomicReference be a better choice here? modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 132: > 130: } > 131: if (selected[0] == null) selected[0] = ""; > 132: return new AttributedString(selected[0]).getIterator(); AtomicReference ref = ... ... String s = ref.get(); return new AttributedString(s == null ? "" : s).getIterator(); here and L102? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1459911995 PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1459916837 From angorya at openjdk.org Fri Jan 19 23:05:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 23:05:38 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: Message-ID: <2preUPo2EQAnaHyBTmuXTt4pvwfi3HkSX9FHEuqHXnU=.c67d4984-a1a1-492b-9268-149f5dc28e21@github.com> On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Switched to local array variables Noticed a (possibly unrelated) problem - Upon first launch , the IME window appears in the bottom right corner instead of near the text field. Dismiss, type - the windows appears where it's supposed to be: Screenshot 2024-01-19 145505 the fix seems to work on window 11 (with one abovementioned problem). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1901265779 PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1901267645 From angorya at openjdk.org Fri Jan 19 23:42:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jan 2024 23:42:35 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: Message-ID: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Switched to local array variables I think this code crashes on macOS with Arabic input... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1901304232 From kcr at openjdk.org Sat Jan 20 00:07:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 20 Jan 2024 00:07:39 GMT Subject: RFR: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:13:09 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin when it is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install listener but is then rejected when setting it due to the `skinProperty` class constraint > -> `PopupControl` is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomSkin extends Skin { > public MyCustomSkin(C skinnable, boolean someFlag) { ... } > } > > Now if we would change the skin of the `PopupControl` two times like this: > > popup.setSkin(new MyCustomSkin(popup, true)); > popup.setSkin(new MyCustomSkin(popup, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. > > This is the same issue and fix as done for `Control` in [JDK-8276056](https://bugs.openjdk.org/browse/JDK-8276056) (PR: https://github.com/openjdk/jfx/pull/806) @arapte Can you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1331#issuecomment-1901365098 From mfox at openjdk.org Sat Jan 20 01:11:38 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 20 Jan 2024 01:11:38 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> References: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> Message-ID: <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> On Fri, 19 Jan 2024 23:39:59 GMT, Andy Goryachev wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Switched to local array variables > > I think this code crashes on macOS with Arabic input... > > correction: not crashes, but throws an NPE, see https://bugs.openjdk.org/browse/JDK-8324232 @andy-goryachev-oracle I can reproduce the misplaced input window problem on Win 11. I added some println statements and verified that JavaFX is returning correct coordinates. My guess is that this is an OS issue though there's the small chance that the problem is in Swing. I'll update JDK-8324232 with some notes. As you've figured out it's an existing problem that predates this PR. > modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 132: > >> 130: } >> 131: if (selected[0] == null) selected[0] = ""; >> 132: return new AttributedString(selected[0]).getIterator(); > > AtomicReference ref = ... > ... > String s = ref.get(); > return new AttributedString(s == null ? "" : s).getIterator(); > > > here and L102? I'm not familiar enough with AtomicReference to have an opinion on this. Someone else will have to weigh in on this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1901527510 PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1460108537 From cto.abidmaqbool at gmail.com Sat Jan 20 06:17:08 2024 From: cto.abidmaqbool at gmail.com (Abid Maqbool) Date: Sat, 20 Jan 2024 11:17:08 +0500 Subject: Hi! All devs, I am CTO Abid Maqbool from Maqbool Solutions (SMC-Pvt) Ltd. and IT Company and Computer Software House! Can anyone help me to solve my problem? Message-ID: Hi! Devs it's my first message at openjfx-dev at openjdk.org. I am using the jfoenix material design library in my projects. It's a very nice and best library in Javafx. But unfortunately it's official support has stopped for years. Official git repo: https://github.com/sshahine/JFoenix/tree/JFoenix-9.0.0 Other best fork]: https://github.com/ihmcrobotics/JFoenix-Group Other best fork: https://github.com/RationalityFrontline/JFoenix/tree/JFoenix-17.0.0 I have some projects which are much dependent upon the jfoenix library, Currently other libraries e.g. MaterialsFX, controlsFX etc can't complete my needs. So I have decided to do self development upon the jfoenix library on my PC. --- Jfoenix library fork of RationalityFrontline can be successfully compiled and run with jdk 17 and javafx 17 latest available yet. But I have some issues! Let's see here! https://github.com/sshahine/JFoenix/issues/1266 Another question, which is the best and quick way to get support on development side issues on Java / Javafx / related libs??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Jan 20 14:13:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 20 Jan 2024 14:13:43 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Switched to local array variables The latest code changes look good to me. I'll do some additional testing, and I'm sure Andy plans to do the same. ------------- PR Review: https://git.openjdk.org/jfx/pull/1337#pullrequestreview-1834680336 From kcr at openjdk.org Sat Jan 20 14:13:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 20 Jan 2024 14:13:44 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> References: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> Message-ID: On Sat, 20 Jan 2024 01:08:23 GMT, Martin Fox wrote: >> modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 132: >> >>> 130: } >>> 131: if (selected[0] == null) selected[0] = ""; >>> 132: return new AttributedString(selected[0]).getIterator(); >> >> AtomicReference ref = ... >> ... >> String s = ref.get(); >> return new AttributedString(s == null ? "" : s).getIterator(); >> >> >> here and L102? > > I'm not familiar enough with AtomicReference to have an opinion on this. Someone else will have to weigh in on this. Either an array or an AtomicReference is OK in this case. AtomicReference is thread-safe, but that's not a concern here, since using `runAndWait` ensures that writing to the array happens before reading it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1460459091 From kcr at openjdk.org Sat Jan 20 14:56:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 20 Jan 2024 14:56:43 GMT Subject: RFR: 8324237: Typo in comment in GlassApplication.m Message-ID: Simple fix of a typo in a code comment. ------------- Commit messages: - 8324237: Typo in comment in GlassApplication.m Changes: https://git.openjdk.org/jfx/pull/1343/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1343&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324237 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1343.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1343/head:pull/1343 PR: https://git.openjdk.org/jfx/pull/1343 From nlisker at gmail.com Sat Jan 20 15:08:41 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 20 Jan 2024 17:08:41 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: Message-ID: Hi Jurgen, What I'm confused about the most is what it is you are actually trying to do that necessitates the use of animations outside of the FX thread. You said that you need to initialize controls on another thread, and that you are using Task (both of which are fine), but how does playing animations relate? Playing an animation is something that is done explicitly, usually in order to manipulate data. Can you give a real use case, like a minimized version of what you're doing? - Nir On Sat, Jan 20, 2024 at 2:42?AM Michael Strau? wrote: > Hi Jurgen, > > the start, stop, pause, etc. methods on the Animation class cannot > reasonably work in the way you suggest. > > While it is generally possible to construct a JavaFX object graph on a > thread other than the JavaFX application thread, this relies on the > fact that JavaFX will not interfere with your newly constructed object > graph unless you attach it to a scene. An object graph is > fundamentally single-threaded, which means that if you don't provide > external synchronization, you're going to have undefined behavior > under concurrent access. > > But that's exactly what would happen if we were to allow calling > animation methods on a background thread. Wrapping the call in > Platform.runLater doesn't help, because as soon as the animation call > is dispatched to the FX thread, the animation can affect your scene > graph in all sorts of unpredictable ways. Every attempt to access or > modify a node after calling an animation method is an access under > potential race, and you can't provide any external synchronization to > make the FX thread wait until you're finished doing whatever needs to > be done on the background thread. > > The fact that this sometimes seems to work when concurrent > modifications of the node are truly orthogonal in their effects > doesn't mean that it can work in general, and there's no way we can > make it work in general. > There isn't even a known set of preconditions where we are sure that > concurrent modifications are okay, so we can't include documentation > to that effect. > > Since we can't make it work in general, and we can't know the > preconditions that may allow it to work in some cases, I think the > best course of action is to disallow this dangerous and unpredictable > use of this API entirely. > > > > On Fri, Jan 19, 2024 at 1:06?PM Jurgen Doll wrote: > > > > Hi Kevin > > > > I was hoping that others would way in on this fix (PR #1167), but now > that > > we're in RDP1 with no other input coming in I decided to looked into this > > matter again and have found that this is not the correct solution for the > > following two reasons: > > > > 1. The current solution doesn't actually fix the bug, but merely avoids > it: > > > > Specifically with regards to bug JDK-8159048 which reports a NPE occuring > > under some conditions in AbstractMasterTimer (subsequently renamed to > > AbstractPrimaryTimer). The reporter suggests that this is as a result of > > some concurrent modification occurring and suggests a workaround of > > wrapping the start/stop animation code in a Platform.runLater() call. > > > > Looking at the AbstractPrimaryTimer code it is apparent that the original > > author made an effort to isolate array modifications from array access. > > However this code has a bug in it which then manifests as a NPE under the > > right timing conditions. So the correct solution is to make the array > > modification code more robust, as apposed to forcing changes to occur on > a > > single thread. > > > > The safest (and proper) solution is to convert the two arrays > ("receivers" > > and "animationTimers") to be CopyOnWriteArrayList(s) which is an ideal > JDK > > data structure for this use case as it replicates the intended behavior > of > > the current implementation. (I've tried this out and it does solve the > NPE > > problem.) > > > > 2. The current solution is based on the misconception that start, stop, > > and pause must occur on the FX thread: > > > > Specifically with regards to the CSR JDK-8313378 which makes this claim. > > > > Firstly the Animation API says explicitly that these methods are > > asynchronous, which means that the thread that invokes these methods and > > the actual execution of the animation occurs on different threads, and > > looking at AbstractPrimaryTimer code it can be seen that this is indeed > > the case. > > > > Secondly JavaFX had tests, as noted in JDK-8314266, that have run > reliably > > for years without invoking these methods on the FX thread. FWIW I've also > > had code and used libraries for years now, where these methods have been > > invoked on a background thread (for example while loading FXML) without > > issue. > > > > > > In conclusion then I request permission to submit a new PR containing the > > following changes: > > > > 1. Revert PR #1167 (if this is the appropriate place, however the test > > case will require it) > > 2. Changing the arrays in AbstractPrimaryTimer to be > > CopyOnWriteArrayList(s) and removing previously supporting array code. > > 3. Adding a test based on the one supplied in JDK-8159048 to check that a > > NPE isn't thrown anymore. > > > > Hope this meets with your approval. > > Regards, > > Jurgen > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Sat Jan 20 20:20:36 2024 From: jvos at openjdk.org (Johan Vos) Date: Sat, 20 Jan 2024 20:20:36 GMT Subject: RFR: 8324237: Typo in comment in GlassApplication.m In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 14:52:19 GMT, Kevin Rushforth wrote: > Simple fix of a typo in a code comment. Trivial but important fix (it is correct in line 72). Great to improve in-code doc quality. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1343#pullrequestreview-1834727071 From jvos at openjdk.org Sat Jan 20 20:34:50 2024 From: jvos at openjdk.org (Johan Vos) Date: Sat, 20 Jan 2024 20:34:50 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v9] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add additional test for IOOBE detection. This test comes from JDK-8323787 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/1ce8fe9d..5f2070fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=07-08 Stats: 67 lines in 1 file changed: 51 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Sat Jan 20 20:37:37 2024 From: jvos at openjdk.org (Johan Vos) Date: Sat, 20 Jan 2024 20:37:37 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v8] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 10:16:08 GMT, Florian Kirmaier wrote: >> A few things about the latest commit: >> >> 1. The usage of the `active` property caused regression: the memoryLeak test that was introduced in the fix for JDK-8318841 now failed. A number of listeners were hard referenced from the `active` property. >> The complexity is that there are different entry points by which a listener should be removed. What we try to do in this PR, is making sure we remove listeners after a defocus/focus operation that would otherwise stay referenced. A focus operation will result in GlassSystemMenu.setMenus() being called. >> I reverted some of the dependencies on the `active` property, and kept those that were directly created as a consequence of the setMenus call. >> >> 2. I added a test that demonstrates the issue when not removing menu's completely inside the listener, as reported by @jperedadnr and this issue is fixed as well now. >> >> 3. All tests now pass, but I noticed that in some cases, the systemtests do not correctly work with the application lifecycle management (see https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044516.html). For now, I consider this anomaly to be independent from JDK-8319779 > > @johanvos > **ticket** > We found a bug, which is also fixed by this PR. This is the ticket: https://bugs.openjdk.org/browse/JDK-8323787 > It's an IndexOutOfBounds exception, related to the visible flag/listeners. > > **unittest** > We wrote a unit test, which goes green with this PR. > Can you do us a favor, and add the test from the ticket to your PR? > Then we can be sure, that this issue will be solved and never reappears. @FlorianKirmaier Thanks for the additional test. There was already a test in the SystemMenuBarTest, but it's really good to have an additional test for this -- I added it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1902259510 From jhendrikx at openjdk.org Sat Jan 20 22:12:36 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 20 Jan 2024 22:12:36 GMT Subject: RFR: 8324219: Remove incorrect documentation from Animation methods In-Reply-To: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> References: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> Message-ID: <1o3JQIcFseJPSTaFj3-QEwWRGBq6PZjDxR-bobv7ss8=.29700545-11d7-45e8-bf6f-de86098d389b@github.com> On Fri, 19 Jan 2024 16:07:31 GMT, Michael Strau? wrote: > The `Animation` class states in the documentation of various methods that the method call would be asynchronous, using language similar to: > > > {@code stop()} is an asynchronous call, the {@code Animation} may not stop immediately. > > > This is factually wrong, there are no asynchronous calls. In fact, the methods in question can only be called synchronously on the JavaFX Application thread, and the state of the animation is changed immediately. For example, when `stop()` is called, the animation transitions to the stopped state instantly, without waiting for the next animation pulse. I think this is a good change. All animation code always runs on the FX thread. Calling start/stop etc on a different thread would mess with flags like `aborted` and `inTimePulse` which are not marked volatile. This change should probably have been made when the FX thread enforcing was added. ------------- Marked as reviewed by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1342#pullrequestreview-1834736625 From nlisker at openjdk.org Sun Jan 21 21:16:36 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 21 Jan 2024 21:16:36 GMT Subject: RFR: 8324219: Remove incorrect documentation from Animation methods In-Reply-To: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> References: <1O3uq54DrCyXiM6wUupgJhBWGWTNOHfd2Rnixt4h9lk=.87db2ee1-d909-454c-95e6-512da88551b7@github.com> Message-ID: On Fri, 19 Jan 2024 16:07:31 GMT, Michael Strau? wrote: > The `Animation` class states in the documentation of various methods that the method call would be asynchronous, using language similar to: > > > {@code stop()} is an asynchronous call, the {@code Animation} may not stop immediately. > > > This is factually wrong, there are no asynchronous calls. In fact, the methods in question can only be called synchronously on the JavaFX Application thread, and the state of the animation is changed immediately. For example, when `stop()` is called, the animation transitions to the stopped state instantly, without waiting for the next animation pulse. Looks fine, but I'd like to see what Jurgen's case is on the mailing list. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1342#pullrequestreview-1835435903 From jpereda at openjdk.org Sun Jan 21 21:48:37 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 21 Jan 2024 21:48:37 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: <5X_h5oKFRrimG0aJV5CnXI5JhPBeNqMaV8mQfCtcFNc=.a2ae4803-c6f2-431f-839e-dbfb5d3b55c3@github.com> On Mon, 18 Dec 2023 22:00:28 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add compile-time checks to GdkSeat > > The addition of the compile-time flags looks OK. > > I did a build with GTK 3.22 (so it compiles the new code, does the dlsym, and does the runtime check) and verified that there are no regressions when running on an older system (Ubuntu 16.04). > > I then did a full test run on our headful test systems, and there is one new test failure -- it seems to be intermittent, although fails pretty consistently on our Ubuntu 22.04 and Ubuntu 20.04 test systems. I can reproduce it locally on a VM running Ubuntu 22.04, where it fails about 1/2 the time with this patch applied (it fails more often on our physical test systems). > > > DatePickerTest > testDatePickerSceneChange FAILED > java.lang.AssertionError: Timeout: Failed to receive onAction call. > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.assertTrue(Assert.java:42) > at test.util.Util.waitForLatch(Util.java:400) > at test.robot.javafx.scene.DatePickerTest.clickDatePickerCalendarPopup(DatePickerTest.java:90) > at test.robot.javafx.scene.DatePickerTest.testDatePickerSceneChange(DatePickerTest.java:123) > > > Not sure what to make of this. I am not aware of any problems with this test, but it's possible that your fix has exposed a latent issue either in the test or somewhere else. @kevinrushforth is there anything else to be done before we can move this PR forward? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1902776414 From jbhaskar at openjdk.org Mon Jan 22 00:51:38 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 22 Jan 2024 00:51:38 GMT Subject: Integrated: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html In-Reply-To: References: Message-ID: <2ho_JkQJ8_HT674riGhxG1rUR_GkBeOr_3gjxw2Y4Ss=.7d4313fb-6ab1-47d1-8c9f-d5bfda79bca9@github.com> On Thu, 18 Jan 2024 03:51:28 GMT, Jay Bhaskar wrote: > Issue: constructor Path(Path) which takes another Path object fails to draw on canvas html. > Solution: copy the old path while creating a new Path object from the existing Path that is already created with the same canvas rendering context. This pull request has now been integrated. Changeset: 3cf9390f Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/3cf9390f5fb2ad564eeec3a95744503f1b26dd0d Stats: 62 lines in 2 files changed: 61 ins; 0 del; 1 mod 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Reviewed-by: kcr, hmeda ------------- PR: https://git.openjdk.org/jfx/pull/1339 From psadhukhan at openjdk.org Mon Jan 22 09:05:58 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 Jan 2024 09:05:58 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 Message-ID: Test fails with JFXPanelHiDPITest > testScale FAILED java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null because scenePeer is not yet created as the test is run with invokeLater. FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. ------------- Commit messages: - 8324239: JFXPanelHiDPITest fails on Windows 11 Changes: https://git.openjdk.org/jfx/pull/1344/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324239 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1344.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1344/head:pull/1344 PR: https://git.openjdk.org/jfx/pull/1344 From psadhukhan at openjdk.org Mon Jan 22 09:40:51 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 Jan 2024 09:40:51 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v2] In-Reply-To: References: Message-ID: > Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the test is run with invokeLater. > FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use Platform.runAndWait ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1344/files - new: https://git.openjdk.org/jfx/pull/1344/files/36aa3356..09be9a2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1344&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1344&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1344.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1344/head:pull/1344 PR: https://git.openjdk.org/jfx/pull/1344 From psadhukhan at openjdk.org Mon Jan 22 09:40:53 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 Jan 2024 09:40:53 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 09:01:10 GMT, Prasanta Sadhukhan wrote: > Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the test is run with invokeLater. > FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. Guess better will be to use Platform.runAndWait for scene to be created ------------- PR Comment: https://git.openjdk.org/jfx/pull/1344#issuecomment-1903600602 From psadhukhan at openjdk.org Mon Jan 22 09:56:01 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 Jan 2024 09:56:01 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: > Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the test is run with invokeLater. > FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use Platform.runAndWait ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1344/files - new: https://git.openjdk.org/jfx/pull/1344/files/09be9a2a..b35b29b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1344&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1344&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1344.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1344/head:pull/1344 PR: https://git.openjdk.org/jfx/pull/1344 From pavelturk2000 at gmail.com Mon Jan 22 10:20:02 2024 From: pavelturk2000 at gmail.com (PavelTurk) Date: Mon, 22 Jan 2024 12:20:02 +0200 Subject: My issue seems to be lost Message-ID: <9886321d-9c21-564c-10aa-bf99ce832cdd@gmail.com> Hello all. On January 10, 2024 I opened an issue with internal review ID 9076431 about bug in ColorPicker and still didn't get any answer. I waited, but almost two weeks has passed. Could anyone say anything about it? Best regards, Pavel From javafx at ivoryemr.co.za Mon Jan 22 10:56:36 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Mon, 22 Jan 2024 12:56:36 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: Message-ID: Hi Michael It seems we are misunderstanding one another. Firstly I agree that the animation code itself must and always has run only on the FX thread. So for example in the following code: new KeyFrame( Duration.seconds(2.5), event -> { int maxMemory = ....; int usedMemory = ....; memoryLabel.setText( usedMemory +" MB / "+ maxMemory +" MB" ); }) The lambda part ALWAYS executes on the FX thread by default, no matter on which thread this KeyFrame is created. And we all agree that the following is ILLEGAL: new KeyFrame( Duration.seconds(2.5), event -> { new Thread( () -> memoryLabel.setText( usedMemory +" MB / "+ maxMemory +" MB" ) ).start(); }) With the above clarified, what I'm contending is that the following can be excuted on any thread: var updater = new Timeline ( new KeyFrame( Duration.seconds(2.5), event -> { int maxMemory = ....; int usedMemory = ....; memoryLabel.setText( usedMemory +" MB / "+ maxMemory +" MB" ); }) ); updater.setCycleCount(Animation.INDEFINITE); updater.play(); The reason is because play, stop, and pause simply causes the Timeline to be added too or removed from an array in AbstractPrimaryTimer. If a pulse is busy executing so that the array is currently being accessed by the FX thread then a copy of the array is made and the addition/removal is made to the copy. (However there is a bug in this code that causes an NPE under certain conditions.) So when the API documentation says that it's asynchronous it means that the 'animation' execution may not yet have started/stopped when the call returns depending on when during the pulse the method was invoked. If play is invoked just before the next pulse then the 'animation' could be running, or if stop is invoked just as a pulse completes then it will not be executing. Otherwise the 'animation' will only actually be (not) executing in the next pulse. Hope this clarifies things. Regards Jurgen From javafx at ivoryemr.co.za Mon Jan 22 10:59:00 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Mon, 22 Jan 2024 12:59:00 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: Message-ID: Here's an example as requested by Nir: public class FxTimeLineTest extends Application { private BorderPane bp = new BorderPane( new Label("Loading") ); public static void main( String[] args ) { launch( FxTimeLineTest.class, args ); } @Override public void start( Stage primaryStage ) throws Exception { new Thread( new LoadScene() ).start(); primaryStage.setScene( new Scene( bp, 300, 200 ) ); primaryStage.setTitle( "Memory Usage" ); primaryStage.show(); } private class LoadScene extends Task { @Override protected Parent call() throws Exception { Parent p = FXMLLoader.load( getClass().getResource("TestView.fxml") ); Thread.sleep( 1000 ); return p; } @Override protected void succeeded() { bp.setCenter( getValue() ); } @Override protected void failed() { getException().printStackTrace(); } } } ------------------------------------------------------------------------------------------------------ public class TestView { @FXML private Label memory; private static final double MEGABYTE = 1024 * 1024; @FXML private void initialize() { var updater = new Timeline ( new KeyFrame( Duration.seconds(2.5), event -> { var runtime = Runtime.getRuntime(); double maxMemory = runtime.maxMemory() / MEGABYTE; double usedMemory = (runtime.totalMemory() - runtime.freeMemory()) / MEGABYTE; memory.setText( (int) usedMemory + " MB / " + (int) maxMemory +" MB" ); }) ); updater.setCycleCount(Animation.INDEFINITE); // This FXML is being loaded on a background thread updater.play(); } } ------------------------------------------------------------------------------------------------------ TestView.fxml On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker wrote: > Hi Jurgen, > > What I'm confused about the most is what it is you are actually trying > to do that necessitates the use of animations outside of the FX thread. > >You said that you need to initialize controls on another thread, and > that you are using Task (both of which are fine), but how does playing > >animations relate? Playing an animation is something that is done > explicitly, usually in order to manipulate data. Can you give a real use > >case, like a minimized version of what you're doing? > > - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Mon Jan 22 12:12:36 2024 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 22 Jan 2024 14:12:36 +0200 Subject: My issue seems to be lost In-Reply-To: <9886321d-9c21-564c-10aa-bf99ce832cdd@gmail.com> References: <9886321d-9c21-564c-10aa-bf99ce832cdd@gmail.com> Message-ID: I don't see a ColorPicker bug in JBS that was created in the last 2 weeks, which means it's still in internal triage. Kevin will have to take a look. On Mon, Jan 22, 2024 at 12:20?PM PavelTurk wrote: > Hello all. > > On January 10, 2024 I opened an issue with internal review ID 9076431 > about bug in ColorPicker > and still didn't get any answer. I waited, but almost two weeks has passed. > > Could anyone say anything about it? > > Best regards, Pavel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Mon Jan 22 13:49:50 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 22 Jan 2024 13:49:50 GMT Subject: RFR: 8324270: Update boot JDK to 21.0.2 Message-ID: JDK 21.0.2 is now released : https://jdk.java.net/21/ Did a full CI build including Webkit and executed all headful tests. ------------- Commit messages: - boot jdk 21.0.2 Changes: https://git.openjdk.org/jfx/pull/1345/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1345&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324270 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1345.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1345/head:pull/1345 PR: https://git.openjdk.org/jfx/pull/1345 From angorya at openjdk.org Mon Jan 22 15:47:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jan 2024 15:47:42 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> Message-ID: On Sat, 20 Jan 2024 14:07:32 GMT, Kevin Rushforth wrote: >> I'm not familiar enough with AtomicReference to have an opinion on this. Someone else will have to weigh in on this. > > Either an array or an AtomicReference is OK in this case. AtomicReference is thread-safe, but that's not a concern here, since using `runAndWait` ensures that writing to the array happens before reading it. I might be wrong, but array would need to store its size (an int, 8 bytes on 64 bit machines) in addition to the pointers themselves, while AtomicReference needs just the pointer. Plus, its semantics is much cleaner. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1462053392 From john.hendrikx at gmail.com Mon Jan 22 15:58:20 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 22 Jan 2024 16:58:20 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: Message-ID: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> This seems like a reasonable use case, and perhaps this was the original intent of the "asynchronous call" documentation. The problem though is that the play/stop code does not seem to take into account being called from a different thread (there are several synchronization issues when I delved into that code). So then there's a choice to make I think, either: - Disallow it completely, and have users wrap it into Platform.runLater() - Have play/stop do the wrapping itself - Make the methods thread safe by fixing the synchronization issues --John On 22/01/2024 11:59, Jurgen Doll wrote: > Here's an example as requested by Nir: > > publicclassFxTimeLineTest extendsApplication > > { > > privateBorderPane bp= newBorderPane( newLabel("Loading") ); > > publicstaticvoidmain( String[] args) { > > launch( FxTimeLineTest.class, args); > > } > > @Override > > publicvoidstart( Stage primaryStage) throwsException { > > newThread( newLoadScene() ).start(); > > primaryStage.setScene( newScene( bp, 300, 200 ) ); > > primaryStage.setTitle( "Memory Usage"); > > primaryStage.show(); > > } > > privateclassLoadScene extendsTask { > > @OverrideprotectedParent call() throwsException { > > Parent p= FXMLLoader.load( getClass().getResource("TestView.fxml") ); > > Thread.sleep( 1000 ); > > returnp; > > } > > @Overrideprotectedvoidsucceeded() { > > bp.setCenter( getValue() ); > > } > > @Overrideprotectedvoidfailed() { > > getException().printStackTrace(); > > } > > } > > } > > ------------------------------------------------------------------------------------------------------ > > > publicclassTestView > > { > > @FXMLprivateLabel memory; > > privatestaticfinaldoubleMEGABYTE= 1024 * 1024; > > @FXMLprivatevoidinitialize() > > { > > varupdater= newTimeline > > ( > > newKeyFrame( Duration.seconds(2.5), event-> > > { > > varruntime= Runtime.getRuntime(); > > doublemaxMemory= runtime.maxMemory() / MEGABYTE; > > doubleusedMemory= (runtime.totalMemory() - runtime.freeMemory()) / > MEGABYTE; > > memory.setText( (int) usedMemory+ " MB / "+ (int) maxMemory+" MB"); > > }) > > ); > > updater.setCycleCount(Animation.INDEFINITE); // This FXML is being > loaded on a background thread > > updater.play(); > > } > > } > > ------------------------------------------------------------------------------------------------------ > > > TestView.fxml > > > > > > > > > > > > > > > > > > > > > On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker wrote: > > Hi Jurgen, > > What I'm confused about the most is what it is you are actually > trying to do that necessitates?the use of animations outside of > the FX thread. You said that you need to initialize controls on > another thread, and that you are using Task (both of which are > fine), but how does playing animations relate? Playing an > animation is something that is done explicitly, usually in order > to manipulate data. Can you give a real use case, like a minimized > version of what you're doing? > > - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Jan 22 16:01:26 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Jan 2024 08:01:26 -0800 Subject: My issue seems to be lost In-Reply-To: <9886321d-9c21-564c-10aa-bf99ce832cdd@gmail.com> References: <9886321d-9c21-564c-10aa-bf99ce832cdd@gmail.com> Message-ID: I can see it in the system. It seems to be stuck, so I'll check with the folks who process incoming? bugs to see if can be moved along. -- Kevin On 1/22/2024 2:20 AM, PavelTurk wrote: > Hello all. > > On January 10, 2024 I opened an issue with internal review ID 9076431 > about bug in ColorPicker > and still didn't get any answer. I waited, but almost two weeks has > passed. > > Could anyone say anything about it? > > Best regards, Pavel > From javafx at ivoryemr.co.za Mon Jan 22 16:46:56 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Mon, 22 Jan 2024 18:46:56 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> Message-ID: I've been delving into the usage of `aborted` and `inTimePulse` as mentioned by John and gleaned the following: 1. stop makes a best effort to abort the 'animation' if it is in the process of execution. 2. `aborted` and `inTimePulse` are reset with every pulse. As to the options that John mentioned there's also a fourth: Accept my original proposal of fixing the NPE which is a known problem and not worry about potential synchronization issues. I mean does it really matter if play, stop, or pause miss a beat due to synchronization, as the API does say this could happen. Furthermore it doesn't appear as though the animation code can be left in some strange inconsistent state as a result of this. Jurgen On Mon, 22 Jan 2024 17:58:20 +0200, John Hendrikx wrote: > > This seems like a reasonable use case, and perhaps this was the original > intent of the "asynchronous call" documentation. > > The problem though is that the play/stop code does not seem to take into > account being called from a different thread (there are several > >synchronization issues when I delved into that code). > > So then there's a choice to make I think, either: > > - Disallow it completely, and have users wrap it into Platform.runLater() > - Have play/stop do the wrapping itself > - Make the methods thread safe by fixing the synchronization issues > > --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Jan 22 17:00:14 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Jan 2024 09:00:14 -0800 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> Message-ID: <300d4f22-b149-4705-9d97-cbeebefc88d2@oracle.com> I would not support your proposed 4th option. It's basically a partial fix for the solution John mentioned as his third option. Of the three John mentions, I favor either 1 or 2. I don't see a compelling reason to guarantee thread-safety for Animation objects (option 3), in which case the question becomes whether it is worth having the play*/pause/stop methods do the runLater or require the user to do it. The latter is more explicit, whereas the former is more convenient. What do others think? -- Kevin On 1/22/2024 8:46 AM, Jurgen Doll wrote: > I've been delving into the usage of `aborted` and `inTimePulse` as > mentioned by John and gleaned the following: > > 1. stop makes a best effort to abort the 'animation' if it is in the > process of execution. > 2. `aborted` and `inTimePulse` are reset with every pulse. > > As to the options that John mentioned there's also a fourth: > > Accept my original proposal of fixing the NPE which is a known problem > and not worry about potential synchronization issues. I mean does it > really matter if play, stop, or pause miss a beat due to > synchronization, as the API does say this could happen. Furthermore it > doesn't appear as though the animation code can be left in some > strange inconsistent state as a result of this. > > Jurgen > > On Mon, 22 Jan 2024 17:58:20 +0200, John Hendrikx > wrote: > > This seems like a reasonable use case, and perhaps this was the > original intent of the "asynchronous call" documentation. > > The problem though is that the play/stop code does not seem to > take into account being called from a different thread (there are > several synchronization issues when I delved into that code). > > So then there's a choice to make I think, either: > > - Disallow it completely, and have users wrap it into > Platform.runLater() > - Have play/stop do the wrapping itself > - Make the methods thread safe by fixing the synchronization issues > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Jan 22 17:11:53 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Jan 2024 09:11:53 -0800 Subject: My issue seems to be lost In-Reply-To: References: <9886321d-9c21-564c-10aa-bf99ce832cdd@gmail.com> Message-ID: <3991ede8-ca22-4dd9-9592-9b42d64eb006@oracle.com> https://bugs.openjdk.org/browse/JDK-8324327 On 1/22/2024 8:01 AM, Kevin Rushforth wrote: > I can see it in the system. It seems to be stuck, so I'll check with > the folks who process incoming? bugs to see if can be moved along. > > -- Kevin > > > On 1/22/2024 2:20 AM, PavelTurk wrote: >> Hello all. >> >> On January 10, 2024 I opened an issue with internal review ID 9076431 >> about bug in ColorPicker >> and still didn't get any answer. I waited, but almost two weeks has >> passed. >> >> Could anyone say anything about it? >> >> Best regards, Pavel >> > From pavelturk2000 at gmail.com Mon Jan 22 17:17:43 2024 From: pavelturk2000 at gmail.com (PavelTurk) Date: Mon, 22 Jan 2024 19:17:43 +0200 Subject: My issue seems to be lost In-Reply-To: <3991ede8-ca22-4dd9-9592-9b42d64eb006@oracle.com> References: <9886321d-9c21-564c-10aa-bf99ce832cdd@gmail.com> <3991ede8-ca22-4dd9-9592-9b42d64eb006@oracle.com> Message-ID: <9388e236-2833-8cf1-d3bf-14c9697e87d1@gmail.com> Thank you very much! Best regards, Pavel On 1/22/24 7:11 PM, Kevin Rushforth wrote: > https://bugs.openjdk.org/browse/JDK-8324327 > > > On 1/22/2024 8:01 AM, Kevin Rushforth wrote: >> I can see it in the system. It seems to be stuck, so I'll check with the folks who process incoming? bugs to see if can be moved along. >> >> -- Kevin >> >> >> On 1/22/2024 2:20 AM, PavelTurk wrote: >>> Hello all. >>> >>> On January 10, 2024 I opened an issue with internal review ID 9076431 about bug in ColorPicker >>> and still didn't get any answer. I waited, but almost two weeks has passed. >>> >>> Could anyone say anything about it? >>> >>> Best regards, Pavel >>> >> > From angorya at openjdk.org Mon Jan 22 19:26:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jan 2024 19:26:40 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created as the test is run with invokeLater. >> FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.runAndWait is there a reason this test is skipped on macOS? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1344#issuecomment-1904657766 From kcr at openjdk.org Mon Jan 22 19:29:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jan 2024 19:29:44 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: <19ZBcPtY06bCwzBf5cN8EQbmJqrdpWa-H9rYX0YHmI0=.abe4c95b-a91a-4277-9c3e-9639e8a1f34e@github.com> On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat This dropped off my radar. The only pending issue is the test failure I noted in an earlier comment: > I then did a full test run on our headful test systems, and there is one new test failure -- it seems to be intermittent, although fails pretty consistently on our Ubuntu 22.04 and Ubuntu 20.04 test systems. I can reproduce it locally on a VM running Ubuntu 22.04, where it fails about 1/2 the time with this patch applied (it fails more often on our physical test systems). > > ``` > DatePickerTest > testDatePickerSceneChange FAILED > java.lang.AssertionError: Timeout: Failed to receive onAction call. > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.assertTrue(Assert.java:42) > at test.util.Util.waitForLatch(Util.java:400) > at test.robot.javafx.scene.DatePickerTest.clickDatePickerCalendarPopup(DatePickerTest.java:90) > at test.robot.javafx.scene.DatePickerTest.testDatePickerSceneChange(DatePickerTest.java:123) > ``` > > Not sure what to make of this. I am not aware of any problems with this test, but it's possible that your fix has exposed a latent issue either in the test or somewhere else. @jperedadnr Can you try it on your system and see if you can reproduce this failure? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1904662936 From kcr at openjdk.org Mon Jan 22 19:48:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jan 2024 19:48:39 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 19:23:58 GMT, Andy Goryachev wrote: > is there a reason this test is skipped on macOS? It's unrelated to this PR, but to answer your question, the test is Windows-specific by it's use of setting `glass.win.uiScale`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1344#issuecomment-1904690147 From angorya at openjdk.org Mon Jan 22 19:55:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jan 2024 19:55:38 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created as the test is run with invokeLater. >> FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.runAndWait I wish the test class had a description. It is not immediately apparent that this is a windows-only test without reading the whole thing very carefully. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1344#issuecomment-1904702195 From jpereda at openjdk.org Mon Jan 22 20:26:39 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 22 Jan 2024 20:26:39 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat I'm testing on my local Linux Intel machine (Ubuntu 20.04), and running the test from head, it passes 5 out of 5 times. After applying this patch, it fails with your same stacktrace 2 out of 5 times. With some printouts, I can see that when the test fails, in `DatePickerTest::clickDatePickerCalendarPopup` the call to `mouseClick` processes correctly the mouse move at the correct coordinates and calls mouse press and mouse release, but what it should trigger the datePicker setOnAction event (line 168), fails to do so. For some reason, the event doesn't make it to the control. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1904746485 From angorya at openjdk.org Mon Jan 22 20:28:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jan 2024 20:28:39 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created as the test is run with invokeLater. >> FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.runAndWait looks good. Are there any other places where we invokeLater() instead of invokeAndWait()? And runLater() instead of runAndWait() ? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1344#pullrequestreview-1837300279 From kcr at openjdk.org Mon Jan 22 20:51:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jan 2024 20:51:39 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 20:26:07 GMT, Andy Goryachev wrote: > Are there any other places where we invokeLater() instead of invokeAndWait()? > And runLater() instead of runAndWait() ? Good question. There might be, but each would need to be looked into to see whether they are causing problems. Also, when doing anything with Swing interop you need to be careful to not introduce a deadlock. It's fine in this specific case. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1344#issuecomment-1904782286 From michaelstrau2 at gmail.com Mon Jan 22 20:53:48 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 22 Jan 2024 21:53:48 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: Message-ID: Hi Jurgen, starting an animation on a background thread would only be safe if the object graph affected by the animation is not accessed on the background thread after calling the play() method. Any access may potentially corrupt internal state. >From what I can see in your example, you're not doing anything with TestView after starting the animation, so you should be good here. >From an API perspective, I wonder if that makes it too easy to introduce subtle bugs into an application. As a general principle, I think an API should make it easy to do the right thing, and hard to do the wrong thing. Allowing potentially unsafe method calls without some explicit procedure (like wrapping the call in Platform.runLater) might not be a good idea. Maybe we should provide an API that allows developers to safely modify an object graph on a background thread and call Platform.runLater without worrying about concurrent modifications. Something like this: try (var scope = Platform.deferredScope()) { var updater = new Timeline( new KeyFrame(Duration.seconds(2.5), event -> { int maxMemory = ....; int usedMemory = ....; memoryLabel.setText(usedMemory + " MB / "+ maxMemory +" MB"); }) ); // This call will only be dispatched after the deferred scope is closed: scope.runLater(updater::play); // Still safe to call in the deferred scope, wouldn't be safe if // Platform.runLater had been called before: memoryLabel.setText("N/A"); } On Mon, Jan 22, 2024 at 11:57?AM Jurgen Doll wrote: > > Hi Michael > > It seems we are misunderstanding one another. > > Firstly I agree that the animation code itself must and always has run > only on the FX thread. > > So for example in the following code: > > new KeyFrame( Duration.seconds(2.5), event -> > { > int maxMemory = ....; > int usedMemory = ....; > memoryLabel.setText( usedMemory +" MB / "+ maxMemory +" MB" ); > }) > > The lambda part ALWAYS executes on the FX thread by default, no matter on > which thread this KeyFrame is created. > > > And we all agree that the following is ILLEGAL: > > new KeyFrame( Duration.seconds(2.5), event -> > { > new Thread( () -> memoryLabel.setText( usedMemory +" MB / "+ > maxMemory +" MB" ) ).start(); > }) > > > With the above clarified, what I'm contending is that the following can be > excuted on any thread: > > var updater = new Timeline > ( > new KeyFrame( Duration.seconds(2.5), event -> > { > int maxMemory = ....; > int usedMemory = ....; > memoryLabel.setText( usedMemory +" MB / "+ maxMemory +" MB" ); > }) > ); > updater.setCycleCount(Animation.INDEFINITE); > updater.play(); > > > The reason is because play, stop, and pause simply causes the Timeline to > be added too or removed from an array in AbstractPrimaryTimer. If a pulse > is busy executing so that the array is currently being accessed by the FX > thread then a copy of the array is made and the addition/removal is made > to the copy. (However there is a bug in this code that causes an NPE under > certain conditions.) > > So when the API documentation says that it's asynchronous it means that > the 'animation' execution may not yet have started/stopped when the call > returns depending on when during the pulse the method was invoked. If play > is invoked just before the next pulse then the 'animation' could be > running, or if stop is invoked just as a pulse completes then it will not > be executing. Otherwise the 'animation' will only actually be (not) > executing in the next pulse. > > Hope this clarifies things. > > Regards > Jurgen From mfox at openjdk.org Mon Jan 22 20:55:38 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 22 Jan 2024 20:55:38 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> Message-ID: On Mon, 22 Jan 2024 15:45:25 GMT, Andy Goryachev wrote: >> Either an array or an AtomicReference is OK in this case. AtomicReference is thread-safe, but that's not a concern here, since using `runAndWait` ensures that writing to the array happens before reading it. > > I might be wrong, but array would need to store its size (an int, 8 bytes on 64 bit machines) in addition to the pointers themselves, while AtomicReference needs just the pointer. > Plus, its semantics is much cleaner. Again, thread-safety isn't an issue here. Even if the OS were to invoke the IM methods on different threads (which is a terrifying thought) these adapters are created on a per-call basis so each thread would get its own instance. This also means those extra eight bytes are transitory. If there's an established JavaFX pattern of using AtomicReference instead of an array I will gladly make the changes. But this does require manual testing (I still haven't figured out how to automate this) so I'm reluctant to do this based on personal style preferences. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1462403040 From kcr at openjdk.org Mon Jan 22 20:56:34 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jan 2024 20:56:34 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created as the test is run with invokeLater. >> FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.runAndWait The test runs correctly now. Tests should generally use `Util.runAndWait` instead of `PlatformImpl.runAndWait`. tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelHiDPITest.java line 154: > 152: > 153: private void createScene(final JFXPanel fxPanel) { > 154: PlatformImpl.runAndWait(() -> { Generally we prefer `test.util.Util::runAndWait` so that exceptions are propagated. ------------- PR Review: https://git.openjdk.org/jfx/pull/1344#pullrequestreview-1837336899 PR Review Comment: https://git.openjdk.org/jfx/pull/1344#discussion_r1462401494 From angorya at openjdk.org Mon Jan 22 21:08:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jan 2024 21:08:38 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> Message-ID: <5DU7wsZ8TNSTzWf6zD25PihsXtpHs85hPpPsACZQ2SI=.56d4ea68-be96-4e07-a3d4-a9188a20a27a@github.com> On Mon, 22 Jan 2024 20:52:56 GMT, Martin Fox wrote: >> I might be wrong, but array would need to store its size (an int, 8 bytes on 64 bit machines) in addition to the pointers themselves, while AtomicReference needs just the pointer. >> Plus, its semantics is much cleaner. > > Again, thread-safety isn't an issue here. Even if the OS were to invoke the IM methods on different threads (which is a terrifying thought) these adapters are created on a per-call basis so each thread would get its own instance. This also means those extra eight bytes are transitory. > > If there's an established JavaFX pattern of using AtomicReference instead of an array I will gladly make the changes. But this does require manual testing (I still haven't figured out how to automate this) so I'm reluctant to do this based on personal style preferences. Here is more info [0]. We **are** dealing with multiple threads. I've seen weird cases where modifying memory from different threads without explicit synchronization resulted in subtle bugs - we don't know all the details of cache coherence [1] implementation in multi-core systems, so I would strongly suggest to use AtomicReference. [0] https://stackoverflow.com/questions/70381029/java-atomincinteger-vs-one-element-array-for-streams [1] https://en.wikipedia.org/wiki/Cache_coherence ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1462422366 From angorya at openjdk.org Mon Jan 22 21:09:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jan 2024 21:09:41 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3] In-Reply-To: References: Message-ID: <3YnoIORnvICj21P_8P_ifPt6vjWk893uLBRfNzXBOcc=.70ddc1d3-1909-408a-86ca-095414a72522@github.com> On Mon, 22 Jan 2024 20:51:53 GMT, Kevin Rushforth wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Platform.runAndWait > > tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelHiDPITest.java line 154: > >> 152: >> 153: private void createScene(final JFXPanel fxPanel) { >> 154: PlatformImpl.runAndWait(() -> { > > Generally we prefer `test.util.Util::runAndWait` so that exceptions are propagated. good point! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1344#discussion_r1462423464 From kcr at openjdk.org Mon Jan 22 21:33:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jan 2024 21:33:36 GMT Subject: RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory [v2] In-Reply-To: References: Message-ID: <7I5PVhccx8I-f6_GyLTEcNwj6vjRyiCYTYaOUbYVfq8=.6dbac5a8-3f75-4a0f-94e2-b19a3b5d25bf@github.com> On Wed, 17 Jan 2024 16:43:23 GMT, Martin Fox wrote: >> When a Stage is closed while processing an OS message the glass peer object is deleted immediately even if it's still executing member functions. As glass unwinds the stack and executes cleanup code it's referencing freed memory. >> >> There are cases where glass generates JavaFX events back-to-back. For example, when handling the Delete key glass sends a PRESSED and TYPED event in the same routine. If the Stage is closed during the PRESSED event the code that sends the TYPED event is running inside an object that has already been deleted. >> >> When the Stage is closed glass calls the OS routine ::DestroyWindow on the HWND causing a WM_NCDESTROY message to be sent. Currently the BaseWnd object is deleted when processing this message. This PR defers the destruction until all messages have been processed. This is the same approach used in the Linux code. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Updated to match existing naming conventions The code changes look good. I tested it, and confirm that with a debug build the test crashes without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1309#pullrequestreview-1837411541 From mfox at openjdk.org Mon Jan 22 22:16:46 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 22 Jan 2024 22:16:46 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: <5DU7wsZ8TNSTzWf6zD25PihsXtpHs85hPpPsACZQ2SI=.56d4ea68-be96-4e07-a3d4-a9188a20a27a@github.com> References: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> <5DU7wsZ8TNSTzWf6zD25PihsXtpHs85hPpPsACZQ2SI=.56d4ea68-be96-4e07-a3d4-a9188a20a27a@github.com> Message-ID: On Mon, 22 Jan 2024 21:06:01 GMT, Andy Goryachev wrote: >> Again, thread-safety isn't an issue here. Even if the OS were to invoke the IM methods on different threads (which is a terrifying thought) these adapters are created on a per-call basis so each thread would get its own instance. This also means those extra eight bytes are transitory. >> >> If there's an established JavaFX pattern of using AtomicReference instead of an array I will gladly make the changes. But this does require manual testing (I still haven't figured out how to automate this) so I'm reluctant to do this based on personal style preferences. > > Here is more info [0]. > > We **are** dealing with multiple threads. > > I've seen weird cases where modifying memory from different threads without explicit synchronization resulted in subtle bugs - we don't know all the details of cache coherence [1] implementation in multi-core systems, so I would strongly suggest to use AtomicReference. > > [0] https://stackoverflow.com/questions/70381029/java-atomincinteger-vs-one-element-array-for-streams > > [1] https://en.wikipedia.org/wiki/Cache_coherence Sorry, I was still thinking about the original thread-safety concern which involved simultaneous access to the fields in this adapter object. Not the issue here. I agree that explicit synchronization needs to happen but I thought that was what `runAndWait` was for. @kevinrushforth also states that `runAndWait` should be sufficient. If you think there's a cache coherence problem that's much, much bigger than this PR since this pattern is used throughout the code base. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1462483419 From mfox at openjdk.org Mon Jan 22 22:18:37 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 22 Jan 2024 22:18:37 GMT Subject: Integrated: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 17:31:57 GMT, Martin Fox wrote: > When a Stage is closed while processing an OS message the glass peer object is deleted immediately even if it's still executing member functions. As glass unwinds the stack and executes cleanup code it's referencing freed memory. > > There are cases where glass generates JavaFX events back-to-back. For example, when handling the Delete key glass sends a PRESSED and TYPED event in the same routine. If the Stage is closed during the PRESSED event the code that sends the TYPED event is running inside an object that has already been deleted. > > When the Stage is closed glass calls the OS routine ::DestroyWindow on the HWND causing a WM_NCDESTROY message to be sent. Currently the BaseWnd object is deleted when processing this message. This PR defers the destruction until all messages have been processed. This is the same approach used in the Linux code. This pull request has now been integrated. Changeset: c1c52e5a Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/c1c52e5a42f9a4319487aa9db8e8fcbcf1ba02c8 Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod 8322215: [win] OS events that close the stage can cause Glass to reference freed memory Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1309 From angorya at openjdk.org Mon Jan 22 22:29:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jan 2024 22:29:42 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2] In-Reply-To: References: <04EWMcHDoRx-kUk1PAAW8TUqqMn-honL6LAQt0oTkWw=.511d71f4-00ce-4bc7-a651-76157eb28cc3@github.com> <0l1zhdIizoCRVYzZ089tr3pl1MNZKKb7Pys5EScHM0w=.24c2f212-f773-47f3-beb3-2155be78475b@github.com> <5DU7wsZ8TNSTzWf6zD25PihsXtpHs85hPpPsACZQ2SI=.56d4ea68-be96-4e07-a3d4-a9188a20a27a@github.com> Message-ID: <72Q5MMP4_cAC8L9P3pFPxLik00W-_7r0gcr-rl3gG6o=.5ef61f3e-7e19-4af2-9566-9e54dbe95c57@github.com> On Mon, 22 Jan 2024 22:13:42 GMT, Martin Fox wrote: > this pattern is used throughout the code base. that might be the case, but I think we should use the right pattern for the new code. single-element array is an anachronism, especially in the case of multi-threaded code as here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1462494527 From john.hendrikx at gmail.com Mon Jan 22 23:52:42 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 23 Jan 2024 00:52:42 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> Message-ID: On 22/01/2024 17:46, Jurgen Doll wrote: > I've been delving into the usage of `aborted` and `inTimePulse` as > mentioned by John and gleaned the following: > > 1. stop makes a best effort to abort the 'animation' if it is in the > process of execution. > 2. `aborted` and `inTimePulse` are reset with every pulse. > > As to the options that John mentioned there's also a fourth: > > Accept my original proposal of fixing the NPE which is a known problem > and not worry about potential synchronization issues. I mean does it > really matter if play, stop, or pause miss a beat due to > synchronization, as the API does say this could happen. Furthermore it > doesn't appear as though the animation code can be left in some > strange inconsistent state as a result of this. This is not a good idea, the NPE is a symptom of the problem, but there can be many more subtler problems (and new ones may surface after fixing the NPE) that can affect other animations making use of the shared structures involved.? For one thing, absent a method of synchronization, Java doesn't even guarantee that fields (or arrays) contain the same value for all threads.? So your thread may modify some state, but the FX thread wouldn't even know about it (or only partially), and may make assumptions about an incorrect state, and then make further changes based on incorrect assumptions. A good example is that even a much simpler class like HashMap when accessed by multiple threads can get into a really bad state.? It will usually throw a "ConcurrentModificationException" (or perhaps a weird NPE or IllegalStateException) to alert you that you're using it wrong -- but those are the **best** case scenarios... In the worst case scenario, modifying a HashMap on multiple threads can result in an infinite loop -- this can happen when two modifications occur, both updating the same bucket, and the threads end up changing things in such a way that the entries point to each other.? Iterating it then (or accessing the wrong key) will cause an infinite loop (not hypothetical, I've had this happen). I'm afraid that even the synchronization option I proposed is not very realistic due to the amount of work it will entail.? We'd need to trace all code paths that a call to play or stop could get to, and all those code paths would need to be made thread safe. --John > > Jurgen > > On Mon, 22 Jan 2024 17:58:20 +0200, John Hendrikx > wrote: > > This seems like a reasonable use case, and perhaps this was the > original intent of the "asynchronous call" documentation. > > The problem though is that the play/stop code does not seem to > take into account being called from a different thread (there are > several synchronization issues when I delved into that code). > > So then there's a choice to make I think, either: > > - Disallow it completely, and have users wrap it into > Platform.runLater() > - Have play/stop do the wrapping itself > - Make the methods thread safe by fixing the synchronization issues > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Tue Jan 23 01:23:38 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 23 Jan 2024 01:23:38 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: <4jXZnhiZBwhUql1dwIiU9teLoHZn2PwZ9ySHOK4jMcg=.b5343a78-6d23-4ec2-8503-e047a4d7beb8@github.com> On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat So it seems definitely related to the changes in this PR. Running with `GDK_DEBUG=nograbs` works (10 out of 10). Adding some debug to the native code, and running with grabs, I can see: When it works: DatePickerTest STANDARD_OUT Glass GTK library to load is glassgtk3 loaded gdk_seat_grab loaded gdk_display_get_default_seat grab grab found schema 'org.gnome.desktop.interface' and key 'scaling-factor' loaded gdk_seat_ungrab ungrab grab ungrab found schema 'org.gnome.desktop.interface' and key 'scaling-factor' ungrab grab > Task :systemTests:test ... (so test starts after window is grabbed and focused, as it should be). When it fails: DatePickerTest STANDARD_OUT Glass GTK library to load is glassgtk3 loaded gdk_seat_grab loaded gdk_display_get_default_seat grab grab found schema 'org.gnome.desktop.interface' and key 'scaling-factor' loaded gdk_seat_ungrab ungrab > Task :systemTests:test ... so window is not grabbed and not focused, and therefore native mouse clicks go elsewhere. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1905121653 From almatvee at openjdk.org Tue Jan 23 03:16:48 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Jan 2024 03:16:48 GMT Subject: RFR: 8308955: MediaPlayer/AudioClip skip data on seek/loop Message-ID: <8b44wHVs5kLdMTYUDFbd9R7lXkQcUlCKlJz1T3lzSfg=.43a2e522-a220-4ee4-b749-c21831c594ca@github.com> This is regression from JDK-8262365. JDK-8262365 introduced support for hardware pause for audio device. For some reason we will skip ~500 ms of audio data after such pause. It is not noticeable for large audio files, but for anything small like sound effects 1-3 seconds long it is noticeable and makes short audio effects unusable without re-creating MediaPlayer after each playback. Fix/workaround is to disable hardware pause. I did not figure out why hardware pause skips audio data. ------------- Commit messages: - 8308955: MediaPlayer/AudioClip skip data on seek/loop Changes: https://git.openjdk.org/jfx/pull/1346/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1346&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308955 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1346.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1346/head:pull/1346 PR: https://git.openjdk.org/jfx/pull/1346 From psadhukhan at openjdk.org Tue Jan 23 03:16:57 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 03:16:57 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v4] In-Reply-To: References: Message-ID: > Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the test is run with invokeLater. > FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use Util.runAndWait ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1344/files - new: https://git.openjdk.org/jfx/pull/1344/files/b35b29b9..b4ff81a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1344&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1344&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1344.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1344/head:pull/1344 PR: https://git.openjdk.org/jfx/pull/1344 From javafx at ivoryemr.co.za Tue Jan 23 11:02:19 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Tue, 23 Jan 2024 13:02:19 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced In-Reply-To: References: Message-ID: Hi Michael > starting an animation on a background thread would only be safe if the > object graph affected by the animation is not accessed on the > background thread after calling the play() method. Any access may > potentially corrupt internal state. Agreed. Actually we should drive this further and say that "No changes should be made to properties that are being 'animated' while animation is in progress regardless of whether you're on the FX thread or not, or if the object is in the scene graph or not". updater.play(); memoryLabel.setStyle( "-fx-text-fill: green" ); // This is OK memoryLabel.setText( "This is NOT okay" ); // This is NOT, move to before play Interesting API idea, however I don't think it's really needed for sensible developers. Regards Jurgen On Mon, 22 Jan 2024 22:53:48 +0200, Michael Strau? wrote: > Hi Jurgen, > > starting an animation on a background thread would only be safe if the > object graph affected by the animation is not accessed on the > background thread after calling the play() method. Any access may > potentially corrupt internal state. > > From what I can see in your example, you're not doing anything with > TestView after starting the animation, so you should be good here. > > From an API perspective, I wonder if that makes it too easy to > introduce subtle bugs into an application. As a general principle, I > think an API should make it easy to do the right thing, and hard to do > the wrong thing. Allowing potentially unsafe method calls without some > explicit procedure (like wrapping the call in Platform.runLater) might > not be a good idea. > > Maybe we should provide an API that allows developers to safely modify > an object graph on a background thread and call Platform.runLater > without worrying about concurrent modifications. > > Something like this: > > try (var scope = Platform.deferredScope()) { > var updater = new Timeline( > new KeyFrame(Duration.seconds(2.5), event -> > { > int maxMemory = ....; > int usedMemory = ....; > memoryLabel.setText(usedMemory + " MB / "+ maxMemory +" MB"); > }) > ); > > // This call will only be dispatched after the deferred scope is > closed: > scope.runLater(updater::play); > > // Still safe to call in the deferred scope, wouldn't be safe if > // Platform.runLater had been called before: > memoryLabel.setText("N/A"); > } From fkirmaier at openjdk.org Tue Jan 23 11:51:52 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 23 Jan 2024 11:51:52 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: <_84BHtkO-P9Y5ar5wHt2z_B5J-dz7sv0x11FK_EoC7o=.4e5a259a-f454-451f-9898-fdeaab0e97f5@github.com> > In some situations, a part of the SG is no longer rendered. > I created a test program that showcases this problem. > > Explanation: > > This can happen, when a part of the SG, is covered by another Node. > In this part, one node is totally covered, and the other node is visible. > > When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. > Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. > > In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. > > In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. > > This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. > > Useful parameters for further investigations: > -Djavafx.pulseLogger=true > -Dprism.printrendergraph=true > -Djavafx.pulseLogger.threshold=0 > > PR: > This PR ensures the dirty flag is set to false of the tree when the culling is used. > It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. > It would be great to have some feedback on this solution - maybe guiding me to a better solution. > > I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: reverted accidental change in the .idea folder ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1310/files - new: https://git.openjdk.org/jfx/pull/1310/files/43be153f..530adc10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1310.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1310/head:pull/1310 PR: https://git.openjdk.org/jfx/pull/1310 From fkirmaier at openjdk.org Tue Jan 23 11:51:54 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 23 Jan 2024 11:51:54 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: <0bY6k0RqAvLJEegdCd0lCXSbga2OuMjSpIpm_07LY8g=.e5b94ade-3361-497e-aafa-e65e72b39a28@github.com> References: <0bY6k0RqAvLJEegdCd0lCXSbga2OuMjSpIpm_07LY8g=.e5b94ade-3361-497e-aafa-e65e72b39a28@github.com> Message-ID: On Thu, 21 Dec 2023 14:47:34 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes > > .idea/jpa-buddy.xml line 1: > >> 1: > > Please revert the addition of this file. Removed the accidental change! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1310#discussion_r1463155517 From kcr at openjdk.org Tue Jan 23 12:57:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Jan 2024 12:57:38 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v4] In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 03:16:57 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created as the test is run with invokeLater. >> FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use Util.runAndWait Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1344#pullrequestreview-1838727446 From tsayao at openjdk.org Tue Jan 23 13:29:42 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 23 Jan 2024 13:29:42 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: <1eRPP88AkjFWiO6pgsQyIohePVEUG4eil1ZTRTg2EC0=.8550da48-54bc-46d4-8ee6-712f2f8af18e@github.com> On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat For me it passes on XWayland and fails on Xorg (with Ubuntu 22.04). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1906056674 From hmeda at openjdk.org Tue Jan 23 14:44:23 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 23 Jan 2024 14:44:23 GMT Subject: [jfx22u] RFR: 8318614: Update WebKit to 617.1 Message-ID: Clean Backport. ------------- Commit messages: - Backport ba79e081547b7f15697bfaaac42ec2de1971935a Changes: https://git.openjdk.org/jfx22u/pull/4/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=4&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318614 Stats: 289254 lines in 6439 files changed: 170206 ins; 83308 del; 35740 mod Patch: https://git.openjdk.org/jfx22u/pull/4.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/4/head:pull/4 PR: https://git.openjdk.org/jfx22u/pull/4 From tsayao at openjdk.org Tue Jan 23 14:45:42 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 23 Jan 2024 14:45:42 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat It seems when it fails it's because `GtkWindow._ungrabFocus` is called before the mouse release event. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1906198790 From hmeda at openjdk.org Tue Jan 23 14:52:40 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 23 Jan 2024 14:52:40 GMT Subject: [jfx22u] Integrated: 8318614: Update WebKit to 617.1 In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 14:26:35 GMT, Hima Bindu Meda wrote: > Clean Backport. This pull request has now been integrated. Changeset: 9336ba77 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx22u/commit/9336ba774e0e4ef06291b0785f3919a9932a0eca Stats: 289254 lines in 6439 files changed: 170206 ins; 83308 del; 35740 mod 8318614: Update WebKit to 617.1 Backport-of: ba79e081547b7f15697bfaaac42ec2de1971935a ------------- PR: https://git.openjdk.org/jfx22u/pull/4 From tsayao at openjdk.org Tue Jan 23 15:17:40 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 23 Jan 2024 15:17:40 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat It seems when it fails, button press is reported, but button release is not. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1906263617 From angorya at openjdk.org Tue Jan 23 15:33:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Jan 2024 15:33:34 GMT Subject: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v4] In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 03:16:57 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created as the test is run with invokeLater. >> FIx is to make it run with invokeAndWait so that it waits for the scene to be created.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use Util.runAndWait Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1344#pullrequestreview-1839084198 From jpereda at openjdk.org Tue Jan 23 15:51:42 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 23 Jan 2024 15:51:42 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: <-11Te5n0irp3CMDxbUV3XcI42dVxvQ5f9oW1Qb8BV0Q=.213c10a3-703c-4065-80fe-6a47f06234dc@github.com> On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat Yes, for some reason, after applying the changes from this PR, there are Leave events. When it works: loaded gdk_seat_grab loaded gdk_display_get_default_seat GlassApplication::process_events: GDK_ENTER_NOTIFY found schema 'org.gnome.desktop.interface' and key 'scaling-factor' GlassApplication::process_events: GDK_ENTER_NOTIFY GlassApplication::process_events: GDK_MOTION_NOTIFY GlassApplication::process_events: GDK_BUTTON_PRESS GlassApplication::process_mouse_button: pressed GlassApplication::process_events: GDK_BUTTON_RELEASE GlassApplication::process_mouse_button: not pressed ... When it fails: loaded gdk_seat_grab loaded gdk_display_get_default_seat GlassApplication::process_events: GDK_LEAVE_NOTIFY GlassApplication::process_events: GDK_ENTER_NOTIFY GlassApplication::process_events: GDK_LEAVE_NOTIFY GlassApplication::process_events: GDK_ENTER_NOTIFY found schema 'org.gnome.desktop.interface' and key 'scaling-factor' GlassApplication::process_events: GDK_LEAVE_NOTIFY GlassApplication::process_events: GDK_MOTION_NOTIFY GlassApplication::process_events: GDK_BUTTON_PRESS GlassApplication::process_mouse_button: pressed Java_com_sun_glass_ui_gtk_GtkWindow__1ungrabFocus() ungrab focus() ... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1906355019 From javafx at ivoryemr.co.za Tue Jan 23 15:56:26 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Tue, 23 Jan 2024 17:56:26 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> Message-ID: Hi John and others, I don't think we are entirely on the same page, so here's the objective. The Goal: To determine if the FX animation thread and a SINGLE other thread can access Animation in a safe manner wrt play, stop, and resume. Non Goal: Multi-threaded access of Animation play, stop, and resume is NOT a goal. Wrt play() and resume(), it is ALWAYS safe to call them on a background thread because at this point the Animation isn't being processed by the FX thread as the "Animation" isn't contained in the AbstractPrimaryTimer receivers array. Wrt stop() from what I can tell there are no shared method calls that need synchronization (see audit below), however the following two boolean flags should be marked as volatile in order to ensure that animation is cut short if executing: TimelineClipCore.abort ClipEnvelope.abort This is simple enough to add to my original proposal of replacing the arrays in AbstractPrimaryTimer with CopyOnWriteArrayList which is thread safe and replicates the intended behavior in a clear and concise way. Here are the methods that are called when stop() is invoked: Timeline.stop() getStatus() clipCore.abort() isStopped() clipEnvelope.abortCurrentPulse() doStop() timer.removePulseReceiver(pulseReceiver); // After this point it doesn't matter setStatus(Status.STOPPED) doSetCurrentRate(0.0) jumpTo(Duration.ZERO) And for AbstractPrimaryTimer.timePulseImpl: AbstractPrimaryTimer.timePulseImpl Animation.PulseReceiver.timePulse Animation.doTimePulse clipEnvelope.timePulse animation.doPlayTo clipCore.playTo visitKeyFrame setTime animation.setCurrentTicks clipInterpolator.interpolate animation.doJumpTo sync(false) setCurrentTicks clipCore.jumpTo timeline.getStatus() clipInterpolator.interpolate Regards Jurgen On Tue, 23 Jan 2024 01:52:42 +0200, John Hendrikx wrote: > > This is not a good idea, the NPE is a symptom of the problem, but there > can be many more subtler problems (and new ones may surface after > >fixing the NPE) that can affect other animations making use of the > shared structures involved. For one thing, absent a method of > >synchronization, Java doesn't even guarantee that fields (or arrays) > contain the same value for all threads. So your thread may modify some > >state, but the FX thread wouldn't even know about it (or only > partially), and may make assumptions about an incorrect state, and then > make >further changes based on incorrect assumptions. > > A good example is that even a much simpler class like HashMap when > accessed by multiple threads can get into a really bad state. It will > >usually throw a "ConcurrentModificationException" (or perhaps a weird > NPE or IllegalStateException) to alert you that you're using it wrong > >-- but those are the **best** case scenarios... In the worst case > scenario, modifying a HashMap on multiple threads can result in an > infinite >loop -- this can happen when two modifications occur, both > updating the same bucket, and the threads end up changing things in such > a way >that the entries point to each other. Iterating it then (or > accessing the wrong key) will cause an infinite loop (not hypothetical, > I've had this >happen). > > I'm afraid that even the synchronization option I proposed is not very > realistic due to the amount of work it will entail. We'd need to trace > all >code paths that a call to play or stop could get to, and all those > code paths would need to be made thread safe. > > --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhaskar at openjdk.org Tue Jan 23 16:28:59 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 23 Jan 2024 16:28:59 GMT Subject: [jfx22u] Integrated: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Message-ID: A clean backport to jfx22u. The fix is for the canvas path constructor drawing with an old path on canvas, without the fix, the page crashes. I have tested the fix it is working with the fix and failing without the fix. ------------- Commit messages: - Backport 3cf9390f5fb2ad564eeec3a95744503f1b26dd0d Changes: https://git.openjdk.org/jfx22u/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=5&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323879 Stats: 62 lines in 2 files changed: 61 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx22u/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx22u/pull/5 From jbhaskar at openjdk.org Tue Jan 23 16:29:00 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 23 Jan 2024 16:29:00 GMT Subject: [jfx22u] Integrated: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 16:15:42 GMT, Jay Bhaskar wrote: > A clean backport to jfx22u. The fix is for the canvas path constructor drawing with an old path on canvas, without the fix, the page crashes. I have tested the fix it is working with the fix and failing without the fix. This pull request has now been integrated. Changeset: 63424643 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx22u/commit/63424643ddd58d3ad9e415f28d0578cb2f5e83a9 Stats: 62 lines in 2 files changed: 61 ins; 0 del; 1 mod 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Backport-of: 3cf9390f5fb2ad564eeec3a95744503f1b26dd0d ------------- PR: https://git.openjdk.org/jfx22u/pull/5 From john.hendrikx at gmail.com Tue Jan 23 16:36:16 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 23 Jan 2024 17:36:16 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> Message-ID: <33021a61-3734-7cf7-165a-8953f0758746@gmail.com> On 23/01/2024 16:56, Jurgen Doll wrote: > Hi John and others, > > I don't think we are entirely on the same page, so here's the objective. > > The Goal: To determine if the FX animation thread and a SINGLE other > thread can access Animation in a safe manner wrt play, stop, and resume. The number of threads is irrelevant really, it's either thread safe or it isn't. > > Non Goal: Multi-threaded access of Animation play, stop, and resume is > NOT a goal. > > Wrt play() and resume(), it is ALWAYS safe to call them on a > background thread because at this point the Animation isn't being > processed by the FX thread as the "Animation" isn't contained in the > AbstractPrimaryTimer receivers array. I'm afraid that is incorrect.? The fact that your animation is not running doesn't mean that AbstractPrimaryTimer isn't in use by other animations that are running.? These other animations are using the receivers array, and may be modifying it or reading from it from the FX thread. When you start your animation on a different thread, you are accessing these fields with a different thread, and modifying them.? Since the JVM is free to cache values and do other fancy things (like reordering read/writes) in the absence of synchronized/locking, there is no guarantee that the FX thread will see those modifications until these are flushed to main memory (or caches are synced).? Even then, the FX thread may have these values cached somewhere, and so it may not go all the way to main memory to see if its assumptions are now incorrect.? The only way to ensure this is with proper use of synchronization. So a hypothetical scenario: - AbstractPrimaryTimer has no receivers - A receiver is added via the FX thread, slot 0 is now filled and receiversLength is now 1.? Due to cache lines being large, it also read slot 1 (which is null) - You start your animation on another thread.? Since you didn't see the receivers array yet, you may see one of these states: ??? - The change from the FX thread was flushed to main memory, and you see [X, null] and receiversLength = 1 ??? - The change from the FX thread was partially flushed, and you see [X, null]? and receiversLength = 0 (!!) ??? - Nothing was flushed yet, and you see [null, null] and receiversLength = 0 Now, you can see that it would be very dangerous to proceed to modify the array based on half flushed information.? Something similar happens when you are the first to start an animation, and then another is started later.? If the changes of your thread are not flushed yet (or partially) then the FX thread will act on partially flushed data, or even see no receivers yet at all... --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Tue Jan 23 16:51:52 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 23 Jan 2024 16:51:52 GMT Subject: [jfx22] RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory Message-ID: This pull request contains a backport of commit [c1c52e5a](https://github.com/openjdk/jfx/commit/c1c52e5a42f9a4319487aa9db8e8fcbcf1ba02c8) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Martin Fox on 22 Jan 2024 and was reviewed by Michael Strau? and Kevin Rushforth. ------------- Commit messages: - Backport c1c52e5a42f9a4319487aa9db8e8fcbcf1ba02c8 Changes: https://git.openjdk.org/jfx/pull/1347/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322215 Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1347.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1347/head:pull/1347 PR: https://git.openjdk.org/jfx/pull/1347 From michaelstrau2 at gmail.com Tue Jan 23 16:58:31 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 23 Jan 2024 17:58:31 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> Message-ID: Hi Jurgen, even assuming that it was as easy as you say it is, there are more problems with this proposal. 1. If non-FX thread access to some methods is allowed, this will become a permanent addition to the API and a complication we have to deal with. There are proposals to refactor the animation framework, and this will become harder as a result. This also has direct implications on the implementation (you already pointed out two instances where fields would have to be marked volatile). Multithreaded code is never easy, even in easy cases. Mutation visibility will become a permanent question for future development. 2. We will need to specify that the `onFinished` handler might be invoked on the thread that calls play() or on the FX thread, or we need to make sure that `onFinished` is always invoked on the FX thread. 3. Any change that would expressly allow concurrent access to the FX framework will require lots of testing to ensure that we don't introduce regressions or race conditions. This competes with reviewer time for other features and fixes. 4. That being said, all of the effort might still be a good investment if the added value was significant. But I don't see the significance of it, as you can simply wrap the play() call in Platform.runLater and be done with it. On Tue, Jan 23, 2024 at 4:56?PM Jurgen Doll wrote: > > Hi John and others, > > I don't think we are entirely on the same page, so here's the objective. > > The Goal: To determine if the FX animation thread and a SINGLE other thread can access Animation in a safe manner wrt play, stop, and resume. > > Non Goal: Multi-threaded access of Animation play, stop, and resume is NOT a goal. > > Wrt play() and resume(), it is ALWAYS safe to call them on a background thread because at this point the Animation isn't being processed by the FX thread as the "Animation" isn't contained in the AbstractPrimaryTimer receivers array. > > Wrt stop() from what I can tell there are no shared method calls that need synchronization (see audit below), however the following two boolean flags should be marked as volatile in order to ensure that animation is cut short if executing: > > TimelineClipCore.abort > ClipEnvelope.abort > > This is simple enough to add to my original proposal of replacing the arrays in AbstractPrimaryTimer with CopyOnWriteArrayList which is thread safe and replicates the intended behavior in a clear and concise way. > > Here are the methods that are called when stop() is invoked: > > Timeline.stop() > > getStatus() > > clipCore.abort() > > isStopped() > > clipEnvelope.abortCurrentPulse() > > doStop() > > timer.removePulseReceiver(pulseReceiver); > > // After this point it doesn't matter > > setStatus(Status.STOPPED) > > doSetCurrentRate(0.0) > > jumpTo(Duration.ZERO) > > > And for AbstractPrimaryTimer.timePulseImpl: > > AbstractPrimaryTimer.timePulseImpl > > Animation.PulseReceiver.timePulse > > Animation.doTimePulse > > clipEnvelope.timePulse > > animation.doPlayTo > > clipCore.playTo > > visitKeyFrame > > setTime > > animation.setCurrentTicks > > clipInterpolator.interpolate > > animation.doJumpTo > > sync(false) > > setCurrentTicks > > clipCore.jumpTo > > timeline.getStatus() > > clipInterpolator.interpolate > > > Regards > Jurgen From kcr at openjdk.org Tue Jan 23 17:10:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Jan 2024 17:10:40 GMT Subject: [jfx22] RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 16:43:05 GMT, Martin Fox wrote: > This pull request contains a backport of commit [c1c52e5a](https://github.com/openjdk/jfx/commit/c1c52e5a42f9a4319487aa9db8e8fcbcf1ba02c8) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Martin Fox on 22 Jan 2024 and was reviewed by Michael Strau? and Kevin Rushforth. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1347#pullrequestreview-1839395473 From mfox at openjdk.org Tue Jan 23 17:24:05 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 23 Jan 2024 17:24:05 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v3] In-Reply-To: References: Message-ID: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Switch to using AtomicReference/AtomicInteger ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1337/files - new: https://git.openjdk.org/jfx/pull/1337/files/17609f6c..4154ae3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1337&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1337&range=01-02 Stats: 24 lines in 1 file changed: 4 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1337.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1337/head:pull/1337 PR: https://git.openjdk.org/jfx/pull/1337 From mfox at openjdk.org Tue Jan 23 17:26:39 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 23 Jan 2024 17:26:39 GMT Subject: [jfx22] Integrated: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 16:43:05 GMT, Martin Fox wrote: > This pull request contains a backport of commit [c1c52e5a](https://github.com/openjdk/jfx/commit/c1c52e5a42f9a4319487aa9db8e8fcbcf1ba02c8) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Martin Fox on 22 Jan 2024 and was reviewed by Michael Strau? and Kevin Rushforth. This pull request has now been integrated. Changeset: b4b576fa Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/b4b576fa1c1ba58f5069e2c40e1f636daeafa85c Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod 8322215: [win] OS events that close the stage can cause Glass to reference freed memory Reviewed-by: kcr Backport-of: c1c52e5a42f9a4319487aa9db8e8fcbcf1ba02c8 ------------- PR: https://git.openjdk.org/jfx/pull/1347 From kcr at openjdk.org Tue Jan 23 18:35:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Jan 2024 18:35:43 GMT Subject: RFR: 8324270: Update boot JDK to 21.0.2 In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 13:45:35 GMT, Ambarish Rapte wrote: > JDK 21.0.2 is now released : https://jdk.java.net/21/ > Did a full CI build including Webkit and executed all headful tests. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1345#pullrequestreview-1839622353 From kcr at openjdk.org Tue Jan 23 18:38:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Jan 2024 18:38:45 GMT Subject: Integrated: 8324237: Typo in comment in GlassApplication.m In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 14:52:19 GMT, Kevin Rushforth wrote: > Simple fix of a typo in a code comment. This pull request has now been integrated. Changeset: ff4f8e38 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/ff4f8e3871fcc29b97b99808dbe2f9b3da3642bc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8324237: Typo in comment in GlassApplication.m Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/1343 From kcr at openjdk.org Tue Jan 23 18:41:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Jan 2024 18:41:39 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v3] In-Reply-To: References: Message-ID: <0u6InT-kg-j6OKAUeSHoxLW1OlgRlQ6hMc3tcyRe8OY=.3fc9c791-19fd-4e73-9cc0-4c5313ba2565@github.com> On Tue, 23 Jan 2024 17:24:05 GMT, Martin Fox wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Switch to using AtomicReference/AtomicInteger Looks good. I tested it on both macOS (to confirm no deadlock) and on Windows (to test the fix). All good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1337#pullrequestreview-1839637887 From angorya at openjdk.org Tue Jan 23 18:58:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Jan 2024 18:58:40 GMT Subject: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v3] In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 17:24:05 GMT, Martin Fox wrote: >> On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. >> >> This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Switch to using AtomicReference/AtomicInteger verified on windows 11 with atomic references, thank you for making the change! I'll probably create a new bug for the misplaced IME window issue. For the misplaced IME window, I could only find this - [JDK-8088485](https://bugs.openjdk.org/browse/JDK-8088485) Windows 8, Chinese input method cadidate window is always placed at the bottom of the screen. Not sure if that's the same issue or not, as it is pretty old. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1337#pullrequestreview-1839689494 PR Comment: https://git.openjdk.org/jfx/pull/1337#issuecomment-1906725825 From kcr at openjdk.org Tue Jan 23 19:58:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Jan 2024 19:58:38 GMT Subject: RFR: 8308955: MediaPlayer/AudioClip skip data on seek/loop In-Reply-To: <8b44wHVs5kLdMTYUDFbd9R7lXkQcUlCKlJz1T3lzSfg=.43a2e522-a220-4ee4-b749-c21831c594ca@github.com> References: <8b44wHVs5kLdMTYUDFbd9R7lXkQcUlCKlJz1T3lzSfg=.43a2e522-a220-4ee4-b749-c21831c594ca@github.com> Message-ID: <9Vtf9lBdpKpzJqa6gDP3Mco-sdqF6_qioTQkmhX1UPw=.42b71e3e-2edc-4ae8-9e12-250f8f12e977@github.com> On Tue, 23 Jan 2024 03:13:11 GMT, Alexander Matveev wrote: > This is regression from JDK-8262365. JDK-8262365 introduced support for hardware pause for audio device. For some reason we will skip ~500 ms of audio data after such pause. It is not noticeable for large audio files, but for anything small like sound effects 1-3 seconds long it is noticeable and makes short audio effects unusable without re-creating MediaPlayer after each playback. Fix/workaround is to disable hardware pause. I did not figure out why hardware pause skips audio data. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1346#pullrequestreview-1839809111 From tsayao at openjdk.org Tue Jan 23 20:40:38 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 23 Jan 2024 20:40:38 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat Maybe this: https://docs.gtk.org/gdk3/enum.CrossingMode.html ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1906879038 From mfox at openjdk.org Tue Jan 23 21:26:40 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 23 Jan 2024 21:26:40 GMT Subject: Integrated: 8322784: JFXPanel calls InputMethodRequests on wrong thread In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote: > On Windows we need to ensure InputMethodRequests coming from JFXPanel are processed on the JavaFX application thread instead of the AWT EventQueue thread. This PR adds the runAndWait() calls to do that. > > This would be difficult to test on Windows without a fix for [JDK-8090267](https://bugs.openjdk.org/browse/JDK-8090267) so I've included the fix first proposed by @prsadhuk in PR #1169. If a developer uses the sample code provided in the JavaDoc to create and show a JFXPanel there's a good chance the JFXPanel will get focus before the scene has been set. To ensure AWT always treats the JFXPanel as an active IME client we return a stub version of the InputMethodRequests object if there's no scene. AWT will continue to ask for the InputMethodRequests and once the scene has been set the panel will return a non-stub version. This pull request has now been integrated. Changeset: 11706581 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/11706581053ca3fc38b175882e573858d0d42020 Stats: 43 lines in 2 files changed: 29 ins; 0 del; 14 mod 8322784: JFXPanel calls InputMethodRequests on wrong thread 8090267: JFXPanel Input Problem Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1337 From nlisker at gmail.com Wed Jan 24 08:30:47 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 24 Jan 2024 10:30:47 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: Message-ID: After playing around with the code sample, I think that this is not the right way to use the animation. The reason is that there is no point in starting the animation before the control is attached to the scenegraph, or even made visible. A small refactoring where, e.g., the controller class exposes a method to start the animation in onSucceeded or just calls it on the FX thread is enough. I never start an animation as part of the construction because it's not the right time. John suggested tying the lifecycle of the animation to the showing of the node, which also solves the problem. There are animations like PauseTransition or other non-interfering Timelines that could reasonably be run on a background thread. Or maybe just on an unconnected control. This could be a reason to not limit animation methods to the FX thread at the expense of possible user errors, but document the pitfall. I don't see a good use case for modifying controls in a background thread while still interacting with the scenegraph, hence for adding multithread support. - Nir On Mon, Jan 22, 2024, 12:59 Jurgen Doll wrote: > Here's an example as requested by Nir: > > public class FxTimeLineTest extends Application > > { > > private BorderPane bp = new BorderPane( new Label("Loading") ); > > > public static void main( String[] args ) { > > launch( FxTimeLineTest.class, args ); > > } > > > @Override > > public void start( Stage primaryStage ) throws Exception { > > new Thread( new LoadScene() ).start(); > > primaryStage.setScene( new Scene( bp, 300, 200 ) ); > > primaryStage.setTitle( "Memory Usage" ); > > primaryStage.show(); > > } > > > private class LoadScene extends Task { > > @Override protected Parent call() throws Exception { > > Parent p = FXMLLoader.load( getClass().getResource("TestView.fxml") ); > > Thread.sleep( 1000 ); > > return p; > > } > > > @Override protected void succeeded() { > > bp.setCenter( getValue() ); > > } > > > @Override protected void failed() { > > getException().printStackTrace(); > > } > > } > > } > > > ------------------------------------------------------------------------------------------------------ > > public class TestView > > { > > @FXML private Label memory; > > > private static final double MEGABYTE = 1024 * 1024; > > > @FXML private void initialize() > > { > > var updater = new Timeline > > ( > > new KeyFrame( Duration.seconds(2.5), event -> > > { > > var runtime = Runtime.getRuntime(); > > double maxMemory = runtime.maxMemory() / MEGABYTE; > > double usedMemory = (runtime.totalMemory() - runtime.freeMemory()) / > MEGABYTE; > > memory.setText( (int) usedMemory + " MB / " + (int) maxMemory +" MB" ); > > }) > > ); > > > updater.setCycleCount(Animation.INDEFINITE); > // This FXML is being loaded on a background thread > > updater.play(); > > } > > } > > > ------------------------------------------------------------------------------------------------------ > > TestView.fxml > > > > > > > > > > > > > > > > > > > > > > On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker wrote: > > Hi Jurgen, > > What I'm confused about the most is what it is you are actually trying to > do that necessitates the use of animations outside of the FX thread. You > said that you need to initialize controls on another thread, and that you > are using Task (both of which are fine), but how does playing animations > relate? Playing an animation is something that is done explicitly, usually > in order to manipulate data. Can you give a real use case, like a minimized > version of what you're doing? > > - Nir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javafx at ivoryemr.co.za Wed Jan 24 09:12:44 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Wed, 24 Jan 2024 11:12:44 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: <33021a61-3734-7cf7-165a-8953f0758746@gmail.com> References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> <33021a61-3734-7cf7-165a-8953f0758746@gmail.com> Message-ID: Hi John Thank you for the hypothetical receivers array scenario, I think it explains the problem exactly and is why replacing the array with CopyOnWriteArrayList removes the NPE. Your perspective then is that AbstractPrimaryTimer is designed for single threaded use only. If that is indeed so, then could you please explain the purpose of the receiversLocked and animationTimersLocked flags, as well as the point of receivers.clone() and animationTimers.clone() all of which indicate to the contrary. Thanks, regards Jurgen On Tue, 23 Jan 2024 18:36:16 +0200, John Hendrikx wrote: > On 23/01/2024 16:56, Jurgen Doll wrote: >> Hi John and others, >> >>>> I don't think we are entirely on the same page, so here's the >>>> objective. >> >> The Goal: To determine if the FX animation thread and a SINGLE other >> thread can access Animation in a >>safe manner wrt play, stop, and >> resume. > The number of threads is irrelevant really, it's either thread safe or > it isn't. >> >>>> Non Goal: Multi-threaded access of Animation play, stop, and resume >>>> is NOT a goal. >> >> Wrt play() and resume(), it is ALWAYS safe to call them on a background >> thread because at this point the >>Animation isn't being processed by >> the FX thread as the "Animation" isn't contained in the >> >>AbstractPrimaryTimer receivers array. > > I'm afraid that is incorrect. The fact that your animation is not > running doesn't mean that AbstractPrimaryTimer isn't in use by other > >animations that are running. These other animations are using the > receivers array, and may be modifying it or reading from it from the FX > >thread. > > When you start your animation on a different thread, you are accessing > these fields with a different thread, and modifying them. Since the > >JVM is free to cache values and do other fancy things (like reordering > read/writes) in the absence of synchronized/locking, there is no > >guarantee that the FX thread will see those modifications until these > are flushed to main memory (or caches are synced). Even then, the FX > >thread may have these values cached somewhere, and so it may not go all > the way to main memory to see if its assumptions are now >incorrect. > The only way to ensure this is with proper use of synchronization. > > So a hypothetical scenario: > > - AbstractPrimaryTimer has no receivers > - A receiver is added via the FX thread, slot 0 is now filled and > receiversLength is now 1. Due to cache lines being large, it also read > slot 1 >(which is null) > - You start your animation on another thread. Since you didn't see the > receivers array yet, you may see one of these states: > - The change from the FX thread was flushed to main memory, and you > see [X, null] and receiversLength = 1 > - The change from the FX thread was partially flushed, and you see > [X, null] and receiversLength = 0 (!!) > - Nothing was flushed yet, and you see [null, null] and > receiversLength = 0 > > Now, you can see that it would be very dangerous to proceed to modify > the array based on half flushed information. Something similar >happens > when you are the first to start an animation, and then another is > started later. If the changes of your thread are not flushed yet (or > >partially) then the FX thread will act on partially flushed data, or > even see no receivers yet at all... > > --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Jan 24 11:26:19 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 24 Jan 2024 12:26:19 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <036931b2-65f1-c8a5-72c0-f601c8797ac8@gmail.com> <33021a61-3734-7cf7-165a-8953f0758746@gmail.com> Message-ID: Hi Jurgen, See my answers inline. On 24/01/2024 10:12, Jurgen Doll wrote: > Hi John > > Thank you for the hypothetical receivers array scenario, I think it > explains the problem exactly and is why replacing the array with > CopyOnWriteArrayList removes the NPE. > > Your perspective then is that AbstractPrimaryTimer is designed for > single threaded use only. Yes, it looks that way simply because I see none of the usual concurrency controls (Locks, synchronized, volatile), and of course it fits with the general design of FX where almost all FX code is assumed to be accessed from a single thread. However, there are issues even with a single thread that must be taken care of, see below. > If that is indeed so, then could you please explain the purpose of the > receiversLocked and animationTimersLocked flags, as well as the point > of receivers.clone() and animationTimers.clone() all of which indicate > to the contrary. This is a pattern that we can also see in other areas of FX (see ExpressionHelper for example).? The clones and the use of a (non-synchronized) locking flag are to prevent issues with recursive calls on the same thread: During the notifying of all registered pulse receivers, the list is locked.? If one of those receivers decides to remove itself *during* the notification callback, then the list would be modified while iterating (as more receivers may need notifying still).? If that happens, it will instead see that the list is currently locked, and make a clone. Replacing the array with a CopyOnWriteArrayList would mean that copies will be made even when not needed.? Since the code seems to go through great lengths to even avoid the super fast ArrayList implementation (which IMHO would have been perfectly acceptable here) I can't help but wonder if that could have significant performance implications.? Perhaps pulse receivers are added/removed far more frequently than we would think. --John > > Thanks, regards > Jurgen > > > On Tue, 23 Jan 2024 18:36:16 +0200, John Hendrikx > wrote: > > On 23/01/2024 16:56, Jurgen Doll wrote: >> Hi John and others, >> >> I don't think we are entirely on the same page, so here's the >> objective. >> >> The Goal: To determine if the FX animation thread and a SINGLE >> other thread can access Animation in a safe manner wrt play, >> stop, and resume. > The number of threads is irrelevant really, it's either thread > safe or it isn't. >> >> Non Goal: Multi-threaded access of Animation play, stop, and >> resume is NOT a goal. >> >> Wrt play() and resume(), it is ALWAYS safe to call them on a >> background thread because at this point the Animation isn't being >> processed by the FX thread as the "Animation" isn't contained in >> the AbstractPrimaryTimer receivers array. > > I'm afraid that is incorrect.? The fact that your animation is not > running doesn't mean that AbstractPrimaryTimer isn't in use by > other animations that are running.? These other animations are > using the receivers array, and may be modifying it or reading from > it from the FX thread. > > When you start your animation on a different thread, you are > accessing these fields with a different thread, and modifying > them.? Since the JVM is free to cache values and do other fancy > things (like reordering read/writes) in the absence of > synchronized/locking, there is no guarantee that the FX thread > will see those modifications until these are flushed to main > memory (or caches are synced).? Even then, the FX thread may have > these values cached somewhere, and so it may not go all the way to > main memory to see if its assumptions are now incorrect.? The only > way to ensure this is with proper use of synchronization. > > So a hypothetical scenario: > > - AbstractPrimaryTimer has no receivers > - A receiver is added via the FX thread, slot 0 is now filled and > receiversLength is now 1.? Due to cache lines being large, it also > read slot 1 (which is null) > - You start your animation on another thread.? Since you didn't > see the receivers array yet, you may see one of these states: > ??? - The change from the FX thread was flushed to main memory, > and you see [X, null] and receiversLength = 1 > ??? - The change from the FX thread was partially flushed, and you > see [X, null]? and receiversLength = 0 (!!) > ??? - Nothing was flushed yet, and you see [null, null] and > receiversLength = 0 > > Now, you can see that it would be very dangerous to proceed to > modify the array based on half flushed information. Something > similar happens when you are the first to start an animation, and > then another is started later.? If the changes of your thread are > not flushed yet (or partially) then the FX thread will act on > partially flushed data, or even see no receivers yet at all... > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Jan 24 13:15:31 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2024 05:15:31 -0800 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: Message-ID: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> Thank you to Jurgen for raising the question and to Nir, John, and Michael for evaluating it. I conclude that there is insufficient motivation to revert the change in behavior implemented by JDK-8159048 to allow calling the play/pause/stop methods of Animation on a background thread. Doing so without making it fully multi-thread-safe would be asking for problems, and making it fully multi-thread-safe would be a fair bit of work to do it right without a clear benefit. We will proceed with the current approach and let JDK-8159048 stand. Further, we will proceed with https://bugs.openjdk.org/browse/JDK-8324219 which is under review in https://github.com/openjdk/jfx/pull/1342 -- Kevin On 1/24/2024 12:30 AM, Nir Lisker wrote: > After playing around with the code sample, I think that this is not > the right way to use the animation. The reason is that there is no > point in starting the animation before the control is attached to the > scenegraph, or even made visible. A small refactoring where, e.g., the > controller class exposes a method to start the animation in > onSucceeded or just calls it on the FX thread is enough. I never start > an animation as part of the construction because it's not the right > time. John suggested tying the lifecycle of the animation to the > showing of the node, which also solves the problem. > > There are animations like PauseTransition or other non-interfering > Timelines that could reasonably be run on a background thread. Or > maybe just on an unconnected control. This could be a reason to not > limit animation methods to the FX thread at the expense of possible > user errors, but document the pitfall. > > I don't see a good use case for modifying controls in a background > thread while still interacting with the scenegraph, hence for adding > multithread support. > > - Nir > > On Mon, Jan 22, 2024, 12:59 Jurgen Doll wrote: > > Here's an example as requested by Nir: > > publicclassFxTimeLineTest extendsApplication > > { > > privateBorderPane bp= newBorderPane( newLabel("Loading") ); > > publicstaticvoidmain( String[] args) { > > launch( FxTimeLineTest.class, args); > > } > > @Override > > publicvoidstart( Stage primaryStage) throwsException { > > newThread( newLoadScene() ).start(); > > primaryStage.setScene( newScene( bp, 300, 200 ) ); > > primaryStage.setTitle( "Memory Usage"); > > primaryStage.show(); > > } > > privateclassLoadScene extendsTask { > > @OverrideprotectedParent call() throwsException { > > Parent p= FXMLLoader.load( getClass().getResource("TestView.fxml") ); > > Thread.sleep( 1000 ); > > returnp; > > } > > @Overrideprotectedvoidsucceeded() { > > bp.setCenter( getValue() ); > > } > > @Overrideprotectedvoidfailed() { > > getException().printStackTrace(); > > } > > } > > } > > ------------------------------------------------------------------------------------------------------ > > > publicclassTestView > > { > > @FXMLprivateLabel memory; > > privatestaticfinaldoubleMEGABYTE= 1024 * 1024; > > @FXMLprivatevoidinitialize() > > { > > varupdater= newTimeline > > ( > > newKeyFrame( Duration.seconds(2.5), event-> > > { > > varruntime= Runtime.getRuntime(); > > doublemaxMemory= runtime.maxMemory() / MEGABYTE; > > doubleusedMemory= (runtime.totalMemory() - runtime.freeMemory()) / > MEGABYTE; > > memory.setText( (int) usedMemory+ " MB / "+ (int) maxMemory+" MB"); > > }) > > ); > > updater.setCycleCount(Animation.INDEFINITE); // This FXML is being > loaded on a background thread > > updater.play(); > > } > > } > > ------------------------------------------------------------------------------------------------------ > > > TestView.fxml > > > > > > > > fx:controller="TestView"> > > > > > > > > > > > > > On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker > wrote: > > Hi Jurgen, > > What I'm confused about the most is what it is you are > actually trying to do that necessitates?the use of animations > outside of the FX thread. You said that you need to initialize > controls on another thread, and that you are using Task (both > of which are fine), but how does playing animations relate? > Playing an animation is something that is done explicitly, > usually in order to manipulate data. Can you give a real use > case, like a minimized version of what you're doing? > > - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javafx at ivoryemr.co.za Wed Jan 24 13:29:39 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Wed, 24 Jan 2024 15:29:39 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> Message-ID: Hi Kevin If I may make one more final appeal then to an alternative solution please. Could we then instead of throwing an Exception rather invoke runLater if needed inside play, stop, and resume. Putting the onus on the developer is fine if it is the developer that is invoking the call, but if it's in a library then it's a no go. In my application I have two libraries that I know of where this happens. The major problem is that with FX22 as it now stands my application just crashes because play() does an FX thread check and throws an Exception which it never did before. There are bound to be other applications out there that are going to find themselves in a similar position. PLEASE ! Regards Jurgen On Wed, 24 Jan 2024 15:15:31 +0200, Kevin Rushforth wrote: > Thank you to Jurgen for raising the question and to Nir, John, and > Michael for evaluating it. > > I conclude that there is insufficient motivation to revert the change in > behavior implemented by JDK-8159048 to allow calling the > play/>pause/stop methods of Animation on a background thread. Doing so > without making it fully multi-thread-safe would be asking for problems, > >and making it fully multi-thread-safe would be a fair bit of work to do > it right without a clear benefit. > > We will proceed with the current approach and let JDK-8159048 stand. > Further, we will proceed with > https://bugs.openjdk.org/browse/>JDK-8324219 which is under review in > https://github.com/openjdk/jfx/pull/1342 > > -- Kevin > > On 1/24/2024 12:30 AM, Nir Lisker wrote: >> After playing around with the code sample, I think that this is not the >> right way to use the animation. The reason is that there is >>no point >> in starting the animation before the control is attached to the >> scenegraph, or even made visible. A small refactoring >>where, e.g., >> the controller class exposes a method to start the animation in >> onSucceeded or just calls it on the FX thread is >>enough. I never >> start an animation as part of the construction because it's not the >> right time. John suggested tying the lifecycle >>of the animation to >> the showing of the node, which also solves the problem. >> There are animations like PauseTransition or other non-interfering >> Timelines that could reasonably be run on a background >>thread. Or >> maybe just on an unconnected control. This could be a reason to not >> limit animation methods to the FX thread at >>the expense of possible >> user errors, but document the pitfall. >> >> I don't see a good use case for modifying controls in a background >> thread while still interacting with the scenegraph, hence for >>adding >> multithread support. >> - Nir >> >> On Mon, Jan 22, 2024, 12:59 Jurgen Doll wrote: >>> Here's an example as requested by Nir: >>> >>>>>> public class FxTimeLineTest extends Application >>> >>> { >>> >>> private BorderPane bp = new BorderPane( new Label("Loading") ); >>> >>> >>> >>> public static void main( String[] args ) { >>> >>> launch( FxTimeLineTest.class, args ); >>> >>> } >>> >>> >>> >>> @Override >>> >>> public void start( Stage primaryStage ) throws Exception { >>> >>> new Thread( new LoadScene() ).start(); >>> >>> primaryStage.setScene(new Scene( bp, 300, 200 ) ); >>> >>> primaryStage.setTitle( "Memory Usage" ); >>> >>> primaryStage.show(); >>> >>> } >>> >>> >>> >>> private class LoadScene extends Task { >>> >>> @Override protected Parent call() throws Exception { >>> >>> Parent p = FXMLLoader.load( getClass( >>> ).getResource("TestView.fxml") ); >>> >>> Thread.sleep( 1000 ); >>> >>> return p; >>> >>> } >>> >>> >>> >>> @Override protected void succeeded() { >>> >>> bp.setCenter( getValue() ); >>> >>> } >>> >>> >>> >>> @Override protected void failed() { >>> >>> getException().printStackTrace(); >>> >>> } >>> >>> } >>> >>> } >>> >>> >>> ------------------------------------------------------------------------------------------------------ >>> >>> >>> public class TestView >>> >>> { >>> >>> @FXML private Label memory; >>> >>> >>> >>> private static final double MEGABYTE = 1024 * 1024; >>> >>> >>> >>> @FXML private void initialize() >>> >>> { >>> >>> var updater = new Timeline >>> >>> ( >>> >>> new K >>> eyFrame( Duration.seconds(2.5), event -> >>> >>> { >>> >>> var runtime = Runtime.getRuntime(); >>> >>> double maxMemory = runtime.maxMemory() / MEGABYTE; >>> >>> double usedMemory = (runtime.totalMemory() - >>> runtime.freeMemory()) / MEGABYTE; >>> >>> memory.setText( (int) usedMemory + " MB / " + (int) >>> maxMemory +" MB" ); >>> >>> }) >>> >>> ); >>> >>> >>> >>> updater.setCycleCount(Animation.INDEFINITE); >>> // This FXML is being loaded on a background thread >>> >>> updater.play(); >>> >>> } >>> >>> } >>> >>> >>> ------------------------------------------------------------------------------------------------------ >>> >>> TestView.fxml >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> fx:controller="TestView"> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker >>> wrote: >>> >>>> Hi Jurgen, >>>> What I'm confused about the most is what it is you are actually >>>> trying to do that necessitates the use of animations outside >>>>of >>>> the FX thread. You said that you need to initialize controls on >>>> another thread, and that you are using Task (both of which >>>>are >>>> fine), but how does playing animations relate? Playing an animation >>>> is something that is done explicitly, usually in >>>>order to >>>> manipulate data. Can you give a real use case, like a minimized >>>> version of what you're doing? >>>> >>>> - Nir > -- Using Opera's mail client: http://www.opera.com/mail/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Jan 24 14:20:45 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2024 06:20:45 -0800 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> Message-ID: <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> I'd like to hear from the others on this. I don't see any fundamental problem with having the play/pause/stop methods wrap their implementation in a runLater (if not on the FX Application thread already), and documenting that it does so, if we can get general agreement. -- Kevin On 1/24/2024 5:29 AM, Jurgen Doll wrote: > Hi Kevin > > If I may make one more final appeal then to an alternative solution > please. > > Could we then instead of throwing an Exception rather invoke runLater > if needed inside play, stop, and resume. > > Putting the onus on the developer is fine if it is the developer that > is invoking the call, but if it's in a library then it's a no go. > > In my application I have two libraries that I know of where this > happens. The major problem is that with FX22 as it now stands my > application just crashes because play() does an FX thread check and > throws an Exception which it never did before. There are bound to be > other applications out there that are going to find themselves in a > similar position. > > PLEASE ! > > Regards > Jurgen > > > > On Wed, 24 Jan 2024 15:15:31 +0200, Kevin Rushforth > wrote: > > Thank you to Jurgen for raising the question and to Nir, John, and > Michael for evaluating it. > > I conclude that there is insufficient motivation to revert the > change in behavior implemented by JDK-8159048 to allow calling the > play/pause/stop methods of Animation on a background thread. Doing > so without making it fully multi-thread-safe would be asking for > problems, and making it fully multi-thread-safe would be a fair > bit of work to do it right without a clear benefit. > > We will proceed with the current approach and let JDK-8159048 > stand. Further, we will proceed with > https://bugs.openjdk.org/browse/JDK-8324219 which is under review > in https://github.com/openjdk/jfx/pull/1342 > > -- Kevin > > On 1/24/2024 12:30 AM, Nir Lisker wrote: >> After playing around with the code sample, I think that this is >> not the right way to use the animation. The reason is that there >> is no point in starting the animation before the control is >> attached to the scenegraph, or even made visible. A small >> refactoring where, e.g., the controller class exposes a method to >> start the animation in onSucceeded or just calls it on the FX >> thread is enough. I never start an animation as part of the >> construction because it's not the right time. John suggested >> tying the lifecycle of the animation to the showing of the node, >> which also solves the problem. >> >> There are animations like PauseTransition or other >> non-interfering Timelines that could reasonably be run on a >> background thread. Or maybe just on an unconnected control. This >> could be a reason to not limit animation methods to the FX thread >> at the expense of possible user errors, but document the pitfall. >> >> I don't see a good use case for modifying controls in a >> background thread while still interacting with the scenegraph, >> hence for adding multithread support. >> >> - Nir >> >> On Mon, Jan 22, 2024, 12:59 Jurgen Doll >> wrote: >> >> Here's an example as requested by Nir: >> >> publicclassFxTimeLineTest extendsApplication >> >> { >> >> privateBorderPane bp= newBorderPane( newLabel("Loading") ); >> >> publicstaticvoidmain( String[] args) { >> >> launch( FxTimeLineTest.class, args); >> >> } >> >> @Override >> >> publicvoidstart( Stage primaryStage) throwsException { >> >> newThread( newLoadScene() ).start(); >> >> primaryStage.setScene( newScene( bp, 300, 200 ) ); >> >> primaryStage.setTitle( "Memory Usage"); >> >> primaryStage.show(); >> >> } >> >> privateclassLoadScene extendsTask { >> >> @OverrideprotectedParent call() throwsException { >> >> Parent p= FXMLLoader.load( getClass( >> ).getResource("TestView.fxml") ); >> >> Thread.sleep( 1000 ); >> >> returnp; >> >> } >> >> @Overrideprotectedvoidsucceeded() { >> >> bp.setCenter( getValue() ); >> >> } >> >> @Overrideprotectedvoidfailed() { >> >> getException().printStackTrace(); >> >> } >> >> } >> >> } >> >> ------------------------------------------------------------------------------------------------------ >> >> >> publicclassTestView >> >> { >> >> @FXMLprivateLabel memory; >> >> privatestaticfinaldoubleMEGABYTE= 1024 * 1024; >> >> @FXMLprivatevoidinitialize() >> >> { >> >> varupdater= newTimeline >> >> ( >> >> newK eyFrame( Duration.seconds(2.5), event-> >> >> { >> >> varruntime= Runtime.getRuntime(); >> >> doublemaxMemory= runtime.maxMemory() / MEGABYTE; >> >> doubleusedMemory= (runtime.totalMemory() - >> runtime.freeMemory()) / MEGABYTE; >> >> memory.setText( (int) usedMemory+ " MB / "+ (int) maxMemory+" >> MB"); >> >> }) >> >> ); >> >> updater.setCycleCount(Animation.INDEFINITE); // This FXML is >> being loaded on a background thread >> >> updater.play(); >> >> } >> >> } >> >> ------------------------------------------------------------------------------------------------------ >> >> >> TestView.fxml >> >> >> >> >> >> >> >> > fx:controller="TestView"> >> >> >> >> >> >> >> >> >> >> >> >> >> On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker >> wrote: >> >> Hi Jurgen, >> >> What I'm confused about the most is what it is you are >> actually trying to do that necessitates?the use of >> animations outside of the FX thread. You said that you >> need to initialize controls on another thread, and that >> you are using Task (both of which are fine), but how does >> playing animations relate? Playing an animation is >> something that is done explicitly, usually in order to >> manipulate data. Can you give a real use case, like a >> minimized version of what you're doing? >> >> - Nir >> > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Jan 24 14:52:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 24 Jan 2024 14:52:42 GMT Subject: RFR: 8260013: Snapshot does not work for nodes in a subscene [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 15:33:49 GMT, Lukasz Kostyra wrote: >> Originally this issue showed the problem of Node being incorrectly rendered (clipped) when snapshotting, compared to a snapshot of the whole Scene. Later on there was another problem added - lights not being taken into account if they are added to a SubScene. >> >> As it later turned out, the original problem from this bug report is a problem with ParallelCamera incorrectly estimating near/far clipping planes, which just happened to reveal itself while snapshotting a Node. During testing I found out you can make the Node clip regardless of snapshot mechanism. Clipping issue was moved to a separate bug report and this PR only fixes the inconsistency in lights being gathered for a snapshot. >> >> `Scene.doSnapshot()` was expanded to also check if SubScene provided to it is non-null and to fetch lights assigned to it. Scenario was tested with added SnapshotLightsTest. >> >> Rest of the tests were checked and don't produce any noticeable regressions. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > doSnapshot: Replace light accumulation code > > Uses suggested simpler implementation using Java's Streams. > > Needed an additional check in NGShape3D, otherwise IndexOutOfBounds was > thrown This looks mostly correct except for the case where both the Scene and the SubScene have lights. It seems worth adding a test for this case as well. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1353: > 1351: Stream lights = Stream.concat( > 1352: Optional.ofNullable(scene).stream().flatMap(s -> s.lights.stream()).map(LightBase::getPeer), > 1353: Optional.ofNullable(subScene).stream().flatMap(s -> s.getLights().stream()).map(LightBase::getPeer) For a node in a SubScene this will apply the lights from both the Scene and SubScene, which is not the right behavior. It should apply the lights from `scene` only if `subScene` is null. ------------- PR Review: https://git.openjdk.org/jfx/pull/1332#pullrequestreview-1841522831 PR Review Comment: https://git.openjdk.org/jfx/pull/1332#discussion_r1465002946 From lbourges at openjdk.org Wed Jan 24 14:59:53 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 24 Jan 2024 14:59:53 GMT Subject: RFR: JDK-8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 + minor syntax fixes (merge with latest MarlinFX) Message-ID: Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java ------------- Commit messages: - JDK-8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 + minor syntax fixes (merge with latest MarlinFX) Changes: https://git.openjdk.org/jfx/pull/1348/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1348&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312603 Stats: 366 lines in 14 files changed: 312 ins; 10 del; 44 mod Patch: https://git.openjdk.org/jfx/pull/1348.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1348/head:pull/1348 PR: https://git.openjdk.org/jfx/pull/1348 From kcr at openjdk.org Wed Jan 24 15:05:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 24 Jan 2024 15:05:43 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since parameter to deprecation annotation Since there is now no hurry to do this, I think we should proceed as follows: 1. Target this deprecation-for-removal enhancement, including adding the needed base class methods from the two subclasses that are being deprecated, to JavaFX 23. This would be done first, as soon as we settle on the new base class methods. 2. Proceed with [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964) / PR #1316 . 3. Later, probably in JavaFX 24, proceed with [JDK-8323706](https://bugs.openjdk.org/browse/JDK-8323706) / PR #1333 to remove SimpleSelector and CompoundSelector from the public API (by moving them to an internal package). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1908313239 From kcr at openjdk.org Wed Jan 24 15:11:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 24 Jan 2024 15:11:39 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 + minor syntax fixes (merge with latest MarlinFX) In-Reply-To: References: Message-ID: On Wed, 24 Jan 2024 14:55:21 GMT, Laurent Bourg?s wrote: > Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java @bourgesl You will need to change the title of this PR to match that of the JBS bug. You can add the additional information by using the `/summary` command if you like. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1908324499 From nlisker at gmail.com Wed Jan 24 18:26:33 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 24 Jan 2024 20:26:33 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: These are the options I see as reasonable: 1. Document that these methods *must* be run on the FX thread and throw an exception otherwise. This leaves it to the responsibility of the user. However, this will cause the backwards compatibility problems that Jugen brought up. As a side note, we do this in other methods already, but I always questioned why let the developer do something illegal - if there's only one execution path, force it. 2. Document that these methods *are* run on the FX thread (the user doesn't need to do anything) and change the implementation to call runLater(...) internally unless they are already on the FX thread. This will be backwards compatible for the most part (see option 3). The downside might be some surprise when these methods behave differently. 3. Document that it's *recommended* that these methods be run on the FX thread and let the user be responsible for the threading. We can explain that manipulating nodes that are attached to an active scenegraph should be avoided. I prefer option 2 over 1 regardless of the backwards compatibility issue even, but would like to know if I'm missing something here because in theory this change could be done to any "must run on the FX thread" method and I question why the user had the option to get an exception. Option 3 is risky and I wager a guess that it will be used wrongly more often than not. It does allow some (what I would call) valid niche uses. I never did it. On Wed, Jan 24, 2024 at 4:21?PM Kevin Rushforth wrote: > I'd like to hear from the others on this. I don't see any fundamental > problem with having the play/pause/stop methods wrap their implementation > in a runLater (if not on the FX Application thread already), and > documenting that it does so, if we can get general agreement. > > -- Kevin > > > On 1/24/2024 5:29 AM, Jurgen Doll wrote: > > Hi Kevin > > If I may make one more final appeal then to an alternative solution please. > > Could we then instead of throwing an Exception rather invoke runLater if > needed inside play, stop, and resume. > > Putting the onus on the developer is fine if it is the developer that is > invoking the call, but if it's in a library then it's a no go. > > In my application I have two libraries that I know of where this happens. > The major problem is that with FX22 as it now stands my application just > crashes because play() does an FX thread check and throws an Exception > which it never did before. There are bound to be other applications out > there that are going to find themselves in a similar position. > > PLEASE ! > > Regards > Jurgen > > > > On Wed, 24 Jan 2024 15:15:31 +0200, Kevin Rushforth > wrote: > > Thank you to Jurgen for raising the question and to Nir, John, and Michael > for evaluating it. > > I conclude that there is insufficient motivation to revert the change in > behavior implemented by JDK-8159048 to allow calling the play/pause/stop > methods of Animation on a background thread. Doing so without making it > fully multi-thread-safe would be asking for problems, and making it fully > multi-thread-safe would be a fair bit of work to do it right without a > clear benefit. > > We will proceed with the current approach and let JDK-8159048 stand. > Further, we will proceed with https://bugs.openjdk.org/browse/JDK-8324219 > which is under review in https://github.com/openjdk/jfx/pull/1342 > > -- Kevin > > On 1/24/2024 12:30 AM, Nir Lisker wrote: > > After playing around with the code sample, I think that this is not the > right way to use the animation. The reason is that there is no point in > starting the animation before the control is attached to the scenegraph, or > even made visible. A small refactoring where, e.g., the controller class > exposes a method to start the animation in onSucceeded or just calls it on > the FX thread is enough. I never start an animation as part of the > construction because it's not the right time. John suggested tying the > lifecycle of the animation to the showing of the node, which also solves > the problem. > > There are animations like PauseTransition or other non-interfering > Timelines that could reasonably be run on a background thread. Or maybe > just on an unconnected control. This could be a reason to not limit > animation methods to the FX thread at the expense of possible user errors, > but document the pitfall. > > I don't see a good use case for modifying controls in a background thread > while still interacting with the scenegraph, hence for adding multithread > support. > > - Nir > > On Mon, Jan 22, 2024, 12:59 Jurgen Doll wrote: > >> Here's an example as requested by Nir: >> >> public class FxTimeLineTest extends Application >> >> { >> >> private BorderPane bp = new BorderPane( new Label("Loading") ); >> >> public static void main( String[] args ) { >> >> launch( FxTimeLineTest.class, args ); >> >> } >> >> @Override >> >> public void start( Stage primaryStage ) throws Exception { >> >> new Thread( new LoadScene() ).start(); >> >> primaryStage.setScene( new Scene( bp, 300, 200 ) ); >> >> primaryStage.setTitle( "Memory Usage" ); >> >> primaryStage.show(); >> >> } >> >> private class LoadScene extends Task { >> >> @Override protected Parent call() throws Exception { >> >> Parent p = FXMLLoader.load( getClass( ).getResource("TestView.fxml") ); >> >> Thread.sleep( 1000 ); >> >> return p; >> >> } >> >> @Override protected void succeeded() { >> >> bp.setCenter( getValue() ); >> >> } >> >> @Override protected void failed() { >> >> getException().printStackTrace(); >> >> } >> >> } >> >> } >> >> >> ------------------------------------------------------------------------------------------------------ >> >> public class TestView >> >> { >> >> @FXML private Label memory; >> >> private static final double MEGABYTE = 1024 * 1024; >> >> @FXML private void initialize() >> >> { >> >> var updater = new Timeline >> >> ( >> >> new K eyFrame( Duration.seconds(2.5), event -> >> >> { >> >> var runtime = Runtime.getRuntime(); >> >> double maxMemory = runtime.maxMemory() / MEGABYTE; >> >> double usedMemory = (runtime.totalMemory() - runtime.freeMemory()) / >> MEGABYTE; >> >> memory.setText( (int) usedMemory + " MB / " + (int) maxMemory +" MB" ); >> >> }) >> >> ); >> >> updater.setCycleCount(Animation.INDEFINITE); // This FXML is being >> loaded on a background thread >> >> updater.play(); >> >> } >> >> } >> >> >> ------------------------------------------------------------------------------------------------------ >> >> TestView.fxml >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker wrote: >> >> Hi Jurgen, >> >> What I'm confused about the most is what it is you are actually trying to >> do that necessitates the use of animations outside of the FX thread. You >> said that you need to initialize controls on another thread, and that you >> are using Task (both of which are fine), but how does playing animations >> relate? Playing an animation is something that is done explicitly, usually >> in order to manipulate data. Can you give a real use case, like a minimized >> version of what you're doing? >> >> - Nir >> >> > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Jan 24 18:42:19 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2024 10:42:19 -0800 Subject: [External] : Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: I also now favor option 2 and was in the process of writing something up recommending that we do that. Phil and I (and a couple others) had an offline discussion and think this is the way to go. Given the short amount of time to get this into 22, I will file the JBS issue in the next hour or so. Nir: if you want to take it, that would be great. Otherwise, I will do it. We need the PR and CSR filed before the end of this week. Regarding other methods that choose option 1, many of them are more complicated (e.g., scene mutation can be done on a background thread as long as the scene is not "showing") or must be synchronous. Animation starts something that conceptually happens later on the FX animation thread anyway, so wrapping it in a runLater (if not already on the right thread) doesn't really change the semantics in an appreciable way. -- Kevin On 1/24/2024 10:26 AM, Nir Lisker wrote: > These are the options I see as reasonable: > > 1. Document that these methods *must* be run on the FX thread and > throw an exception otherwise. This leaves it to the responsibility of > the user. However, this will cause the backwards compatibility > problems that Jugen brought up. As a side note, we do this in other > methods already, but I always questioned why let the developer do > something illegal - if there's only one execution path, force it. > 2. Document that these methods *are* run on the FX thread (the user > doesn't need to do anything) and change the implementation to call > runLater(...) internally unless they are already on the FX thread. > This will be backwards compatible for the most part (see option 3). > The downside might be some surprise when these methods behave differently. > 3. Document that it's *recommended* that these methods be run on the > FX thread and let the user be responsible for the threading. We can > explain that manipulating nodes that are attached to an active > scenegraph should be avoided. > > I prefer option 2 over 1 regardless of the backwards compatibility > issue even, but would like to know if I'm missing something here > because in theory this change could be done to any "must run on the FX > thread" method and I question why the user had the option to get an > exception. > Option 3 is risky and I wager a guess that it will be used wrongly > more often than not. It does allow some (what I would call) valid > niche uses. I never did it. > > On Wed, Jan 24, 2024 at 4:21?PM Kevin Rushforth > wrote: > > I'd like to hear from the others on this. I don't see any > fundamental problem with having the play/pause/stop methods wrap > their implementation in a runLater (if not on the FX Application > thread already), and documenting that it does so, if we can get > general agreement. > > -- Kevin > > > On 1/24/2024 5:29 AM, Jurgen Doll wrote: >> Hi Kevin >> >> If I may make one more final appeal then to an alternative >> solution please. >> >> Could we then instead of throwing an Exception rather invoke >> runLater if needed inside play, stop, and resume. >> >> Putting the onus on the developer is fine if it is the developer >> that is invoking the call, but if it's in a library then it's a >> no go. >> >> In my application I have two libraries that I know of where this >> happens. The major problem is that with FX22 as it now stands my >> application just crashes because play() does an FX thread check >> and throws an Exception which it never did before. There are >> bound to be other applications out there that are going to find >> themselves in a similar position. >> >> PLEASE ! >> >> Regards >> Jurgen >> >> >> >> On Wed, 24 Jan 2024 15:15:31 +0200, Kevin Rushforth >> >> wrote: >> >> Thank you to Jurgen for raising the question and to Nir, >> John, and Michael for evaluating it. >> >> I conclude that there is insufficient motivation to revert >> the change in behavior implemented by JDK-8159048 to allow >> calling the play/pause/stop methods of Animation on a >> background thread. Doing so without making it fully >> multi-thread-safe would be asking for problems, and making it >> fully multi-thread-safe would be a fair bit of work to do it >> right without a clear benefit. >> >> We will proceed with the current approach and let JDK-8159048 >> stand. Further, we will proceed with >> https://bugs.openjdk.org/browse/JDK-8324219 which is under >> review in https://github.com/openjdk/jfx/pull/1342 >> >> >> -- Kevin >> >> On 1/24/2024 12:30 AM, Nir Lisker wrote: >>> After playing around with the code sample, I think that this >>> is not the right way to use the animation. The reason is >>> that there is no point in starting the animation before the >>> control is attached to the scenegraph, or even made visible. >>> A small refactoring where, e.g., the controller class >>> exposes a method to start the animation in onSucceeded or >>> just calls it on the FX thread is enough. I never start an >>> animation as part of the construction because it's not the >>> right time. John suggested tying the lifecycle of the >>> animation to the showing of the node, which also solves the >>> problem. >>> >>> There are animations like PauseTransition or other >>> non-interfering Timelines that could reasonably be run on a >>> background thread. Or maybe just on an unconnected control. >>> This could be a reason to not limit animation methods to the >>> FX thread at the expense of possible user errors, but >>> document the pitfall. >>> >>> I don't see a good use case for modifying controls in a >>> background thread while still interacting with the >>> scenegraph, hence for adding multithread support. >>> >>> - Nir >>> >>> On Mon, Jan 22, 2024, 12:59 Jurgen Doll >>> wrote: >>> >>> Here's an example as requested by Nir: >>> >>> publicclassFxTimeLineTest extendsApplication >>> >>> { >>> >>> privateBorderPane bp= newBorderPane( newLabel("Loading") ); >>> >>> publicstaticvoidmain( String[] args) { >>> >>> launch( FxTimeLineTest.class, args); >>> >>> } >>> >>> @Override >>> >>> publicvoidstart( Stage primaryStage) throwsException { >>> >>> newThread( newLoadScene() ).start(); >>> >>> primaryStage.setScene( newScene( bp, 300, 200 ) ); >>> >>> primaryStage.setTitle( "Memory Usage"); >>> >>> primaryStage.show(); >>> >>> } >>> >>> privateclassLoadScene extendsTask { >>> >>> @OverrideprotectedParent call() throwsException { >>> >>> Parent p= FXMLLoader.load( getClass( >>> ).getResource("TestView.fxml") ); >>> >>> Thread.sleep( 1000 ); >>> >>> returnp; >>> >>> } >>> >>> @Overrideprotectedvoidsucceeded() { >>> >>> bp.setCenter( getValue() ); >>> >>> } >>> >>> @Overrideprotectedvoidfailed() { >>> >>> getException().printStackTrace(); >>> >>> } >>> >>> } >>> >>> } >>> >>> ------------------------------------------------------------------------------------------------------ >>> >>> >>> publicclassTestView >>> >>> { >>> >>> @FXMLprivateLabel memory; >>> >>> privatestaticfinaldoubleMEGABYTE= 1024 * 1024; >>> >>> @FXMLprivatevoidinitialize() >>> >>> { >>> >>> varupdater= newTimeline >>> >>> ( >>> >>> newK eyFrame( Duration.seconds(2.5), event-> >>> >>> { >>> >>> varruntime= Runtime.getRuntime(); >>> >>> doublemaxMemory= runtime.maxMemory() / MEGABYTE; >>> >>> doubleusedMemory= (runtime.totalMemory() - >>> runtime.freeMemory()) / MEGABYTE; >>> >>> memory.setText( (int) usedMemory+ " MB / "+ (int) >>> maxMemory+" MB"); >>> >>> }) >>> >>> ); >>> >>> updater.setCycleCount(Animation.INDEFINITE); // This >>> FXML is being loaded on a background thread >>> >>> updater.play(); >>> >>> } >>> >>> } >>> >>> ------------------------------------------------------------------------------------------------------ >>> >>> >>> TestView.fxml >>> >>> >>> >>> >>> >>> >>> >>> >> fx:controller="TestView"> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker >>> wrote: >>> >>> Hi Jurgen, >>> >>> What I'm confused about the most is what it is you >>> are actually trying to do that necessitates?the use >>> of animations outside of the FX thread. You said >>> that you need to initialize controls on another >>> thread, and that you are using Task (both of which >>> are fine), but how does playing animations relate? >>> Playing an animation is something that is done >>> explicitly, usually in order to manipulate data. Can >>> you give a real use case, like a minimized version >>> of what you're doing? >>> >>> - Nir >>> >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Jan 24 18:50:59 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 24 Jan 2024 20:50:59 +0200 Subject: [External] : Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: If there's an agreement, I can do it tomorrow. It will effectively revert JDK-8159048 and supersede JDK-8324219. On Wed, Jan 24, 2024 at 8:42?PM Kevin Rushforth wrote: > I also now favor option 2 and was in the process of writing something up > recommending that we do that. Phil and I (and a couple others) had an > offline discussion and think this is the way to go. > > Given the short amount of time to get this into 22, I will file the JBS > issue in the next hour or so. > > Nir: if you want to take it, that would be great. Otherwise, I will do it. > We need the PR and CSR filed before the end of this week. > > Regarding other methods that choose option 1, many of them are more > complicated (e.g., scene mutation can be done on a background thread as > long as the scene is not "showing") or must be synchronous. Animation > starts something that conceptually happens later on the FX animation thread > anyway, so wrapping it in a runLater (if not already on the right thread) > doesn't really change the semantics in an appreciable way. > > -- Kevin > > > On 1/24/2024 10:26 AM, Nir Lisker wrote: > > These are the options I see as reasonable: > > 1. Document that these methods *must* be run on the FX thread and throw an > exception otherwise. This leaves it to the responsibility of the user. > However, this will cause the backwards compatibility problems that Jugen > brought up. As a side note, we do this in other methods already, but I > always questioned why let the developer do something illegal - if there's > only one execution path, force it. > 2. Document that these methods *are* run on the FX thread (the user > doesn't need to do anything) and change the implementation to call > runLater(...) internally unless they are already on the FX thread. This > will be backwards compatible for the most part (see option 3). The downside > might be some surprise when these methods behave differently. > 3. Document that it's *recommended* that these methods be run on the FX > thread and let the user be responsible for the threading. We can explain > that manipulating nodes that are attached to an active scenegraph should be > avoided. > > I prefer option 2 over 1 regardless of the backwards compatibility issue > even, but would like to know if I'm missing something here because in > theory this change could be done to any "must run on the FX thread" method > and I question why the user had the option to get an exception. > Option 3 is risky and I wager a guess that it will be used wrongly more > often than not. It does allow some (what I would call) valid niche uses. I > never did it. > > On Wed, Jan 24, 2024 at 4:21?PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I'd like to hear from the others on this. I don't see any fundamental >> problem with having the play/pause/stop methods wrap their implementation >> in a runLater (if not on the FX Application thread already), and >> documenting that it does so, if we can get general agreement. >> >> -- Kevin >> >> >> On 1/24/2024 5:29 AM, Jurgen Doll wrote: >> >> Hi Kevin >> >> If I may make one more final appeal then to an alternative solution >> please. >> >> Could we then instead of throwing an Exception rather invoke runLater if >> needed inside play, stop, and resume. >> >> Putting the onus on the developer is fine if it is the developer that is >> invoking the call, but if it's in a library then it's a no go. >> >> In my application I have two libraries that I know of where this happens. >> The major problem is that with FX22 as it now stands my application just >> crashes because play() does an FX thread check and throws an Exception >> which it never did before. There are bound to be other applications out >> there that are going to find themselves in a similar position. >> >> PLEASE ! >> >> Regards >> Jurgen >> >> >> >> On Wed, 24 Jan 2024 15:15:31 +0200, Kevin Rushforth >> wrote: >> >> Thank you to Jurgen for raising the question and to Nir, John, and >> Michael for evaluating it. >> >> I conclude that there is insufficient motivation to revert the change in >> behavior implemented by JDK-8159048 to allow calling the play/pause/stop >> methods of Animation on a background thread. Doing so without making it >> fully multi-thread-safe would be asking for problems, and making it fully >> multi-thread-safe would be a fair bit of work to do it right without a >> clear benefit. >> >> We will proceed with the current approach and let JDK-8159048 stand. >> Further, we will proceed with https://bugs.openjdk.org/browse/JDK-8324219 >> which is under review in https://github.com/openjdk/jfx/pull/1342 >> >> >> -- Kevin >> >> On 1/24/2024 12:30 AM, Nir Lisker wrote: >> >> After playing around with the code sample, I think that this is not the >> right way to use the animation. The reason is that there is no point in >> starting the animation before the control is attached to the scenegraph, or >> even made visible. A small refactoring where, e.g., the controller class >> exposes a method to start the animation in onSucceeded or just calls it on >> the FX thread is enough. I never start an animation as part of the >> construction because it's not the right time. John suggested tying the >> lifecycle of the animation to the showing of the node, which also solves >> the problem. >> >> There are animations like PauseTransition or other non-interfering >> Timelines that could reasonably be run on a background thread. Or maybe >> just on an unconnected control. This could be a reason to not limit >> animation methods to the FX thread at the expense of possible user errors, >> but document the pitfall. >> >> I don't see a good use case for modifying controls in a background thread >> while still interacting with the scenegraph, hence for adding multithread >> support. >> >> - Nir >> >> On Mon, Jan 22, 2024, 12:59 Jurgen Doll wrote: >> >>> Here's an example as requested by Nir: >>> >>> public class FxTimeLineTest extends Application >>> >>> { >>> >>> private BorderPane bp = new BorderPane( new Label("Loading") ); >>> >>> public static void main( String[] args ) { >>> >>> launch( FxTimeLineTest.class, args ); >>> >>> } >>> >>> @Override >>> >>> public void start( Stage primaryStage ) throws Exception { >>> >>> new Thread( new LoadScene() ).start(); >>> >>> primaryStage.setScene( new Scene( bp, 300, 200 ) ); >>> >>> primaryStage.setTitle( "Memory Usage" ); >>> >>> primaryStage.show(); >>> >>> } >>> >>> private class LoadScene extends Task { >>> >>> @Override protected Parent call() throws Exception { >>> >>> Parent p = FXMLLoader.load( getClass( ).getResource("TestView.fxml") ); >>> >>> Thread.sleep( 1000 ); >>> >>> return p; >>> >>> } >>> >>> @Override protected void succeeded() { >>> >>> bp.setCenter( getValue() ); >>> >>> } >>> >>> @Override protected void failed() { >>> >>> getException().printStackTrace(); >>> >>> } >>> >>> } >>> >>> } >>> >>> >>> ------------------------------------------------------------------------------------------------------ >>> >>> public class TestView >>> >>> { >>> >>> @FXML private Label memory; >>> >>> private static final double MEGABYTE = 1024 * 1024; >>> >>> @FXML private void initialize() >>> >>> { >>> >>> var updater = new Timeline >>> >>> ( >>> >>> new K eyFrame( Duration.seconds(2.5), event -> >>> >>> { >>> >>> var runtime = Runtime.getRuntime(); >>> >>> double maxMemory = runtime.maxMemory() / MEGABYTE; >>> >>> double usedMemory = (runtime.totalMemory() - runtime.freeMemory()) / >>> MEGABYTE; >>> >>> memory.setText( (int) usedMemory + " MB / " + (int) maxMemory +" MB" ); >>> >>> }) >>> >>> ); >>> >>> updater.setCycleCount(Animation.INDEFINITE); // This FXML is being >>> loaded on a background thread >>> >>> updater.play(); >>> >>> } >>> >>> } >>> >>> >>> ------------------------------------------------------------------------------------------------------ >>> >>> TestView.fxml >>> >>> >>> >>> >>> >>> >>> >>> >> fx:controller="TestView"> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker >>> wrote: >>> >>> Hi Jurgen, >>> >>> What I'm confused about the most is what it is you are actually trying >>> to do that necessitates the use of animations outside of the FX thread. You >>> said that you need to initialize controls on another thread, and that you >>> are using Task (both of which are fine), but how does playing animations >>> relate? Playing an animation is something that is done explicitly, usually >>> in order to manipulate data. Can you give a real use case, like a minimized >>> version of what you're doing? >>> >>> - Nir >>> >>> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sproket at videotron.ca Wed Jan 24 18:59:43 2024 From: sproket at videotron.ca (Dan Howard) Date: Wed, 24 Jan 2024 13:59:43 -0500 Subject: Animation timing inconsistent on Windows (recently) Message-ID: Hi All, I'm not sure if this is the right place to discuss but while working on a game, I noticed that the animations are not running the correct durations sometimes on Windows 11 Pro. I tried it out on my Mac (Ventura) and I don't see this issue. This is running the latest JavaFX (maven 21.0.2) under openjdk-21. vm: -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -ea If it's not a known issue I can add more information. Thanks! From kevin.rushforth at oracle.com Wed Jan 24 19:00:27 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2024 11:00:27 -0800 Subject: [External] : Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: Thanks! I just filed https://bugs.openjdk.org/browse/JDK-8324658 It should mostly revert JDK-8159048 (although the sentence added to the class docs about animations running on the JavaFX app thread is still valid), and some of the unit tests might still be valid. -- Kevin On 1/24/2024 10:50 AM, Nir Lisker wrote: > If there's an agreement, I can do it tomorrow. It will effectively > revert JDK-8159048 and supersede JDK-8324219. > > On Wed, Jan 24, 2024 at 8:42?PM Kevin Rushforth > wrote: > > I also now favor option 2 and was in the process of writing > something up recommending that we do that. Phil and I (and a > couple others) had an offline discussion and think this is the way > to go. > > Given the short amount of time to get this into 22, I will file > the JBS issue in the next hour or so. > > Nir: if you want to take it, that would be great. Otherwise, I > will do it. We need the PR and CSR filed before the end of this week. > > Regarding other methods that choose option 1, many of them are > more complicated (e.g., scene mutation can be done on a background > thread as long as the scene is not "showing") or must be > synchronous. Animation starts something that conceptually happens > later on the FX animation thread anyway, so wrapping it in a > runLater (if not already on the right thread) doesn't really > change the semantics in an appreciable way. > > -- Kevin > > > On 1/24/2024 10:26 AM, Nir Lisker wrote: >> These are the options I see as reasonable: >> >> 1. Document that these methods *must* be run on the FX thread and >> throw an exception otherwise. This leaves it to the >> responsibility of the user. However, this will cause the >> backwards compatibility problems that Jugen brought up. As a side >> note, we do this in other methods already, but I always >> questioned why let the developer do something illegal - if >> there's only one execution path, force it. >> 2. Document that these methods *are* run on the FX thread (the >> user doesn't need to do anything) and change the implementation >> to call runLater(...) internally unless they are already on the >> FX thread. This will be backwards compatible for the most part >> (see option 3). The downside might be some surprise when these >> methods behave differently. >> 3. Document that it's *recommended* that these methods be run on >> the FX thread and let the user be responsible for the threading. >> We can explain that manipulating nodes that are attached to an >> active scenegraph should be avoided. >> >> I prefer option 2 over 1 regardless of the backwards >> compatibility issue even, but would like to know if I'm missing >> something here because in theory this change could be done to any >> "must run on the FX thread" method and I question why the user >> had the option to get an exception. >> Option 3 is risky and I wager a guess that it will be used >> wrongly more often than not. It does allow some (what I would >> call) valid niche uses. I never did it. >> >> On Wed, Jan 24, 2024 at 4:21?PM Kevin Rushforth >> wrote: >> >> I'd like to hear from the others on this. I don't see any >> fundamental problem with having the play/pause/stop methods >> wrap their implementation in a runLater (if not on the FX >> Application thread already), and documenting that it does so, >> if we can get general agreement. >> >> -- Kevin >> >> >> On 1/24/2024 5:29 AM, Jurgen Doll wrote: >>> Hi Kevin >>> >>> If I may make one more final appeal then to an alternative >>> solution please. >>> >>> Could we then instead of throwing an Exception rather invoke >>> runLater if needed inside play, stop, and resume. >>> >>> Putting the onus on the developer is fine if it is the >>> developer that is invoking the call, but if it's in a >>> library then it's a no go. >>> >>> In my application I have two libraries that I know of where >>> this happens. The major problem is that with FX22 as it now >>> stands my application just crashes because play() does an FX >>> thread check and throws an Exception which it never did >>> before. There are bound to be other applications out there >>> that are going to find themselves in a similar position. >>> >>> PLEASE ! >>> >>> Regards >>> Jurgen >>> >>> >>> >>> On Wed, 24 Jan 2024 15:15:31 +0200, Kevin Rushforth >>> >>> wrote: >>> >>> Thank you to Jurgen for raising the question and to Nir, >>> John, and Michael for evaluating it. >>> >>> I conclude that there is insufficient motivation to >>> revert the change in behavior implemented by JDK-8159048 >>> to allow calling the play/pause/stop methods of >>> Animation on a background thread. Doing so without >>> making it fully multi-thread-safe would be asking for >>> problems, and making it fully multi-thread-safe would be >>> a fair bit of work to do it right without a clear benefit. >>> >>> We will proceed with the current approach and let >>> JDK-8159048 stand. Further, we will proceed with >>> https://bugs.openjdk.org/browse/JDK-8324219 which is >>> under review in https://github.com/openjdk/jfx/pull/1342 >>> >>> >>> -- Kevin >>> >>> On 1/24/2024 12:30 AM, Nir Lisker wrote: >>>> After playing around with the code sample, I think that >>>> this is not the right way to use the animation. The >>>> reason is that there is no point in starting the >>>> animation before the control is attached to the >>>> scenegraph, or even made visible. A small refactoring >>>> where, e.g., the controller class exposes a method to >>>> start the animation in onSucceeded or just calls it on >>>> the FX thread is enough. I never start an animation as >>>> part of the construction because it's not the right >>>> time. John suggested tying the lifecycle of the >>>> animation to the showing of the node, which also solves >>>> the problem. >>>> >>>> There are animations like PauseTransition or other >>>> non-interfering Timelines that could reasonably be run >>>> on a background thread. Or maybe just on an unconnected >>>> control. This could be a reason to not limit animation >>>> methods to the FX thread at the expense of possible >>>> user errors, but document the pitfall. >>>> >>>> I don't see a good use case for modifying controls in a >>>> background thread while still interacting with the >>>> scenegraph, hence for adding multithread support. >>>> >>>> - Nir >>>> >>>> On Mon, Jan 22, 2024, 12:59 Jurgen Doll >>>> wrote: >>>> >>>> Here's an example as requested by Nir: >>>> >>>> publicclassFxTimeLineTest extendsApplication >>>> >>>> { >>>> >>>> privateBorderPane bp= newBorderPane( >>>> newLabel("Loading") ); >>>> >>>> publicstaticvoidmain( String[] args) { >>>> >>>> launch( FxTimeLineTest.class, args); >>>> >>>> } >>>> >>>> @Override >>>> >>>> publicvoidstart( Stage primaryStage) throwsException { >>>> >>>> newThread( newLoadScene() ).start(); >>>> >>>> primaryStage.setScene( newScene( bp, 300, 200 ) ); >>>> >>>> primaryStage.setTitle( "Memory Usage"); >>>> >>>> primaryStage.show(); >>>> >>>> } >>>> >>>> privateclassLoadScene extendsTask { >>>> >>>> @OverrideprotectedParent call() throwsException { >>>> >>>> Parent p= FXMLLoader.load( getClass( >>>> ).getResource("TestView.fxml") ); >>>> >>>> Thread.sleep( 1000 ); >>>> >>>> returnp; >>>> >>>> } >>>> >>>> @Overrideprotectedvoidsucceeded() { >>>> >>>> bp.setCenter( getValue() ); >>>> >>>> } >>>> >>>> @Overrideprotectedvoidfailed() { >>>> >>>> getException().printStackTrace(); >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> ------------------------------------------------------------------------------------------------------ >>>> >>>> >>>> publicclassTestView >>>> >>>> { >>>> >>>> @FXMLprivateLabel memory; >>>> >>>> privatestaticfinaldoubleMEGABYTE= 1024 * 1024; >>>> >>>> @FXMLprivatevoidinitialize() >>>> >>>> { >>>> >>>> varupdater= newTimeline >>>> >>>> ( >>>> >>>> newK eyFrame( Duration.seconds(2.5), event-> >>>> >>>> { >>>> >>>> varruntime= Runtime.getRuntime(); >>>> >>>> doublemaxMemory= runtime.maxMemory() / MEGABYTE; >>>> >>>> doubleusedMemory= (runtime.totalMemory() - >>>> runtime.freeMemory()) / MEGABYTE; >>>> >>>> memory.setText( (int) usedMemory+ " MB / "+ (int) >>>> maxMemory+" MB"); >>>> >>>> }) >>>> >>>> ); >>>> >>>> updater.setCycleCount(Animation.INDEFINITE); // >>>> This FXML is being loaded on a background thread >>>> >>>> updater.play(); >>>> >>>> } >>>> >>>> } >>>> >>>> ------------------------------------------------------------------------------------------------------ >>>> >>>> >>>> TestView.fxml >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> fx:controller="TestView"> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, 20 Jan 2024 17:08:41 +0200, Nir Lisker >>>> wrote: >>>> >>>> Hi Jurgen, >>>> >>>> What I'm confused about the most is what it is >>>> you are actually trying to do that >>>> necessitates?the use of animations outside of >>>> the FX thread. You said that you need to >>>> initialize controls on another thread, and that >>>> you are using Task (both of which are fine), >>>> but how does playing animations relate? Playing >>>> an animation is something that is done >>>> explicitly, usually in order to manipulate >>>> data. Can you give a real use case, like a >>>> minimized version of what you're doing? >>>> >>>> - Nir >>>> >>> >>> >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Wed Jan 24 19:04:03 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 24 Jan 2024 20:04:03 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: I am not in favor of option 2 if the implementation was simply "wrap the implementation in runLater", as this would be a surprising change. Consider the following code: var transition = new FadeTransition(); transition.play(); // Will always print "RUNNING" currently, but might print "STOPPED" // if we go with the proposed change: System.out.println(transition.getStatus()); Regardless of the race condition in AbstractPrimaryTimer, this code always seemed to be working quite fine (albeit superficially), because the play/stop/etc. methods change that status of the animation as one would expect. You are proposing to change that, such that calling these methods will not predictably change the status of the animation. Instead, these methods now act more like "requests" that may be fulfilled at some later point in time, rather than statements of fact. This is not a change that I think we should be doing on an ad-hoc basis, since the same considerations potentially apply for many methods in many places. If we were to allow calling play/stop/etc. on a background thread, I would be in favor of keeping the semantics that these methods instantly and predictably affect the status of the animation. Only the internal operation of adding the animation to AbstractPrimaryTimer should be posted to the FX thread. If that is not possible, this suggests to me that we should choose option 1. Introducing new and surprising semantics to an existing API is not the way to go. On Wed, Jan 24, 2024 at 7:27?PM Nir Lisker wrote: > > These are the options I see as reasonable: > > 1. Document that these methods *must* be run on the FX thread and throw an exception otherwise. This leaves it to the responsibility of the user. However, this will cause the backwards compatibility problems that Jugen brought up. As a side note, we do this in other methods already, but I always questioned why let the developer do something illegal - if there's only one execution path, force it. > 2. Document that these methods *are* run on the FX thread (the user doesn't need to do anything) and change the implementation to call runLater(...) internally unless they are already on the FX thread. This will be backwards compatible for the most part (see option 3). The downside might be some surprise when these methods behave differently. > 3. Document that it's *recommended* that these methods be run on the FX thread and let the user be responsible for the threading. We can explain that manipulating nodes that are attached to an active scenegraph should be avoided. > > I prefer option 2 over 1 regardless of the backwards compatibility issue even, but would like to know if I'm missing something here because in theory this change could be done to any "must run on the FX thread" method and I question why the user had the option to get an exception. > Option 3 is risky and I wager a guess that it will be used wrongly more often than not. It does allow some (what I would call) valid niche uses. I never did it. From kpk at openjdk.org Wed Jan 24 19:07:40 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 24 Jan 2024 19:07:40 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 In-Reply-To: References: Message-ID: <0UPev-h5g9eF5Y1Yim2sfsi84YTpksF1Jy4YY7SwG9Y=.ca691c46-ae5f-4240-9d60-07998ea4bf1f@github.com> On Wed, 24 Jan 2024 14:55:21 GMT, Laurent Bourg?s wrote: > Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java @bourgesl Some of the unit tests looks to be failing. Can you please check? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1908749026 From kevin.rushforth at oracle.com Wed Jan 24 19:16:00 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2024 11:16:00 -0800 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: <31b59650-7123-4ba0-814d-f35618cb42bf@oracle.com> The point you raise is one reason why I wouldn't advocate doing this in other places, e.g., for scene graph updates, which do need to run synchronously. I note that the Animation docs currently state that these operations are asynchronous (and yes, I know you were proposing the change this). So while it might be surprising to some apps, it is within the current spec, and I'm not sure it is any more surprising than the exception we now throw in JavaFX 22. If we could safely do what you suggest, and just wrap the part that touches the AbstractPrimaryTimer, that might be the best option. I don't know if that is feasible, though, especially going from a running state to a stopped or paused state. -- Kevin On 1/24/2024 11:04 AM, Michael Strau? wrote: > I am not in favor of option 2 if the implementation was simply "wrap > the implementation in runLater", as this would be a surprising change. > Consider the following code: > > var transition = new FadeTransition(); > transition.play(); > > // Will always print "RUNNING" currently, but might print "STOPPED" > // if we go with the proposed change: > System.out.println(transition.getStatus()); > > Regardless of the race condition in AbstractPrimaryTimer, this code > always seemed to be working quite fine (albeit superficially), because > the play/stop/etc. methods change that status of the animation as one > would expect. > > You are proposing to change that, such that calling these methods will > not predictably change the status of the animation. Instead, these > methods now act more like "requests" that may be fulfilled at some > later point in time, rather than statements of fact. > This is not a change that I think we should be doing on an ad-hoc > basis, since the same considerations potentially apply for many > methods in many places. > > If we were to allow calling play/stop/etc. on a background thread, I > would be in favor of keeping the semantics that these methods > instantly and predictably affect the status of the animation. Only the > internal operation of adding the animation to AbstractPrimaryTimer > should be posted to the FX thread. If that is not possible, this > suggests to me that we should choose option 1. Introducing new and > surprising semantics to an existing API is not the way to go. > > > On Wed, Jan 24, 2024 at 7:27?PM Nir Lisker wrote: >> These are the options I see as reasonable: >> >> 1. Document that these methods *must* be run on the FX thread and throw an exception otherwise. This leaves it to the responsibility of the user. However, this will cause the backwards compatibility problems that Jugen brought up. As a side note, we do this in other methods already, but I always questioned why let the developer do something illegal - if there's only one execution path, force it. >> 2. Document that these methods *are* run on the FX thread (the user doesn't need to do anything) and change the implementation to call runLater(...) internally unless they are already on the FX thread. This will be backwards compatible for the most part (see option 3). The downside might be some surprise when these methods behave differently. >> 3. Document that it's *recommended* that these methods be run on the FX thread and let the user be responsible for the threading. We can explain that manipulating nodes that are attached to an active scenegraph should be avoided. >> >> I prefer option 2 over 1 regardless of the backwards compatibility issue even, but would like to know if I'm missing something here because in theory this change could be done to any "must run on the FX thread" method and I question why the user had the option to get an exception. >> Option 3 is risky and I wager a guess that it will be used wrongly more often than not. It does allow some (what I would call) valid niche uses. I never did it. From kevin.rushforth at oracle.com Wed Jan 24 19:18:32 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2024 11:18:32 -0800 Subject: Animation timing inconsistent on Windows (recently) In-Reply-To: References: Message-ID: This isn't a known issue, so please post more information. -- Kevin On 1/24/2024 10:59 AM, Dan Howard wrote: > Hi All, > > I'm not sure if this is the right place to discuss but while working > on a game, I noticed that the animations are not running the correct > durations sometimes on Windows 11 Pro. I tried it out on my Mac > (Ventura) and I don't see this issue. > > This is running the latest JavaFX (maven 21.0.2) under openjdk-21. vm: > -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -ea > > > If it's not a known issue I can add more information. > > Thanks! > > From nlisker at gmail.com Wed Jan 24 21:06:31 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 24 Jan 2024 23:06:31 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: This is the ballpark of what I meant with "the downside might be some surprise when these methods behave differently". The example you give will only show a potential change if 'play' is not called from the FX thread. In such a case, what's the chance that this is an undeliberate misuse vs. an informed use? This brings me again to: what is the use case for running an animation from a background thread? In your simple example, listening on the Status property would work. Also, while runLater makes no guarantees, I've never seen a non-negligible delay in its execution, so how surprising is it really going to be? If you want to be able to run an animation from a background thread with no race conditions, why not opt for option 3? And option 1 is also new and surprising because now code that worked (or pretended to work) throws, which ruins properly written code (with respect to multithreading), or exposes a bug. On Wed, Jan 24, 2024 at 9:04?PM Michael Strau? wrote: > I am not in favor of option 2 if the implementation was simply "wrap > the implementation in runLater", as this would be a surprising change. > Consider the following code: > > var transition = new FadeTransition(); > transition.play(); > > // Will always print "RUNNING" currently, but might print "STOPPED" > // if we go with the proposed change: > System.out.println(transition.getStatus()); > > Regardless of the race condition in AbstractPrimaryTimer, this code > always seemed to be working quite fine (albeit superficially), because > the play/stop/etc. methods change that status of the animation as one > would expect. > > You are proposing to change that, such that calling these methods will > not predictably change the status of the animation. Instead, these > methods now act more like "requests" that may be fulfilled at some > later point in time, rather than statements of fact. > This is not a change that I think we should be doing on an ad-hoc > basis, since the same considerations potentially apply for many > methods in many places. > > If we were to allow calling play/stop/etc. on a background thread, I > would be in favor of keeping the semantics that these methods > instantly and predictably affect the status of the animation. Only the > internal operation of adding the animation to AbstractPrimaryTimer > should be posted to the FX thread. If that is not possible, this > suggests to me that we should choose option 1. Introducing new and > surprising semantics to an existing API is not the way to go. > > > On Wed, Jan 24, 2024 at 7:27?PM Nir Lisker wrote: > > > > These are the options I see as reasonable: > > > > 1. Document that these methods *must* be run on the FX thread and throw > an exception otherwise. This leaves it to the responsibility of the user. > However, this will cause the backwards compatibility problems that Jugen > brought up. As a side note, we do this in other methods already, but I > always questioned why let the developer do something illegal - if there's > only one execution path, force it. > > 2. Document that these methods *are* run on the FX thread (the user > doesn't need to do anything) and change the implementation to call > runLater(...) internally unless they are already on the FX thread. This > will be backwards compatible for the most part (see option 3). The downside > might be some surprise when these methods behave differently. > > 3. Document that it's *recommended* that these methods be run on the FX > thread and let the user be responsible for the threading. We can explain > that manipulating nodes that are attached to an active scenegraph should be > avoided. > > > > I prefer option 2 over 1 regardless of the backwards compatibility issue > even, but would like to know if I'm missing something here because in > theory this change could be done to any "must run on the FX thread" method > and I question why the user had the option to get an exception. > > Option 3 is risky and I wager a guess that it will be used wrongly more > often than not. It does allow some (what I would call) valid niche uses. I > never did it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Wed Jan 24 21:30:02 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 24 Jan 2024 22:30:02 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: Here's another option, which I have implemented as a proof of concept [0]: The play/stop/etc. methods are currently specified to be "asynchronous". This language should be removed, such that the methods will be implied to execute synchronously from the point of view of the caller (like every method that doesn't specify anything to the contrary). All changes to observable state will remain instantly visible for the calling thread. However, internally, interactions with AbstractPrimaryTimer are posted to the FX thread if necessary. This is not an unsurprising change, since the callback from the FX thread was always occuring at an unspecified time in the future. To make this work, AbstractPrimaryTimer::pause/resume/nanos will have to be synchronized to ensure field visibility across threads. In the Animation class, interactions with AbstractPrimaryTimer will be encapsulated in the new nested class AnimationPulseReceiver, which also deduplicates redundant interactions with AbstractPrimaryTimer. For example, repeatedly calling start() and stop() in quick succession may require just a single interaction with AbstractPrimaryTimer in the future (if we ended up in the running state), or no interaction at all (if we ended up in the stopped state). [0] https://github.com/openjdk/jfx/pull/1349 On Wed, Jan 24, 2024 at 7:27?PM Nir Lisker wrote: > > These are the options I see as reasonable: > > 1. Document that these methods *must* be run on the FX thread and throw an exception otherwise. This leaves it to the responsibility of the user. However, this will cause the backwards compatibility problems that Jugen brought up. As a side note, we do this in other methods already, but I always questioned why let the developer do something illegal - if there's only one execution path, force it. > 2. Document that these methods *are* run on the FX thread (the user doesn't need to do anything) and change the implementation to call runLater(...) internally unless they are already on the FX thread. This will be backwards compatible for the most part (see option 3). The downside might be some surprise when these methods behave differently. > 3. Document that it's *recommended* that these methods be run on the FX thread and let the user be responsible for the threading. We can explain that manipulating nodes that are attached to an active scenegraph should be avoided. > > I prefer option 2 over 1 regardless of the backwards compatibility issue even, but would like to know if I'm missing something here because in theory this change could be done to any "must run on the FX thread" method and I question why the user had the option to get an exception. > Option 3 is risky and I wager a guess that it will be used wrongly more often than not. It does allow some (what I would call) valid niche uses. I never did it. > From michaelstrau2 at gmail.com Wed Jan 24 21:39:41 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 24 Jan 2024 22:39:41 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: Note: this proposal does NOT allow Animation.play/stop/etc. to be "called on any thread" as mentioned in JDK-8324658 [0]. It merely removes the requirement that these methods must be called on the FX thread, but this doesn't make the class inherently thread-safe. That is an important distinction to proposals that call for posting the play/stop calls directly to the FX thread. [0] https://bugs.openjdk.org/browse/JDK-8324658 On Wed, Jan 24, 2024 at 10:30?PM Michael Strau? wrote: > > Here's another option, which I have implemented as a proof of concept [0]: > > The play/stop/etc. methods are currently specified to be > "asynchronous". This language should be removed, such that the methods > will be implied to execute synchronously from the point of view of the > caller (like every method that doesn't specify anything to the > contrary). > > All changes to observable state will remain instantly visible for the > calling thread. However, internally, interactions with > AbstractPrimaryTimer are posted to the FX thread if necessary. This is > not an unsurprising change, since the callback from the FX thread was > always occuring at an unspecified time in the future. > > To make this work, AbstractPrimaryTimer::pause/resume/nanos will have > to be synchronized to ensure field visibility across threads. > In the Animation class, interactions with AbstractPrimaryTimer will be > encapsulated in the new nested class AnimationPulseReceiver, which > also deduplicates redundant interactions with AbstractPrimaryTimer. > For example, repeatedly calling start() and stop() in quick succession > may require just a single interaction with AbstractPrimaryTimer in the > future (if we ended up in the running state), or no interaction at all > (if we ended up in the stopped state). > > > [0] https://github.com/openjdk/jfx/pull/1349 From arapte at openjdk.org Thu Jan 25 07:14:38 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 25 Jan 2024 07:14:38 GMT Subject: RFR: 8308955: MediaPlayer/AudioClip skip data on seek/loop In-Reply-To: <8b44wHVs5kLdMTYUDFbd9R7lXkQcUlCKlJz1T3lzSfg=.43a2e522-a220-4ee4-b749-c21831c594ca@github.com> References: <8b44wHVs5kLdMTYUDFbd9R7lXkQcUlCKlJz1T3lzSfg=.43a2e522-a220-4ee4-b749-c21831c594ca@github.com> Message-ID: On Tue, 23 Jan 2024 03:13:11 GMT, Alexander Matveev wrote: > This is regression from JDK-8262365. JDK-8262365 introduced support for hardware pause for audio device. For some reason we will skip ~500 ms of audio data after such pause. It is not noticeable for large audio files, but for anything small like sound effects 1-3 seconds long it is noticeable and makes short audio effects unusable without re-creating MediaPlayer after each playback. Fix/workaround is to disable hardware pause. I did not figure out why hardware pause skips audio data. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1346#pullrequestreview-1842975437 From john.hendrikx at gmail.com Thu Jan 25 09:02:28 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 25 Jan 2024 10:02:28 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: <564dc74f-c5b5-6bbc-6aac-42ed9f805b76@gmail.com> On 24/01/2024 22:06, Nir Lisker wrote: > This is the ballpark of what I meant with "the downside might be some > surprise when these methods behave differently". That can be documented, and basically already is (because that is what the "asynchronous" is alluding to, the fact that after calling "play" the state will change asynchronously). > > The example you give will only show a potential change if 'play' is > not called from the FX thread. In such a?case, what's the chance that > this is an undeliberate misuse vs. an informed use? This brings me > again to: what is the use case for running an animation from a > background thread? The only possible use case I can think of is when using FX properties stand-alone (ie. only using javafx.base), without any FX thread involvement.? Even in that case though one has to remember that properties themselves are not thread safe either. Any "animation" would need to be done on the same thread that is manipulating properties. However, Animation and Timeline simply can't work in such scenario's, as they're tied to javafx.graphics, to the FX system being started, and the FX thread.? For such a use case you'd need to write your own system, or provide the option of specifying an Executor for Animations/Timelines. > In your simple example, listening on the Status property would work. > Also, while runLater makes no guarantees, I've never seen a > non-negligible delay in its execution,?so how surprising is?it really > going to be? > > If you want to be able to run an animation from a background thread > with no race conditions, why not opt for option 3? Option 3 is basically document it as "be careful" and remove the thread restriction recently introduced, am I correct? IMHO that can simply can't work at all, because this is what (theoretically) can happen: 1. Non-FX thread starts animation ???? - Fields are manipulated in AbstractPrimaryTimer ???? - There is no synchronization, so no guarantee anything is flushed (it may all reside in CPU caches) 2. FX Thread becomes involved to actually process the animation ???? - Sees partially flushed state fields, and acts on garbage information (ie. number of animations > 0, but array contains only null's) There just is no safe way to do this in without synchronization or having everything immutable (and this extends to references to "thread safe" structures). --John > > And option 1 is also new and surprising because now code that worked > (or pretended to work) throws, which ruins properly written code (with > respect to multithreading), or exposes a bug. > > On Wed, Jan 24, 2024 at 9:04?PM Michael Strau? > wrote: > > I am not in favor of option 2 if the implementation was simply "wrap > the implementation in runLater", as this would be a surprising change. > Consider the following code: > > ? ? var transition = new FadeTransition(); > ? ? transition.play(); > > ? ? // Will always print "RUNNING" currently, but might print > "STOPPED" > ? ? // if we go with the proposed change: > ? ? System.out.println(transition.getStatus()); > > Regardless of the race condition in AbstractPrimaryTimer, this code > always seemed to be working quite fine (albeit superficially), because > the play/stop/etc. methods change that status of the animation as one > would expect. > > You are proposing to change that, such that calling these methods will > not predictably change the status of the animation. Instead, these > methods now act more like "requests" that may be fulfilled at some > later point in time, rather than statements of fact. > This is not a change that I think we should be doing on an ad-hoc > basis, since the same considerations potentially apply for many > methods in many places. > > If we were to allow calling play/stop/etc. on a background thread, I > would be in favor of keeping the semantics that these methods > instantly and predictably affect the status of the animation. Only the > internal operation of adding the animation to AbstractPrimaryTimer > should be posted to the FX thread. If that is not possible, this > suggests to me that we should choose option 1. Introducing new and > surprising semantics to an existing API is not the way to go. > > > On Wed, Jan 24, 2024 at 7:27?PM Nir Lisker wrote: > > > > These are the options I see as reasonable: > > > > 1. Document that these methods *must* be run on the FX thread > and throw an exception otherwise. This leaves it to the > responsibility of the user. However, this will cause the backwards > compatibility problems that Jugen brought up. As a side note, we > do this in other methods already, but I always questioned why let > the developer do something illegal - if there's only one execution > path, force it. > > 2. Document that these methods *are* run on the FX thread (the > user doesn't need to do anything) and change the implementation to > call runLater(...) internally unless they are already on the FX > thread. This will be backwards compatible for the most part (see > option 3). The downside might be some surprise when these methods > behave differently. > > 3. Document that it's *recommended* that these methods be run on > the FX thread and let the user be responsible for the threading. > We can explain that manipulating nodes that are attached to an > active scenegraph should be avoided. > > > > I prefer option 2 over 1 regardless of the backwards > compatibility issue even, but would like to know if I'm missing > something here because in theory this change could be done to any > "must run on the FX thread" method and I question why the user had > the option to get an exception. > > Option 3 is risky and I wager a guess that it will be used > wrongly more often than not. It does allow some (what I would > call) valid niche uses. I never did it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Thu Jan 25 09:39:50 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 25 Jan 2024 10:39:50 +0100 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> Message-ID: Hi Michael, I'm not quite sure I see the point of this change.? The PR did not remove the threading restrictions on play/stop. I'm also confused by the seemingly contradictory statements: - this proposal does NOT allow Animation.play/stop/etc. to be "called on any thread" - It merely removes the requirement that these methods must be called on the FX thread What does that mean exactly? Also, I think the "asynchronous" wording may apply to property changes and action handlers that run at time index 0.? These surely won't be ran synchronous when calling "play", and I'm pretty sure they never were. --John On 24/01/2024 22:39, Michael Strau? wrote: > Note: this proposal does NOT allow Animation.play/stop/etc. to be > "called on any thread" as mentioned in JDK-8324658 [0]. > > It merely removes the requirement that these methods must be called on > the FX thread, but this doesn't make the class inherently thread-safe. > That is an important distinction to proposals that call for posting > the play/stop calls directly to the FX thread. > > > [0] https://bugs.openjdk.org/browse/JDK-8324658 > > > On Wed, Jan 24, 2024 at 10:30?PM Michael Strau? wrote: >> Here's another option, which I have implemented as a proof of concept [0]: >> >> The play/stop/etc. methods are currently specified to be >> "asynchronous". This language should be removed, such that the methods >> will be implied to execute synchronously from the point of view of the >> caller (like every method that doesn't specify anything to the >> contrary). >> >> All changes to observable state will remain instantly visible for the >> calling thread. However, internally, interactions with >> AbstractPrimaryTimer are posted to the FX thread if necessary. This is >> not an unsurprising change, since the callback from the FX thread was >> always occuring at an unspecified time in the future. >> >> To make this work, AbstractPrimaryTimer::pause/resume/nanos will have >> to be synchronized to ensure field visibility across threads. >> In the Animation class, interactions with AbstractPrimaryTimer will be >> encapsulated in the new nested class AnimationPulseReceiver, which >> also deduplicates redundant interactions with AbstractPrimaryTimer. >> For example, repeatedly calling start() and stop() in quick succession >> may require just a single interaction with AbstractPrimaryTimer in the >> future (if we ended up in the running state), or no interaction at all >> (if we ended up in the stopped state). >> >> >> [0] https://github.com/openjdk/jfx/pull/1349 From john.hendrikx at gmail.com Thu Jan 25 09:50:35 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 25 Jan 2024 10:50:35 +0100 Subject: Thought experiment: constructing Nodes on a different thread... Message-ID: All this threading talk has made me wonder something: Let's say there are two threads, the FX thread and Thread 1.? I do the following: - On thread 1: create Label - On thread 1: set Label text to "xyz" I now attach this label to an active Scene graph. This should be done on the FX thread as we're going to be manipulating an active Scene graph, so: - On FX thread: attach Label to active scene graph There is no synchronization in place on the Label's text field. What guarantees do I have that when the label is shown on screen it will show "xyz" ? IMHO, there is no such guarantee, and so any creation or manipulation of Nodes that will later be part of an active scene graph (and thus accessed by the FX thread) **must** be done on the FX thread.? Involving any other thread in their creation or manipulation runs the risk of seeing an object in the incorrect state (or even an "impossible" state when multiple fields are involved that normally change together). Effectively, assuming that when you create Nodes you always have the intention of showing them at some point, you can never construct Nodes on any other thread than the FX thread... Am I missing something? --John From arapte at openjdk.org Thu Jan 25 10:24:43 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 25 Jan 2024 10:24:43 GMT Subject: Integrated: 8324270: Update boot JDK to 21.0.2 In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 13:45:35 GMT, Ambarish Rapte wrote: > JDK 21.0.2 is now released : https://jdk.java.net/21/ > Did a full CI build including Webkit and executed all headful tests. This pull request has now been integrated. Changeset: 9e7e8e1d Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/9e7e8e1d08a9d03611da99ef1a7e6e29cd870eca Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8324270: Update boot JDK to 21.0.2 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1345 From nlisker at gmail.com Thu Jan 25 13:07:44 2024 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 25 Jan 2024 15:07:44 +0200 Subject: Thought experiment: constructing Nodes on a different thread... In-Reply-To: References: Message-ID: Isn't that exactly what the Worker interface and its Task and Service implementations are for? Service says A Service is a non-visual component encapsulating the information required > to perform some work on one or more background threads. As part of the > JavaFX UI library, the Service knows about the JavaFX Application thread > and is designed to relieve the application developer from the burden of > managing multithreaded code that interacts with the user interface. The example provided by Jurgen uses Task, which guarantees that the resulting Parent can be attached to the scenegraph on the FX thread (in 'succeeded()'). Up to here everything is fine. The problem starts when the code from inside Task#call, which is called on the background thread, starts an animation itself, an operation that interacts with the FX thread. Task warns about this: Because the Task is designed for use with JavaFX GUI applications, it > ensures that every change to its public properties, as well as change > notifications for state, errors, and for event handlers, all occur on the > main JavaFX application thread. Accessing these properties from a > background thread (including the call() method) will result in runtime > exceptions being raised. and Generally, Tasks should not interact directly with the UI. Doing so creates > a tight coupling between a specific Task implementation and a specific part > of your UI. However, when you do want to create such a coupling, you must > ensure that you use Platform.runLater so that any modifications of the > scene graph occur on the FX Application Thread. So I don't think you're missing something in your description of the problem, and I don't think anyone has argued that doing what you described is not a problem. Thankfully, I don't remember coming across code that does this. People seem to be vigilant about using javafx.concurrent tools for this purpose, which is a good sign. On Thu, Jan 25, 2024 at 11:50?AM John Hendrikx wrote: > All this threading talk has made me wonder something: > > Let's say there are two threads, the FX thread and Thread 1. I do the > following: > > - On thread 1: create Label > - On thread 1: set Label text to "xyz" > > I now attach this label to an active Scene graph. This should be done on > the FX thread as we're going to be manipulating an active Scene graph, so: > > - On FX thread: attach Label to active scene graph > > There is no synchronization in place on the Label's text field. What > guarantees do I have that when the label is shown on screen it will show > "xyz" ? > > IMHO, there is no such guarantee, and so any creation or manipulation of > Nodes that will later be part of an active scene graph (and thus > accessed by the FX thread) **must** be done on the FX thread. Involving > any other thread in their creation or manipulation runs the risk of > seeing an object in the incorrect state (or even an "impossible" state > when multiple fields are involved that normally change together). > > Effectively, assuming that when you create Nodes you always have the > intention of showing them at some point, you can never construct Nodes > on any other thread than the FX thread... > > Am I missing something? > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmeda at openjdk.org Thu Jan 25 13:37:49 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 25 Jan 2024 13:37:49 GMT Subject: RFR: JDK-8324337: Cherry-pick WebKit 617.1 stabilization fixes Message-ID: Cherry-picked changes related to webkit-2.42.4.Verified build on all platforms. Sanity testing looks fine. ------------- Commit messages: - Resolve compilation error - Cherrypick changes related to 2.42.4 Changes: https://git.openjdk.org/jfx/pull/1350/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1350&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324337 Stats: 1294 lines in 161 files changed: 750 ins; 111 del; 433 mod Patch: https://git.openjdk.org/jfx/pull/1350.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1350/head:pull/1350 PR: https://git.openjdk.org/jfx/pull/1350 From nlisker at gmail.com Thu Jan 25 13:46:21 2024 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 25 Jan 2024 15:46:21 +0200 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: <564dc74f-c5b5-6bbc-6aac-42ed9f805b76@gmail.com> References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> <564dc74f-c5b5-6bbc-6aac-42ed9f805b76@gmail.com> Message-ID: > > Option 3 is basically document it as "be careful" and remove the thread > restriction recently introduced, am I correct? > Yes :) IMHO that can simply can't work at all, because this is what > (theoretically) can happen: > 1. Non-FX thread starts animation > - Fields are manipulated in AbstractPrimaryTimer > - There is no synchronization, so no guarantee anything is flushed > (it may all reside in CPU caches) > 2. FX Thread becomes involved to actually process the animation > - Sees partially flushed state fields, and acts on garbage > information (ie. number of animations > 0, but array contains only null's) > There just is no safe way to do this in without synchronization or having > everything immutable (and this extends to references to "thread safe" > structures). What about something like a PauseTransition that doesn't manipulate properties? On Thu, Jan 25, 2024 at 11:02?AM John Hendrikx wrote: > > On 24/01/2024 22:06, Nir Lisker wrote: > > This is the ballpark of what I meant with "the downside might be some > surprise when these methods behave differently". > > That can be documented, and basically already is (because that is what the > "asynchronous" is alluding to, the fact that after calling "play" the state > will change asynchronously). > > > The example you give will only show a potential change if 'play' is not > called from the FX thread. In such a case, what's the chance that this is > an undeliberate misuse vs. an informed use? This brings me again to: what > is the use case for running an animation from a background thread? > > The only possible use case I can think of is when using FX properties > stand-alone (ie. only using javafx.base), without any FX thread > involvement. Even in that case though one has to remember that properties > themselves are not thread safe either. Any "animation" would need to be > done on the same thread that is manipulating properties. > > However, Animation and Timeline simply can't work in such scenario's, as > they're tied to javafx.graphics, to the FX system being started, and the FX > thread. For such a use case you'd need to write your own system, or > provide the option of specifying an Executor for Animations/Timelines. > > In your simple example, listening on the Status property would work. Also, > while runLater makes no guarantees, I've never seen a non-negligible delay > in its execution, so how surprising is it really going to be? > > If you want to be able to run an animation from a background thread with > no race conditions, why not opt for option 3? > > Option 3 is basically document it as "be careful" and remove the thread > restriction recently introduced, am I correct? > > IMHO that can simply can't work at all, because this is what > (theoretically) can happen: > > 1. Non-FX thread starts animation > - Fields are manipulated in AbstractPrimaryTimer > - There is no synchronization, so no guarantee anything is flushed > (it may all reside in CPU caches) > > 2. FX Thread becomes involved to actually process the animation > - Sees partially flushed state fields, and acts on garbage > information (ie. number of animations > 0, but array contains only null's) > > There just is no safe way to do this in without synchronization or having > everything immutable (and this extends to references to "thread safe" > structures). > > --John > > > And option 1 is also new and surprising because now code that worked (or > pretended to work) throws, which ruins properly written code (with respect > to multithreading), or exposes a bug. > > On Wed, Jan 24, 2024 at 9:04?PM Michael Strau? > wrote: > >> I am not in favor of option 2 if the implementation was simply "wrap >> the implementation in runLater", as this would be a surprising change. >> Consider the following code: >> >> var transition = new FadeTransition(); >> transition.play(); >> >> // Will always print "RUNNING" currently, but might print "STOPPED" >> // if we go with the proposed change: >> System.out.println(transition.getStatus()); >> >> Regardless of the race condition in AbstractPrimaryTimer, this code >> always seemed to be working quite fine (albeit superficially), because >> the play/stop/etc. methods change that status of the animation as one >> would expect. >> >> You are proposing to change that, such that calling these methods will >> not predictably change the status of the animation. Instead, these >> methods now act more like "requests" that may be fulfilled at some >> later point in time, rather than statements of fact. >> This is not a change that I think we should be doing on an ad-hoc >> basis, since the same considerations potentially apply for many >> methods in many places. >> >> If we were to allow calling play/stop/etc. on a background thread, I >> would be in favor of keeping the semantics that these methods >> instantly and predictably affect the status of the animation. Only the >> internal operation of adding the animation to AbstractPrimaryTimer >> should be posted to the FX thread. If that is not possible, this >> suggests to me that we should choose option 1. Introducing new and >> surprising semantics to an existing API is not the way to go. >> >> >> On Wed, Jan 24, 2024 at 7:27?PM Nir Lisker wrote: >> > >> > These are the options I see as reasonable: >> > >> > 1. Document that these methods *must* be run on the FX thread and throw >> an exception otherwise. This leaves it to the responsibility of the user. >> However, this will cause the backwards compatibility problems that Jugen >> brought up. As a side note, we do this in other methods already, but I >> always questioned why let the developer do something illegal - if there's >> only one execution path, force it. >> > 2. Document that these methods *are* run on the FX thread (the user >> doesn't need to do anything) and change the implementation to call >> runLater(...) internally unless they are already on the FX thread. This >> will be backwards compatible for the most part (see option 3). The downside >> might be some surprise when these methods behave differently. >> > 3. Document that it's *recommended* that these methods be run on the FX >> thread and let the user be responsible for the threading. We can explain >> that manipulating nodes that are attached to an active scenegraph should be >> avoided. >> > >> > I prefer option 2 over 1 regardless of the backwards compatibility >> issue even, but would like to know if I'm missing something here because in >> theory this change could be done to any "must run on the FX thread" method >> and I question why the user had the option to get an exception. >> > Option 3 is risky and I wager a guess that it will be used wrongly more >> often than not. It does allow some (what I would call) valid niche uses. I >> never did it. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Thu Jan 25 14:49:38 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jan 2024 06:49:38 -0800 Subject: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE In-Reply-To: References: <29891deb-d5af-4eaf-a4ad-06b4540ac2d0@oracle.com> <5625f790-5317-4e5c-ac2b-1ce3a4a5de0f@oracle.com> <564dc74f-c5b5-6bbc-6aac-42ed9f805b76@gmail.com> Message-ID: And that's why the "be careful" option is not a satisfying solution. Let's proceed with the option to change the implementation of play/pause/stop/start to do the work in a runLater, and change the docs accordingly. It's the only feasible option for JavaFX 22 (other than "do nothing"), and I also think it is a good choice. If we later want to evolve it for thread-safety, which I'm not convinced that we do, we can consider that for a future release. -- Kevin On 1/25/2024 5:46 AM, Nir Lisker wrote: > > Option 3 is basically document it as "be careful" and remove the > thread restriction recently introduced, am I correct? > > > Yes :) > > IMHO that can simply can't work at all, because this is what > (theoretically) can happen: > 1. Non-FX thread starts animation > ???? - Fields are manipulated in AbstractPrimaryTimer > ???? - There is no synchronization, so no guarantee anything is > flushed (it may all reside in CPU caches) > > > 2. FX Thread becomes involved to actually process the animation > ???? - Sees partially flushed state fields, and acts on garbage > information (ie. number of animations > 0, but array contains only > null's) > There just is no safe way to do this in without synchronization or > having everything immutable (and this extends to references to > "thread safe" structures). > > What about something like a PauseTransition that doesn't > manipulate?properties? > > On Thu, Jan 25, 2024 at 11:02?AM John Hendrikx > wrote: > > > On 24/01/2024 22:06, Nir Lisker wrote: >> This is the ballpark of what I meant with "the downside might be >> some surprise when these methods behave differently". > That can be documented, and basically already is (because that is > what the "asynchronous" is alluding to, the fact that after > calling "play" the state will change asynchronously). >> >> The example you give will only show a potential change if 'play' >> is not called from the FX thread. In such a?case, what's the >> chance that this is an undeliberate misuse vs. an informed use? >> This brings me again to: what is the use case for running an >> animation from a background thread? > > The only possible use case I can think of is when using FX > properties stand-alone (ie. only using javafx.base), without any > FX thread involvement.? Even in that case though one has to > remember that properties themselves are not thread safe either.? > Any "animation" would need to be done on the same thread that is > manipulating properties. > > However, Animation and Timeline simply can't work in such > scenario's, as they're tied to javafx.graphics, to the FX system > being started, and the FX thread.? For such a use case you'd need > to write your own system, or provide the option of specifying an > Executor for Animations/Timelines. > > >> In your simple example, listening on the Status property would >> work. Also, while runLater makes no guarantees, I've never seen a >> non-negligible delay in its execution,?so how surprising is?it >> really going to be? >> >> If you want to be able to run an animation from a background >> thread with no race conditions, why not opt for option 3? > > Option 3 is basically document it as "be careful" and remove the > thread restriction recently introduced, am I correct? > > IMHO that can simply can't work at all, because this is what > (theoretically) can happen: > > 1. Non-FX thread starts animation > ???? - Fields are manipulated in AbstractPrimaryTimer > ???? - There is no synchronization, so no guarantee anything is > flushed (it may all reside in CPU caches) > > 2. FX Thread becomes involved to actually process the animation > ???? - Sees partially flushed state fields, and acts on garbage > information (ie. number of animations > 0, but array contains only > null's) > > There just is no safe way to do this in without synchronization or > having everything immutable (and this extends to references to > "thread safe" structures). > > --John > >> >> And option 1 is also new and surprising because now code that >> worked (or pretended to work) throws, which ruins properly >> written code (with respect to multithreading), or exposes a bug. >> >> On Wed, Jan 24, 2024 at 9:04?PM Michael Strau? >> wrote: >> >> I am not in favor of option 2 if the implementation was >> simply "wrap >> the implementation in runLater", as this would be a >> surprising change. >> Consider the following code: >> >> ? ? var transition = new FadeTransition(); >> ? ? transition.play(); >> >> ? ? // Will always print "RUNNING" currently, but might print >> "STOPPED" >> ? ? // if we go with the proposed change: >> ? ? System.out.println(transition.getStatus()); >> >> Regardless of the race condition in AbstractPrimaryTimer, >> this code >> always seemed to be working quite fine (albeit >> superficially), because >> the play/stop/etc. methods change that status o