From ajoseph at openjdk.java.net Mon Feb 1 03:34:53 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 1 Feb 2021 03:34:53 GMT Subject: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows Message-ID: Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few ms early. The same is not present in `WorkQueueGeneric` and needs to be added. Also removing `WorkQueueWin` as it's removed for WebKit as well. ------------- Commit messages: - 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows Changes: https://git.openjdk.java.net/jfx/pull/391/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=391&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260163 Stats: 204 lines in 3 files changed: 5 ins; 199 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/391.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/391/head:pull/391 PR: https://git.openjdk.java.net/jfx/pull/391 From jhendrikx at openjdk.java.net Mon Feb 1 04:44:03 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 1 Feb 2021 04:44:03 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. John Hendrikx has updated the pull request incrementally with four additional commits since the last revision: - Add missing TreeShowingExpressionTest which also tests SubScene - Also dispose listeners on Window/Showing in dispose - Fix review comments - Update copyrights ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/185/files - new: https://git.openjdk.java.net/jfx/pull/185/files/e68a886d..2b6df779 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=02-03 Stats: 342 lines in 7 files changed: 325 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/185/head:pull/185 PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Mon Feb 1 04:44:04 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 1 Feb 2021 04:44:04 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v3] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Thu, 28 Jan 2021 13:37:59 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add performance test >> - Use registerChangeListener in ProgressIndicatorSkin > > The updated fix using `registerChangeListener` and the test look good. I left a few mostly-minor comments. I think this change is complete now, including an integration test and tests on all new code. Please let me know if anything else needs to be done. > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/TreeShowingExpression.java line 2: > >> 1: /* >> 2: * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved. > > change 2020 to 2021 Solved, and also did this in all other files included in this change. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Mon Feb 1 04:44:05 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 1 Feb 2021 04:44:05 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <0QZ-f0ZmMKwfVDHvdJnUedzwDn87R-gQvyQxNp-y49Q=.038a108a-c7e5-4ad3-823b-c06fe9afd03c@github.com> On Fri, 22 Jan 2021 21:36:06 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add missing TreeShowingExpressionTest which also tests SubScene >> - Also dispose listeners on Window/Showing in dispose >> - Fix review comments >> - Update copyrights > > modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java line 312: > >> 310: _value.setTreeVisible(isTreeVisible()); >> 311: _value.setDisabled(isDisabled()); >> 312: _value.setTreeShowing(isTreeShowing()); > > This looks fine. It might be worth adding a unit test to ensure that `isTreeShowing` works correctly for nodes in a `SubScene`. I've added a test for this in `TreeShowingExpressionTest`. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Mon Feb 1 13:31:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Feb 2021 13:31:45 GMT Subject: Integrated: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. This pull request has now been integrated. Changeset: 217a8cba Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/217a8cba Stats: 446 lines in 15 files changed: 445 ins; 0 del; 1 mod 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys Reviewed-by: arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Feb 1 14:01:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Feb 2021 14:01:43 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 20:21:59 GMT, Nir Lisker wrote: >> The usual doc fixes (for OpenJFX 16). >> >> Can wait until RDP2 to see if something else comes up. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From kcr at openjdk.java.net Mon Feb 1 15:38:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Feb 2021 15:38:44 GMT Subject: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 03:31:10 GMT, Arun Joseph wrote: > Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few ms early. The same is not present in `WorkQueueGeneric` and needs to be added. > > Also removing `WorkQueueWin` as it's removed for WebKit as well. The fix and the test look good with one question and one doc comment. modules/javafx.web/src/main/native/Source/WTF/wtf/generic/WorkQueueGeneric.cpp line 78: > 76: // Adding the slop adjustment from wtf/win/WorkQueueWin.cpp > 77: const Seconds slopAdjustment { 20_ms }; > 78: delay += slopAdjustment; Can you replace the above comment with the actual comment from the (now-deleted) `WorkQueueWin.cpp` file? Also, I see that the original fix only added the `slopAdjustment` if `delay` was non-zero. Should that be preserved? ------------- PR: https://git.openjdk.java.net/jfx/pull/391 From ajoseph at openjdk.java.net Mon Feb 1 16:52:10 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 1 Feb 2021 16:52:10 GMT Subject: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2] In-Reply-To: References: Message-ID: > Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few ms early. The same is not present in `WorkQueueGeneric` and needs to be added. > > Also removing `WorkQueueWin` as it's removed for WebKit as well. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Update comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/391/files - new: https://git.openjdk.java.net/jfx/pull/391/files/739f3207..ea61414f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=391&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=391&range=00-01 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/391.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/391/head:pull/391 PR: https://git.openjdk.java.net/jfx/pull/391 From kcr at openjdk.java.net Mon Feb 1 16:58:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Feb 2021 16:58:47 GMT Subject: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 16:52:10 GMT, Arun Joseph wrote: >> Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few ms early. The same is not present in `WorkQueueGeneric` and needs to be added. >> >> Also removing `WorkQueueWin` as it's removed for WebKit as well. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Update comment modules/javafx.web/src/main/native/Source/WTF/wtf/generic/WorkQueueGeneric.cpp line 85: > 83: // so far. > 84: const Seconds slopAdjustment { 20_ms }; > 85: if (delay) Since `delay` is an object of type `Seconds`, should this be `if (delay.milliseconds())`? Otherwise, won't it just check whether the object is non-null? ------------- PR: https://git.openjdk.java.net/jfx/pull/391 From ajoseph at openjdk.java.net Mon Feb 1 17:36:44 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 1 Feb 2021 17:36:44 GMT Subject: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2] In-Reply-To: References: Message-ID: <2uvQkMIm-4Ar9rvFs90wTlpapNv0CoYI91GHVd-axBI=.81ca5695-6628-4926-b680-32e5eeaec11d@github.com> On Mon, 1 Feb 2021 16:55:50 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment > > modules/javafx.web/src/main/native/Source/WTF/wtf/generic/WorkQueueGeneric.cpp line 85: > >> 83: // so far. >> 84: const Seconds slopAdjustment { 20_ms }; >> 85: if (delay) > > Since `delay` is an object of type `Seconds`, should this be `if (delay.milliseconds())`? Otherwise, won't it just check whether the object is non-null? In [Seconds.h](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/Seconds.h), there's an `operator bool()` which checks the m_value. ------------- PR: https://git.openjdk.java.net/jfx/pull/391 From kcr at openjdk.java.net Mon Feb 1 18:02:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Feb 2021 18:02:41 GMT Subject: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 16:52:10 GMT, Arun Joseph wrote: >> Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few ms early. The same is not present in `WorkQueueGeneric` and needs to be added. >> >> Also removing `WorkQueueWin` as it's removed for WebKit as well. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Update comment Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/391 From github.com+31666175+jonathanvusich at openjdk.java.net Mon Feb 1 21:02:52 2021 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Mon, 1 Feb 2021 21:02:52 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5] In-Reply-To: References: Message-ID: > As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Remove unused import - Unrotate labels if there is enough space for them - Added copyright header - Added fix and test ------------- Changes: https://git.openjdk.java.net/jfx/pull/342/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=04 Stats: 126 lines in 2 files changed: 126 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342 From kcr at openjdk.java.net Mon Feb 1 21:31:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Feb 2021 21:31:43 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5] In-Reply-To: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> Message-ID: On Wed, 25 Nov 2020 15:56:05 GMT, Jonathan Vusich wrote: >> While this does fix the specific problem, it introduces a new one. If the labels are initially too big, but after resizing the window would now fit, it does not recompute the orientation. This means that you are left with labels that are rotated even when they don't need to be. > > @kevinrushforth Thank you for catching that. Do you think it would be acceptable to simply rotate the labels back to zero if the user expands the window? @JonathanVusich Once a review is in progress, please don't force-push your branch without a compelling reason, since that makes it harder to do incremental reviews. In the future, we recommend `git merge master` rather than `git rebase master`, since the former doesn't require force-pushing. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From kcr at openjdk.java.net Mon Feb 1 21:40:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Feb 2021 21:40:43 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5] In-Reply-To: References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> Message-ID: On Mon, 1 Feb 2021 21:28:58 GMT, Kevin Rushforth wrote: >> @kevinrushforth Thank you for catching that. Do you think it would be acceptable to simply rotate the labels back to zero if the user expands the window? > > @JonathanVusich Once a review is in progress, please don't force-push your branch without a compelling reason, since that makes it harder to do incremental reviews. In the future, we recommend `git merge master` rather than `git rebase master`, since the former doesn't require force-pushing. I do see that there are no changes from last time, which is good, so it will be fine for this time. When ready, you can add the new test by pushing a new commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From github.com+31666175+jonathanvusich at openjdk.java.net Mon Feb 1 23:12:08 2021 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Mon, 1 Feb 2021 23:12:08 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6] In-Reply-To: References: Message-ID: <16kUqQeqlS-UX5eowm6MXCxwfp_kJEhaTOM100o4N50=.80846225-0435-4f38-809e-3c5d2074ddfa@github.com> > As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request incrementally with two additional commits since the last revision: - Add tests for vertical axis as well - Improve layout calculations for rotated text ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/342/files - new: https://git.openjdk.java.net/jfx/pull/342/files/dff9ee17..d5a3fae9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=04-05 Stats: 134 lines in 3 files changed: 120 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342 From github.com+31666175+jonathanvusich at openjdk.java.net Mon Feb 1 23:15:46 2021 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Mon, 1 Feb 2021 23:15:46 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6] In-Reply-To: References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> Message-ID: On Mon, 1 Feb 2021 21:37:44 GMT, Kevin Rushforth wrote: >> @JonathanVusich Once a review is in progress, please don't force-push your branch without a compelling reason, since that makes it harder to do incremental reviews. In the future, we recommend `git merge master` rather than `git rebase master`, since the former doesn't require force-pushing. > > I do see that there are no changes from last time, which is good, so it will be fine for this time. > > When ready, you can add the new test by pushing a new commit. @kevinrushforth I was not aware of that, thank you for letting me know! I wrote a new test for vertical axes and discovered that there were more issues with axis layout calculations, which I also addressed. I also found out that the layout tests sometimes fail without a short pause using `Util.sleep()`. I don't really like having to add sleeps, but I did find that it got rid of any test flakiness. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From kcr at openjdk.java.net Tue Feb 2 00:27:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Feb 2021 00:27:43 GMT Subject: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 20:56:07 GMT, Nir Lisker wrote: > Deprecating protected members in DateTimeStringConverter. Internal implementation should not be exposed (similar to `NumberStringConverter` and others). Can you also add a javadoc comment block with an `@deprecated tag` to each field or method, similar to what we recently did for [JDK-8252387](https://bugs.openjdk.java.net/browse/JDK-8252387)? ------------- PR: https://git.openjdk.java.net/jfx/pull/390 From ajoseph at openjdk.java.net Tue Feb 2 02:28:44 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 2 Feb 2021 02:28:44 GMT Subject: Integrated: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 03:31:10 GMT, Arun Joseph wrote: > Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few ms early. The same is not present in `WorkQueueGeneric` and needs to be added. > > Also removing `WorkQueueWin` as it's removed for WebKit as well. This pull request has now been integrated. Changeset: e481f8c7 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/e481f8c7 Stats: 212 lines in 3 files changed: 13 ins; 199 del; 0 mod 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/391 From naastonn at gmail.com Tue Feb 2 06:37:10 2021 From: naastonn at gmail.com (naastonn at gmail.com) Date: Tue, 02 Feb 2021 10:37:10 +0400 Subject: Make javafx.controls open and community-driven Message-ID: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> Hello. JavaFX is a great toolkit, which personally I like a lot, but it's slowly dying for the past 5 years. You can barely argue with that. Most of the devs still prefer Swing. Have a look how many topics like "JavaFX is dead" on Reddit or similar resources. Look how many community libraries are abandoned or badly maintained (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, like ControlsFX. Look how small the numbers of real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX or have plans to use it in any near future. Eclipse sticks with SWT, NetBeans uses FlatLaf (https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of resources into JetPack Compose. They even implemented interop layer for Swing apps (https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/). OpenJFX team is understaffed while modern desktop and mobile applications require more components that JavaFX could provide (and support) at the moment. javafx.controls are outdated and Modena theme doesn't look pleasing anymore. But that's not the worst part about it. The worst part is that it's almost impossible to extend existing components. I do understand that current resources and maintainers time are very limited and maintaining graphics layer should be top priority. The only thing I ask is to REMOVE BARRIERS that stop those who want to improve standard controls. Make javafx.controls fully open. Allow community to fix things that you don't have time to fix. 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK maintainers. But OpenJFX is not a part of OpenJDK, not anymore. No other UI library imposes strict limitations like these. Check Electron, Avalonia, WXwidgets, even god-damned proprietary Qt. While it may be the case for low-level stuff like javafx.graphics it's absolutely unacceptable for controls. You're stopping a lot of people from commenting existing bugs and sharing their workarounds and any feedback they could provide. Moreover you require signing OCA from everyone who want to commit into controls even if it's a slightest improvement. 2. Controls implementation is hidden for NO GOOD REASON. Almost everything in skins is private and things like *Behavior are module-private. Hello, fellow users! Wanna DatePicker w/o text field or TreeCell w/o disclosure node? Sorry, you can't w/o re-implementing everything from scratch. This is effectively stops everyone who want to improve current skin for it's own project or create a library that extends current controls. https://github.com/sshahine/JFoenix/issues/955 https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above That's why JS is so popular. No self imposed limitations! Everything is customizable, manipulate the DOM in any way you want. 3. javafx.controls i18n support is very limited (https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ resources). You've put a lot or resources in thing like RTL implementation, but who cares if there's literally no API to customize standard controls. Back to #2, it would be possible if you'd opened skins for customization or/and reflection. Summary: - Move javafx.controls support to the Github (not to javafxports, it's outdated and barely maintained). Mark issues: "good first issue", "help needed" etc. Everyone do this, because it helps to encourage new devs to participate into development. This is exactly how social coding works. - Allow community to extend and improve controls in any way they want. Export "com.sun.javafx.scene.control" (esp "com.sun.javafx.scene.control.behavior.*") and make everything "" inside skins protected, not private. I beg you to hear me. Controls are just controls, it's not a platform thing, it's not something sacred you should keep in private. You can't possibly foreknow all possible uses cases. By stopping to extend them you just lose your users and that's it. They simply go away and use more extensible and feature-rich alternative. Ironically, even Swing beats JavaFX in that case. We need more libraries like JFoenix and ControlsFX. Without that you can't compete with either Flutter or Compose in near future. You literally doom JavaFX to stay a bunch of legacy controls no one really like or want to use. Ideally javafx.controls should not rely on private javafx.graphics or javafx.base API at all. - Be open. Stop hiding in mailing lists. There's no corporation behind JavaFX, it won't survive without community. There's?https://www.reddit.com/r/JavaFX. Share your plans, make regular announcements, discuss what need to be improved. Guide community efforts! - Invest some time into i18n support. There's no way to localize controls w/o dirty hack (https://pastebin.com/RgadNwZd). If you'd removed JBS/OCA barrier for javafx.controls more people could help you with that. Even w/o that you could just ask people on Reddit to translate controls.properties (it's really short) into their native language and commit it yourself.? Thanks for reading this. Best regards Mike From julianjupiter.io at gmail.com Tue Feb 2 07:02:55 2021 From: julianjupiter.io at gmail.com (Julian Jupiter) Date: Tue, 2 Feb 2021 15:02:55 +0800 Subject: Make javafx.controls open and community-driven In-Reply-To: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> References: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> Message-ID: Yes, please! Julez On Tue, Feb 2, 2021, 2:37 PM , wrote: > Hello. > > JavaFX is a great toolkit, which personally I like a lot, but it's slowly > dying for the past 5 years. You can barely > argue with that. Most of the devs still prefer Swing. Have a look how many > topics like "JavaFX is dead" on Reddit or > similar resources. Look how many community libraries are abandoned or > badly maintained > (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, > like ControlsFX. Look how small the numbers of > real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX > or have plans to use it in any near future. > Eclipse sticks with SWT, NetBeans uses FlatLaf ( > https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of > resources into JetPack Compose. They even implemented interop layer for > Swing apps > ( > https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/ > ). > > OpenJFX team is understaffed while modern desktop and mobile applications > require more components that JavaFX could > provide (and support) at the moment. javafx.controls are outdated and > Modena theme doesn't look pleasing anymore. But > that's not the worst part about it. The worst part is that it's almost > impossible to extend existing components. I do > understand that current resources and maintainers time are very limited > and maintaining graphics layer should be top > priority. The only thing I ask is to REMOVE BARRIERS that stop those who > want to improve standard controls. Make > javafx.controls fully open. Allow community to fix things that you don't > have time to fix. > > 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK > maintainers. But OpenJFX is not a part of > OpenJDK, not anymore. No other UI library imposes strict limitations like > these. Check Electron, Avalonia, WXwidgets, > even god-damned proprietary Qt. While it may be the case for low-level > stuff like javafx.graphics it's absolutely > unacceptable for controls. You're stopping a lot of people from commenting > existing bugs and sharing their workarounds > and any feedback they could provide. Moreover you require signing OCA from > everyone who want to commit into controls > even if it's a slightest improvement. > > 2. Controls implementation is hidden for NO GOOD REASON. Almost everything > in skins is private and things like *Behavior > are module-private. Hello, fellow users! Wanna DatePicker w/o text field > or TreeCell w/o disclosure node? Sorry, you > can't w/o re-implementing everything from scratch. This is effectively > stops everyone who want to improve current skin > for it's own project or create a library that extends current controls. > > https://github.com/sshahine/JFoenix/issues/955 > > https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above > > That's why JS is so popular. No self imposed limitations! Everything is > customizable, manipulate the DOM in any way you > want. > > 3. javafx.controls i18n support is very limited > ( > https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ > > > resources). You've put a lot or resources in thing like RTL > implementation, but who cares if there's literally no API to > customize standard controls. Back to #2, it would be possible if you'd > opened skins for customization or/and reflection. > > Summary: > > - Move javafx.controls support to the Github (not to javafxports, it's > outdated and barely maintained). Mark issues: > "good first issue", "help needed" etc. Everyone do this, because it helps > to encourage new devs to participate into > development. This is exactly how social coding works. > - Allow community to extend and improve controls in any way they want. > Export "com.sun.javafx.scene.control" (esp > "com.sun.javafx.scene.control.behavior.*") and make everything " Node>" inside skins protected, not private. > I beg you to hear me. Controls are just controls, it's not a platform > thing, it's not something sacred you should keep > in private. You can't possibly foreknow all possible uses cases. By > stopping to extend them you just lose your users and > that's it. They simply go away and use more extensible and feature-rich > alternative. Ironically, even Swing beats JavaFX > in that case. We need more libraries like JFoenix and ControlsFX. Without > that you can't compete with either Flutter or > Compose in near future. You literally doom JavaFX to stay a bunch of > legacy controls no one really like or want to use. > Ideally javafx.controls should not rely on private javafx.graphics or > javafx.base API at all. > - Be open. Stop hiding in mailing lists. There's no corporation behind > JavaFX, it won't survive without community. > There's https://www.reddit.com/r/JavaFX. Share your plans, make regular > announcements, discuss what need to be improved. > Guide community efforts! > - Invest some time into i18n support. There's no way to localize controls > w/o dirty hack > (https://pastebin.com/RgadNwZd). If you'd removed JBS/OCA barrier for > javafx.controls more people could help you with > that. Even w/o that you could just ask people on Reddit to translate > controls.properties (it's really short) into their > native language and commit it yourself. > > Thanks for reading this. > > Best regards > Mike > > From tbee at tbee.org Tue Feb 2 07:11:28 2021 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 2 Feb 2021 08:11:28 +0100 Subject: Make javafx.controls open and community-driven In-Reply-To: References: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> Message-ID: I have to agree. All the protection measures, although well intended originally, are not helping. On 2-2-2021 08:02, Julian Jupiter wrote: > Yes, please! > > > Julez > > On Tue, Feb 2, 2021, 2:37 PM , wrote: > >> Hello. >> >> JavaFX is a great toolkit, which personally I like a lot, but it's slowly >> dying for the past 5 years. You can barely >> argue with that. Most of the devs still prefer Swing. Have a look how many >> topics like "JavaFX is dead" on Reddit or >> similar resources. Look how many community libraries are abandoned or >> badly maintained >> (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, >> like ControlsFX. Look how small the numbers of >> real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX >> or have plans to use it in any near future. >> Eclipse sticks with SWT, NetBeans uses FlatLaf ( >> https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of >> resources into JetPack Compose. They even implemented interop layer for >> Swing apps >> ( >> https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/ >> ). >> >> OpenJFX team is understaffed while modern desktop and mobile applications >> require more components that JavaFX could >> provide (and support) at the moment. javafx.controls are outdated and >> Modena theme doesn't look pleasing anymore. But >> that's not the worst part about it. The worst part is that it's almost >> impossible to extend existing components. I do >> understand that current resources and maintainers time are very limited >> and maintaining graphics layer should be top >> priority. The only thing I ask is to REMOVE BARRIERS that stop those who >> want to improve standard controls. Make >> javafx.controls fully open. Allow community to fix things that you don't >> have time to fix. >> >> 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK >> maintainers. But OpenJFX is not a part of >> OpenJDK, not anymore. No other UI library imposes strict limitations like >> these. Check Electron, Avalonia, WXwidgets, >> even god-damned proprietary Qt. While it may be the case for low-level >> stuff like javafx.graphics it's absolutely >> unacceptable for controls. You're stopping a lot of people from commenting >> existing bugs and sharing their workarounds >> and any feedback they could provide. Moreover you require signing OCA from >> everyone who want to commit into controls >> even if it's a slightest improvement. >> >> 2. Controls implementation is hidden for NO GOOD REASON. Almost everything >> in skins is private and things like *Behavior >> are module-private. Hello, fellow users! Wanna DatePicker w/o text field >> or TreeCell w/o disclosure node? Sorry, you >> can't w/o re-implementing everything from scratch. This is effectively >> stops everyone who want to improve current skin >> for it's own project or create a library that extends current controls. >> >> https://github.com/sshahine/JFoenix/issues/955 >> >> https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above >> >> That's why JS is so popular. No self imposed limitations! Everything is >> customizable, manipulate the DOM in any way you >> want. >> >> 3. javafx.controls i18n support is very limited >> ( >> https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ >> >> >> resources). You've put a lot or resources in thing like RTL >> implementation, but who cares if there's literally no API to >> customize standard controls. Back to #2, it would be possible if you'd >> opened skins for customization or/and reflection. >> >> Summary: >> >> - Move javafx.controls support to the Github (not to javafxports, it's >> outdated and barely maintained). Mark issues: >> "good first issue", "help needed" etc. Everyone do this, because it helps >> to encourage new devs to participate into >> development. This is exactly how social coding works. >> - Allow community to extend and improve controls in any way they want. >> Export "com.sun.javafx.scene.control" (esp >> "com.sun.javafx.scene.control.behavior.*") and make everything "> Node>" inside skins protected, not private. >> I beg you to hear me. Controls are just controls, it's not a platform >> thing, it's not something sacred you should keep >> in private. You can't possibly foreknow all possible uses cases. By >> stopping to extend them you just lose your users and >> that's it. They simply go away and use more extensible and feature-rich >> alternative. Ironically, even Swing beats JavaFX >> in that case. We need more libraries like JFoenix and ControlsFX. Without >> that you can't compete with either Flutter or >> Compose in near future. You literally doom JavaFX to stay a bunch of >> legacy controls no one really like or want to use. >> Ideally javafx.controls should not rely on private javafx.graphics or >> javafx.base API at all. >> - Be open. Stop hiding in mailing lists. There's no corporation behind >> JavaFX, it won't survive without community. >> There's https://www.reddit.com/r/JavaFX. Share your plans, make regular >> announcements, discuss what need to be improved. >> Guide community efforts! >> - Invest some time into i18n support. There's no way to localize controls >> w/o dirty hack >> (https://pastebin.com/RgadNwZd). If you'd removed JBS/OCA barrier for >> javafx.controls more people could help you with >> that. Even w/o that you could just ask people on Reddit to translate >> controls.properties (it's really short) into their >> native language and commit it yourself. >> >> Thanks for reading this. >> >> Best regards >> Mike >> >> From fastegal at openjdk.java.net Tue Feb 2 12:04:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 2 Feb 2021 12:04:42 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6] In-Reply-To: References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> Message-ID: <7ivK8A9fCK-8XRFBlGkBkoWRP5xuwDDy_P8tNSKHxYE=.c81f3909-bc9c-4d85-a837-8ade6afc27d9@github.com> On Mon, 1 Feb 2021 23:13:02 GMT, Jonathan Vusich wrote: >> I do see that there are no changes from last time, which is good, so it will be fine for this time. >> >> When ready, you can add the new test by pushing a new commit. > > @kevinrushforth I was not aware of that, thank you for letting me know! > I wrote a new test for vertical axes and discovered that there were more issues with axis layout calculations, which I also addressed. > > I also found out that the layout tests sometimes fail without a short pause using `Util.sleep()`. I don't really like having to add sleeps, but I did find that it got rid of any test flakiness. wondering about the system test - what stands in the way to add a simple "normal" unit test? ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From fastegal at openjdk.java.net Tue Feb 2 13:17:44 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 2 Feb 2021 13:17:44 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v3] In-Reply-To: <1X3jSdcGCK-ftUW7GZsFHzk7oJA2t2cXrpP1LrwbDxc=.c4e11c26-f86b-4470-aafd-d245fd4735be@github.com> References: <8LlhfU0Zb-0FAM7E1sOl-9LSEzP-unqsmkA8EhB9MiE=.e8024574-6050-4d0a-87a1-09f081136124@github.com> <1X3jSdcGCK-ftUW7GZsFHzk7oJA2t2cXrpP1LrwbDxc=.c4e11c26-f86b-4470-aafd-d245fd4735be@github.com> Message-ID: <_viZbB_qbM23-0vkhSEJT6ptXgGMKMWU12f80s7b9Qc=.c3cad891-153b-4685-97fc-79d8894dadee@github.com> On Tue, 22 Dec 2020 09:32:36 GMT, Ajit Ghaisas wrote: > > > At first, I thought this setTickLabelRotation() call violates the method javadoc above. On a second look, I found that the javadoc is applicable only if AutoRanging() is true. > Method calls - calculateNewSpacing() and calculateNewFirstPos() also set properties if AutoRanging is false. Hence, this fix seems OK to me. hmm ... indeed they do, unexpected for me, reading the must-not-effect-the-state in the javadoc ;) Sounds like a doc error, if the intention was to clearly state that the method shouldn't do the auto-ranging itself? ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From pedro.duquevieira at gmail.com Tue Feb 2 14:12:15 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 2 Feb 2021 14:12:15 +0000 Subject: Make javafx.controls open and community-driven Message-ID: Hi, Although I don't agree with everything said here at the start of this thread, I agree with the base idea that JavaFX would benefit from being more open than it is currently. It's something I've already said here in this mailing list and since it's been a while and that discussion probably already got forgotten I'll add the comments to this thread again. Not even just the controls case but more hooks to extend JavaFX just generally by adding API that allows for that and making things less private/final/etc. It would be great to be able to extend more parts of JavaFX in a library independent way (i.e. by creating your own library that extends some parts of JavaFX in more fundamental cool way). Besides what was already said about controls, here's another example: wouldn't it be great for the community to be able to create a library that could extend the CSS parser by adding animations, layout support, etc, etc. One could argue, why don't you just contribute a PR to the JavaFX code base that does just that (adds animation support to CSS, or something less trivial like that)? I'd say that that process is too lengthy and often out of possibility for an individual developer that wants to improve JavaFX but doesn't have time to do it that way. I see the advantage of exposing less of the internals and why the JavaFX team decided to do it. Many of the same guys that developed JavaFX were part of the Swing team which were bothered by the inverse situation, i.e. being too open (which also can have its disadvantages). Weighing in the pros and cons, I still think there's a bigger advantage in being more open than closed. This hinders the capacity for the community to create libraries that extend JavaFX in new and fundamental ways without having to fork JavaFX. And this is more of a reality now that the JavaFX team is smaller (than the original team) and hence has less capacity to keep improving and adding features to JavaFX which means it has to rely more on the community. I also agree with the process of submitting a bug and following upon it, commenting, etc. Ideally it should be easier. That's something that has also been brought up before. Anyways, this mail is not meant to put down the guys working on JavaFX, there are no perfect toolkits, each one has its downfalls. Think it more like throwing in ideas and sharing my experience of using JavaFX for creating libraries and applications. -- Pedro Duque Vieira - https://www.pixelduke.com From mp at jugs.org Tue Feb 2 14:30:17 2021 From: mp at jugs.org (Michael Paus) Date: Tue, 2 Feb 2021 15:30:17 +0100 Subject: Make javafx.controls open and community-driven In-Reply-To: References: Message-ID: <8d81d978-17f0-7f0c-e050-429bf3fa2241@jugs.org> 1+ Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira: > Hi, > > Although I don't agree with everything said here at the start of this > thread, I agree with the base idea that JavaFX would benefit from being > more open than it is currently. It's something I've already said here in > this mailing list and since it's been a while and that discussion probably > already got forgotten I'll add the comments to this thread again. > > Not even just the controls case but more hooks to extend JavaFX just > generally by adding API that allows for that and making things less > private/final/etc. It would be great to be able to extend more parts of > JavaFX in a library independent way (i.e. by creating your own library that > extends some parts of JavaFX in more fundamental cool way). > Besides what was already said about controls, here's another example: > wouldn't it be great for the community to be able to create a library that > could extend the CSS parser by adding animations, layout support, etc, etc. > One could argue, why don't you just contribute a PR to the JavaFX code base > that does just that (adds animation support to CSS, or something less > trivial like that)? I'd say that that process is too lengthy and often out > of possibility for an individual developer that wants to improve JavaFX but > doesn't have time to do it that way. > > I see the advantage of exposing less of the internals and why the JavaFX > team decided to do it. Many of the same guys that developed JavaFX were > part of the Swing team which were bothered by the inverse situation, i.e. > being too open (which also can have its disadvantages). > Weighing in the pros and cons, I still think there's a bigger advantage in > being more open than closed. This hinders the capacity for the community to > create libraries that extend JavaFX in new and fundamental ways without > having to fork JavaFX. > And this is more of a reality now that the JavaFX team is smaller (than the > original team) and hence has less capacity to keep improving and adding > features to JavaFX which means it has to rely more on the community. > > I also agree with the process of submitting a bug and following upon it, > commenting, etc. Ideally it should be easier. That's something that has > also been brought up before. > > Anyways, this mail is not meant to put down the guys working on > JavaFX, there are no perfect toolkits, each one has its downfalls. Think it > more like throwing in ideas and sharing my experience of using JavaFX for > creating libraries and applications. > From kevin.rushforth at oracle.com Tue Feb 2 21:40:17 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 2 Feb 2021 13:40:17 -0800 Subject: Make javafx.controls open and community-driven In-Reply-To: <8d81d978-17f0-7f0c-e050-429bf3fa2241@jugs.org> References: <8d81d978-17f0-7f0c-e050-429bf3fa2241@jugs.org> Message-ID: There are two separate issues here. I won't address the first point from the initial poster, other than to say that I understand that the lack of direct write access to JBS for occasional contributors is a pain point. I don't think it is stopping anyone from contributing, though. As for the other part of this point, JavaFX is already on GitHub along with the rest of the JDK, and it's easy enough for someone who is motivated to provide a pull request for a bug fix. The more interesting question is the one about extensibility that others have also responded to. This raises the question of which areas are most in need of new public API to facilitate this. "Just make every internal detail of your implementation public or protected" isn't the right way to frame the discussion. Anything that makes it into the public API is something that needs to be documented, tested, and supported. It requires us to consider what it means to support that API forever; we take compatibility seriously. The main idea is to think in terms of "stewardship" when evolving the JavaFX API. Keeping that in mind, there are certainly areas that could be made easier to extend. Two things in the UI Controls area that were brought up are skins, which are public API with not all of the fields and methods of the skins are public/protected, and behaviors. The former isn't too difficult to address. It requires some amount of thought, discussion, API documentation, implementation, and testing, but doesn't need a whole new design. VirtualFlow has been extended in this fashion to provide missing pieces for third-party controls. If there are others, developers can propose them and we can discuss them. This is definitely an area we would welcome well-thought-out contributions in. The harder area is that of behaviors. For a little background, a public behaviors API was originally part of the proposed new public API for FX in JDK 9, which was done via JEP 253 [1]. It was decoupled from that JEP, but still remains an open enhancement request tracked by JDK-8091189 [2]. That JBS issue has a very long discussion thread about possible approaches for the API. This would be a very large effort, and would require someone with a very good understanding of both UI control design in general and the design and implementation of JavaFX UI Controls in particular to lead the effort. It isn't something that we would accept from an application developer who is just wanting to make their life easier. Again, think of it in terms of API stewardship. I'm not saying there is no way this could be done, just that it's unlikely. I'm sure there are other areas outside of UI controls that could be made more extensible, too (although knowing how fragile CSS is, I wouldn't have much enthusiasm for that). What we would need is a concrete proposal that we could discuss. -- Kevin [1] https://openjdk.java.net/jeps/253 [2] https://bugs.openjdk.java.net/browse/JDK-8091189 On 2/2/2021 6:30 AM, Michael Paus wrote: > 1+ > > Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira: >> Hi, >> >> Although I don't agree with everything said here at the start of this >> thread, I agree with the base idea that JavaFX would benefit from being >> more open than it is currently. It's something I've already said here in >> this mailing list and since it's been a while and that discussion >> probably >> already got forgotten I'll add the comments to this thread again. >> >> Not even just the controls case but more hooks to extend JavaFX just >> generally by adding API that allows for that and making things less >> private/final/etc. It would be great to be able to extend more parts of >> JavaFX in a library independent way (i.e. by creating your own >> library that >> extends some parts of JavaFX in more fundamental cool way). >> Besides what was already said about controls, here's another example: >> wouldn't it be great for the community to be able to create a library >> that >> could extend the CSS parser by adding animations, layout support, >> etc, etc. >> One could argue, why don't you just contribute a PR to the JavaFX >> code base >> that does just that (adds animation support to CSS, or something less >> trivial like that)? I'd say that that process is too lengthy and >> often out >> of possibility for an individual developer that wants to improve >> JavaFX but >> doesn't have time to do it that way. >> >> I see the advantage of exposing less of the internals and why the JavaFX >> team decided to do it. Many of the same guys that developed JavaFX were >> part of the Swing team which were bothered by the inverse situation, >> i.e. >> being too open (which also can have its disadvantages). >> Weighing in the pros and cons, I still think there's a bigger >> advantage in >> being more open than closed. This hinders the capacity for the >> community to >> create libraries that extend JavaFX in new and fundamental ways without >> having to fork JavaFX. >> And this is more of a reality now that the JavaFX team is smaller >> (than the >> original team) and hence has less capacity to keep improving and adding >> features to JavaFX which means it has to rely more on the community. >> >> I also agree with the process of submitting a bug and following upon it, >> commenting, etc. Ideally it should be easier. That's something that has >> also been brought up before. >> >> Anyways, this mail is not meant to put down the guys working on >> JavaFX, there are no perfect toolkits, each one has its downfalls. >> Think it >> more like throwing in ideas and sharing my experience of using JavaFX >> for >> creating libraries and applications. >> > From nlisker at gmail.com Wed Feb 3 02:16:33 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 3 Feb 2021 04:16:33 +0200 Subject: Make javafx.controls open and community-driven In-Reply-To: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> References: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> Message-ID: Hi Mike, First of all, I would have you consider revisiting your medical observation on the state of JavaFX. If you've read the almost-weekly recurrent threads of "should I use Swing or JavaFX" in r/Java, you'd realize that reports of JavaFX's death are greatly exaggerated. But yes, it is very understaffed. Other than that, there is a discussion list, openjfx-discuss at openjdk.java.net, where you can bring up general community and social media related topics and continue that branch of the discussion there. 1. I also advocated for having JBS more open in the past. I was told that Oracle tried opening JBS for everyone, but it was a big mess. I remember Alan Bateman saying a few years ago in an Ask The Architect session, when he was asked about this, that more than half of the bugs submitted are about OpenGL in Minecraft. These are the things you don't see from the outside. Another thing you need to consider is that we don't want to split the discussion of an issue between JBS and the mailing list. While I agree it's more comfortable to just be able to add a comment in the issue you are already reading, you can just write an email here, like you just did, with the extra info. I'm willing to spend the 30 seconds (most of which are spent on JBS loading :) ) of linking the discussion thread to the JBS issue myself. No one is being stopped from sharing their findings, this is the place to do it. As for the OCA, it is a license requirement for all of OpenJDK. The developers here have nothing to do with it. I suspect you will have to take it up with the legal department of Oracle. Good luck :) 2. There is a very good reason for hiding implementation. When you make something into a public API, you're making a long term commitment to its existence and functionality. This makes it very difficult to change it without breaking any existing behavior. Making everything public API is one of the worst decisions in terms of library design that wants to keep a contract with its users. There needs to be a way to allow controls extensions, I agree, but through an API that was designed for it. JS libraries break things all the time, which means that whenever you update a dependency you might need to rewrite some part of your code. That's the other side of the coin. The middleground is far from trivial. As for your points: - JavaFX is already on GitHub, it was one of the first (if not the first) OpenJDK project to transition. The javafxports repo was before Skara happened, and it has been defunct for a while now. We are on github.com/openjdk/jfx. - The mailing list is open, not hidden [1]. Social media is not a place to make formal announcements. The correct usage is to link announcements and such there (as done with all other OpenJDK projects and r/Java, for example). Since every reply here has agreed that it should be easier to customize controls, and there are many able bodies there, it seems like a discussion should start on a design plan (which is not "make everything public/protected). I would suggest first to break the general statement about controls into smaller chunks, like i18n, skins, css, behavior, extending an existing control vs creating a new one etc. Then look at existing issues for each, there have been many discussions on them in the past and this will give a good starting point. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/ Best, Nir On Tue, Feb 2, 2021 at 8:37 AM wrote: > Hello. > > JavaFX is a great toolkit, which personally I like a lot, but it's slowly > dying for the past 5 years. You can barely > argue with that. Most of the devs still prefer Swing. Have a look how many > topics like "JavaFX is dead" on Reddit or > similar resources. Look how many community libraries are abandoned or > badly maintained > (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, > like ControlsFX. Look how small the numbers of > real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX > or have plans to use it in any near future. > Eclipse sticks with SWT, NetBeans uses FlatLaf ( > https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of > resources into JetPack Compose. They even implemented interop layer for > Swing apps > ( > https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/ > ). > > OpenJFX team is understaffed while modern desktop and mobile applications > require more components that JavaFX could > provide (and support) at the moment. javafx.controls are outdated and > Modena theme doesn't look pleasing anymore. But > that's not the worst part about it. The worst part is that it's almost > impossible to extend existing components. I do > understand that current resources and maintainers time are very limited > and maintaining graphics layer should be top > priority. The only thing I ask is to REMOVE BARRIERS that stop those who > want to improve standard controls. Make > javafx.controls fully open. Allow community to fix things that you don't > have time to fix. > > 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK > maintainers. But OpenJFX is not a part of > OpenJDK, not anymore. No other UI library imposes strict limitations like > these. Check Electron, Avalonia, WXwidgets, > even god-damned proprietary Qt. While it may be the case for low-level > stuff like javafx.graphics it's absolutely > unacceptable for controls. You're stopping a lot of people from commenting > existing bugs and sharing their workarounds > and any feedback they could provide. Moreover you require signing OCA from > everyone who want to commit into controls > even if it's a slightest improvement. > > 2. Controls implementation is hidden for NO GOOD REASON. Almost everything > in skins is private and things like *Behavior > are module-private. Hello, fellow users! Wanna DatePicker w/o text field > or TreeCell w/o disclosure node? Sorry, you > can't w/o re-implementing everything from scratch. This is effectively > stops everyone who want to improve current skin > for it's own project or create a library that extends current controls. > > https://github.com/sshahine/JFoenix/issues/955 > > https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above > > That's why JS is so popular. No self imposed limitations! Everything is > customizable, manipulate the DOM in any way you > want. > > 3. javafx.controls i18n support is very limited > ( > https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ > > > resources). You've put a lot or resources in thing like RTL > implementation, but who cares if there's literally no API to > customize standard controls. Back to #2, it would be possible if you'd > opened skins for customization or/and reflection. > > Summary: > > - Move javafx.controls support to the Github (not to javafxports, it's > outdated and barely maintained). Mark issues: > "good first issue", "help needed" etc. Everyone do this, because it helps > to encourage new devs to participate into > development. This is exactly how social coding works. > - Allow community to extend and improve controls in any way they want. > Export "com.sun.javafx.scene.control" (esp > "com.sun.javafx.scene.control.behavior.*") and make everything " Node>" inside skins protected, not private. > I beg you to hear me. Controls are just controls, it's not a platform > thing, it's not something sacred you should keep > in private. You can't possibly foreknow all possible uses cases. By > stopping to extend them you just lose your users and > that's it. They simply go away and use more extensible and feature-rich > alternative. Ironically, even Swing beats JavaFX > in that case. We need more libraries like JFoenix and ControlsFX. Without > that you can't compete with either Flutter or > Compose in near future. You literally doom JavaFX to stay a bunch of > legacy controls no one really like or want to use. > Ideally javafx.controls should not rely on private javafx.graphics or > javafx.base API at all. > - Be open. Stop hiding in mailing lists. There's no corporation behind > JavaFX, it won't survive without community. > There's https://www.reddit.com/r/JavaFX. Share your plans, make regular > announcements, discuss what need to be improved. > Guide community efforts! > - Invest some time into i18n support. There's no way to localize controls > w/o dirty hack > (https://pastebin.com/RgadNwZd). If you'd removed JBS/OCA barrier for > javafx.controls more people could help you with > that. Even w/o that you could just ask people on Reddit to translate > controls.properties (it's really short) into their > native language and commit it yourself. > > Thanks for reading this. > > Best regards > Mike > > From nlisker at openjdk.java.net Wed Feb 3 02:49:53 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 3 Feb 2021 02:49:53 GMT Subject: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter [v2] In-Reply-To: References: Message-ID: > Deprecating protected members in DateTimeStringConverter. Internal implementation should not be exposed (similar to `NumberStringConverter` and others). Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added javadoc deprecation tags ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/390/files - new: https://git.openjdk.java.net/jfx/pull/390/files/9fb95ba8..fb6d71a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=390&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=390&range=00-01 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/390.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/390/head:pull/390 PR: https://git.openjdk.java.net/jfx/pull/390 From youngty1997 at gmail.com Wed Feb 3 04:13:15 2021 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 2 Feb 2021 22:13:15 -0600 Subject: Make javafx.controls open and community-driven In-Reply-To: References: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> Message-ID: <177e1ac5-e1bf-cdb9-4750-a8dfe32b7c87@gmail.com> On 2/2/21 8:16 PM, Nir Lisker wrote: > Hi Mike, > > First of all, I would have you consider revisiting your medical observation > on the state of JavaFX. If you've read the almost-weekly recurrent threads > of "should I use Swing or JavaFX" in r/Java, you'd realize that reports of > JavaFX's death are greatly exaggerated. But yes, it is very understaffed. > Other than that, there is a discussion list, > openjfx-discuss at openjdk.java.net, where you can bring up general community > and social media related topics and continue that branch of the discussion > there. > > 1. I also advocated for having JBS more open in the past. I was told that > Oracle tried opening JBS for everyone, but it was a big mess. I > remember Alan Bateman saying a few years ago in an Ask The Architect > session, when he was asked about this, that more than half of the bugs > submitted are about OpenGL in Minecraft. These are the things you don't see > from the outside. I'm guessing some of those are the OpenGL segfault crash on exit that affects (nearly?) *every* OpenGL based Java application for the last few years, including JavaFX and Minecraft, on Nvidia hardware. I have to clear out my build directory often because of it. > As for the OCA, it is a license requirement for all of OpenJDK. The > developers here have nothing to do with it. I suspect you will have to take > it up with the legal department of Oracle. Good luck :) > OCA is more of a symptom of a larger problem IMO: gate keeping. A long time ago I suggested a 1-liner change to JavaFX's build script that would simply place the source zip generated with the JavaFX source build *outside* the lib folder. Generating this zip inside the lib folder caused runtime problems with Ant and Netbeans whenever you designated the entire folder as a lib directory in a project and it didn't make sense anyway. It was rejected, IIRC, because of Oracle's or Gluon's server configuration issues with the change. There were no issues doing a local build that I'm aware of when I tested the change locally. More recently,? Oracle decided to break Swing applications that use the GTK L&F on Arch Linux based distros in JDK 16, was notified of the issue multiple times by multiple people, and AFAIK refused to revert the changes simply because Arch Linux isn't a "supported" distro. AFAIK, it's still not possible to even launch Netbeans on Arch Linux without overriding the L&F. Even more recently, I suggested (and was willing to actually do) what I thought to be reasonable API changes to Project Panama, which I use in my JavaFX application,? were rejected because it was decided a year ago behind closed doors discussions that the direction of that API part was already decided. Not only that, but the ability to even have a public discussion was basically shut down. Someone has to be that person to make the decisions in the end, but often times it feels like free outsourcing rather than contributing. One moment it's "You should contribute!" and the next it's "No, I didn't mean contribute *that* way!". Anyway, this is a much larger issue that goes beyond JavaFX and I don't want to derail, I'm just pointing out that not only when someone suggests reasonable changes and fixes or, better yet(by far!), is willing to make those changes, they are denied the ability to do so because of reasons that person could not possibly be aware of. From julianjupiter.io at gmail.com Wed Feb 3 05:11:50 2021 From: julianjupiter.io at gmail.com (Julian Jupiter) Date: Wed, 3 Feb 2021 13:11:50 +0800 Subject: Make javafx.controls open and community-driven In-Reply-To: <177e1ac5-e1bf-cdb9-4750-a8dfe32b7c87@gmail.com> References: <104439aa95f088c969592458f2fbf648fa1da18a.camel@gmail.com> <177e1ac5-e1bf-cdb9-4750-a8dfe32b7c87@gmail.com> Message-ID: Desktop is already a smaller market compared before. And the competition has become toucher because of several toolkits out there - Electron, Flutter, Compose for Desktop, etc. Hence, the need for more open and community-driven JavaFX project. On Wed, Feb 3, 2021, 12:14 PM Ty Young, wrote: > On 2/2/21 8:16 PM, Nir Lisker wrote: > > > Hi Mike, > > > > First of all, I would have you consider revisiting your medical > observation > > on the state of JavaFX. If you've read the almost-weekly recurrent > threads > > of "should I use Swing or JavaFX" in r/Java, you'd realize that reports > of > > JavaFX's death are greatly exaggerated. But yes, it is very understaffed. > > Other than that, there is a discussion list, > > openjfx-discuss at openjdk.java.net, where you can bring up general > community > > and social media related topics and continue that branch of the > discussion > > there. > > > > 1. I also advocated for having JBS more open in the past. I was told that > > Oracle tried opening JBS for everyone, but it was a big mess. I > > remember Alan Bateman saying a few years ago in an Ask The Architect > > session, when he was asked about this, that more than half of the bugs > > submitted are about OpenGL in Minecraft. These are the things you don't > see > > from the outside. > > > I'm guessing some of those are the OpenGL segfault crash on exit that > affects (nearly?) *every* OpenGL based Java application for the last few > years, including JavaFX and Minecraft, on Nvidia hardware. I have to > clear out my build directory often because of it. > > > > As for the OCA, it is a license requirement for all of OpenJDK. The > > developers here have nothing to do with it. I suspect you will have to > take > > it up with the legal department of Oracle. Good luck :) > > > > OCA is more of a symptom of a larger problem IMO: gate keeping. > > > A long time ago I suggested a 1-liner change to JavaFX's build script > that would simply place the source zip generated with the JavaFX source > build *outside* the lib folder. Generating this zip inside the lib > folder caused runtime problems with Ant and Netbeans whenever you > designated the entire folder as a lib directory in a project and it > didn't make sense anyway. It was rejected, IIRC, because of Oracle's or > Gluon's server configuration issues with the change. There were no > issues doing a local build that I'm aware of when I tested the change > locally. > > > More recently, Oracle decided to break Swing applications that use the > GTK L&F on Arch Linux based distros in JDK 16, was notified of the issue > multiple times by multiple people, and AFAIK refused to revert the > changes simply because Arch Linux isn't a "supported" distro. AFAIK, > it's still not possible to even launch Netbeans on Arch Linux without > overriding the L&F. > > > Even more recently, I suggested (and was willing to actually do) what I > thought to be reasonable API changes to Project Panama, which I use in > my JavaFX application, were rejected because it was decided a year ago > behind closed doors discussions that the direction of that API part was > already decided. Not only that, but the ability to even have a public > discussion was basically shut down. > > > Someone has to be that person to make the decisions in the end, but > often times it feels like free outsourcing rather than contributing. One > moment it's "You should contribute!" and the next it's "No, I didn't > mean contribute *that* way!". > > > Anyway, this is a much larger issue that goes beyond JavaFX and I don't > want to derail, I'm just pointing out that not only when someone > suggests reasonable changes and fixes or, better yet(by far!), is > willing to make those changes, they are denied the ability to do so > because of reasons that person could not possibly be aware of. > > From aghaisas at openjdk.java.net Wed Feb 3 06:59:50 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 3 Feb 2021 06:59:50 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 20:21:59 GMT, Nir Lisker wrote: >> The usual doc fixes (for OpenJFX 16). >> >> Can wait until RDP2 to see if something else comes up. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From aghaisas at openjdk.java.net Wed Feb 3 10:11:43 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 3 Feb 2021 10:11:43 GMT Subject: RFR: 8260246: Ensemble: Update version of Lucene to 7.7.3 In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 13:13:13 GMT, Kevin Rushforth wrote: > This updates to the latest bug fix version of Lucene 7, which is version 7.7.3. Since it is only an update to the micro version, there is no need to regenerate the index. See [UPDATING-lucene.txt](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt). Marked as reviewed by aghaisas (Reviewer). I applied the patch and tested on macOS 10.15.7. ------------- PR: https://git.openjdk.java.net/jfx/pull/387 From nlisker at openjdk.java.net Wed Feb 3 11:49:44 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 3 Feb 2021 11:49:44 GMT Subject: [jfx16] Integrated: 8252389: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 15:07:34 GMT, Nir Lisker wrote: > The usual doc fixes (for OpenJFX 16). > > Can wait until RDP2 to see if something else comes up. This pull request has now been integrated. Changeset: 0f20a984 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/0f20a984 Stats: 30 lines in 5 files changed: 1 ins; 5 del; 24 mod 8252389: Fix mistakes in FX API docs Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From naastonn at gmail.com Wed Feb 3 12:24:20 2021 From: naastonn at gmail.com (naastonn at gmail.com) Date: Wed, 03 Feb 2021 16:24:20 +0400 Subject: Make javafx.controls open and community-driven In-Reply-To: References: <8d81d978-17f0-7f0c-e050-429bf3fa2241@jugs.org> Message-ID: <5fe013782ad3d261522142cd1ca895b94b5e86b2.camel@gmail.com> What do you think about decoupling javafx.controls from other modules private API? Is it possible? In current situation it may be the best solution, because this would allow to fork it. So, those who interested could play with fork(s) and backport changes when neccessary. It would also allow to develop other controls libs, those aren't based of javafx.controls, e.g. just for mobile. Best regards Mike On Tue, 2021-02-02 at 13:40 -0800, Kevin Rushforth wrote: > There are two separate issues here. I won't address the first point from > the initial poster, other than to say that I understand that the lack of > direct write access to JBS for occasional contributors is a pain point. > I don't think it is stopping anyone from contributing, though. As for > the other part of this point, JavaFX is already on GitHub along with the > rest of the JDK, and it's easy enough for someone who is motivated to > provide a pull request for a bug fix. > > The more interesting question is the one about extensibility that others > have also responded to. This raises the question of which areas are most > in need of new public API to facilitate this. "Just make every internal > detail of your implementation public or protected" isn't the right way > to frame the discussion. Anything that makes it into the public API is > something that needs to be documented, tested, and supported. It > requires us to consider what it means to support that API forever; we > take compatibility seriously. The main idea is to think in terms of > "stewardship" when evolving the JavaFX API. > > Keeping that in mind, there are certainly areas that could be made > easier to extend. Two things in the UI Controls area that were brought > up are skins, which are public API with not all of the fields and > methods of the skins are public/protected, and behaviors. The former > isn't too difficult to address. It requires some amount of thought, > discussion, API documentation, implementation, and testing, but doesn't > need a whole new design. VirtualFlow has been extended in this fashion > to provide missing pieces for third-party controls. If there are others, > developers can propose them and we can discuss them. This is definitely > an area we would welcome well-thought-out contributions in. > > The harder area is that of behaviors. For a little background, a public > behaviors API was originally part of the proposed new public API for FX > in JDK 9, which was done via JEP 253 [1]. It was decoupled from that > JEP, but still remains an open enhancement request tracked by > JDK-8091189 [2]. That JBS issue has a very long discussion thread about > possible approaches for the API. This would be a very large effort, and > would require someone with a very good understanding of both UI control > design in general and the design and implementation of JavaFX UI > Controls in particular to lead the effort. It isn't something that we > would accept from an application developer who is just wanting to make > their life easier. Again, think of it in terms of API stewardship. I'm > not saying there is no way this could be done, just that it's unlikely. > > I'm sure there are other areas outside of UI controls that could be made > more extensible, too (although knowing how fragile CSS is, I wouldn't > have much enthusiasm for that). What we would need is a concrete > proposal that we could discuss. > > -- Kevin > > [1] https://openjdk.java.net/jeps/253 > [2] https://bugs.openjdk.java.net/browse/JDK-8091189 > > On 2/2/2021 6:30 AM, Michael Paus wrote: > > 1+ > > > > Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira: > > > Hi, > > > > > > Although I don't agree with everything said here at the start of this > > > thread, I agree with the base idea that JavaFX would benefit from being > > > more open than it is currently. It's something I've already said here in > > > this mailing list and since it's been a while and that discussion > > > probably > > > already got forgotten I'll add the comments to this thread again. > > > > > > Not even just the controls case but more hooks to extend JavaFX just > > > generally by adding API that allows for that and making things less > > > private/final/etc. It would be great to be able to extend more parts of > > > JavaFX in a library independent way (i.e. by creating your own > > > library that > > > extends some parts of JavaFX in more fundamental cool way). > > > Besides what was already said about controls, here's another example: > > > wouldn't it be great for the community to be able to create a library > > > that > > > could extend the CSS parser by adding animations, layout support, > > > etc, etc. > > > One could argue, why don't you just contribute a PR to the JavaFX > > > code base > > > that does just that (adds animation support to CSS, or something less > > > trivial like that)? I'd say that that process is too lengthy and > > > often out > > > of possibility for an individual developer that wants to improve > > > JavaFX but > > > doesn't have time to do it that way. > > > > > > I see the advantage of exposing less of the internals and why the JavaFX > > > team decided to do it. Many of the same guys that developed JavaFX were > > > part of the Swing team which were bothered by the inverse situation, > > > i.e. > > > being too open (which also can have its disadvantages). > > > Weighing in the pros and cons, I still think there's a bigger > > > advantage in > > > being more open than closed. This hinders the capacity for the > > > community to > > > create libraries that extend JavaFX in new and fundamental ways without > > > having to fork JavaFX. > > > And this is more of a reality now that the JavaFX team is smaller > > > (than the > > > original team) and hence has less capacity to keep improving and adding > > > features to JavaFX which means it has to rely more on the community. > > > > > > I also agree with the process of submitting a bug and following upon it, > > > commenting, etc. Ideally it should be easier. That's something that has > > > also been brought up before. > > > > > > Anyways, this mail is not meant to put down the guys working on > > > JavaFX, there are no perfect toolkits, each one has its downfalls. > > > Think it > > > more like throwing in ideas and sharing my experience of using JavaFX > > > for > > > creating libraries and applications. > > > > > > From r.lichtenberger at gmail.com Wed Feb 3 13:29:19 2021 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Wed, 3 Feb 2021 14:29:19 +0100 Subject: Make javafx.controls open and community-driven In-Reply-To: <5fe013782ad3d261522142cd1ca895b94b5e86b2.camel@gmail.com> References: <8d81d978-17f0-7f0c-e050-429bf3fa2241@jugs.org> <5fe013782ad3d261522142cd1ca895b94b5e86b2.camel@gmail.com> Message-ID: I think I can comment from the perspective of a successful user of JavaFX (we have been running an administration application for our medical software for over 5 years now) as well as a part-time contributor to the JavaFX project (with the help of Kevin Rushforth and Ajit Ghaisas my pull request https://github.com/openjdk/jfx/pull/383 was integrated into JavaFX a few days ago): * Yes, the closed bug tracker of OpenJFX is a bit of a nuisance but no, it is not the biggest obstacle when trying to contribute. * Contributing is hard because JavaFX is quite complex and there is a very stringent process in place. As a contributor this can sometimes be tiresome. As an example, when Kevin Rushforth asked for a better API comment in the aforementioned pull request, it felt like exxagerated attention to details. However, when trying to write that better API comment I discovered another bug in my pull request which would have broken things. So it might be a difficult process but it pays off in terms of quality. So as a user of JavaFX I absolutely want the quality and stability it provides. As a contributor I would sometimes like to have my pull request integrated more easily. Since I can't have both, I'd rather have reviewers nitpick at my next pull request (and thus ensuring quality) for a dozen times than having my application break down from regressions after I update to the next JavaFX version. * As a long-time user of JavaFX I would not like for javafx.controls to be split off and modified in a way that is less stringent than now. Because one users fix is the regression of another :-). * I think contributing to JavaFX is about as difficult as contributing to other projects of the same scale. You can't contribute to Qt easily and certainly not to the Linux kernel. Am Mi., 3. Feb. 2021 um 13:24 Uhr schrieb : > What do you think about decoupling javafx.controls from other modules > private API? Is it possible? In current situation > it may be the best solution, because this would allow to fork it. So, > those who interested could play with fork(s) and > backport changes when neccessary. It would also allow to develop other > controls libs, those aren't based of > javafx.controls, e.g. just for mobile. > > Best regards > Mike > > On Tue, 2021-02-02 at 13:40 -0800, Kevin Rushforth wrote: > > There are two separate issues here. I won't address the first point from > > the initial poster, other than to say that I understand that the lack of > > direct write access to JBS for occasional contributors is a pain point. > > I don't think it is stopping anyone from contributing, though. As for > > the other part of this point, JavaFX is already on GitHub along with the > > rest of the JDK, and it's easy enough for someone who is motivated to > > provide a pull request for a bug fix. > > > > The more interesting question is the one about extensibility that others > > have also responded to. This raises the question of which areas are most > > in need of new public API to facilitate this. "Just make every internal > > detail of your implementation public or protected" isn't the right way > > to frame the discussion. Anything that makes it into the public API is > > something that needs to be documented, tested, and supported. It > > requires us to consider what it means to support that API forever; we > > take compatibility seriously. The main idea is to think in terms of > > "stewardship" when evolving the JavaFX API. > > > > Keeping that in mind, there are certainly areas that could be made > > easier to extend. Two things in the UI Controls area that were brought > > up are skins, which are public API with not all of the fields and > > methods of the skins are public/protected, and behaviors. The former > > isn't too difficult to address. It requires some amount of thought, > > discussion, API documentation, implementation, and testing, but doesn't > > need a whole new design. VirtualFlow has been extended in this fashion > > to provide missing pieces for third-party controls. If there are others, > > developers can propose them and we can discuss them. This is definitely > > an area we would welcome well-thought-out contributions in. > > > > The harder area is that of behaviors. For a little background, a public > > behaviors API was originally part of the proposed new public API for FX > > in JDK 9, which was done via JEP 253 [1]. It was decoupled from that > > JEP, but still remains an open enhancement request tracked by > > JDK-8091189 [2]. That JBS issue has a very long discussion thread about > > possible approaches for the API. This would be a very large effort, and > > would require someone with a very good understanding of both UI control > > design in general and the design and implementation of JavaFX UI > > Controls in particular to lead the effort. It isn't something that we > > would accept from an application developer who is just wanting to make > > their life easier. Again, think of it in terms of API stewardship. I'm > > not saying there is no way this could be done, just that it's unlikely. > > > > I'm sure there are other areas outside of UI controls that could be made > > more extensible, too (although knowing how fragile CSS is, I wouldn't > > have much enthusiasm for that). What we would need is a concrete > > proposal that we could discuss. > > > > -- Kevin > > > > [1] https://openjdk.java.net/jeps/253 > > [2] https://bugs.openjdk.java.net/browse/JDK-8091189 > > > > On 2/2/2021 6:30 AM, Michael Paus wrote: > > > 1+ > > > > > > Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira: > > > > Hi, > > > > > > > > Although I don't agree with everything said here at the start of this > > > > thread, I agree with the base idea that JavaFX would benefit from > being > > > > more open than it is currently. It's something I've already said > here in > > > > this mailing list and since it's been a while and that discussion > > > > probably > > > > already got forgotten I'll add the comments to this thread again. > > > > > > > > Not even just the controls case but more hooks to extend JavaFX just > > > > generally by adding API that allows for that and making things less > > > > private/final/etc. It would be great to be able to extend more parts > of > > > > JavaFX in a library independent way (i.e. by creating your own > > > > library that > > > > extends some parts of JavaFX in more fundamental cool way). > > > > Besides what was already said about controls, here's another example: > > > > wouldn't it be great for the community to be able to create a > library > > > > that > > > > could extend the CSS parser by adding animations, layout support, > > > > etc, etc. > > > > One could argue, why don't you just contribute a PR to the JavaFX > > > > code base > > > > that does just that (adds animation support to CSS, or something less > > > > trivial like that)? I'd say that that process is too lengthy and > > > > often out > > > > of possibility for an individual developer that wants to improve > > > > JavaFX but > > > > doesn't have time to do it that way. > > > > > > > > I see the advantage of exposing less of the internals and why the > JavaFX > > > > team decided to do it. Many of the same guys that developed JavaFX > were > > > > part of the Swing team which were bothered by the inverse situation, > > > > i.e. > > > > being too open (which also can have its disadvantages). > > > > Weighing in the pros and cons, I still think there's a bigger > > > > advantage in > > > > being more open than closed. This hinders the capacity for the > > > > community to > > > > create libraries that extend JavaFX in new and fundamental ways > without > > > > having to fork JavaFX. > > > > And this is more of a reality now that the JavaFX team is smaller > > > > (than the > > > > original team) and hence has less capacity to keep improving and > adding > > > > features to JavaFX which means it has to rely more on the community. > > > > > > > > I also agree with the process of submitting a bug and following upon > it, > > > > commenting, etc. Ideally it should be easier. That's something that > has > > > > also been brought up before. > > > > > > > > Anyways, this mail is not meant to put down the guys working on > > > > JavaFX, there are no perfect toolkits, each one has its downfalls. > > > > Think it > > > > more like throwing in ideas and sharing my experience of using > JavaFX > > > > for > > > > creating libraries and applications. > > > > > > > > > > From ebresie at gmail.com Wed Feb 3 13:31:04 2021 From: ebresie at gmail.com (Eric Bresie) Date: Wed, 3 Feb 2021 07:31:04 -0600 Subject: Make javafx.controls open and community-driven In-Reply-To: 5fe013782ad3d261522142cd1ca895b94b5e86b2.camel@gmail.com References: CAAEud6baHkTR-WvvCNKsMrBGrmcFqWPOs1J+dHQFS8tdm7u8Rw@mail.gmail.com 8d81d978-17f0-7f0c-e050-429bf3fa2241@jugs.org f3838ac7-bd3e-7f4b-4fa1-79187c4e8b5f@oracle.com f3838ac7-bd3e-7f4b-4fa1-79187c4e8b5f@oracle.com Message-ID: I assume since JFX stated with and was closely coupled with Java prior to being removed from the JDK/JRE, this allow for the link up with the java bug link. The case could be made it could be similar to the other library?s. I believe some other existing libraries (JAXB?) were removed [maybe more for modularity and smaller profiles but] in favor of the having dependency when needed but allowing development separately as independent projects but the specific I?m a little fuzzy on). Since JFX was Sun/Oracle IP, I assume this also accounts for some of the restrictions. As I understand in the grand open bizaar scheme that if there are areas that are closed, re-implement and replace it with open where applicable. Now with all those comments out of the way... Regarding the decoupling java fix.controls...With modularity in mind, would it be worth having a service layer / package / module interface added in some way and then make existing controls implementations of the service then further improvements could implement and/or extend as preferred as implementations of this? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On February 3, 2021 at 6:24:20 AM CST, naastonn at gmail.com (mailto:naastonn at gmail.com) wrote: > What do you think about decoupling javafx.controls from other modules private API? Is it possible? In current situation > it may be the best solution, because this would allow to fork it. So, those who interested could play with fork(s) and > backport changes when neccessary. It would also allow to develop other controls libs, those aren't based of > javafx.controls, e.g. just for mobile. > > Best regards > Mike > > On Tue, 2021-02-02 at 13:40 -0800, Kevin Rushforth wrote: > > There are two separate issues here. I won't address the first point from > > the initial poster, other than to say that I understand that the lack of > > direct write access to JBS for occasional contributors is a pain point. > > I don't think it is stopping anyone from contributing, though. As for > > the other part of this point, JavaFX is already on GitHub along with the > > rest of the JDK, and it's easy enough for someone who is motivated to > > provide a pull request for a bug fix. > > > > The more interesting question is the one about extensibility that others > > have also responded to. This raises the question of which areas are most > > in need of new public API to facilitate this. "Just make every internal > > detail of your implementation public or protected" isn't the right way > > to frame the discussion. Anything that makes it into the public API is > > something that needs to be documented, tested, and supported. It > > requires us to consider what it means to support that API forever; we > > take compatibility seriously. The main idea is to think in terms of > > "stewardship" when evolving the JavaFX API. > > > > Keeping that in mind, there are certainly areas that could be made > > easier to extend. Two things in the UI Controls area that were brought > > up are skins, which are public API with not all of the fields and > > methods of the skins are public/protected, and behaviors. The former > > isn't too difficult to address. It requires some amount of thought, > > discussion, API documentation, implementation, and testing, but doesn't > > need a whole new design. VirtualFlow has been extended in this fashion > > to provide missing pieces for third-party controls. If there are others, > > developers can propose them and we can discuss them. This is definitely > > an area we would welcome well-thought-out contributions in. > > > > The harder area is that of behaviors. For a little background, a public > > behaviors API was originally part of the proposed new public API for FX > > in JDK 9, which was done via JEP 253 [1]. It was decoupled from that > > JEP, but still remains an open enhancement request tracked by > > JDK-8091189 [2]. That JBS issue has a very long discussion thread about > > possible approaches for the API. This would be a very large effort, and > > would require someone with a very good understanding of both UI control > > design in general and the design and implementation of JavaFX UI > > Controls in particular to lead the effort. It isn't something that we > > would accept from an application developer who is just wanting to make > > their life easier. Again, think of it in terms of API stewardship. I'm > > not saying there is no way this could be done, just that it's unlikely. > > > > I'm sure there are other areas outside of UI controls that could be made > > more extensible, too (although knowing how fragile CSS is, I wouldn't > > have much enthusiasm for that). What we would need is a concrete > > proposal that we could discuss. > > > > -- Kevin > > > > [1] https://openjdk.java.net/jeps/253 > > [2] https://bugs.openjdk.java.net/browse/JDK-8091189 > > > > On 2/2/2021 6:30 AM, Michael Paus wrote: > > > 1+ > > > > > > Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira: > > > > Hi, > > > > > > > > Although I don't agree with everything said here at the start of this > > > > thread, I agree with the base idea that JavaFX would benefit from being > > > > more open than it is currently. It's something I've already said here in > > > > this mailing list and since it's been a while and that discussion > > > > probably > > > > already got forgotten I'll add the comments to this thread again. > > > > > > > > Not even just the controls case but more hooks to extend JavaFX just > > > > generally by adding API that allows for that and making things less > > > > private/final/etc. It would be great to be able to extend more parts of > > > > JavaFX in a library independent way (i.e. by creating your own > > > > library that > > > > extends some parts of JavaFX in more fundamental cool way). > > > > Besides what was already said about controls, here's another example: > > > > wouldn't it be great for the community to be able to create a library > > > > that > > > > could extend the CSS parser by adding animations, layout support, > > > > etc, etc. > > > > One could argue, why don't you just contribute a PR to the JavaFX > > > > code base > > > > that does just that (adds animation support to CSS, or something less > > > > trivial like that)? I'd say that that process is too lengthy and > > > > often out > > > > of possibility for an individual developer that wants to improve > > > > JavaFX but > > > > doesn't have time to do it that way. > > > > > > > > I see the advantage of exposing less of the internals and why the JavaFX > > > > team decided to do it. Many of the same guys that developed JavaFX were > > > > part of the Swing team which were bothered by the inverse situation, > > > > i.e. > > > > being too open (which also can have its disadvantages). > > > > Weighing in the pros and cons, I still think there's a bigger > > > > advantage in > > > > being more open than closed. This hinders the capacity for the > > > > community to > > > > create libraries that extend JavaFX in new and fundamental ways without > > > > having to fork JavaFX. > > > > And this is more of a reality now that the JavaFX team is smaller > > > > (than the > > > > original team) and hence has less capacity to keep improving and adding > > > > features to JavaFX which means it has to rely more on the community. > > > > > > > > I also agree with the process of submitting a bug and following upon it, > > > > commenting, etc. Ideally it should be easier. That's something that has > > > > also been brought up before. > > > > > > > > Anyways, this mail is not meant to put down the guys working on > > > > JavaFX, there are no perfect toolkits, each one has its downfalls. > > > > Think it > > > > more like throwing in ideas and sharing my experience of using JavaFX > > > > for > > > > creating libraries and applications. > > > > > > > > > From kcr at openjdk.java.net Wed Feb 3 13:39:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Feb 2021 13:39:45 GMT Subject: Integrated: 8260246: Ensemble: Update version of Lucene to 7.7.3 In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 13:13:13 GMT, Kevin Rushforth wrote: > This updates to the latest bug fix version of Lucene 7, which is version 7.7.3. Since it is only an update to the micro version, there is no need to regenerate the index. See [UPDATING-lucene.txt](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt). This pull request has now been integrated. Changeset: 215384d7 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/215384d7 Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod 8260246: Ensemble: Update version of Lucene to 7.7.3 Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/387 From fastegal at openjdk.java.net Wed Feb 3 17:10:44 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 3 Feb 2021 17:10:44 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6] In-Reply-To: <7ivK8A9fCK-8XRFBlGkBkoWRP5xuwDDy_P8tNSKHxYE=.c81f3909-bc9c-4d85-a837-8ade6afc27d9@github.com> References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> <7ivK8A9fCK-8XRFBlGkBkoWRP5xuwDDy_P8tNSKHxYE=.c81f3909-bc9c-4d85-a837-8ade6afc27d9@github.com> Message-ID: On Tue, 2 Feb 2021 12:02:17 GMT, Jeanette Winzenburg wrote: > > > wondering about the system test - what stands in the way to add a simple "normal" unit test? looks like there might be a bug in StubFontLoader that makes a normal unit test fail w/out the fix: Axis uses a Text field (measure) for measuring size requirements for the tick labels - its font has no nativeFont set in the stub context such that all fields of the bounds of text are always 0, consequently the change in autoRange never kicks in. Hacking around with explicitly setting a tickLabelFont gives us a test that fails before and passes after the fix: @Test public void testRotatedStandAlone() { Pane root = new Pane(); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); CategoryAxis xAxis = new CategoryAxis(FXCollections.observableArrayList(categories)); // hack around stubFontLoader bug (?feature) xAxis.setTickLabelFont(new Font(8)); BarChart chart = new BarChart<>(xAxis, new NumberAxis()); chart.setPrefWidth(400); root.getChildren().add(chart); stage.show(); assertEquals(90, xAxis.getTickLabelRotation(), 0.1); } Question is why the stubFontLoader fails: its load implementation looks like it should always set the nativeFont fiel to a fitting test font, but it doesn't if the name is a plain "Amble" (vs. a more specialized like "Amble Regular"). ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From ajoseph at openjdk.java.net Wed Feb 3 18:00:00 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 3 Feb 2021 18:00:00 GMT Subject: RFR: 8254836: Cherry pick GTK WebKit 2.30.3 changes Message-ID: Update to GTK WebKit 2.30.3 https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html ------------- Commit messages: - 8254836: Cherry pick GTK WebKit 2.30.3 changes Changes: https://git.openjdk.java.net/jfx/pull/392/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=392&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254836 Stats: 679 lines in 37 files changed: 483 ins; 87 del; 109 mod Patch: https://git.openjdk.java.net/jfx/pull/392.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/392/head:pull/392 PR: https://git.openjdk.java.net/jfx/pull/392 From kcr at openjdk.java.net Wed Feb 3 18:00:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Feb 2021 18:00:01 GMT Subject: RFR: 8254836: Cherry pick GTK WebKit 2.30.3 changes In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 17:52:31 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.30.3 > https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html @johanvos @tiainen can you test this in your environment? ------------- PR: https://git.openjdk.java.net/jfx/pull/392 From kcr at openjdk.java.net Wed Feb 3 20:29:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Feb 2021 20:29:44 GMT Subject: RFR: 8254836: Cherry pick GTK WebKit 2.30.3 changes In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 17:52:31 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.30.3 > https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/392 From kcr at openjdk.java.net Wed Feb 3 21:08:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Feb 2021 21:08:45 GMT Subject: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter [v2] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 02:49:53 GMT, Nir Lisker wrote: >> Deprecating protected members in DateTimeStringConverter. Internal implementation should not be exposed (similar to `NumberStringConverter` and others). > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added javadoc deprecation tags Looks good. Go ahead and file a CSR. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/390 From nlisker at openjdk.java.net Wed Feb 3 21:35:43 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 3 Feb 2021 21:35:43 GMT Subject: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter [v2] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 21:06:07 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Added javadoc deprecation tags > > Looks good. Go ahead and file a CSR. CSR filed. ------------- PR: https://git.openjdk.java.net/jfx/pull/390 From kcr at openjdk.java.net Wed Feb 3 21:58:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Feb 2021 21:58:44 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 00:31:20 GMT, Nir Lisker wrote: >> The updated API looks fine, with a few wording suggestions. I haven't looked at the updated shaders yet. >> >> I have a few general comments and I left a few inline. >> >> 1. It's too late for JavaFX 16, so you will need to update the `@since` tags to 17 and the fixVersion of both the Enhancement request and the CSR in JBS to openjfx17. >> >> 2. I see you renamed the `setPointLight` method in the Prism pipelines to `setLight` and got rid of the separate `setSpotLight` method. Have you considered whether this will still make sense when adding a DirectionalLight? Maybe leaving the name as `setPointLight` is best? >> >> 3. I get the following error when trying to run any 3D program on Mac, such as the "3D Box" sample in Ensemble8: >> >> Shader compile log: ERROR: 0:314: '==' does not operate on 'float' and 'int' >> ERROR: 0:314: '==' does not operate on 'float' and 'int' >> ERROR: 0:315: Expression in 'return' statement must match return type of function (and no available implicit conversion) >> ERROR: 0:319: '!=' does not operate on 'float' and 'int' >> ERROR: 0:320: No matching function for call to clamp(float, int, int) >> ERROR: 0:322: '>=' does not operate on 'float' and 'int' >> ERROR: 0:326: '!=' does not operate on 'float' and 'int' >> ERROR: 0:329: No matching function for call to clamp(float, int, int) >> ERROR: 0:331: '==' does not operate on 'float' and 'int' >> ERROR: 0:332: Expression in 'return' statement must match return type of function (and no available implicit conversion) >> ERROR: 0:336: '>=' does not operate on 'float' and 'int' >> ERROR: 0:342: '!=' does not operate on 'float' and 'int' >> ERROR: 0:343: No matching function for call to clamp(float, int, int) >> ERROR: 0:345: '>=' does not operate on 'float' and 'int' >> >> java.lang.RuntimeException: Error creating fragment shader >> at javafx.graphics/com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:141) >> at javafx.graphics/com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:177) >> at javafx.graphics/com.sun.prism.es2.ES2Context.getPhongShader(ES2Context.java:142) >> at javafx.graphics/com.sun.prism.es2.ES2Context.renderMeshView(ES2Context.java:474) >> at javafx.graphics/com.sun.prism.es2.ES2MeshView.render(ES2MeshView.java:123) >> at javafx.graphics/com.sun.javafx.sg.prism.NGShape3D.renderMeshView(NGShape3D.java:204) >> ... >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >> at java.base/java.lang.Thread.run(Thread.java:832) > >> I see you renamed the setPointLight method in the Prism pipelines to setLight and got rid of the separate setSpotLight method. Have you considered whether this will still make sense when adding a DirectionalLight? Maybe leaving the name as setPointLight is best? > > Directional light will be simulated as a point light at an infinite distance, making the illumination appear like it's coming from one direction, so I made this renaming deliberately. A few comments: I still get a runtime shader compilation error on Mac (see above) > I forgot to mention that I edited the topmost comment to include another API discussion point about using the rotation of the node as the direction of the light. We might also need to be careful about a (0, 0, 0) direction since it's not normalizable. Unless the transform itself is non-invertible, I don't think this can happen. What I would expect is that if we go this route -- which seems like a fine API choice to me -- the direction vector would be `(0, 0, 1)` in the local coordinate system of the light, which would then be suitably rotated based on the transform of the light (and any transforms above it). > Directional light will be simulated as a point light at an infinite distance, making the illumination appear like it's coming from one direction, so I made this renaming deliberately. Hmm. I wonder if the ideal choice? One of the reasons for wanting a DirectionalLight, as distinct from a very far away PointLight with no attenuation, is performance. On the other hand, since it will complicates the design of the shaders to have a special case for directional lights, it might not be worth implementing. I don't think it matters all that much, so if you want to rename it to setLight that seems OK. It's an implementation detail and could be revisited in the future. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From jvos at openjdk.java.net Thu Feb 4 08:15:43 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 4 Feb 2021 08:15:43 GMT Subject: RFR: 8254836: Cherry pick GTK WebKit 2.30.3 changes In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:27:23 GMT, Kevin Rushforth wrote: >> Update to GTK WebKit 2.30.3 >> https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html > > Looks good. We're creating test-builds in our CI for this now. ------------- PR: https://git.openjdk.java.net/jfx/pull/392 From jvos at openjdk.java.net Thu Feb 4 11:58:45 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 4 Feb 2021 11:58:45 GMT Subject: RFR: 8254836: Cherry pick GTK WebKit 2.30.3 changes In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 17:52:31 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.30.3 > https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html sanity checks pass ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/392 From aghaisas at openjdk.java.net Thu Feb 4 12:16:42 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 4 Feb 2021 12:16:42 GMT Subject: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter [v2] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 02:49:53 GMT, Nir Lisker wrote: >> Deprecating protected members in DateTimeStringConverter. Internal implementation should not be exposed (similar to `NumberStringConverter` and others). > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added javadoc deprecation tags Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/390 From ajoseph at openjdk.java.net Thu Feb 4 12:48:44 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 4 Feb 2021 12:48:44 GMT Subject: Integrated: 8254836: Cherry pick GTK WebKit 2.30.3 changes In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 17:52:31 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.30.3 > https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html This pull request has now been integrated. Changeset: 425c3353 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/425c3353 Stats: 679 lines in 37 files changed: 483 ins; 87 del; 109 mod 8254836: Cherry pick GTK WebKit 2.30.3 changes Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/392 From nlisker at openjdk.java.net Thu Feb 4 20:10:00 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 4 Feb 2021 20:10:00 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter Message-ID: Fixes a mutability issue for `LocalDateTimeStringConverter` (and `LocalDateStringConverter`) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made: * The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class. * The chronology field value does not change anymore when there is an exception due to inability to format the date. * Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand. Added a test that fails without this patch. The test creates a converter with an explicit `Chronology` and `null` parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/393/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=393&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260468 Stats: 39 lines in 2 files changed: 13 ins; 22 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/393.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/393/head:pull/393 PR: https://git.openjdk.java.net/jfx/pull/393 From nlisker at openjdk.java.net Thu Feb 4 20:10:00 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 4 Feb 2021 20:10:00 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 20:01:10 GMT, Nir Lisker wrote: > Fixes a mutability issue for `LocalDateTimeStringConverter` (and `LocalDateStringConverter`) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made: > > * The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class. > * The chronology field value does not change anymore when there is an exception due to inability to format the date. > * Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand. > > Added a test that fails without this patch. The test creates a converter with an explicit `Chronology` and `null` parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly. The added test will look meaningless after the patch, since it's trying to force a change that can't happen anymore, and this can be confusing in the future. Does it still make sense to commit it? It's more of a demonstration of the bug and the fix. I also noticed that other tests in `LocalDateTimeStringConverterTest` are not named with `test` in the beginning. Is this wrong? ------------- PR: https://git.openjdk.java.net/jfx/pull/393 From arapte at openjdk.java.net Fri Feb 5 08:12:44 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 5 Feb 2021 08:12:44 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v3] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Mon, 1 Feb 2021 04:41:20 GMT, John Hendrikx wrote: >> The updated fix using `registerChangeListener` and the test look good. I left a few mostly-minor comments. > > I think this change is complete now, including an integration test and tests on all new code. Please let me know if anything else needs to be done. This PR also seems to fix another issue [JDK-8259558](https://bugs.openjdk.java.net/browse/JDK-8259558). Test program is attached to the bug. Time readings, with this fix, time to remove 100000 nodes : ~20 ms time to add those removed 100000 nodes to a different parent: ~80 ms without this fix, time to remove 100000 nodes : ~1720 ms time to add those removed 100000 nodes to a different parent: ~100 ms ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jpereda at openjdk.java.net Fri Feb 5 10:42:53 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 5 Feb 2021 10:42:53 GMT Subject: RFR: 8249737: java.lang.RuntimeException: Too many touch points reported Message-ID: Using a digitizer tablet with a pen that works with Windows or MacOS, it works fine on MacOS, but throws a RTE on Windows 10. On MacOS there are only MouseEvents, while on Windows there are both MouseEvents and TouchEvents mixed together. Windows only uses [direct](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/win/ViewContainer.cpp#L1271) touch events natively, and that works for touch screens. But when touch pads are used generate mainly indirect touch events. There is already a way to find the source of the touch event (touch screen or touch pad/pen), via [isTouchEvent()](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/win/ViewContainer.cpp#L62), so this PR uses that method to set `isDirect` based on the source: true or direct for touch screen and false or indirect for touch pad/pen. Tested successfully using a touch screen and a touch pad with pen. ------------- Commit messages: - Set isDirect using isTouchEvent() that returns the source of the touch event (screen or pen) Changes: https://git.openjdk.java.net/jfx/pull/394/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=394&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249737 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/394.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/394/head:pull/394 PR: https://git.openjdk.java.net/jfx/pull/394 From arapte at openjdk.java.net Fri Feb 5 14:49:47 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 5 Feb 2021 14:49:47 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Mon, 1 Feb 2021 04:44:03 GMT, John Hendrikx wrote: >> This is a PoC for performance testing. >> >> It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. >> >> This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. > > John Hendrikx has updated the pull request incrementally with four additional commits since the last revision: > > - Add missing TreeShowingExpressionTest which also tests SubScene > - Also dispose listeners on Window/Showing in dispose > - Fix review comments > - Update copyrights Added couple minor comments and a suggestion. Rest looks good to me, Observed no failures. It would be a great performance improvement for large scene applications. modules/javafx.graphics/src/test/java/test/javafx/scene/TreeShowingExpressionTest.java line 318: > 316: assertNull(state.getAndSet(null)); > 317: } > 318: } Please add a new line here at end of file. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/TreeShowingExpression.java line 2: > 1: /* > 2: * Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved. It should be changed to -> `Copyright (c) 2021, Oracle ` modules/javafx.graphics/src/main/java/com/sun/javafx/scene/TreeShowingExpression.java line 89: > 87: NodeHelper.treeVisibleProperty(node).addListener(windowShowingChangedListener); > 88: > 89: nodeSceneChangedListener.changed(null, null, node.getScene()); // registers listeners on Window/Showing We do not follow this pattern of calling the changed() or invalidated() methods. Instead we directly add the necessary calls at the time of initialisation and disposal. I think the pattern should be followed here too. For reference, the pattern is followed in all Skin classes. For example [here](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L148) in ButtonSkin, we do not make a call to `sceneChangeListener.changed()`, instead the necessary calls are directly made on [next lines](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L151) and then [opposite](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L179) calls in dispose(). For this line 89 needs to be replaced by following code, (with additional null checks) node.getScene().windowProperty().addListener(sceneWindowChangedListener); node.getScene().getWindow().showingProperty().addListener(windowShowingChangedListener); updateTreeShowing(); and similarly they should be removed in dispose(). ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/185 From perini.davide at dpsoftware.org Fri Feb 5 17:07:38 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 5 Feb 2021 18:07:38 +0100 Subject: JavaFX 15 with Java 14? Message-ID: Hi all, is it safe to use JavaFX 15 with Java 14? How JavaFX is related to Java version? Thanks Davide From mp at jugs.org Fri Feb 5 17:55:25 2021 From: mp at jugs.org (Michael Paus) Date: Fri, 5 Feb 2021 18:55:25 +0100 Subject: JavaFX 15 with Java 14? In-Reply-To: References: Message-ID: The JavaFX versions are not directly related to the Java versions. So you can use JavaFX 16-ea on Java 11+. It is however advisable to always use the latest version of JavaFX and an as late as possible Java version >= 11. Am 05.02.21 um 18:07 schrieb Davide Perini: > Hi all, > is it safe to use JavaFX 15 with Java 14? > > How JavaFX is related to Java version? > > Thanks > Davide From nlisker at openjdk.java.net Fri Feb 5 21:10:42 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 5 Feb 2021 21:10:42 GMT Subject: Integrated: 8260475: Deprecate for removal protected access members in DateTimeStringConverter In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 20:56:07 GMT, Nir Lisker wrote: > Deprecating protected members in DateTimeStringConverter. Internal implementation should not be exposed (similar to `NumberStringConverter` and others). This pull request has now been integrated. Changeset: d4058a18 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/d4058a18 Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod 8260475: Deprecate for removal protected access members in DateTimeStringConverter Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/390 From jhendrikx at openjdk.java.net Sat Feb 6 18:08:46 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 6 Feb 2021 18:08:46 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Fri, 5 Feb 2021 14:46:49 GMT, Ambarish Rapte wrote: >> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add missing TreeShowingExpressionTest which also tests SubScene >> - Also dispose listeners on Window/Showing in dispose >> - Fix review comments >> - Update copyrights > > Added couple minor comments and a suggestion. > Rest looks good to me, Observed no failures. It would be a great performance improvement for large scene applications. > This PR also seems to fix another issue [JDK-8259558](https://bugs.openjdk.java.net/browse/JDK-8259558). Test program is attached to the bug. > > Time readings, > with this fix, > time to remove 100000 nodes : ~20 ms > time to add those removed 100000 nodes to a different parent: ~80 ms > > without this fix, > time to remove 100000 nodes : ~1720 ms > time to add those removed 100000 nodes to a different parent: ~100 ms This is possible, as for each Node removed two listeners are also removed from the huge listener lists in Scene and Window (O(n) performance). Adding is not affected much as adding a listener to a huge list is not that costly. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Sat Feb 6 18:20:42 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 6 Feb 2021 18:20:42 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Fri, 5 Feb 2021 14:43:25 GMT, Ambarish Rapte wrote: >> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add missing TreeShowingExpressionTest which also tests SubScene >> - Also dispose listeners on Window/Showing in dispose >> - Fix review comments >> - Update copyrights > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/TreeShowingExpression.java line 89: > >> 87: NodeHelper.treeVisibleProperty(node).addListener(windowShowingChangedListener); >> 88: >> 89: nodeSceneChangedListener.changed(null, null, node.getScene()); // registers listeners on Window/Showing > > We do not follow this pattern of calling the changed() or invalidated() methods. Instead we directly add the necessary calls at the time of initialisation and disposal. I think the pattern should be followed here too. > For reference, the pattern is followed in all Skin classes. For example [here](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L148) in ButtonSkin, we do not make a call to `sceneChangeListener.changed()`, instead the necessary calls are directly made on [next lines](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L151) and then [opposite](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L179) calls in dispose(). > > For this line 89 needs to be replaced by following code, (with additional null checks) > node.getScene().windowProperty().addListener(sceneWindowChangedListener); > node.getScene().getWindow().showingProperty().addListener(windowShowingChangedListener); > updateTreeShowing(); > > and similarly they should be removed in dispose(). Isn't it quite error prone to repeat this logic again (especially with all the null cases), not to mention that you would need to test the code for the initial case (with/without Scene, with/without Window), the "in use" case and again for the disposal case? I personally use helpers for this kind of property chaining as it is far to easy to get wrong: public Binding isShowing(Node node) { Values.of(node.sceneProperty()) .flatMap(s -> Values.of(s.windowProperty())) .flatMap(w -> Values.of(w.showingProperty())) .orElse(false) .toBinding(); } The implementation here takes care of `null` and automatically tracks property changes and is type safe to boot. I think JavaFX in general could really benefit from this, as I've seen this chaining logic repeated a lot. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From thorsten.reimers at softquadrat.de Sun Feb 7 19:45:04 2021 From: thorsten.reimers at softquadrat.de (Thorsten Reimers) Date: Sun, 7 Feb 2021 20:45:04 +0100 Subject: System Menu Bar and Splash Screen under Mac OS X Message-ID: <55D54016-CF68-4F5E-A94A-5533310BB6E8@softquadrat.de> Hello, I have a problem with Open JFX under Mac OS X. When using System Menu Bar for a menu and starting Java with -splash option the menu is no longer displayed as System menu. My environment OS OS X El Capitan (10.11.6) Java openjdk version "15" 2020-09-15 OpenJDK Runtime Environment AdoptOpenJDK (build 15+36) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed mode, sharing) OpenJFX 15.0.1 I have created a Stackoverflow question with a more detailed description: https://stackoverflow.com/questions/65511188/javafx-problem-with-usesystemmenubar-when-starting-with-splash-option Does anybody has seen this behaviour? Is this a Java FX bug? Thanks in advance Thorsten From nlisker at openjdk.java.net Mon Feb 8 07:04:05 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 8 Feb 2021 07:04:05 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ### Performance > > Win 10 > Testing 3 point lights compared with the `master` branch shows a small drop in fps (5-10 in the mesh 200 test and ~5 in the mesh 5000 test). I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. The "optimizations" in `D3DMeshView.cc` didn't make a difference, which is not so surprising considering these are on the CPU. > The sphere with 1000 subdivisions always gives 120 fps. > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with three additional commits since the last revision: - Merge remote-tracking branch - Speculative fix for Mac - Fixed shader field name ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/db109b28..d1bc9af5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=07-08 Stats: 40 lines in 4 files changed: 0 ins; 0 del; 40 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From pbansal at openjdk.java.net Mon Feb 8 09:55:43 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 8 Feb 2021 09:55:43 GMT Subject: RFR: 8259046: ViewPainter.ROOT_PATHS holds reference to Scene causing memory leak In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 13:31:45 GMT, Kevin Rushforth wrote: > Prism implements a dirty region optimization, where in many cases, only part of the scene graph is re-rendered when something changes. In support of this, the `ViewPainter` class in the Quantum Toolkit keeps an array of node paths, `ROOT_PATHS`, which is a list of sub-trees in the scene graph that need to be rendered based on a change to that node. The entries in the `ROOT_PATHS` array are intended to be transient during the rendering of a single pass of a single scene. They are recreated every time a scene is rendered. The leak occurs because the entries are not cleared after being used. The fix is to clear each entry after it is rendered. In addition to static analysis, which shows that the entries are never used again after a frame is rendered, I have done a full build and test, including manual tests, to be sure that there is no regression. > > I have added a test that will fail consistently on Mac and Windows (and intermittently on Linux) without the fix. It passes consistently on all platforms with the fix. > > Even though this is a simple change, it is in an area that has historically been fragile, so I would like two reviewers. I did ran full test and did some run some manual tests also. The changes look fine to me. ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/388 From arapte at openjdk.java.net Mon Feb 8 11:41:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 8 Feb 2021 11:41:56 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time Message-ID: Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). Fix is very specific to this scenario and did not show any side effect nor any test failure. There are 12 new unit tests added along with fix: - Two tests fail before and pass after this fix. These test verify the reported failing scenario. sameRelativeFontSizeNestedParentTest relativeFontSizeDeepNestedParentControlTest - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. propertySizesRelativeToFontSizeOfControlTest propertySizesRelativeToFontSizeOfParentTest - Other 8 tests are sanity tests which pass both before and after this fix. ------------- Commit messages: - fix and test Changes: https://git.openjdk.java.net/jfx/pull/397/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8204568 Stats: 319 lines in 2 files changed: 317 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/397.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/397/head:pull/397 PR: https://git.openjdk.java.net/jfx/pull/397 From arapte at openjdk.java.net Mon Feb 8 13:45:45 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 8 Feb 2021 13:45:45 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Sat, 6 Feb 2021 18:17:40 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/TreeShowingExpression.java line 89: >> >>> 87: NodeHelper.treeVisibleProperty(node).addListener(windowShowingChangedListener); >>> 88: >>> 89: nodeSceneChangedListener.changed(null, null, node.getScene()); // registers listeners on Window/Showing >> >> We do not follow this pattern of calling the changed() or invalidated() methods. Instead we directly add the necessary calls at the time of initialisation and disposal. I think the pattern should be followed here too. >> For reference, the pattern is followed in all Skin classes. For example [here](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L148) in ButtonSkin, we do not make a call to `sceneChangeListener.changed()`, instead the necessary calls are directly made on [next lines](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L151) and then [opposite](https://github.com/openjdk/jfx/blob/887a443693a04d29ffaff8b8da353db839a987b4/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java#L179) calls in dispose(). >> >> For this line 89 needs to be replaced by following code, (with additional null checks) >> node.getScene().windowProperty().addListener(sceneWindowChangedListener); >> node.getScene().getWindow().showingProperty().addListener(windowShowingChangedListener); >> updateTreeShowing(); >> >> and similarly they should be removed in dispose(). > > Isn't it quite error prone to repeat this logic again (especially with all the null cases), not to mention that you would need to test the code for the initial case (with/without Scene, with/without Window), the "in use" case and again for the disposal case? > > I personally use helpers for this kind of property chaining as it is far to easy to get wrong: > > public Binding isShowing(Node node) { > Values.of(node.sceneProperty()) > .flatMap(s -> Values.of(s.windowProperty())) > .flatMap(w -> Values.of(w.showingProperty())) > .orElse(false) > .toBinding(); > } > > The implementation here takes care of `null` and automatically tracks property changes and is type safe to boot. I think JavaFX in general could really benefit from this, as I've seen this chaining logic repeated a lot. My concern is about having a similar way of doing something. It would keep the code uniform. We have been following the earlier pattern under a cleanup task [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). Several bugs under this task are being fixed in earlier way. May be we can discuss the new way of handling properties under a separate issue and plan to modify all such instances at once. Does that sound ok ? ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From dgrieve at openjdk.java.net Mon Feb 8 16:11:41 2021 From: dgrieve at openjdk.java.net (David Grieve) Date: Mon, 8 Feb 2021 16:11:41 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 11:37:35 GMT, Ambarish Rapte wrote: > Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. > > Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). > > Fix is very specific to this scenario and did not show any side effect nor any test failure. > > There are 12 new unit tests added along with fix: > - Two tests fail before and pass after this fix. These test verify the reported failing scenario. > sameRelativeFontSizeNestedParentTest > relativeFontSizeDeepNestedParentControlTest > - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. > propertySizesRelativeToFontSizeOfControlTest > propertySizesRelativeToFontSizeOfParentTest > - Other 8 tests are sanity tests which pass both before and after this fix. Marked as reviewed by dgrieve (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From arapte at openjdk.java.net Mon Feb 8 17:07:45 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 8 Feb 2021 17:07:45 GMT Subject: RFR: 8259046: ViewPainter.ROOT_PATHS holds reference to Scene causing memory leak In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 13:31:45 GMT, Kevin Rushforth wrote: > Prism implements a dirty region optimization, where in many cases, only part of the scene graph is re-rendered when something changes. In support of this, the `ViewPainter` class in the Quantum Toolkit keeps an array of node paths, `ROOT_PATHS`, which is a list of sub-trees in the scene graph that need to be rendered based on a change to that node. The entries in the `ROOT_PATHS` array are intended to be transient during the rendering of a single pass of a single scene. They are recreated every time a scene is rendered. The leak occurs because the entries are not cleared after being used. The fix is to clear each entry after it is rendered. In addition to static analysis, which shows that the entries are never used again after a frame is rendered, I have done a full build and test, including manual tests, to be sure that there is no regression. > > I have added a test that will fail consistently on Mac and Windows (and intermittently on Linux) without the fix. It passes consistently on all platforms with the fix. > > Even though this is a simple change, it is in an area that has historically been fragile, so I would like two reviewers. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/388 From nlisker at openjdk.java.net Mon Feb 8 19:30:46 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 8 Feb 2021 19:30:46 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 21:56:08 GMT, Kevin Rushforth wrote: > I still get a runtime shader compilation error on Mac (see above) I pushed a fix now. Since it doesn't happen on Win or Ubuntu I can't verify it, but I changed `0` to `0.0` etc. in the shader code. > Unless the transform itself is non-invertible, I don't think this can happen. What I would expect is that if we go this route -- which seems like a fine API choice to me -- the direction vector would be `(0, 0, 1)` in the local coordinate system of the light, which would then be suitably rotated based on the transform of the light (and any transforms above it). I think that this is also what I did when I tested this approach. When computing the direction in `NGSpotLight`, I multiplied the `Affine3D worldTransform` by a `Vec3D` of (0, 0, 1). Then, using rotations on the main axes, I was able to rotate the light in any direction I want. The problem here is ease of use. Because the order in which you add the rotation transforms matter, it becomes unintuitive for the user compared to using a direction. If I rotate 90 degrees in the X direction, the Y and Z axes are "flipped". If we can make it intuitive, then I think this approach is better. > Hmm. I wonder if the ideal choice? One of the reasons for wanting a DirectionalLight, as distinct from a very far away PointLight with no attenuation, is performance. On the other hand, since it will complicates the design of the shaders to have a special case for directional lights, it might not be worth implementing. I don't think it matters all that much, so if you want to rename it to setLight that seems OK. It's an implementation detail and could be revisited in the future. The branching vs unneeded computation costs is a main testing point in this patch. We will do the same tests for DirectionalLight in its own patch. A DirectionalLight can be implemented in the vertex shader, but it gives less accurate results I believe. I updated the Ubuntu tests results. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Feb 9 01:35:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 01:35:44 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 11:37:35 GMT, Ambarish Rapte wrote: > Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. > > Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). > > Fix is very specific to this scenario and did not show any side effect nor any test failure. > > There are 12 new unit tests added along with fix: > - Two tests fail before and pass after this fix. These test verify the reported failing scenario. > sameRelativeFontSizeNestedParentTest > relativeFontSizeDeepNestedParentControlTest > - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. > propertySizesRelativeToFontSizeOfControlTest > propertySizesRelativeToFontSizeOfParentTest > - Other 8 tests are sanity tests which pass both before and after this fix. This is taking me longer to review than I expected, because I ran into some anomalies while doing some additional testing. There is an unexpected change in behavior for nested panes with relative sizes. We need to understand this change before this is integrated. I added a modified version of the original test program to the JBS bug report that creates a scene graph like this, where the root and both parent nodes specify the font size in absolute pixels: Root // -fx-font-size: 96px P1 // -fx-font-size: 48px P2 // -fx-font-size: 36px L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em The above scene graph works as expected with the fix, whereas before the fix label L3 had incorrect padding. I then added a button to cycle through 4 modes replacing first P2, then P1, then the Root with what would be "equivalent" relative font sizes if the definition of an "em" is its parent's font size. Root // -fx-font-size: 96px P1 // -fx-font-size: 48px P2 // -fx-font-size: 0.75em L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em Root // -fx-font-size: 96px P1 // -fx-font-size: 0.5em P2 // -fx-font-size: 0.75em L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em Root // -fx-font-size: 8.0em P1 // -fx-font-size: 0.5em P2 // -fx-font-size: 0.75em L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em Things start getting unexpected when there is a parent with a relative font size, and the label had a relative font size (e.g., L3 when P2 is relative). When all nodes are relative (the last case), the padding size is completely wrong. Btw, I'm not currently worried about the calculation of the font size itself; this fix is intended to be a targeted fix that doesn't change the calculated font size (separately, we could look at that, but it would be much riskier and is out of scope for this bug fix). What I want to make sure is that in all cases, specifying the padding or other sizes in a node in ems will be relative to whatever the calculated font size is. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/397 From fastegal at openjdk.java.net Tue Feb 9 10:34:30 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 9 Feb 2021 10:34:30 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Mon, 8 Feb 2021 13:42:52 GMT, Ambarish Rapte wrote: >> Isn't it quite error prone to repeat this logic again (especially with all the null cases), not to mention that you would need to test the code for the initial case (with/without Scene, with/without Window), the "in use" case and again for the disposal case? >> >> I personally use helpers for this kind of property chaining as it is far to easy to get wrong: >> >> public Binding isShowing(Node node) { >> Values.of(node.sceneProperty()) >> .flatMap(s -> Values.of(s.windowProperty())) >> .flatMap(w -> Values.of(w.showingProperty())) >> .orElse(false) >> .toBinding(); >> } >> >> The implementation here takes care of `null` and automatically tracks property changes and is type safe to boot. I think JavaFX in general could really benefit from this, as I've seen this chaining logic repeated a lot. > > My concern is about having a similar way of doing something. It would keep the code uniform. We have been following the earlier pattern under a cleanup task [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). Several bugs under this task are being fixed in earlier way. > May be we can discuss the new way of handling properties under a separate issue and plan to modify all such instances at once. Does that sound ok ? hmm ... might appear convenient (in very controlled contexts) but looks like a precondition violation: the sender of the change must not be null (concededly not explicitly spec'ed but logically implied, IMO) so would tend to _not_ see this as blueprint for a general pattern fx code base ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Tue Feb 9 12:24:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 12:24:33 GMT Subject: Integrated: 8259046: ViewPainter.ROOT_PATHS holds reference to Scene causing memory leak In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 13:31:45 GMT, Kevin Rushforth wrote: > Prism implements a dirty region optimization, where in many cases, only part of the scene graph is re-rendered when something changes. In support of this, the `ViewPainter` class in the Quantum Toolkit keeps an array of node paths, `ROOT_PATHS`, which is a list of sub-trees in the scene graph that need to be rendered based on a change to that node. The entries in the `ROOT_PATHS` array are intended to be transient during the rendering of a single pass of a single scene. They are recreated every time a scene is rendered. The leak occurs because the entries are not cleared after being used. The fix is to clear each entry after it is rendered. In addition to static analysis, which shows that the entries are never used again after a frame is rendered, I have done a full build and test, including manual tests, to be sure that there is no regression. > > I have added a test that will fail consistently on Mac and Windows (and intermittently on Linux) without the fix. It passes consistently on all platforms with the fix. > > Even though this is a simple change, it is in an area that has historically been fragile, so I would like two reviewers. This pull request has now been integrated. Changeset: 676cf3e6 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/676cf3e6 Stats: 116 lines in 2 files changed: 116 ins; 0 del; 0 mod 8259046: ViewPainter.ROOT_PATHS holds reference to Scene causing memory leak Reviewed-by: pbansal, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/388 From arapte at openjdk.java.net Tue Feb 9 12:31:28 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 9 Feb 2021 12:31:28 GMT Subject: RFR: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice In-Reply-To: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> References: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> Message-ID: On Fri, 29 Jan 2021 00:05:57 GMT, Kevin Rushforth wrote: > As indicated in the JBS bug, using a `PixelReader` to read a scaled image in HiDPI mode, for example an `@2x` image, to read more than one pixel will read data from the wrong location in the image, usually leading to an IOOBE. > > The bug is in the `getPixelAccessor` method of Prism Image. The method correctly creates a new `Accessor` if one hasn't already been created, but then it unconditionally wraps the current `Accessor` in a `ScaledPixelAccessor` if the scale is > 1. So the second time this method is called, it created another `ScaledPixelAccessor` that wraps the first `ScaledPixelAccessor`, meaning that the indexes into the pixel array are multiplied by 4. This continues for each new call to this method. > > The fix is to only wrap an `Accessor` in a `ScaledPixelAccessor` the first time, when it is created. > > I added a test, which is run for both scaled and unscaled images, to ensure that we get the right value when reading a pixel, and that reading it a second time returns the same result. Without the fix, the new test will fail with IOOBE when the scale factor is two. Related to this, I initially commented out the wrapping in a `ScaledPixelAccessor` entirely, just to see what would happen, and none of the existing tests caught it. The new test will catch this. +1 Test and sanity check looks good. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/389 From kcr at openjdk.java.net Tue Feb 9 12:37:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 12:37:30 GMT Subject: Integrated: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice In-Reply-To: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> References: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> Message-ID: On Fri, 29 Jan 2021 00:05:57 GMT, Kevin Rushforth wrote: > As indicated in the JBS bug, using a `PixelReader` to read a scaled image in HiDPI mode, for example an `@2x` image, to read more than one pixel will read data from the wrong location in the image, usually leading to an IOOBE. > > The bug is in the `getPixelAccessor` method of Prism Image. The method correctly creates a new `Accessor` if one hasn't already been created, but then it unconditionally wraps the current `Accessor` in a `ScaledPixelAccessor` if the scale is > 1. So the second time this method is called, it created another `ScaledPixelAccessor` that wraps the first `ScaledPixelAccessor`, meaning that the indexes into the pixel array are multiplied by 4. This continues for each new call to this method. > > The fix is to only wrap an `Accessor` in a `ScaledPixelAccessor` the first time, when it is created. > > I added a test, which is run for both scaled and unscaled images, to ensure that we get the right value when reading a pixel, and that reading it a second time returns the same result. Without the fix, the new test will fail with IOOBE when the scale factor is two. Related to this, I initially commented out the wrapping in a `ScaledPixelAccessor` entirely, just to see what would happen, and none of the existing tests caught it. The new test will catch this. This pull request has now been integrated. Changeset: e85ce5a5 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e85ce5a5 Stats: 160 lines in 4 files changed: 157 ins; 0 del; 3 mod 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/389 From kcr at openjdk.java.net Tue Feb 9 13:06:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 13:06:27 GMT Subject: RFR: 8249737: java.lang.RuntimeException: Too many touch points reported In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 10:37:54 GMT, Jose Pereda wrote: > Using a digitizer tablet with a pen that works with Windows or MacOS, it works fine on MacOS, but throws a RTE on Windows 10. On MacOS there are only MouseEvents, while on Windows there are both MouseEvents and TouchEvents mixed together. > > Windows only uses [direct](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/win/ViewContainer.cpp#L1271) touch events natively, and that works for touch screens. > > But when touch pads are used generate mainly indirect touch events. > > There is already a way to find the source of the touch event (touch screen or touch pad/pen), via [isTouchEvent()](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/win/ViewContainer.cpp#L62), so this PR uses that method to set `isDirect` based on the source: true or direct for touch screen and false or indirect for touch pad/pen. > > Tested successfully using a touch screen and a touch pad with pen. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/394 From kcr at openjdk.java.net Tue Feb 9 13:43:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 13:43:40 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 20:04:39 GMT, Nir Lisker wrote: > The added test will look meaningless after the patch, since it's trying to force a change that can't happen anymore, and this can be confusing in the future. Does it still make sense to commit it? It's more of a demonstration of the bug and the fix. This seems fine to me. We've done this sort of thing for other tests as well. > I also noticed that other tests in `LocalDateTimeStringConverterTest` are not named with `test` in the beginning. Is this wrong? This is a loose naming convention that many classes follow, but many others do not, so it is not a problem. ------------- PR: https://git.openjdk.java.net/jfx/pull/393 From kcr at openjdk.java.net Tue Feb 9 13:50:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 13:50:42 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 20:01:10 GMT, Nir Lisker wrote: > Fixes a mutability issue for `LocalDateTimeStringConverter` (and `LocalDateStringConverter`) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made: > > * The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class. > * The chronology field value does not change anymore when there is an exception due to inability to format the date. > * Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand. > > Added a test that fails without this patch. The test creates a converter with an explicit `Chronology` and `null` parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly. The fix looks good to me, as does the test with a couple suggestions. modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 167: > 165: // force a chronology change with an invalid Japanese date > 166: try { > 167: System.out.println(converter.toString(LocalDateTime.of(1, 1, 1, 1, 1, 1))); Since you are expecting an exception, it seems a good idea to fail if you didn't get one. Something like: fail("Did not get the expected exception"); Also, you might consider narrowing the `catch` to just the exception that you expect, so that an unexpected exception will also fail the test. ------------- PR: https://git.openjdk.java.net/jfx/pull/393 From pbansal at openjdk.java.net Tue Feb 9 15:06:47 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 9 Feb 2021 15:06:47 GMT Subject: RFR: 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms Message-ID: JavaFX ignores the HiDPI scaling settings on Fedora 32 and Ubuntu 20.04. The scale detection in JavaFX assumes that the "scaling-factor" setting in "org.gnome.desktop.interface" has the correct Hi-DPI setting. But this not true for some systems and "scaling-factor" has value of 0. JavaFX should detect the windows level scale factor automatically in this case, but this logic is missing right now. So, the JavaFX applications are not scaled properly. This issue can be reproduced by setting the scale from Settings->Displays->Set Scale. Note, the option for scale may not be present from some resolution settings, so you may need to change it to see the option to scale the full windowing system. The issue can be verified by running some JavaFX applications/samples. The application will not be scaled properly according to the UIScale. https://bugs.openjdk.java.net/browse/JDK-8258464 is similar bug and has been closed as duplicate. This fix adds the logic to detect the scale from windows system itself. I have ran all automated unit tests and system tests, this fix is not causing any new failures. I have tested this on fedora 32 VM, Ubuntu 20.04 VM and Ubuntu 20.10 VM. ------------- Commit messages: - 8248126: JavaFX ignores HiDPI scaling settings on Fedora 32 (Gnome) Changes: https://git.openjdk.java.net/jfx/pull/396/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=396&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248126 Stats: 15 lines in 3 files changed: 5 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/396.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/396/head:pull/396 PR: https://git.openjdk.java.net/jfx/pull/396 From kcr at openjdk.java.net Tue Feb 9 15:11:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 15:11:40 GMT Subject: RFR: 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 11:33:13 GMT, Pankaj Bansal wrote: > JavaFX ignores the HiDPI scaling settings on Fedora 32 and Ubuntu 20.04. > > The scale detection in JavaFX assumes that the "scaling-factor" setting in "org.gnome.desktop.interface" has the correct Hi-DPI setting. But this not true for some systems and "scaling-factor" has value of 0. JavaFX should detect the windows level scale factor automatically in this case, but this logic is missing right now. So, the JavaFX applications are not scaled properly. > This issue can be reproduced by setting the scale from Settings->Displays->Set Scale. Note, the option for scale may not be present from some resolution settings, so you may need to change it to see the option to scale the full windowing system. The issue can be verified by running some JavaFX applications/samples. The application will not be scaled properly according to the UIScale. https://bugs.openjdk.java.net/browse/JDK-8258464 is similar bug and has been closed as duplicate. > > This fix adds the logic to detect the scale from windows system itself. > I have ran all automated unit tests and system tests, this fix is not causing any new failures. I have tested this on fedora 32 VM, Ubuntu 20.04 VM and Ubuntu 20.10 VM. This is a simple enough fix, but it would be helpful to have a second reviewer take a look, and test it. ------------- PR: https://git.openjdk.java.net/jfx/pull/396 From kcr at openjdk.java.net Tue Feb 9 16:46:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 16:46:39 GMT Subject: RFR: 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms In-Reply-To: References: Message-ID: <5PQ7_arVZK4h4toX3dh8zi1I6Bbf-bV7TBVZ0O1zY0g=.41ff0959-5b36-49be-a567-7853594736e6@github.com> On Sun, 7 Feb 2021 11:33:13 GMT, Pankaj Bansal wrote: > JavaFX ignores the HiDPI scaling settings on Fedora 32 and Ubuntu 20.04. > > The scale detection in JavaFX assumes that the "scaling-factor" setting in "org.gnome.desktop.interface" has the correct Hi-DPI setting. But this not true for some systems and "scaling-factor" has value of 0. JavaFX should detect the windows level scale factor automatically in this case, but this logic is missing right now. So, the JavaFX applications are not scaled properly. > This issue can be reproduced by setting the scale from Settings->Displays->Set Scale. Note, the option for scale may not be present from some resolution settings, so you may need to change it to see the option to scale the full windowing system. The issue can be verified by running some JavaFX applications/samples. The application will not be scaled properly according to the UIScale. https://bugs.openjdk.java.net/browse/JDK-8258464 is similar bug and has been closed as duplicate. > > This fix adds the logic to detect the scale from windows system itself. > I have ran all automated unit tests and system tests, this fix is not causing any new failures. I have tested this on fedora 32 VM, Ubuntu 20.04 VM and Ubuntu 20.10 VM. Looks good. I tested on Ubuntu 20.04 with both GTK3 and GTK2. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/396 From jpereda at openjdk.java.net Tue Feb 9 19:57:38 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Feb 2021 19:57:38 GMT Subject: Integrated: 8249737: java.lang.RuntimeException: Too many touch points reported In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 10:37:54 GMT, Jose Pereda wrote: > Using a digitizer tablet with a pen that works with Windows or MacOS, it works fine on MacOS, but throws a RTE on Windows 10. On MacOS there are only MouseEvents, while on Windows there are both MouseEvents and TouchEvents mixed together. > > Windows only uses [direct](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/win/ViewContainer.cpp#L1271) touch events natively, and that works for touch screens. > > But when touch pads are used generate mainly indirect touch events. > > There is already a way to find the source of the touch event (touch screen or touch pad/pen), via [isTouchEvent()](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/win/ViewContainer.cpp#L62), so this PR uses that method to set `isDirect` based on the source: true or direct for touch screen and false or indirect for touch pad/pen. > > Tested successfully using a touch screen and a touch pad with pen. This pull request has now been integrated. Changeset: 9c8d30ac Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/9c8d30ac Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8249737: java.lang.RuntimeException: Too many touch points reported Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/394 From jhendrikx at openjdk.java.net Tue Feb 9 20:45:37 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 9 Feb 2021 20:45:37 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <2VBfZdmvi5ILMkkM9FNTZfrPBn5oNLsBdMWphgfIWOY=.7c046868-bdd9-4dd3-85f4-f1286976ec73@github.com> On Tue, 9 Feb 2021 10:31:57 GMT, Jeanette Winzenburg wrote: >> My concern is about having a similar way of doing something. It would keep the code uniform. We have been following the earlier pattern under a cleanup task [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). Several bugs under this task are being fixed in earlier way. >> May be we can discuss the new way of handling properties under a separate issue and plan to modify all such instances at once. Does that sound ok ? > > hmm ... might appear convenient (in very controlled contexts) but looks like a precondition violation: the sender of the change must not be null (concededly not explicitly spec'ed but logically implied, IMO) > > so would tend to _not_ see this as blueprint for a general pattern fx code base So, what you are suggesting is to replace the above single line to this: Scene scene = node.getScene(); if (scene != null) { Window window = scene.getWindow(); scene.addListener(nodeSceneChangedListener); if (window != null) { window.showingProperty().addListener(windowShowingChangedListener); } } updateTreeShowing(); And something similarly wordy in dispose again -- and donot forget that I would then need to also duplicate the testing code to make sure all these branches are covered in both the constructor and in dispose again. Are you sure? I could extract the methods instead if you donot like me passing in `null` for the `ObservableValue`, it would then look like: sceneChanged(null, node.getScene()); // register chain sceneChanged(node.getScene(), null); // unregister chain No further changes in testing required as it is all covered and proven to work correctly. Also I should mention that this is not Skin code in case it was missed. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Tue Feb 9 20:56:00 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 9 Feb 2021 20:56:00 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v5] In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Apply changes from review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/185/files - new: https://git.openjdk.java.net/jfx/pull/185/files/2b6df779..02b4272e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=03-04 Stats: 71 lines in 3 files changed: 31 ins; 32 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/185/head:pull/185 PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Tue Feb 9 20:56:00 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 9 Feb 2021 20:56:00 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: <2VBfZdmvi5ILMkkM9FNTZfrPBn5oNLsBdMWphgfIWOY=.7c046868-bdd9-4dd3-85f4-f1286976ec73@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <2VBfZdmvi5ILMkkM9FNTZfrPBn5oNLsBdMWphgfIWOY=.7c046868-bdd9-4dd3-85f4-f1286976ec73@github.com> Message-ID: On Tue, 9 Feb 2021 20:43:08 GMT, John Hendrikx wrote: >> hmm ... might appear convenient (in very controlled contexts) but looks like a precondition violation: the sender of the change must not be null (concededly not explicitly spec'ed but logically implied, IMO) >> >> so would tend to _not_ see this as blueprint for a general pattern fx code base > > So, what you are suggesting is to replace the above single line to this: > > Scene scene = node.getScene(); > > if (scene != null) { > Window window = scene.getWindow(); > > scene.addListener(nodeSceneChangedListener); > > if (window != null) { > window.showingProperty().addListener(windowShowingChangedListener); > } > } > > updateTreeShowing(); > > And something similarly wordy in dispose again -- and donot forget that I would then need to also duplicate the testing code to make sure all these branches are covered in both the constructor and in dispose again. > > Are you sure? I could extract the methods instead if you donot like me passing in `null` for the `ObservableValue`, it would then look like: > > sceneChanged(null, node.getScene()); // register chain > > sceneChanged(node.getScene(), null); // unregister chain > > No further changes in testing required as it is all covered and proven to work correctly. > > Also I should mention that this is not Skin code in case it was missed. I could also split the register/unregister part into separate methods for Scene and Window (as you can see, I have a great aversion against duplicating code, mostly because it would then need to be tested multiple times as well). ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jpereda at openjdk.java.net Tue Feb 9 22:03:46 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Feb 2021 22:03:46 GMT Subject: RFR: 8252099: JavaFX does not render Myanmar script correctly Message-ID: This PR allows rendering Myanmar script correctly, following up on https://bugs.openjdk.java.net/browse/JDK-8223558. ------------- Commit messages: - Allow rendering Myanmar script correctly Changes: https://git.openjdk.java.net/jfx/pull/399/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=399&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252099 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/399.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/399/head:pull/399 PR: https://git.openjdk.java.net/jfx/pull/399 From kcr at openjdk.java.net Tue Feb 9 23:47:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 23:47:39 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Tue, 9 Feb 2021 10:31:57 GMT, Jeanette Winzenburg wrote: >> My concern is about having a similar way of doing something. It would keep the code uniform. We have been following the earlier pattern under a cleanup task [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). Several bugs under this task are being fixed in earlier way. >> May be we can discuss the new way of handling properties under a separate issue and plan to modify all such instances at once. Does that sound ok ? > > hmm ... might appear convenient (in very controlled contexts) but looks like a precondition violation: the sender of the change must not be null (concededly not explicitly spec'ed but logically implied, IMO) > > so would tend to _not_ see this as blueprint for a general pattern fx code base I took a quick look at your latest change, and it seems reasonable to me now that you are calling a helper method rather than triggering a change method on the listener. I'll take a closer look later in the week. In the mean time @kleopatra and @arapte can provide their feedback. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Tue Feb 9 23:50:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 23:50:37 GMT Subject: RFR: 8252099: JavaFX does not render Myanmar script correctly In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 21:59:58 GMT, Jose Pereda wrote: > This PR allows rendering Myanmar script correctly, following up on https://bugs.openjdk.java.net/browse/JDK-8223558. It looks fine to me. Not sure whether there is a good way to have an automated test, but as the fix is simple enough, we can take it as long as you've verified it manually. @prrace any comments on this fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/399 From nlisker at openjdk.java.net Wed Feb 10 02:24:57 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 10 Feb 2021 02:24:57 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter [v2] In-Reply-To: References: Message-ID: > Fixes a mutability issue for `LocalDateTimeStringConverter` (and `LocalDateStringConverter`) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made: > > * The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class. > * The chronology field value does not change anymore when there is an exception due to inability to format the date. > * Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand. > > Added a test that fails without this patch. The test creates a converter with an explicit `Chronology` and `null` parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Removed printing and narrowed the exception ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/393/files - new: https://git.openjdk.java.net/jfx/pull/393/files/854c98bc..14475167 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=393&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=393&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/393.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/393/head:pull/393 PR: https://git.openjdk.java.net/jfx/pull/393 From nlisker at openjdk.java.net Wed Feb 10 02:24:58 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 10 Feb 2021 02:24:58 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 13:46:15 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed printing and narrowed the exception > > modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 167: > >> 165: // force a chronology change with an invalid Japanese date >> 166: try { >> 167: System.out.println(converter.toString(LocalDateTime.of(1, 1, 1, 1, 1, 1))); > > Since you are expecting an exception, it seems a good idea to fail if you didn't get one. Something like: > fail("Did not get the expected exception"); > Also, you might consider narrowing the `catch` to just the exception that you expect, so that an unexpected exception will also fail the test. The test checks that the chronology didn't change as a result of catching the exception internally. The thrown exception is from `formatter.parse` later on and will happen regardless of this fix. The only reason I catch and ignore an exception here is so that we can reach the assertion line after that. If we want to test that an exception is thrown, it should be as part of an input-output test (and we can do the same for other converters). ------------- PR: https://git.openjdk.java.net/jfx/pull/393 From fastegal at openjdk.java.net Wed Feb 10 10:52:40 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 10 Feb 2021 10:52:40 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Tue, 9 Feb 2021 23:44:56 GMT, Kevin Rushforth wrote: >> hmm ... might appear convenient (in very controlled contexts) but looks like a precondition violation: the sender of the change must not be null (concededly not explicitly spec'ed but logically implied, IMO) >> >> so would tend to _not_ see this as blueprint for a general pattern fx code base > > I took a quick look at your latest change, and it seems reasonable to me now that you are calling a helper method rather than triggering a change method on the listener. I'll take a closer look later in the week. In the mean time @kleopatra and @arapte can provide their feedback. not going for a full review - just a comment: agree with Kevin, the delegate methods are the way out, basically look good `No further changes in testing required as it is all covered` - a bold statement .. looks like there's a missed null check (which was in the listener code but didn't make it into the delegate) at the end of sceneChanged windowChanged(oldScene.getWindow(), newScene.getWindow()); any of old/new scene can be null (or what am I missing?) If that's not covered by the tests .. ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Wed Feb 10 13:14:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Feb 2021 13:14:38 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Wed, 10 Feb 2021 10:49:52 GMT, Jeanette Winzenburg wrote: > any of old/new scene can be null (or what am I missing?) If that's not covered by the tests .. ;) Yep. And if you look at the checks run by GitHub actions, there are failing tests. For example: 2021-02-09T20:57:51.7835652Z test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactoryTest > testAlternativeSkinAssignable FAILED 2021-02-09T20:57:51.7838200Z java.lang.RuntimeException: java.lang.reflect.InvocationTargetException 2021-02-09T20:57:51.7841382Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.createAlternativeSkin(ControlSkinFactory.java:323) 2021-02-09T20:57:51.7845300Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.replaceSkin(ControlSkinFactory.java:302) 2021-02-09T20:57:51.7852081Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactoryTest.testAlternativeSkinAssignable(ControlSkinFactoryTest.java:91) 2021-02-09T20:57:51.7854816Z 2021-02-09T20:57:51.7855105Z Caused by: 2021-02-09T20:57:51.7855858Z java.lang.reflect.InvocationTargetException 2021-02-09T20:57:51.7857628Z at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 2021-02-09T20:57:51.7860264Z at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64) 2021-02-09T20:57:51.7863798Z at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 2021-02-09T20:57:51.7866625Z at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500) 2021-02-09T20:57:51.7868214Z at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481) 2021-02-09T20:57:51.7870982Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.createAlternativeSkin(ControlSkinFactory.java:321) 2021-02-09T20:57:51.7873192Z ... 2 more 2021-02-09T20:57:51.7873407Z 2021-02-09T20:57:51.7873689Z Caused by: 2021-02-09T20:57:51.7874236Z java.lang.NullPointerException 2021-02-09T20:57:51.7875765Z at javafx.graphics/com.sun.javafx.scene.TreeShowingExpression.sceneChanged(TreeShowingExpression.java:127) 2021-02-09T20:57:51.7877830Z at javafx.graphics/com.sun.javafx.scene.TreeShowingExpression.(TreeShowingExpression.java:66) 2021-02-09T20:57:51.7879836Z at javafx.controls/javafx.scene.control.skin.ProgressIndicatorSkin.(ProgressIndicatorSkin.java:130) 2021-02-09T20:57:51.7881678Z at javafx.controls/javafx.scene.control.skin.ProgressBarSkin.(ProgressBarSkin.java:97) 2021-02-09T20:57:51.7883928Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory$ProgressBarSkin1.(ControlSkinFactory.java:515) 2021-02-09T20:57:51.7885496Z ... 8 more ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Wed Feb 10 13:21:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Feb 2021 13:21:39 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter [v2] In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 02:24:57 GMT, Nir Lisker wrote: >> Fixes a mutability issue for `LocalDateTimeStringConverter` (and `LocalDateStringConverter`) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made: >> >> * The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class. >> * The chronology field value does not change anymore when there is an exception due to inability to format the date. >> * Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand. >> >> Added a test that fails without this patch. The test creates a converter with an explicit `Chronology` and `null` parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Removed printing and narrowed the exception Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/393 From fastegal at openjdk.java.net Wed Feb 10 14:15:37 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 10 Feb 2021 14:15:37 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Wed, 10 Feb 2021 13:12:17 GMT, Kevin Rushforth wrote: >> not going for a full review - just a comment: agree with Kevin, the delegate methods are the way out, basically look good >> >> `No further changes in testing required as it is all covered` - a bold statement .. looks like there's a missed null check (which was in the listener code but didn't make it into the delegate) at the end of sceneChanged >> >> windowChanged(oldScene.getWindow(), newScene.getWindow()); >> >> any of old/new scene can be null (or what am I missing?) If that's not covered by the tests .. ;) > >> any of old/new scene can be null (or what am I missing?) If that's not covered by the tests .. ;) > > Yep. And if you look at the checks run by GitHub actions, there are failing tests. For example: > > 2021-02-09T20:57:51.7835652Z test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactoryTest > testAlternativeSkinAssignable FAILED > 2021-02-09T20:57:51.7838200Z java.lang.RuntimeException: java.lang.reflect.InvocationTargetException > 2021-02-09T20:57:51.7841382Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.createAlternativeSkin(ControlSkinFactory.java:323) > 2021-02-09T20:57:51.7845300Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.replaceSkin(ControlSkinFactory.java:302) > 2021-02-09T20:57:51.7852081Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactoryTest.testAlternativeSkinAssignable(ControlSkinFactoryTest.java:91) > 2021-02-09T20:57:51.7854816Z > 2021-02-09T20:57:51.7855105Z Caused by: > 2021-02-09T20:57:51.7855858Z java.lang.reflect.InvocationTargetException > 2021-02-09T20:57:51.7857628Z at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > 2021-02-09T20:57:51.7860264Z at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64) > 2021-02-09T20:57:51.7863798Z at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > 2021-02-09T20:57:51.7866625Z at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500) > 2021-02-09T20:57:51.7868214Z at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481) > 2021-02-09T20:57:51.7870982Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.createAlternativeSkin(ControlSkinFactory.java:321) > 2021-02-09T20:57:51.7873192Z ... 2 more > 2021-02-09T20:57:51.7873407Z > 2021-02-09T20:57:51.7873689Z Caused by: > 2021-02-09T20:57:51.7874236Z java.lang.NullPointerException > 2021-02-09T20:57:51.7875765Z at javafx.graphics/com.sun.javafx.scene.TreeShowingExpression.sceneChanged(TreeShowingExpression.java:127) > 2021-02-09T20:57:51.7877830Z at javafx.graphics/com.sun.javafx.scene.TreeShowingExpression.(TreeShowingExpression.java:66) > 2021-02-09T20:57:51.7879836Z at javafx.controls/javafx.scene.control.skin.ProgressIndicatorSkin.(ProgressIndicatorSkin.java:130) > 2021-02-09T20:57:51.7881678Z at javafx.controls/javafx.scene.control.skin.ProgressBarSkin.(ProgressBarSkin.java:97) > 2021-02-09T20:57:51.7883928Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory$ProgressBarSkin1.(ControlSkinFactory.java:515) > 2021-02-09T20:57:51.7885496Z ... 8 more good ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From fastegal at openjdk.java.net Wed Feb 10 14:27:41 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 10 Feb 2021 14:27:41 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Wed, 10 Feb 2021 14:13:23 GMT, Jeanette Winzenburg wrote: >>> any of old/new scene can be null (or what am I missing?) If that's not covered by the tests .. ;) >> >> Yep. And if you look at the checks run by GitHub actions, there are failing tests. For example: >> >> 2021-02-09T20:57:51.7835652Z test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactoryTest > testAlternativeSkinAssignable FAILED >> 2021-02-09T20:57:51.7838200Z java.lang.RuntimeException: java.lang.reflect.InvocationTargetException >> 2021-02-09T20:57:51.7841382Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.createAlternativeSkin(ControlSkinFactory.java:323) >> 2021-02-09T20:57:51.7845300Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.replaceSkin(ControlSkinFactory.java:302) >> 2021-02-09T20:57:51.7852081Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactoryTest.testAlternativeSkinAssignable(ControlSkinFactoryTest.java:91) >> 2021-02-09T20:57:51.7854816Z >> 2021-02-09T20:57:51.7855105Z Caused by: >> 2021-02-09T20:57:51.7855858Z java.lang.reflect.InvocationTargetException >> 2021-02-09T20:57:51.7857628Z at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> 2021-02-09T20:57:51.7860264Z at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64) >> 2021-02-09T20:57:51.7863798Z at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> 2021-02-09T20:57:51.7866625Z at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500) >> 2021-02-09T20:57:51.7868214Z at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481) >> 2021-02-09T20:57:51.7870982Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory.createAlternativeSkin(ControlSkinFactory.java:321) >> 2021-02-09T20:57:51.7873192Z ... 2 more >> 2021-02-09T20:57:51.7873407Z >> 2021-02-09T20:57:51.7873689Z Caused by: >> 2021-02-09T20:57:51.7874236Z java.lang.NullPointerException >> 2021-02-09T20:57:51.7875765Z at javafx.graphics/com.sun.javafx.scene.TreeShowingExpression.sceneChanged(TreeShowingExpression.java:127) >> 2021-02-09T20:57:51.7877830Z at javafx.graphics/com.sun.javafx.scene.TreeShowingExpression.(TreeShowingExpression.java:66) >> 2021-02-09T20:57:51.7879836Z at javafx.controls/javafx.scene.control.skin.ProgressIndicatorSkin.(ProgressIndicatorSkin.java:130) >> 2021-02-09T20:57:51.7881678Z at javafx.controls/javafx.scene.control.skin.ProgressBarSkin.(ProgressBarSkin.java:97) >> 2021-02-09T20:57:51.7883928Z at test.com.sun.javafx.scene.control.infrastructure.ControlSkinFactory$ProgressBarSkin1.(ControlSkinFactory.java:515) >> 2021-02-09T20:57:51.7885496Z ... 8 more > > good ;) somehow missed that the red cross on the checks below might be related to test failures (vs. pre-checking compile issues or such only ;) Any way to see the failing tests only? Scrolling through the complete log is a bit .. well ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Wed Feb 10 14:31:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Feb 2021 14:31:39 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Wed, 10 Feb 2021 14:24:31 GMT, Jeanette Winzenburg wrote: >> good ;) > > somehow missed that the red cross on the checks below might be related to test failures (vs. pre-checking compile issues or such only ;) Any way to see the failing tests only? Scrolling through the complete log is a bit .. well Sadly, there is no way to view just the failures -- at least not right now. What I do is open the raw log and look for "FAILED" (all caps). I'll file an RFE to see whether we can produce a summary of the test failures, but I won't have time to look at it right away. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From fastegal at openjdk.java.net Wed Feb 10 14:55:39 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 10 Feb 2021 14:55:39 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Wed, 10 Feb 2021 14:29:09 GMT, Kevin Rushforth wrote: >> somehow missed that the red cross on the checks below might be related to test failures (vs. pre-checking compile issues or such only ;) Any way to see the failing tests only? Scrolling through the complete log is a bit .. well > > Sadly, there is no way to view just the failures -- at least not right now. What I do is open the raw log and look for "FAILED" (all caps). > > I'll file an RFE to see whether we can produce a summary of the test failures, but I won't have time to look at it right away. thanks for the info :) ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From fastegal at openjdk.java.net Wed Feb 10 15:26:45 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 10 Feb 2021 15:26:45 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Wed, 10 Feb 2021 14:53:20 GMT, Jeanette Winzenburg wrote: >> Sadly, there is no way to view just the failures -- at least not right now. What I do is open the raw log and look for "FAILED" (all caps). >> >> I'll file an RFE to see whether we can produce a summary of the test failures, but I won't have time to look at it right away. > > thanks for the info :) > I could extract the methods instead if you donot like me passing in `null` for the `ObservableValue`, it would then look like: > > ``` > sceneChanged(null, node.getScene()); // register chain > > sceneChanged(node.getScene(), null); // unregister chain > ``` > That's a good pattern, IMO (biased, using it in my own code) > > Also I should mention that this is not Skin code in case it was missed. No, it was not missed :) Aside: actually, we cannot use the pattern above in skin code because we are using LambdaMultipleListenerHandler to un/register for change notification. The consumer that's registered carries only the observable, consequently its old value is not available at notification time. Which forces keeping the old value stored in the skin, if interested in changes from a "path" property. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From prr at openjdk.java.net Wed Feb 10 19:13:38 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 10 Feb 2021 19:13:38 GMT Subject: RFR: 8252099: JavaFX does not render Myanmar script correctly In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 21:59:58 GMT, Jose Pereda wrote: > This PR allows rendering Myanmar script correctly, following up on https://bugs.openjdk.java.net/browse/JDK-8223558. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/399 From jpereda at openjdk.java.net Wed Feb 10 19:42:42 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 10 Feb 2021 19:42:42 GMT Subject: Integrated: 8252099: JavaFX does not render Myanmar script correctly In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 21:59:58 GMT, Jose Pereda wrote: > This PR allows rendering Myanmar script correctly, following up on https://bugs.openjdk.java.net/browse/JDK-8223558. This pull request has now been integrated. Changeset: a23d4aeb Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/a23d4aeb Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8252099: JavaFX does not render Myanmar script correctly Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jfx/pull/399 From jhendrikx at openjdk.java.net Wed Feb 10 21:56:01 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 10 Feb 2021 21:56:01 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v6] In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add missed null checks to fix test failure ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/185/files - new: https://git.openjdk.java.net/jfx/pull/185/files/02b4272e..7a685f43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=04-05 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/185/head:pull/185 PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Wed Feb 10 21:56:02 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 10 Feb 2021 21:56:02 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v4] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <_B1_auw1-RcmOuIxqB0mFpGdfYmmbnJBHa5dkCHahQU=.90a8352e-c337-4f61-a354-70467304415a@github.com> On Wed, 10 Feb 2021 15:24:07 GMT, Jeanette Winzenburg wrote: >> thanks for the info :) > >> I could extract the methods instead if you donot like me passing in `null` for the `ObservableValue`, it would then look like: >> >> ``` >> sceneChanged(null, node.getScene()); // register chain >> >> sceneChanged(node.getScene(), null); // unregister chain >> ``` >> > > That's a good pattern, IMO (biased, using it in my own code) > >> >> Also I should mention that this is not Skin code in case it was missed. > > No, it was not missed :) Aside: actually, we cannot use the pattern above in skin code because we are using LambdaMultipleListenerHandler to un/register for change notification. The consumer that's registered carries only the observable, consequently its old value is not available at notification time. Which forces keeping the old value stored in the skin, if interested in changes from a "path" property. I saw the failures in github actions, but figured it was an intermittent failure as I couldn't see an obvious test failure. Somehow the local build didn't run the test again, so I missed it completely. I've pushed a fix. I'm happy this pattern is more to your liking, it does look a bit cleaner and saves some duplication. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Thu Feb 11 00:19:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 00:19:38 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> Message-ID: <22tfdEO1ILt4VorRR14lxyBICTzCMSuY6BkrPtu16ms=.d3afb490-c51d-4ef0-b50a-59c1a2565d77@github.com> On Mon, 11 Jan 2021 22:20:38 GMT, Kevin Rushforth wrote: >> Now more of my company are remoting into machines this issue is causing problems for us. > > I moved it to Draft before noticing that there were additional commits after your last comment that I had missed seeing earlier, so I moved it back to RFR. This is a good starting point, but it will need additional work, possibly in the native D3D code as well as on the Java side, to fully cleanup and recreate all of the resources after the device is recreated. As discussed offline, I'll take a stab at this using your PR as a starting point. I ran some tests this afternoon. It does detect that the devide was removed, and the disposes and recreates the device, but then it has problem drawing anything with a texture; it throws an exception and there are rendering artifacts: KCR: create resource factor for screen 0 D3DContext::testCooperativeLevel D3DContext::testCooperativeLevel D3DContext::testCooperativeLevel D3DContext::testCooperativeLevel D3DContext::testCooperativeLevel KCR: D3DERR_DEVICEREMOVED KCR: dispose graphics pipeline KCR: instance is null: reinitialize D3DPipeline Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "com.sun.prism.GraphicsPipeline.is3DSupported()" because the return value of "com.sun.prism.GraphicsPipeline.getPipeline()" is null at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.isSupported(QuantumToolkit.java:1209) at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupportedImpl(PlatformImpl.java:979) at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupported(PlatformImpl.java:646) at javafx.graphics/javafx.application.Platform.isSupported(Platform.java:262) at javafx.graphics/com.sun.javafx.scene.input.PickResultChooser.processOffer(PickResultChooser.java:182) at javafx.graphics/com.sun.javafx.scene.input.PickResultChooser.offer(PickResultChooser.java:143) at javafx.graphics/javafx.scene.Node.intersects(Node.java:5229) at javafx.graphics/javafx.scene.Node$1.intersects(Node.java:553) at javafx.graphics/com.sun.javafx.scene.NodeHelper.intersects(NodeHelper.java:258) at javafx.graphics/javafx.scene.layout.Region.doPickNodeLocal(Region.java:3227) ... at javafx.graphics/javafx.scene.Scene.pick(Scene.java:2031) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3810) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1851) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2584) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:409) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:299) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:447) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:413) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:446) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:556) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:942) at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) at java.base/java.lang.Thread.run(Thread.java:832) ... KCR: create resource factor for screen 0 D3DContext::testCooperativeLevel D3DContext::testCooperativeLevel KCR: dispose graphics pipeline ![HelloFontSize](https://user-images.githubusercontent.com/34689748/107589656-568bf000-6bbb-11eb-9c0d-bea50b190d4d.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From github.com+3197675+abhinayagarwal at openjdk.java.net Fri Feb 12 16:55:57 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Fri, 12 Feb 2021 16:55:57 GMT Subject: RFR: 8261460: Incorrect CSS applied to ContextMenu on DialogPane Message-ID: Both DialogPane and ContextMenu have a child node with a style-class `graphic-container`. This leads to a corner case where an unwanted style is applied to ContextMenu when it is shown on a DialogPane. ------------- Commit messages: - Remove executable flag from image and move it to correct directory - Remove whitespace - Update tests - 8261460: Incorrect CSS applied to ContextMenu on DialogPane Changes: https://git.openjdk.java.net/jfx/pull/400/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=400&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261460 Stats: 107 lines in 4 files changed: 106 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/400.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/400/head:pull/400 PR: https://git.openjdk.java.net/jfx/pull/400 From kcr at openjdk.java.net Sat Feb 13 18:53:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 13 Feb 2021 18:53:43 GMT Subject: RFR: 8261460: Incorrect CSS applied to ContextMenu on DialogPane In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 08:52:55 GMT, Abhinay Agarwal wrote: > Both DialogPane and ContextMenu have a child node with a style-class `graphic-container`. This leads to a corner case where an unwanted style is applied to ContextMenu when it is shown on a DialogPane. Both the fix and the new tests look good to me. I can confirm that it fixes the test program attached to JBS, and that the new ContextMenu unit test fails before and passes after the fix. This looks like a simple and safe fix, but I'd like a second reviewer for anything that touches the `modena.css` stylesheet. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/400 From tsayao at openjdk.java.net Sun Feb 14 22:09:43 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 14 Feb 2021 22:09:43 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> Message-ID: On Wed, 27 Jan 2021 16:39:55 GMT, Thiago Milczarek Sayao wrote: >> This does look like a much more manageable approach. >> >> One thing to be aware of from a bookkeeping point of view is that a JBS issues is resolved by a single PR. Once a PR has been integrated for a given JBS bug ID, that bug ID cannot be reused. >> >> This means that each separate PR will need it's own JBS issue to be filed, even if those enhancements taken together are part of a larger set of improvements. Incremental improvements are fine (and in this case a good way to proceed), but you might give some thought to the title of each such improvement. I wouldn't want to see 5 fixes go in each with the same title of `Simplify and update glass gtk backend`. > > It's been pointed out about this > https://stackoverflow.com/questions/49512491/javafx-getting-single-resize-events > > My tests point out that this PR causes less sizing events that the current master branch, but I also think this could be improved further. > > But, by the nature of X and window managers, window sizes does not account decoration frames, but javafx does (probably mimicking windows behavior). Given this information I probably could reduce further the sizing events, but not make it equivalent to windows. Changed to WIP to reduce sizing events. ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Mon Feb 15 00:10:09 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 15 Feb 2021 00:10:09 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v4] In-Reply-To: References: Message-ID: <57WpFOoqvQryU6HWGcVu1lkEuFqdz3xTKOSrwKcEf4k=.9a8863c0-b9a1-4170-a4b1-d2264ae7381b@github.com> > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao 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 25 additional commits since the last revision: - Reduce size notify to java - Merge branch 'master' into glass_gtk_new_position_and_size - Merge pull request #16 from openjdk/master Update - Reduce size notify to java - Revert change to reduce size notify events due to frame extents adjustment - it makes some tests fail. - Merge branch 'master' into glass_gtk_new_position_and_size - Merge pull request #15 from openjdk/master Update from jfx - Avoid redundant resize notify - Fix parent window being resizable (it should not) - Minor fix to positioning - ... and 15 more: https://git.openjdk.java.net/jfx/compare/2e19b548...5f87da28 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/e8528ef2..5f87da28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=02-03 Stats: 257585 lines in 5458 files changed: 125365 ins; 93757 del; 38463 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Mon Feb 15 00:13:02 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 15 Feb 2021 00:13:02 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v5] In-Reply-To: References: Message-ID: <-rx0nVlA1_Hhyyo6fKpZjQUEaAipCZqOHBGH6P2b9iw=.93fb34ab-4487-46bf-b457-5cf09c1e141a@github.com> > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Prefer bool ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/5f87da28..f04d3b40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Mon Feb 15 00:53:01 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 15 Feb 2021 00:53:01 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v6] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/f04d3b40..b3b0adcd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=04-05 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From arapte at openjdk.java.net Mon Feb 15 07:43:39 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Feb 2021 07:43:39 GMT Subject: RFR: 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 11:33:13 GMT, Pankaj Bansal wrote: > JavaFX ignores the HiDPI scaling settings on Fedora 32 and Ubuntu 20.04. > > The scale detection in JavaFX assumes that the "scaling-factor" setting in "org.gnome.desktop.interface" has the correct Hi-DPI setting. But this not true for some systems and "scaling-factor" has value of 0. JavaFX should detect the windows level scale factor automatically in this case, but this logic is missing right now. So, the JavaFX applications are not scaled properly. > This issue can be reproduced by setting the scale from Settings->Displays->Set Scale. Note, the option for scale may not be present from some resolution settings, so you may need to change it to see the option to scale the full windowing system. The issue can be verified by running some JavaFX applications/samples. The application will not be scaled properly according to the UIScale. https://bugs.openjdk.java.net/browse/JDK-8258464 is similar bug and has been closed as duplicate. > > This fix adds the logic to detect the scale from windows system itself. > I have ran all automated unit tests and system tests, this fix is not causing any new failures. I have tested this on fedora 32 VM, Ubuntu 20.04 VM and Ubuntu 20.10 VM. Looks good, verified with Ubuntu 20.04. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/396 From pbansal at openjdk.java.net Mon Feb 15 08:14:45 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 15 Feb 2021 08:14:45 GMT Subject: Integrated: 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 11:33:13 GMT, Pankaj Bansal wrote: > JavaFX ignores the HiDPI scaling settings on Fedora 32 and Ubuntu 20.04. > > The scale detection in JavaFX assumes that the "scaling-factor" setting in "org.gnome.desktop.interface" has the correct Hi-DPI setting. But this not true for some systems and "scaling-factor" has value of 0. JavaFX should detect the windows level scale factor automatically in this case, but this logic is missing right now. So, the JavaFX applications are not scaled properly. > This issue can be reproduced by setting the scale from Settings->Displays->Set Scale. Note, the option for scale may not be present from some resolution settings, so you may need to change it to see the option to scale the full windowing system. The issue can be verified by running some JavaFX applications/samples. The application will not be scaled properly according to the UIScale. https://bugs.openjdk.java.net/browse/JDK-8258464 is similar bug and has been closed as duplicate. > > This fix adds the logic to detect the scale from windows system itself. > I have ran all automated unit tests and system tests, this fix is not causing any new failures. I have tested this on fedora 32 VM, Ubuntu 20.04 VM and Ubuntu 20.10 VM. This pull request has now been integrated. Changeset: 782f22a1 Author: Pankaj Bansal URL: https://git.openjdk.java.net/jfx/commit/782f22a1 Stats: 15 lines in 3 files changed: 5 ins; 1 del; 9 mod 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/396 From arapte at openjdk.java.net Mon Feb 15 08:42:44 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Feb 2021 08:42:44 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v6] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <8TOBXPB7657ynFtxEuT_SsMA2C7hHMGxQT7NCPd3ruA=.eeaa1314-db57-4251-a9a2-f3d629e5c2d9@github.com> On Wed, 10 Feb 2021 21:56:01 GMT, John Hendrikx wrote: >> This is a PoC for performance testing. >> >> It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. >> >> This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add missed null checks to fix test failure Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/185 From org.openjdk at io7m.com Mon Feb 15 13:40:43 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 15 Feb 2021 13:40:43 +0000 Subject: Layering JavaFX onto an external rendering context Message-ID: <20210215134043.09b57608@sunflower.int.arc7.info> Hello! I'd like to use JavaFX for the UI of an application that will involve rendering using an existing Vulkan-based renderer. For the sake of example, assume that the application looks and behaves a bit like the Unreal Engine 4 editing tools. Here's an example of those: https://www.youtube.com/watch?v=2UowdJetXwA My understanding right now is that there isn't direct support in JavaFX for building this kind of application, and the primary reason for this is that there's a sort of conceptual wrestling match for control of a platform-specific rendering context here. For example: * A JavaFX application will tell JavaFX to open a new window, and the JavaFX implementation will do all of the OS-windowing-system-specific things to achieve this, and will also set up a system-specific rendering context depending on what the underlying platform is (OpenGL, DirectX, Metal, etc). JavaFX then translates input such as mouse and keyboard events from OS-specific types to the platform-independent JavaFX types so that the application can process them. * A typical Vulkan application will ask something analogous to the GLFW library to open a new window, and set up a rendering context. The GLFW library then translates input such as mouse and keyboard events from OS-specific types to generic GLFW event types, and the Vulkan application (probably) translates these into its own application-specific event types for processing. Obviously, in a given application, we're limited to having either one of these things happen, but realistically not both. The current approach (as of JavaFX 14) seems to be to use the PixelBuffer API in order to provide a CPU-side bridge between JavaFX and whatever rendering system is being used for external 3D rendering. In other words, this is the expected setup: 1. A JavaFX application will tell JavaFX to open a new window, and JavaFX will do all of the system-specific work required as described previously. 2. The application will then tell a library such as GLFW to create an _offscreen_ rendering context, perhaps configuring Vulkan or OpenGL. 3. The application, at the end of each frame, copies the contents of the offscreen rendering context's framebuffer into a PixelBuffer instance to be displayed inside a JavaFX UI. This, as far as I know, works correctly. The main complaint with this is that it pays a pretty heavy price: There's one framebuffer-sized copy operation from the GPU to the CPU (in order to read the required pixels), and then another framebuffer-sized copy operation back from the CPU to the GPU (either when writing into the PixelBuffer, or when JavaFX renders the contents of that PixelBuffer to the screen). My understanding is that it's essentially necessary to do these two rather expensive copying operations merely because JavaFX can't and won't expose the underlying rendering context it uses for its own UI rendering, and it also can't be expected to talk to whatever other rendering system the application might be using. The problem is essentially "we have these two systems both using the GPU, but they don't know each other and therefore we can't write code to get memory from one to the other without going via the CPU". Is this an accurate picture of the situation? As someone working exclusively with Vulkan, I can arrange to have the GPU copy the framebuffer into host-visible (not necessarily host-resident, but host _visible_) memory at the end of each frame. It's a little sad to have to actually copy that memory over the PCI bus just to immediately copy it back again, though. Is there no design we could come up with that would allow for at worst a simple GPU ? GPU copy? I'm resigned to the fact that a copying operation is probably going to happen _somewhere_, but it'd be nice if we could avoid a rather expensive and redundant GPU ? CPU ? GPU copy. -- Mark Raynsford | https://www.io7m.com From herve.girod at gmail.com Mon Feb 15 13:54:43 2021 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Mon, 15 Feb 2021 14:54:43 +0100 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210215134043.09b57608@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> Message-ID: I did that with OpenGL some time ago. I should setup a GitHub project to show how it can be done. Sent from my iPhone > On Feb 15, 2021, at 14:41, Mark Raynsford wrote: > > ?Hello! > > I'd like to use JavaFX for the UI of an application that will > involve rendering using an existing Vulkan-based renderer. For the sake > of example, assume that the application looks and behaves a bit like > the Unreal Engine 4 editing tools. Here's an example of those: > > https://www.youtube.com/watch?v=2UowdJetXwA > > My understanding right now is that there isn't direct support in > JavaFX for building this kind of application, and the primary reason > for this is that there's a sort of conceptual wrestling match for > control of a platform-specific rendering context here. For example: > > * A JavaFX application will tell JavaFX to open a new window, > and the JavaFX implementation will do all of the > OS-windowing-system-specific things to achieve this, and will > also set up a system-specific rendering context depending on > what the underlying platform is (OpenGL, DirectX, Metal, etc). > JavaFX then translates input such as mouse and keyboard events > from OS-specific types to the platform-independent JavaFX types > so that the application can process them. > > * A typical Vulkan application will ask something analogous to > the GLFW library to open a new window, and set up a rendering > context. The GLFW library then translates input such as mouse and > keyboard events from OS-specific types to generic GLFW event > types, and the Vulkan application (probably) translates these > into its own application-specific event types for processing. > > Obviously, in a given application, we're limited to having either > one of these things happen, but realistically not both. > > The current approach (as of JavaFX 14) seems to be to use the > PixelBuffer API in order to provide a CPU-side bridge between > JavaFX and whatever rendering system is being used for external 3D > rendering. In other words, this is the expected setup: > > 1. A JavaFX application will tell JavaFX to open a new window, > and JavaFX will do all of the system-specific work required > as described previously. > > 2. The application will then tell a library such as GLFW to > create an _offscreen_ rendering context, perhaps configuring > Vulkan or OpenGL. > > 3. The application, at the end of each frame, copies the contents > of the offscreen rendering context's framebuffer into a PixelBuffer > instance to be displayed inside a JavaFX UI. > > This, as far as I know, works correctly. The main complaint with > this is that it pays a pretty heavy price: There's one framebuffer-sized > copy operation from the GPU to the CPU (in order to read the required > pixels), and then another framebuffer-sized copy operation back from > the CPU to the GPU (either when writing into the PixelBuffer, or when > JavaFX renders the contents of that PixelBuffer to the screen). > > My understanding is that it's essentially necessary to do these two > rather expensive copying operations merely because JavaFX can't and > won't expose the underlying rendering context it uses for its own UI > rendering, and it also can't be expected to talk to whatever other > rendering system the application might be using. The problem is > essentially "we have these two systems both using the GPU, but they > don't know each other and therefore we can't write code to get > memory from one to the other without going via the CPU". > > Is this an accurate picture of the situation? > > As someone working exclusively with Vulkan, I can arrange to have > the GPU copy the framebuffer into host-visible (not necessarily > host-resident, but host _visible_) memory at the end of each frame. > It's a little sad to have to actually copy that memory over the PCI bus > just to immediately copy it back again, though. Is there no design we > could come up with that would allow for at worst a simple GPU ? GPU > copy? I'm resigned to the fact that a copying operation is probably > going to happen _somewhere_, but it'd be nice if we could avoid a > rather expensive and redundant GPU ? CPU ? GPU copy. > > -- > Mark Raynsford | https://www.io7m.com > From thorsten.reimers at softquadrat.de Mon Feb 15 14:09:56 2021 From: thorsten.reimers at softquadrat.de (Thorsten Reimers) Date: Mon, 15 Feb 2021 15:09:56 +0100 Subject: System Menu Bar and Splash Screen under Mac OS X In-Reply-To: <55D54016-CF68-4F5E-A94A-5533310BB6E8@softquadrat.de> References: <55D54016-CF68-4F5E-A94A-5533310BB6E8@softquadrat.de> Message-ID: <3DFBE46C-60F4-4000-9809-AF9B19B79CF3@softquadrat.de> Hallo, any ideas to my problem? How can I open a new OpenJFX issue? Thanks in advance Thorsten > Am 07.02.2021 um 20:45 schrieb Thorsten Reimers : > > Hello, > > I have a problem with Open JFX under Mac OS X. When using System Menu Bar for a menu and starting Java with -splash option the menu is no longer displayed as System menu. > > My environment > > > OS OS X El Capitan (10.11.6) > Java openjdk version "15" 2020-09-15 > OpenJDK Runtime Environment AdoptOpenJDK (build 15+36) > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed mode, sharing) > OpenJFX 15.0.1 > > I have created a Stackoverflow question with a more detailed description: https://stackoverflow.com/questions/65511188/javafx-problem-with-usesystemmenubar-when-starting-with-splash-option > > Does anybody has seen this behaviour? Is this a Java FX bug? > > Thanks in advance > Thorsten > From github.com+25760501+rnayabed at openjdk.java.net Mon Feb 15 14:51:44 2021 From: github.com+25760501+rnayabed at openjdk.java.net (Debayan Sutradhar) Date: Mon, 15 Feb 2021 14:51:44 GMT Subject: RFR: 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 07:41:17 GMT, Ambarish Rapte wrote: >> JavaFX ignores the HiDPI scaling settings on Fedora 32 and Ubuntu 20.04. >> >> The scale detection in JavaFX assumes that the "scaling-factor" setting in "org.gnome.desktop.interface" has the correct Hi-DPI setting. But this not true for some systems and "scaling-factor" has value of 0. JavaFX should detect the windows level scale factor automatically in this case, but this logic is missing right now. So, the JavaFX applications are not scaled properly. >> This issue can be reproduced by setting the scale from Settings->Displays->Set Scale. Note, the option for scale may not be present from some resolution settings, so you may need to change it to see the option to scale the full windowing system. The issue can be verified by running some JavaFX applications/samples. The application will not be scaled properly according to the UIScale. https://bugs.openjdk.java.net/browse/JDK-8258464 is similar bug and has been closed as duplicate. >> >> This fix adds the logic to detect the scale from windows system itself. >> I have ran all automated unit tests and system tests, this fix is not causing any new failures. I have tested this on fedora 32 VM, Ubuntu 20.04 VM and Ubuntu 20.10 VM. > > Looks good, verified with Ubuntu 20.04. This is amazing. I had to set uiScale on startup because it wouldnt work on ubuntu 20.04 ------------- PR: https://git.openjdk.java.net/jfx/pull/396 From nlisker at gmail.com Mon Feb 15 15:08:11 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 15 Feb 2021 17:08:11 +0200 Subject: System Menu Bar and Splash Screen under Mac OS X In-Reply-To: <3DFBE46C-60F4-4000-9809-AF9B19B79CF3@softquadrat.de> References: <55D54016-CF68-4F5E-A94A-5533310BB6E8@softquadrat.de> <3DFBE46C-60F4-4000-9809-AF9B19B79CF3@softquadrat.de> Message-ID: If you can't find it in bugs.openjdk.java.net then you can submit a new issue on bugs.java.com. On Mon, Feb 15, 2021 at 4:10 PM Thorsten Reimers < thorsten.reimers at softquadrat.de> wrote: > Hallo, > > any ideas to my problem? How can I open a new OpenJFX issue? > > Thanks in advance > Thorsten > > > Am 07.02.2021 um 20:45 schrieb Thorsten Reimers < > thorsten.reimers at softquadrat.de>: > > > > Hello, > > > > I have a problem with Open JFX under Mac OS X. When using System Menu > Bar for a menu and starting Java with -splash option the menu is no longer > displayed as System menu. > > > > My environment > > > > > > OS OS X El Capitan (10.11.6) > > Java openjdk version "15" 2020-09-15 > > OpenJDK Runtime Environment AdoptOpenJDK (build 15+36) > > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed > mode, sharing) > > OpenJFX 15.0.1 > > > > I have created a Stackoverflow question with a more detailed > description: > https://stackoverflow.com/questions/65511188/javafx-problem-with-usesystemmenubar-when-starting-with-splash-option > > > > Does anybody has seen this behaviour? Is this a Java FX bug? > > > > Thanks in advance > > Thorsten > > > > From thorsten.reimers at softquadrat.de Mon Feb 15 15:37:57 2021 From: thorsten.reimers at softquadrat.de (Thorsten Reimers) Date: Mon, 15 Feb 2021 16:37:57 +0100 Subject: System Menu Bar and Splash Screen under Mac OS X In-Reply-To: References: <55D54016-CF68-4F5E-A94A-5533310BB6E8@softquadrat.de> <3DFBE46C-60F4-4000-9809-AF9B19B79CF3@softquadrat.de> Message-ID: <3DB63FA4-C6CB-4611-881F-E8ED8B25C5E2@softquadrat.de> Thank you, I shall do! Best regards Thorsten > Am 15.02.2021 um 16:08 schrieb Nir Lisker : > > If you can't find it in bugs.openjdk.java.net then you can submit a new issue on bugs.java.com . > > On Mon, Feb 15, 2021 at 4:10 PM Thorsten Reimers > wrote: > Hallo, > > any ideas to my problem? How can I open a new OpenJFX issue? > > Thanks in advance > Thorsten > > > Am 07.02.2021 um 20:45 schrieb Thorsten Reimers >: > > > > Hello, > > > > I have a problem with Open JFX under Mac OS X. When using System Menu Bar for a menu and starting Java with -splash option the menu is no longer displayed as System menu. > > > > My environment > > > > > > OS OS X El Capitan (10.11.6) > > Java openjdk version "15" 2020-09-15 > > OpenJDK Runtime Environment AdoptOpenJDK (build 15+36) > > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed mode, sharing) > > OpenJFX 15.0.1 > > > > I have created a Stackoverflow question with a more detailed description: https://stackoverflow.com/questions/65511188/javafx-problem-with-usesystemmenubar-when-starting-with-splash-option > > > > Does anybody has seen this behaviour? Is this a Java FX bug? > > > > Thanks in advance > > Thorsten > > > From jvos at openjdk.java.net Mon Feb 15 21:16:55 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 15 Feb 2021 21:16:55 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. Message-ID: This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. ------------- Commit messages: - fix whitespace issues - * fix failing tests by hard-coding new count values. - Fix whitespace issues - fix a few more tests. - VirtualFlow refactory to pixel-based calculations Changes: https://git.openjdk.java.net/jfx/pull/398/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=398&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8089589 Stats: 594 lines in 6 files changed: 446 ins; 85 del; 63 mod Patch: https://git.openjdk.java.net/jfx/pull/398.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/398/head:pull/398 PR: https://git.openjdk.java.net/jfx/pull/398 From tsayao at openjdk.java.net Tue Feb 16 01:07:01 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 16 Feb 2021 01:07:01 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v7] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Another approach to avoid extra size notify events ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/b3b0adcd..ff2f0f8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=05-06 Stats: 30 lines in 2 files changed: 6 ins; 15 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From org.openjdk at io7m.com Tue Feb 16 15:26:28 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Tue, 16 Feb 2021 15:26:28 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: References: <20210215134043.09b57608@sunflower.int.arc7.info> Message-ID: <20210216152628.0992fb9a@sunflower.int.arc7.info> On 2021-02-15T14:54:43 +0100 Herv? Girod wrote: > I did that with OpenGL some time ago. I should setup a GitHub project to show how it can be done. > I appreciate the response, but there is a difference between "I did it" and "there's actually a good, officially supported way to do this". I've seen people do various tricks like those in DriftFX: https://github.com/eclipse-efx/efxclipse-drift/ But it seems to me like those projects shouldn't _have_ to exist. It seems like a bit of a design flaw that there isn't an efficient code path to do something (relatively) simple like this. Has anyone given any thought as to what an API like this should look like? -- Mark Raynsford | https://www.io7m.com From kcr at openjdk.java.net Tue Feb 16 15:45:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Feb 2021 15:45:45 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: <22tfdEO1ILt4VorRR14lxyBICTzCMSuY6BkrPtu16ms=.d3afb490-c51d-4ef0-b50a-59c1a2565d77@github.com> References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> <22tfdEO1ILt4VorRR14lxyBICTzCMSuY6BkrPtu16ms=.d3afb490-c51d-4ef0-b50a-59c1a2565d77@github.com> Message-ID: <9wHn5ETuz3xCDDn8097ykOtE0g7jUon2d6FQi9eWwAc=.c384aa85-4026-4194-afc8-73e2cbaa20f7@github.com> On Thu, 11 Feb 2021 00:17:10 GMT, Kevin Rushforth wrote: >> I moved it to Draft before noticing that there were additional commits after your last comment that I had missed seeing earlier, so I moved it back to RFR. > > This is a good starting point, but it will need additional work, possibly in the native D3D code as well as on the Java side, to fully cleanup and recreate all of the resources after the device is recreated. As discussed offline, I'll take a stab at this using your PR as a starting point. > > I ran some tests this afternoon. It does detect that the devide was removed, and the disposes and recreates the device, but then it has problem drawing anything with a texture; it throws an exception and there are rendering artifacts: > > KCR: create resource factor for screen 0 > D3DContext::testCooperativeLevel > D3DContext::testCooperativeLevel > D3DContext::testCooperativeLevel > D3DContext::testCooperativeLevel > D3DContext::testCooperativeLevel > KCR: D3DERR_DEVICEREMOVED > KCR: dispose graphics pipeline > KCR: instance is null: reinitialize D3DPipeline > Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "com.sun.prism.GraphicsPipeline.is3DSupported()" because the return value of "com.sun.prism.GraphicsPipeline.getPipeline()" is null > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.isSupported(QuantumToolkit.java:1209) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupportedImpl(PlatformImpl.java:979) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupported(PlatformImpl.java:646) > at javafx.graphics/javafx.application.Platform.isSupported(Platform.java:262) > at javafx.graphics/com.sun.javafx.scene.input.PickResultChooser.processOffer(PickResultChooser.java:182) > at javafx.graphics/com.sun.javafx.scene.input.PickResultChooser.offer(PickResultChooser.java:143) > at javafx.graphics/javafx.scene.Node.intersects(Node.java:5229) > at javafx.graphics/javafx.scene.Node$1.intersects(Node.java:553) > at javafx.graphics/com.sun.javafx.scene.NodeHelper.intersects(NodeHelper.java:258) > at javafx.graphics/javafx.scene.layout.Region.doPickNodeLocal(Region.java:3227) > ... > at javafx.graphics/javafx.scene.Scene.pick(Scene.java:2031) > at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3810) > at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1851) > at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2584) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:409) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:299) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:447) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:413) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:446) > at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:556) > at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:942) > at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > at java.base/java.lang.Thread.run(Thread.java:832) > ... > KCR: create resource factor for screen 0 > D3DContext::testCooperativeLevel > D3DContext::testCooperativeLevel > KCR: dispose graphics pipeline > ![HelloFontSize](https://user-images.githubusercontent.com/34689748/107589656-568bf000-6bbb-11eb-9c0d-bea50b190d4d.png) I created PR #403 using this as a starting point, so I am moving this PR back to draft (and it probably can be closed). ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From neil at codelerity.com Tue Feb 16 16:09:04 2021 From: neil at codelerity.com (Neil C Smith) Date: Tue, 16 Feb 2021 16:09:04 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210216152628.0992fb9a@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210216152628.0992fb9a@sunflower.int.arc7.info> Message-ID: Hi Mark, On Tue, 16 Feb 2021 at 15:27, Mark Raynsford wrote: > But it seems to me like those projects shouldn't _have_ to exist. It > seems like a bit of a design flaw that there isn't an efficient code > path to do something (relatively) simple like this. > > Has anyone given any thought as to what an API like this should look > like? I agree with you, and have certain similar requirements, like being able to allow GStreamer and JavaFX to share GPU contexts. In fact, was bugging Johan about this in the chat around his FOSDEM talk, and promised to follow up here, so might as well pop my head above the parapet. :-) I certainly don't know what such an API should look like, but in some ways to me parallels the differences between io file and nio2 files - hidden by abstraction vs type-safe queryable capabilities / profiles. In fact, given above, also something slightly akin to GStreamer's context querying. Incidentally, reading your initial post about PixelBuffer reminds me that I should also follow up on a point about concurrency issues with that from last year. The API has (or had?) issues with accessing the buffer from the rendering thread after it's been removed in the event thread, which particularly with externally allocated buffers makes it hard to safely mark as invalid to allow them to be freed. Best wishes, Neil -- Neil C Smith Codelerity Ltd. www.codelerity.com Codelerity Ltd. is a company registered in England and Wales Registered company number : 12063669 Registered office address : Office 4 219 Kensington High Street, Kensington, London, England, W8 6BD From kcr at openjdk.java.net Tue Feb 16 18:59:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Feb 2021 18:59:46 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v6] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <-LtfVzOE5eWcqnOTG-tvHyoR10dwc21Dv77Duuvn1sM=.9211acce-aeac-4692-a5b3-35a2262382b5@github.com> On Wed, 10 Feb 2021 21:56:01 GMT, John Hendrikx wrote: >> This is a PoC for performance testing. >> >> It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. >> >> This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add missed null checks to fix test failure The updated test and fix look good. While fixing up the copyright years you lost the initial year on one of the files, so that needs to be restored. I'll approve it after that. modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. The initial year needs to be preserved. Please restore as follows: `2013, 2021, ` ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/185 From org.openjdk at io7m.com Tue Feb 16 20:41:33 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Tue, 16 Feb 2021 20:41:33 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210216152628.0992fb9a@sunflower.int.arc7.info> Message-ID: <20210216204133.2dbb06fb@sunflower.int.arc7.info> On 2021-02-16T16:09:04 +0000 Neil C Smith wrote: > > I agree with you, and have certain similar requirements, like being > able to allow GStreamer and JavaFX to share GPU contexts. In fact, > was bugging Johan about this in the chat around his FOSDEM talk, and > promised to follow up here, so might as well pop my head above the > parapet. :-) I do think it ultimately boils down to "provide an image to JavaFX when it asks for one, and don't allow the image to leave the GPU". I've used GStreamer outside of Java quite a bit for aggregating feeds from network cameras... In your case, is it that you want to consume one or more video streams from GStreamer inside a JavaFX UI? We'd be pretty close in terms of requirements with regards to not copying across CPU/GPU boundaries, and requiring low latency. :) > I certainly don't know what such an API should look like, but in some > ways to me parallels the differences between io file and nio2 files - > hidden by abstraction vs type-safe queryable capabilities / profiles. > In fact, given above, also something slightly akin to GStreamer's > context querying. > > Incidentally, reading your initial post about PixelBuffer reminds me > that I should also follow up on a point about concurrency issues with > that from last year. The API has (or had?) issues with accessing the > buffer from the rendering thread after it's been removed in the event > thread, which particularly with externally allocated buffers makes it > hard to safely mark as invalid to allow them to be freed. Yeah, that is a problem. It's why I said in my original email that I was resigned to the fact that a copy was probably going to have to happen somewhere. Without going into API specifics, I was sort of picturing JavaFX maintaining two images on the GPU; at any given time one is being displayed (ie. used as a texture whilst rendering a scene) and the other is being offered to the user as a destination for a GPU copy operation. It would be the responsibility of the user to copy an image in the right format into the offered buffer. There would need to be the appropriate memory barriers inserted, and I don't know how this could/would be handled given that it might be two completely different graphics APIs involved (there isn't a Vulkan JavaFX backend, for example,so in my case I'm guaranteed to be talking to something that isn't Vulkan). When an image had been copied in as required, and JavaFX had been told that this had happened, the two images would be swapped on the GPU. -- Mark Raynsford | https://www.io7m.com From michaelstrau2 at gmail.com Tue Feb 16 23:33:13 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 17 Feb 2021 00:33:13 +0100 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210216204133.2dbb06fb@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210216152628.0992fb9a@sunflower.int.arc7.info> <20210216204133.2dbb06fb@sunflower.int.arc7.info> Message-ID: The main problem with this idea is that there is no universally available hardware rendering backend in JavaFX. There's OpenGL on Linux and macOS, Direct3D on Windows, and potentially a software renderer on all platforms. One approach might be to create a new ANGLE rendering backend, which would allow you to use the OpenGL API with any kind of platform-specific API. If such a rendering backend is ever created, it might actually be sensible to deprecate the existing D3D and GLES backends. Since ANGLE also supports Vulkan, it might be unnecessary to implement a new backend for Vulkan support specifically. As far as JavaFX API is concerned, it should be relatively straightforward to create a control that can host a custom GL surface similar to D3DImage in WPF. It is generally not safe to expose the OpenGL rendering context that is used internally by JavaFX, because users might inadvertently change the GL state machine. A better approach would be to create a new shared context that can share surfaces with the main JavaFX GL context. Of course, having all of that might still not be really useful without a Java-based API for OpenGL. Perhaps JOGL could be adapted to work for this scenario? Am Di., 16. Feb. 2021 um 21:42 Uhr schrieb Mark Raynsford < org.openjdk at io7m.com>: > On 2021-02-16T16:09:04 +0000 > Neil C Smith wrote: > > > > I agree with you, and have certain similar requirements, like being > > able to allow GStreamer and JavaFX to share GPU contexts. In fact, > > was bugging Johan about this in the chat around his FOSDEM talk, and > > promised to follow up here, so might as well pop my head above the > > parapet. :-) > > I do think it ultimately boils down to "provide an image to JavaFX when > it asks for one, and don't allow the image to leave the GPU". I've used > GStreamer outside of Java quite a bit for aggregating feeds from > network cameras... In your case, is it that you want to consume one or > more video streams from GStreamer inside a JavaFX UI? We'd be pretty > close in terms of requirements with regards to not copying across > CPU/GPU boundaries, and requiring low latency. :) > > > I certainly don't know what such an API should look like, but in some > > ways to me parallels the differences between io file and nio2 files - > > hidden by abstraction vs type-safe queryable capabilities / profiles. > > In fact, given above, also something slightly akin to GStreamer's > > context querying. > > > > Incidentally, reading your initial post about PixelBuffer reminds me > > that I should also follow up on a point about concurrency issues with > > that from last year. The API has (or had?) issues with accessing the > > buffer from the rendering thread after it's been removed in the event > > thread, which particularly with externally allocated buffers makes it > > hard to safely mark as invalid to allow them to be freed. > > Yeah, that is a problem. It's why I said in my original email that I > was resigned to the fact that a copy was probably going to have to > happen somewhere. Without going into API specifics, I was sort of > picturing JavaFX maintaining two images on the GPU; at any given time > one is being displayed (ie. used as a texture whilst rendering a scene) > and the other is being offered to the user as a destination for a GPU > copy operation. It would be the responsibility of the user to copy an > image in the right format into the offered buffer. There would need to > be the appropriate memory barriers inserted, and I don't know how this > could/would be handled given that it might be two completely different > graphics APIs involved (there isn't a Vulkan JavaFX backend, for > example,so in my case I'm guaranteed to be talking to something that isn't > Vulkan). When an image had been copied in as required, and JavaFX had > been told that this had happened, the two images would be swapped on the > GPU. > > -- > Mark Raynsford | https://www.io7m.com > > From tsayao at openjdk.java.net Tue Feb 16 23:54:09 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 16 Feb 2021 23:54:09 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v8] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix maximize bug ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/ff2f0f8e..fedccf56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=06-07 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Wed Feb 17 00:18:02 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 17 Feb 2021 00:18:02 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v9] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Pass PixelBufferDrawTest ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/fedccf56..30d5291e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=07-08 Stats: 32 lines in 1 file changed: 9 ins; 1 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From neil at codelerity.com Wed Feb 17 10:34:33 2021 From: neil at codelerity.com (Neil C Smith) Date: Wed, 17 Feb 2021 10:34:33 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210216204133.2dbb06fb@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210216152628.0992fb9a@sunflower.int.arc7.info> <20210216204133.2dbb06fb@sunflower.int.arc7.info> Message-ID: On Tue, 16 Feb 2021 at 20:41, Mark Raynsford wrote: > I've used > GStreamer outside of Java quite a bit for aggregating feeds from > network cameras... Yes, just working with a client doing exactly that - and the UI won't be using JavaFX there, in fact they're still using Swing/AWT because it's easier to attach window overlays there. > In your case, is it that you want to consume one or > more video streams from GStreamer inside a JavaFX UI? We'd be pretty > close in terms of requirements with regards to not copying across > CPU/GPU boundaries, and requiring low latency. :) Yes, that would be part of it. Although I can also see potential cases for putting aspects of a JavaFX display back into a GStreamer pipeline, for streaming, overlays, etc. > It's why I said in my original email that I > was resigned to the fact that a copy was probably going to have to > happen somewhere. Yes, the PixelBuffer issue we faced is slightly different there. In fact, in theory we don't need an extra copy on the software side. Taking GStreamer as a specific example, although it's not the only native API that works in this way, you have a bunch of buffers allocated externally from a pool. On the JavaFX side, you want to atomically swap what buffer is in use, and release the old one back to the native library, which might end up freeing the memory. Just removing all references on the JavaFX event thread isn't (wasn't?) atomic - the renderer thread might still try and access the memory to upload the data later, which might segfault. Best wishes, Neil -- Neil C Smith Codelerity Ltd. www.codelerity.com Codelerity Ltd. is a company registered in England and Wales Registered company number : 12063669 Registered office address : Office 4 219 Kensington High Street, Kensington, London, England, W8 6BD From neil at codelerity.com Wed Feb 17 11:05:48 2021 From: neil at codelerity.com (Neil C Smith) Date: Wed, 17 Feb 2021 11:05:48 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210216152628.0992fb9a@sunflower.int.arc7.info> <20210216204133.2dbb06fb@sunflower.int.arc7.info> Message-ID: On Tue, 16 Feb 2021 at 23:33, Michael Strau? wrote: > The main problem with this idea is that there is no universally available > hardware rendering backend in JavaFX. There's OpenGL on Linux and macOS, > Direct3D on Windows, and potentially a software renderer on all platforms. How is that a problem? Not all platforms support PosixFilePermissions either. I used that io -> nio2 comparison because of that similar choice of lowest denominator abstraction as opposed to an API for querying capabilities and exposing them if available. Most, if not all, of the use cases here are about interaction with libraries using native components that are either not universally available or provide platform-specific alternatives too? Incidentally, does the OpenGL renderer not work on Windows at all, or just not get used by default? Can't remember. > It is generally not safe to expose the OpenGL rendering context > that is used internally by JavaFX, because users might inadvertently change > the GL state machine. Why is that actually a problem? Surely caveat emptor has to apply here? And potentially access can be managed within scopes that require permissions, push/pop state, etc if required? Best wishes, Neil -- Neil C Smith Codelerity Ltd. www.codelerity.com Codelerity Ltd. is a company registered in England and Wales Registered company number : 12063669 Registered office address : Office 4 219 Kensington High Street, Kensington, London, England, W8 6BD From herve.girod at gmail.com Wed Feb 17 14:11:11 2021 From: herve.girod at gmail.com (Herve Girod) Date: Wed, 17 Feb 2021 15:11:11 +0100 Subject: Layering JavaFX onto an external rendering context In-Reply-To: References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210216152628.0992fb9a@sunflower.int.arc7.info> <20210216204133.2dbb06fb@sunflower.int.arc7.info> Message-ID: There is also something that we should be aware of. The external graphic context is a fragile thing. In our case, for example with OpenGL, it was very easy to create problems with the Java app which try to paint things on the context. Which can lead to crashes or artefacts. Le mer. 17 f?vr. 2021 ? 12:06, Neil C Smith a ?crit : > On Tue, 16 Feb 2021 at 23:33, Michael Strau? > wrote: > > The main problem with this idea is that there is no universally available > > hardware rendering backend in JavaFX. There's OpenGL on Linux and macOS, > > Direct3D on Windows, and potentially a software renderer on all > platforms. > > How is that a problem? Not all platforms support PosixFilePermissions > either. I used that io -> nio2 comparison because of that similar > choice of lowest denominator abstraction as opposed to an API for > querying capabilities and exposing them if available. Most, if not > all, of the use cases here are about interaction with libraries using > native components that are either not universally available or provide > platform-specific alternatives too? > > Incidentally, does the OpenGL renderer not work on Windows at all, or > just not get used by default? Can't remember. > > > It is generally not safe to expose the OpenGL rendering context > > that is used internally by JavaFX, because users might inadvertently > change > > the GL state machine. > > Why is that actually a problem? Surely caveat emptor has to apply > here? And potentially access can be managed within scopes that > require permissions, push/pop state, etc if required? > > Best wishes, > > Neil > > -- > Neil C Smith > Codelerity Ltd. > www.codelerity.com > > Codelerity Ltd. is a company registered in England and Wales > Registered company number : 12063669 > Registered office address : Office 4 219 Kensington High Street, > Kensington, London, England, W8 6BD > From ajoseph at openjdk.java.net Wed Feb 17 14:19:48 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 17 Feb 2021 14:19:48 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events Message-ID: Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. Reverting back to WebCore Timer for ScrollAnimation in Linux. ------------- Commit messages: - 8260257: [Linux] WebView no longer reacts to some mouse events Changes: https://git.openjdk.java.net/jfx/pull/404/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=404&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260257 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/404.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/404/head:pull/404 PR: https://git.openjdk.java.net/jfx/pull/404 From kcr at openjdk.java.net Wed Feb 17 16:11:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Feb 2021 16:11:45 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 14:14:35 GMT, Arun Joseph wrote: > Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. Looks good. Tested on all three platforms (although it should only affect Linux). I confirm that on Linux scrolling via the trackpad (or by clicking in the scrollbar track) now works properly. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/404 From github.com+3855776+xardif at openjdk.java.net Wed Feb 17 18:02:57 2021 From: github.com+3855776+xardif at openjdk.java.net (=?UTF-8?B?UGF3ZcWC?= =?UTF-8?B?IA==?= =?UTF-8?B?S3J1c3pjennFhHNraQ==?=) Date: Wed, 17 Feb 2021 18:02:57 GMT Subject: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again Message-ID: `Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on overlaying tooltip also kills the tooltip, so the infinite duration tooltip can be closed. ------------- Commit messages: - 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again Changes: https://git.openjdk.java.net/jfx/pull/395/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=395&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261221 Stats: 24 lines in 1 file changed: 24 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/395.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/395/head:pull/395 PR: https://git.openjdk.java.net/jfx/pull/395 From kcr at openjdk.java.net Wed Feb 17 18:53:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Feb 2021 18:53:46 GMT Subject: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again In-Reply-To: References: Message-ID: <21FZi3uUrZuc2alNFDKRev6GWSZzS7ZGPHxx-BQOWr4=.04c2d319-9734-43e8-bba8-33f46f11192d@github.com> On Fri, 5 Feb 2021 10:46:49 GMT, Pawe? Kruszczy?ski wrote: > `Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on overlaying tooltip also kills the tooltip, so the infinite duration tooltip can be closed. I'll review and test it later. This will need a unit test (or system test if a unit test is infeasible). I also left a minor formatting comment below. modules/javafx.controls/src/main/java/javafx/scene/control/Tooltip.java line 1034: > 1032: */ > 1033: private EventHandler LEAVING_HANDLER = (MouseEvent event) -> { > 1034: if( mouseInsideTooltip ) Can you reformat this to follow our code style guidelines? Add a space after the `if`, remove the spaces after `(` and before `)`, and move the opening `{` to the same line as the `if`. modules/javafx.controls/src/main/java/javafx/scene/control/Tooltip.java line 1095: > 1093: node.addEventHandler(MouseEvent.MOUSE_EXITED, LEAVING_HANDLER); > 1094: node.addEventHandler(MouseEvent.MOUSE_PRESSED, KILL_HANDLER); > 1095: t.addEventFilter( MouseEvent.MOUSE_ENTERED_TARGET, TOOLTIP_MOUSE_ENTERED ); Code style: remove spaces after `(` and before `)` here and similar method calls elsewhere. ------------- PR: https://git.openjdk.java.net/jfx/pull/395 From kcr at openjdk.java.net Wed Feb 17 18:53:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Feb 2021 18:53:46 GMT Subject: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again In-Reply-To: <21FZi3uUrZuc2alNFDKRev6GWSZzS7ZGPHxx-BQOWr4=.04c2d319-9734-43e8-bba8-33f46f11192d@github.com> References: <21FZi3uUrZuc2alNFDKRev6GWSZzS7ZGPHxx-BQOWr4=.04c2d319-9734-43e8-bba8-33f46f11192d@github.com> Message-ID: On Wed, 17 Feb 2021 18:45:28 GMT, Kevin Rushforth wrote: >> `Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on overlaying tooltip also kills the tooltip, so the infinite duration tooltip can be closed. > > I'll review and test it later. This will need a unit test (or system test if a unit test is infeasible). I also left a minor formatting comment below. One more request: Please follow the instructions [here](https://github.com/openjdk/jfx/pull/395/checks) to enable running pre-submit tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/395 From tsayao at openjdk.java.net Wed Feb 17 20:20:53 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 17 Feb 2021 20:20:53 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v10] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Turns out gravity is used! ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/30d5291e..636114b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=08-09 Stats: 21 lines in 2 files changed: 5 ins; 15 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From jhendrikx at openjdk.java.net Wed Feb 17 22:52:01 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 17 Feb 2021 22:52:01 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v7] In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix initial year in SubScene ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/185/files - new: https://git.openjdk.java.net/jfx/pull/185/files/7a685f43..fcaf2d6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/185/head:pull/185 PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Wed Feb 17 22:52:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Feb 2021 22:52:03 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v6] In-Reply-To: <-LtfVzOE5eWcqnOTG-tvHyoR10dwc21Dv77Duuvn1sM=.9211acce-aeac-4692-a5b3-35a2262382b5@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <-LtfVzOE5eWcqnOTG-tvHyoR10dwc21Dv77Duuvn1sM=.9211acce-aeac-4692-a5b3-35a2262382b5@github.com> Message-ID: On Tue, 16 Feb 2021 17:55:45 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missed null checks to fix test failure > > modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > The initial year needs to be preserved. Please restore as follows: `2013, 2021, ` Alternatively, you can just restore the previous date range of `2013, 2018, ` and let our copyright update script handle bumping the "last modified year" the next time we run it. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Wed Feb 17 22:52:03 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 17 Feb 2021 22:52:03 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v6] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <-LtfVzOE5eWcqnOTG-tvHyoR10dwc21Dv77Duuvn1sM=.9211acce-aeac-4692-a5b3-35a2262382b5@github.com> Message-ID: <2qkXjeY56Ttpe0qWVN4JgOow5gvQS2iAwQ-0_AIR-cg=.e1ee0361-560d-427f-901c-524a104ab9a4@github.com> On Tue, 16 Feb 2021 18:59:30 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. >> >> The initial year needs to be preserved. Please restore as follows: `2013, 2021, ` > > Alternatively, you can just restore the previous date range of `2013, 2018, ` and let our copyright update script handle bumping the "last modified year" the next time we run it. My mistake, I thought @arapte meant the start year should be removed from all files I touched, but didn't realize it was about a new file I created with an incorrect start year. I pushed a fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Wed Feb 17 22:57:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Feb 2021 22:57:48 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v7] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <_R6469Fr3KB4OssoHcl47rtTrIarKELvv9o9f76AAFA=.c75a0da0-1a4b-4cab-9074-bc53acef4c0b@github.com> On Wed, 17 Feb 2021 22:52:01 GMT, John Hendrikx wrote: >> This is a PoC for performance testing. >> >> It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. >> >> This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix initial year in SubScene Looks good. @arapte will need to re-approve ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/185 From arapte at openjdk.java.net Thu Feb 18 01:10:41 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 18 Feb 2021 01:10:41 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v7] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Wed, 17 Feb 2021 22:52:01 GMT, John Hendrikx wrote: >> This is a PoC for performance testing. >> >> It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. >> >> This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix initial year in SubScene Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From ebresie at gmail.com Thu Feb 18 02:16:04 2021 From: ebresie at gmail.com (Eric Bresie) Date: Wed, 17 Feb 2021 20:16:04 -0600 Subject: Layering JavaFX onto an external rendering context In-Reply-To: References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210216152628.0992fb9a@sunflower.int.arc7.info> <20210216204133.2dbb06fb@sunflower.int.arc7.info> Message-ID: There was a thread around obsolete rendering code (1) around removal of Prisim rendering and related api layers architectural elements later on. Is this relevant here? Eric (1) https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-January/028581.html On Wed, Feb 17, 2021 at 8:11 AM Herve Girod wrote: > There is also something that we should be aware of. The external graphic > context is a fragile thing. In our case, for example with OpenGL, it was > very easy to create problems with the Java app which try to paint things on > the context. Which can lead to crashes or artefacts. > > Le mer. 17 f?vr. 2021 ? 12:06, Neil C Smith a ?crit > : > > > On Tue, 16 Feb 2021 at 23:33, Michael Strau? > > wrote: > > > The main problem with this idea is that there is no universally > available > > > hardware rendering backend in JavaFX. There's OpenGL on Linux and > macOS, > > > Direct3D on Windows, and potentially a software renderer on all > > platforms. > > > > How is that a problem? Not all platforms support PosixFilePermissions > > either. I used that io -> nio2 comparison because of that similar > > choice of lowest denominator abstraction as opposed to an API for > > querying capabilities and exposing them if available. Most, if not > > all, of the use cases here are about interaction with libraries using > > native components that are either not universally available or provide > > platform-specific alternatives too? > > > > Incidentally, does the OpenGL renderer not work on Windows at all, or > > just not get used by default? Can't remember. > > > > > It is generally not safe to expose the OpenGL rendering context > > > that is used internally by JavaFX, because users might inadvertently > > change > > > the GL state machine. > > > > Why is that actually a problem? Surely caveat emptor has to apply > > here? And potentially access can be managed within scopes that > > require permissions, push/pop state, etc if required? > > > > Best wishes, > > > > Neil > > > > -- > > Neil C Smith > > Codelerity Ltd. > > www.codelerity.com > > > > Codelerity Ltd. is a company registered in England and Wales > > Registered company number : 12063669 > > Registered office address : Office 4 219 Kensington High Street, > > Kensington, London, England, W8 6BD > > > -- Eric Bresie ebresie at gmail.com From aghaisas at openjdk.java.net Thu Feb 18 09:08:47 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 18 Feb 2021 09:08:47 GMT Subject: RFR: 8261460: Incorrect CSS applied to ContextMenu on DialogPane In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 08:52:55 GMT, Abhinay Agarwal wrote: > Both DialogPane and ContextMenu have a child node with a style-class `graphic-container`. This leads to a corner case where an unwanted style is applied to ContextMenu when it is shown on a DialogPane. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/400 From ajoseph at openjdk.java.net Thu Feb 18 13:30:00 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 18 Feb 2021 13:30:00 GMT Subject: RFR: 8261927: WebKit build fails with Visual Studio 2017 Message-ID: The WebKit build fails with Visual Studio 2017. Issue: Visual Studio 2017 doesn't support if constexpr in lamda Test: Build webkit with the VS2017 compiler with and without this fix. It should fail without the fix and build with the fix. ------------- Commit messages: - 8261927: WebKit build fails with Visual Studio 2017 Changes: https://git.openjdk.java.net/jfx/pull/405/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=405&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261927 Stats: 33 lines in 1 file changed: 31 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/405.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/405/head:pull/405 PR: https://git.openjdk.java.net/jfx/pull/405 From kcr at openjdk.java.net Thu Feb 18 13:57:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Feb 2021 13:57:42 GMT Subject: RFR: 8261927: WebKit build fails with Visual Studio 2017 In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 13:25:14 GMT, Arun Joseph wrote: > The WebKit build fails with Visual Studio 2017. > > Issue: Visual Studio 2017 doesn't support if constexpr in lamda > > Test: Build webkit with the VS2017 compiler with and without this fix. It should fail without the fix and build with the fix. This is restoring a change that went into WebKit 610.1 but was lost during the upgrade to 610.2. It is a straightforward change, but would be good to get a second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/405 From kcr at openjdk.java.net Thu Feb 18 16:01:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Feb 2021 16:01:42 GMT Subject: RFR: 8261927: WebKit build fails with Visual Studio 2017 In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 13:25:14 GMT, Arun Joseph wrote: > The WebKit build fails with Visual Studio 2017. > > Issue: Visual Studio 2017 doesn't support if constexpr in lamda > > Test: Build webkit with the VS2017 compiler with and without this fix. It should fail without the fix and build with the fix. Looks good. Validated with both VS 2017 and VS 2019. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/405 From tsayao at openjdk.java.net Thu Feb 18 17:31:57 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 18 Feb 2021 17:31:57 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v11] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix centering of Stages and Dialogs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/636114b5..07219e70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=09-10 Stats: 26 lines in 1 file changed: 19 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Thu Feb 18 21:17:44 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 18 Feb 2021 21:17:44 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> Message-ID: <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> On Sun, 14 Feb 2021 22:06:34 GMT, Thiago Milczarek Sayao wrote: >> It's been pointed out about this >> https://stackoverflow.com/questions/49512491/javafx-getting-single-resize-events >> >> My tests point out that this PR causes less sizing events that the current master branch, but I also think this could be improved further. >> >> But, by the nature of X and window managers, window sizes does not account decoration frames, but javafx does (probably mimicking windows behavior). Given this information I probably could reduce further the sizing events, but not make it equivalent to windows. > > Changed to WIP to reduce sizing events. Current Status: ![image](https://user-images.githubusercontent.com/30704286/108422319-2aa0e800-7215-11eb-8b9e-8f62e7f8d553.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Thu Feb 18 21:29:58 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 18 Feb 2021 21:29:58 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v12] In-Reply-To: References: Message-ID: <7IaeHGKMIrgSe_RzDarV-0eHfWcJRKrPfcnCwZ8ipVw=.2bc43661-9d7d-4d12-a0b2-9e54ab2a7517@github.com> > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao 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: Replace the window size & positining code ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/07219e70..6766502e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=10-11 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Thu Feb 18 21:29:59 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 18 Feb 2021 21:29:59 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Thu, 18 Feb 2021 21:14:44 GMT, Thiago Milczarek Sayao wrote: >> Changed to WIP to reduce sizing events. > > Current Status: > > ![image](https://user-images.githubusercontent.com/30704286/108422319-2aa0e800-7215-11eb-8b9e-8f62e7f8d553.png) Ready to be reviewed. ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From github.com+3197675+abhinayagarwal at openjdk.java.net Fri Feb 19 12:24:44 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Fri, 19 Feb 2021 12:24:44 GMT Subject: Integrated: 8261460: Incorrect CSS applied to ContextMenu on DialogPane In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 08:52:55 GMT, Abhinay Agarwal wrote: > Both DialogPane and ContextMenu have a child node with a style-class `graphic-container`. This leads to a corner case where an unwanted style is applied to ContextMenu when it is shown on a DialogPane. This pull request has now been integrated. Changeset: f02019f6 Author: Abhinay Agarwal Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f02019f6 Stats: 107 lines in 4 files changed: 106 ins; 0 del; 1 mod 8261460: Incorrect CSS applied to ContextMenu on DialogPane Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/400 From alexsch at openjdk.java.net Fri Feb 19 14:22:54 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 19 Feb 2021 14:22:54 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen Message-ID: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> The issue is reproduced on Raspberry Pi 3 B+ with Touchscreen display. To reproduce the issue run the [ScrollPaneSample](https://bugs.openjdk.java.net/secure/attachment/93270/ScrollPaneSample.java) with Monocle: > sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=monocle -Dembedded=monocle -Dglass.platform=Monocle ScrollPaneSample An application consists of a ScrollPane with buttons. if a button is touched by a finger, moved up/down and released, the button is scrolled and the button's action is fired. This happens because Monocle generates mouse pressed, mouse dragged, scroll, mouse released events when touch events are received. Even a button is scrolled on a ScrollPane it still fires the button's action on the synthesized mouse release event. My first attempt was to add a scroll event listener to a ButtonBehavior class and disarm the button when the scroll event is received. This does work not in the case where buttons are small and scrolling buttons leads that a finger is released on the next button (the scrolling process is remained a slightly behind the touched finger so the finger is touched on one button and released on another). In this case all scroll events goes to the first button and the second button still fires its action (it does not disarmed because it does not receive scroll events). The current fix adds drag event listener to ButtonBehavior to disarm the button. Drag events goes to the touched and released buttons. Than I checked the fix on the same Raspberry Pi using GTK with touchscreen. > sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=gtk ScrollPaneSample I have not seen scroll events using GTK (even using -Dgtk.com.sun.javafx.gestures.scroll=true option), but GTK sends mouse drag events on a button touch. The mouse drag event between a button touch and release events would disarm the button in the proposed ButtonBehavior drag event handler. So I added the check if the mouse drag is synthesized. If the mouse drag is synthesized (Monocle case on touchscreen) it disarms the button, otherwise (GTK case) not. I checked the fix for the following controls placed on a ScrollPane (see [ScrollPaneControlsSample](https://bugs.openjdk.java.net/secure/attachment/93271/ScrollPaneControlsSample.java) sample) : - Fixed in corresponding behavior classes or its parents: Button, ToggleButton, CheckBox, ComboBox, ChoiceBox, ColorPicker, DatePicker, RadioButton - Works because an action is not fired on mouse release event: TextField - Does not work: Slider The Slider control does not work with the fix because it reacts not only on mouse release event but on mouse drag event as well. It requires a separate fix. I checked the Ensemble8 sample with the fix. It works with Monocle on Raspberry Pi 3B+ on Touchscreen. Scrolling the main page by a finger does not makes it to be pressed. The Ensemble8 sample does not work with GTK on Raspberry Pi 3B+ with Touchscreen. I see it generates scroll events ( it has its own [ScrollEventSynthesizer](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/src/app/java/ensemble/ScrollEventSynthesizer.java)) and action events and it can makes the Ensemble8 buttons on a ScrollPane to be pressed. ------------- Commit messages: - Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen Changes: https://git.openjdk.java.net/jfx/pull/406/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=406&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262023 Stats: 69 lines in 4 files changed: 66 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/406.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/406/head:pull/406 PR: https://git.openjdk.java.net/jfx/pull/406 From kcr at openjdk.java.net Fri Feb 19 15:58:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Feb 2021 15:58:37 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 14:19:35 GMT, Alexander Scherbatiy wrote: > The issue is reproduced on Raspberry Pi 3 B+ with Touchscreen display. > > To reproduce the issue run the [ScrollPaneSample](https://bugs.openjdk.java.net/secure/attachment/93270/ScrollPaneSample.java) with Monocle: >> sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=monocle -Dembedded=monocle -Dglass.platform=Monocle ScrollPaneSample > > > An application consists of a ScrollPane with buttons. if a button is touched by a finger, moved up/down and released, the button is scrolled and the button's action is fired. > > This happens because Monocle generates mouse pressed, mouse dragged, scroll, mouse released events when touch events are received. > Even a button is scrolled on a ScrollPane it still fires the button's action on the synthesized mouse release event. > > My first attempt was to add a scroll event listener to a ButtonBehavior class and disarm the button when the scroll event is received. > This does work not in the case where buttons are small and scrolling buttons leads that a finger is released on the next button (the scrolling process is remained a slightly behind the touched finger so the finger is touched on one button and released on another). > In this case all scroll events goes to the first button and the second button still fires its action (it does not disarmed because it does not receive scroll events). > > The current fix adds drag event listener to ButtonBehavior to disarm the button. Drag events goes to the touched and released buttons. > > Than I checked the fix on the same Raspberry Pi using GTK with touchscreen. >> sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=gtk ScrollPaneSample > > I have not seen scroll events using GTK (even using -Dgtk.com.sun.javafx.gestures.scroll=true option), but GTK sends mouse drag events on a button touch. > The mouse drag event between a button touch and release events would disarm the button in the proposed ButtonBehavior drag event handler. So I added the check if the mouse drag is synthesized. If the mouse drag is synthesized (Monocle case on touchscreen) it disarms the button, otherwise (GTK case) not. > > I checked the fix for the following controls placed on a ScrollPane (see [ScrollPaneControlsSample](https://bugs.openjdk.java.net/secure/attachment/93271/ScrollPaneControlsSample.java) sample) : > - Fixed in corresponding behavior classes or its parents: Button, ToggleButton, CheckBox, ComboBox, ChoiceBox, ColorPicker, DatePicker, RadioButton > - Works because an action is not fired on mouse release event: TextField > - Does not work: Slider > > The Slider control does not work with the fix because it reacts not only on mouse release event but on mouse drag event as well. It requires a separate fix. > > I checked the Ensemble8 sample with the fix. It works with Monocle on Raspberry Pi 3B+ on Touchscreen. Scrolling the main page by a finger does not makes it to be pressed. > > The Ensemble8 sample does not work with GTK on Raspberry Pi 3B+ with Touchscreen. I see it generates scroll events ( it has its own [ScrollEventSynthesizer](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/src/app/java/ensemble/ScrollEventSynthesizer.java)) and action events and it can makes the Ensemble8 buttons on a ScrollPane to be pressed. Can you provide an automated test for this? Since this is touching common code, what testing have you done to ensure no regressions on other platforms when not using Monocle? This will need careful review and testing. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From alexsch at openjdk.java.net Fri Feb 19 16:14:40 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 19 Feb 2021 16:14:40 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 15:56:02 GMT, Kevin Rushforth wrote: >> The issue is reproduced on Raspberry Pi 3 B+ with Touchscreen display. >> >> To reproduce the issue run the [ScrollPaneSample](https://bugs.openjdk.java.net/secure/attachment/93270/ScrollPaneSample.java) with Monocle: >>> sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=monocle -Dembedded=monocle -Dglass.platform=Monocle ScrollPaneSample >> >> >> An application consists of a ScrollPane with buttons. if a button is touched by a finger, moved up/down and released, the button is scrolled and the button's action is fired. >> >> This happens because Monocle generates mouse pressed, mouse dragged, scroll, mouse released events when touch events are received. >> Even a button is scrolled on a ScrollPane it still fires the button's action on the synthesized mouse release event. >> >> My first attempt was to add a scroll event listener to a ButtonBehavior class and disarm the button when the scroll event is received. >> This does work not in the case where buttons are small and scrolling buttons leads that a finger is released on the next button (the scrolling process is remained a slightly behind the touched finger so the finger is touched on one button and released on another). >> In this case all scroll events goes to the first button and the second button still fires its action (it does not disarmed because it does not receive scroll events). >> >> The current fix adds drag event listener to ButtonBehavior to disarm the button. Drag events goes to the touched and released buttons. >> >> Than I checked the fix on the same Raspberry Pi using GTK with touchscreen. >>> sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=gtk ScrollPaneSample >> >> I have not seen scroll events using GTK (even using -Dgtk.com.sun.javafx.gestures.scroll=true option), but GTK sends mouse drag events on a button touch. >> The mouse drag event between a button touch and release events would disarm the button in the proposed ButtonBehavior drag event handler. So I added the check if the mouse drag is synthesized. If the mouse drag is synthesized (Monocle case on touchscreen) it disarms the button, otherwise (GTK case) not. >> >> I checked the fix for the following controls placed on a ScrollPane (see [ScrollPaneControlsSample](https://bugs.openjdk.java.net/secure/attachment/93271/ScrollPaneControlsSample.java) sample) : >> - Fixed in corresponding behavior classes or its parents: Button, ToggleButton, CheckBox, ComboBox, ChoiceBox, ColorPicker, DatePicker, RadioButton >> - Works because an action is not fired on mouse release event: TextField >> - Does not work: Slider >> >> The Slider control does not work with the fix because it reacts not only on mouse release event but on mouse drag event as well. It requires a separate fix. >> >> I checked the Ensemble8 sample with the fix. It works with Monocle on Raspberry Pi 3B+ on Touchscreen. Scrolling the main page by a finger does not makes it to be pressed. >> >> The Ensemble8 sample does not work with GTK on Raspberry Pi 3B+ with Touchscreen. I see it generates scroll events ( it has its own [ScrollEventSynthesizer](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/src/app/java/ensemble/ScrollEventSynthesizer.java)) and action events and it can makes the Ensemble8 buttons on a ScrollPane to be pressed. > > Can you provide an automated test for this? > > Since this is touching common code, what testing have you done to ensure no regressions on other platforms when not using Monocle? > > This will need careful review and testing. I have Touchscreen only on Raspberry Pi so I checked the touch events only on JavaFX on arm with Monocle and GTK. I also checked the fix with ScrollPaneControlsSample on Linux and Windows with ordinary screen and using only mouse (press, release, scroll) and the sample works with and without the fix. I run all but webkit automated tests with the fix on Ubuntu `gradle test` and they passed. I will look the way to provide an automated test. I am interested if there is a better way to fix this. Handling scroll event would be straightforward (because the ScrollPane is used) but unfortunately it does not work when two controls are scrolled. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From alexsch at openjdk.java.net Fri Feb 19 16:29:40 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 19 Feb 2021 16:29:40 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 16:12:01 GMT, Alexander Scherbatiy wrote: >> Can you provide an automated test for this? >> >> Since this is touching common code, what testing have you done to ensure no regressions on other platforms when not using Monocle? >> >> This will need careful review and testing. > > I have Touchscreen only on Raspberry Pi so I checked the touch events only on JavaFX on arm with Monocle and GTK. > > I also checked the fix with ScrollPaneControlsSample on Linux and Windows with ordinary screen and using only mouse (press, release, scroll) and the sample works with and without the fix. > > I run all but webkit automated tests with the fix on Ubuntu `gradle test` and they passed. > I will look the way to provide an automated test. > > I am interested if there is a better way to fix this. Handling scroll event would be straightforward (because the ScrollPane is used) but unfortunately it does not work when two controls are scrolled. Some more details about handled events in ScrollPaneSample Monocle. Touch and release a button (press a button by touching the screen) [button behavior] MOUSE_ENTERED, Button: 2 [button behavior] MOUSE_PRESSED, Button: 2 [button behavior] MOUSE_RELEASED, Button: 2 Scroll a button: [button behavior] MOUSE_PRESSED, Button: 3 [button behavior] SCROLL, Button: 3 [button behavior] MOUSE_DRAGGED, Button: 3 [button behavior] SCROLL, Button: 3 [button behavior] MOUSE_DRAGGED, Button: 3 [button behavior] SCROLL, Button: 3 [button behavior] MOUSE_DRAGGED, Button: 3 [button behavior] SCROLL, Button: 3 [button behavior] MOUSE_DRAGGED, Button: 3 [button behavior] MOUSE_RELEASED, Button: 3 Scroll a button that the next button appears under the finger: [button behavior] MOUSE_ENTERED, Button: 5 [button behavior] MOUSE_PRESSED, Button: 5 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_DRAGGED, Button: 5 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_DRAGGED, Button: 5 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_DRAGGED, Button: 5 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_DRAGGED, Button: 5 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_DRAGGED, Button: 5 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_DRAGGED, Button: 5 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_DRAGGED, Button: 5 [button behavior] MOUSE_RELEASED, Button: 5 Note: all scroll events go to Button 4 but mouse is released on Button 5. GTK Touch and release a button (press a button by touching the screen) [button behavior] MOUSE_PRESSED, Button: 1 [button behavior] MOUSE_DRAGGED, Button: 1 [button behavior] MOUSE_DRAGGED, Button: 1 [button behavior] MOUSE_RELEASED, Button: 1 Note: mouse drag events are generated Scroll buttons by mouse (scrolling by touch does not work for me on GTK) [button behavior] MOUSE_EXITED, Button: 3 [button behavior] MOUSE_ENTERED, Button: 4 [button behavior] SCROLL, Button: 4 [button behavior] SCROLL, Button: 4 [button behavior] SCROLL, Button: 4 [button behavior] SCROLL, Button: 4 [button behavior] MOUSE_EXITED, Button: 4 [button behavior] MOUSE_ENTERED, Button: 5 ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From alexsch at openjdk.java.net Fri Feb 19 17:52:43 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 19 Feb 2021 17:52:43 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 16:26:50 GMT, Alexander Scherbatiy wrote: >> I have Touchscreen only on Raspberry Pi so I checked the touch events only on JavaFX on arm with Monocle and GTK. >> >> I also checked the fix with ScrollPaneControlsSample on Linux and Windows with ordinary screen and using only mouse (press, release, scroll) and the sample works with and without the fix. >> >> I run all but webkit automated tests with the fix on Ubuntu `gradle test` and they passed. >> I will look the way to provide an automated test. >> >> I am interested if there is a better way to fix this. Handling scroll event would be straightforward (because the ScrollPane is used) but unfortunately it does not work when two controls are scrolled. > > Some more details about handled events in ScrollPaneSample > Monocle. > > Touch and release a button (press a button by touching the screen) > [button behavior] MOUSE_ENTERED, Button: 2 > [button behavior] MOUSE_PRESSED, Button: 2 > [button behavior] MOUSE_RELEASED, Button: 2 > > Scroll a button: > [button behavior] MOUSE_PRESSED, Button: 3 > [button behavior] SCROLL, Button: 3 > [button behavior] MOUSE_DRAGGED, Button: 3 > [button behavior] SCROLL, Button: 3 > [button behavior] MOUSE_DRAGGED, Button: 3 > [button behavior] SCROLL, Button: 3 > [button behavior] MOUSE_DRAGGED, Button: 3 > [button behavior] SCROLL, Button: 3 > [button behavior] MOUSE_DRAGGED, Button: 3 > [button behavior] MOUSE_RELEASED, Button: 3 > > Scroll a button that the next button appears under the finger: > [button behavior] MOUSE_ENTERED, Button: 5 > [button behavior] MOUSE_PRESSED, Button: 5 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_DRAGGED, Button: 5 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_DRAGGED, Button: 5 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_DRAGGED, Button: 5 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_DRAGGED, Button: 5 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_DRAGGED, Button: 5 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_DRAGGED, Button: 5 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_DRAGGED, Button: 5 > [button behavior] MOUSE_RELEASED, Button: 5 > Note: all scroll events go to Button 4 but mouse is released on Button 5. > > GTK > Touch and release a button (press a button by touching the screen) > [button behavior] MOUSE_PRESSED, Button: 1 > [button behavior] MOUSE_DRAGGED, Button: 1 > [button behavior] MOUSE_DRAGGED, Button: 1 > [button behavior] MOUSE_RELEASED, Button: 1 > Note: mouse drag events are generated > > Scroll buttons by mouse (scrolling by touch does not work for me on GTK even with `-Dgtk.com.sun.javafx.gestures.scroll=true` option) > [button behavior] MOUSE_EXITED, Button: 3 > [button behavior] MOUSE_ENTERED, Button: 4 > [button behavior] SCROLL, Button: 4 > [button behavior] SCROLL, Button: 4 > [button behavior] SCROLL, Button: 4 > [button behavior] SCROLL, Button: 4 > [button behavior] MOUSE_EXITED, Button: 4 > [button behavior] MOUSE_ENTERED, Button: 5 May be it has sense to add a drag event handler (which disarms the corresponding button) to ButtonBehavior only if javafx.platform is monocle to localize the fix only for Monocle. Or add a separate property and set it by default to true on Monocle and to false otherwise. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From kcr at openjdk.java.net Fri Feb 19 20:40:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Feb 2021 20:40:45 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 17:50:01 GMT, Alexander Scherbatiy wrote: >> Some more details about handled events in ScrollPaneSample >> Monocle. >> >> Touch and release a button (press a button by touching the screen) >> [button behavior] MOUSE_ENTERED, Button: 2 >> [button behavior] MOUSE_PRESSED, Button: 2 >> [button behavior] MOUSE_RELEASED, Button: 2 >> >> Scroll a button: >> [button behavior] MOUSE_PRESSED, Button: 3 >> [button behavior] SCROLL, Button: 3 >> [button behavior] MOUSE_DRAGGED, Button: 3 >> [button behavior] SCROLL, Button: 3 >> [button behavior] MOUSE_DRAGGED, Button: 3 >> [button behavior] SCROLL, Button: 3 >> [button behavior] MOUSE_DRAGGED, Button: 3 >> [button behavior] SCROLL, Button: 3 >> [button behavior] MOUSE_DRAGGED, Button: 3 >> [button behavior] MOUSE_RELEASED, Button: 3 >> >> Scroll a button that the next button appears under the finger: >> [button behavior] MOUSE_ENTERED, Button: 5 >> [button behavior] MOUSE_PRESSED, Button: 5 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_DRAGGED, Button: 5 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_DRAGGED, Button: 5 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_DRAGGED, Button: 5 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_DRAGGED, Button: 5 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_DRAGGED, Button: 5 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_DRAGGED, Button: 5 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_DRAGGED, Button: 5 >> [button behavior] MOUSE_RELEASED, Button: 5 >> Note: all scroll events go to Button 4 but mouse is released on Button 5. >> >> GTK >> Touch and release a button (press a button by touching the screen) >> [button behavior] MOUSE_PRESSED, Button: 1 >> [button behavior] MOUSE_DRAGGED, Button: 1 >> [button behavior] MOUSE_DRAGGED, Button: 1 >> [button behavior] MOUSE_RELEASED, Button: 1 >> Note: mouse drag events are generated >> >> Scroll buttons by mouse (scrolling by touch does not work for me on GTK even with `-Dgtk.com.sun.javafx.gestures.scroll=true` option) >> [button behavior] MOUSE_EXITED, Button: 3 >> [button behavior] MOUSE_ENTERED, Button: 4 >> [button behavior] SCROLL, Button: 4 >> [button behavior] SCROLL, Button: 4 >> [button behavior] SCROLL, Button: 4 >> [button behavior] SCROLL, Button: 4 >> [button behavior] MOUSE_EXITED, Button: 4 >> [button behavior] MOUSE_ENTERED, Button: 5 > > May be it has sense to add a drag event handler (which disarms the corresponding button) to ButtonBehavior only if javafx.platform is set to monocle to localize the fix only for Monocle? Or add a separate property and set it by default to true on Monocle and to false otherwise? That would certainly be a safer (more targeted) fix. I'd like to hear from @jperedadnr and @johanvos on this. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From hjohn at xs4all.nl Fri Feb 19 21:53:51 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 19 Feb 2021 22:53:51 +0100 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210215134043.09b57608@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> Message-ID: <00d3b348-d9fa-446a-89dd-f71e4f69f6ad@xs4all.nl> I don't know if this is useful or not, but I've pretty succesfully combined a JavaFX UI with the MPV video player (also VLC), without resorting to any kind of frame copying. It basically involves finding the HWND id (or Window id on Linux) of a JavaFX Stage, then telling MPV / VLC to render directly to that window. A 2nd (transparent where needed) window is then used to render the JavaFX content. A top-level Stage is created, for which we find out the HWND. Here we allow MPV to render its content. The top-level Stage also has a child stage, which tracks the size and location of the main stage. This stage is transparent and contains a JavaFX Scene that can be given a (partially) transparent background made to show the content of the main stage. Child stages automatically appear on top of their parent stage. Here's a screenshot of how that looks, where the control panel, the timer, clock and pause indicator are JavaFX and the background is MPV: https://github.com/hjohn/MediaSystem-v2/blob/master/screenshot-5.jpg Although this works pretty well, there are some limitations. It may not work as well on Linux or Mac, as I rarely test this solution there. Secondly, you cannot do any kind of special effects on the MPV content (like a blur or something). --John On 15/02/2021 14:40, Mark Raynsford wrote: > Hello! > > I'd like to use JavaFX for the UI of an application that will > involve rendering using an existing Vulkan-based renderer. For the sake > of example, assume that the application looks and behaves a bit like > the Unreal Engine 4 editing tools. Here's an example of those: > > https://www.youtube.com/watch?v=2UowdJetXwA > > My understanding right now is that there isn't direct support in > JavaFX for building this kind of application, and the primary reason > for this is that there's a sort of conceptual wrestling match for > control of a platform-specific rendering context here. For example: > > * A JavaFX application will tell JavaFX to open a new window, > and the JavaFX implementation will do all of the > OS-windowing-system-specific things to achieve this, and will > also set up a system-specific rendering context depending on > what the underlying platform is (OpenGL, DirectX, Metal, etc). > JavaFX then translates input such as mouse and keyboard events > from OS-specific types to the platform-independent JavaFX types > so that the application can process them. > > * A typical Vulkan application will ask something analogous to > the GLFW library to open a new window, and set up a rendering > context. The GLFW library then translates input such as mouse and > keyboard events from OS-specific types to generic GLFW event > types, and the Vulkan application (probably) translates these > into its own application-specific event types for processing. > > Obviously, in a given application, we're limited to having either > one of these things happen, but realistically not both. > > The current approach (as of JavaFX 14) seems to be to use the > PixelBuffer API in order to provide a CPU-side bridge between > JavaFX and whatever rendering system is being used for external 3D > rendering. In other words, this is the expected setup: > > 1. A JavaFX application will tell JavaFX to open a new window, > and JavaFX will do all of the system-specific work required > as described previously. > > 2. The application will then tell a library such as GLFW to > create an _offscreen_ rendering context, perhaps configuring > Vulkan or OpenGL. > > 3. The application, at the end of each frame, copies the contents > of the offscreen rendering context's framebuffer into a PixelBuffer > instance to be displayed inside a JavaFX UI. > > This, as far as I know, works correctly. The main complaint with > this is that it pays a pretty heavy price: There's one framebuffer-sized > copy operation from the GPU to the CPU (in order to read the required > pixels), and then another framebuffer-sized copy operation back from > the CPU to the GPU (either when writing into the PixelBuffer, or when > JavaFX renders the contents of that PixelBuffer to the screen). > > My understanding is that it's essentially necessary to do these two > rather expensive copying operations merely because JavaFX can't and > won't expose the underlying rendering context it uses for its own UI > rendering, and it also can't be expected to talk to whatever other > rendering system the application might be using. The problem is > essentially "we have these two systems both using the GPU, but they > don't know each other and therefore we can't write code to get > memory from one to the other without going via the CPU". > > Is this an accurate picture of the situation? > > As someone working exclusively with Vulkan, I can arrange to have > the GPU copy the framebuffer into host-visible (not necessarily > host-resident, but host _visible_) memory at the end of each frame. > It's a little sad to have to actually copy that memory over the PCI bus > just to immediately copy it back again, though. Is there no design we > could come up with that would allow for at worst a simple GPU ? GPU > copy? I'm resigned to the fact that a copying operation is probably > going to happen _somewhere_, but it'd be nice if we could avoid a > rather expensive and redundant GPU ? CPU ? GPU copy. > From github.com+1413266+jgneff at openjdk.java.net Fri Feb 19 22:56:40 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 19 Feb 2021 22:56:40 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 20:37:46 GMT, Kevin Rushforth wrote: >> May be it has sense to add a drag event handler (which disarms the corresponding button) to ButtonBehavior only if javafx.platform is set to monocle to localize the fix only for Monocle? Or add a separate property and set it by default to true on Monocle and to false otherwise? > > That would certainly be a safer (more targeted) fix. I'd like to hear from @jperedadnr and @johanvos on this. In case it helps, I reproduced the problem on a Kobo Touch e-reader with an e-paper display. The expected result isn't explicit in the bug report, so just to confirm, there should be no button action events received at all when you touch any of the buttons only for the purpose of scrolling the entire pane, right? $ sudo $HOME/opt/jdk-15.0.2+7/bin/java \ --module-path=$HOME/lib/armv6hf-sdk/lib --add-modules=javafx.controls \ -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ -Dmonocle.input.18/0/0/0.minX=0 -Dmonocle.input.18/0/0/0.maxX=800 \ -Dmonocle.input.18/0/0/0.minY=0 -Dmonocle.input.18/0/0/0.maxY=600 ScrollPaneSample Button is pressed: 3 Button is pressed: 3 Button is pressed: 5 Button is pressed: 5 Button is pressed: 5 It's subtle, though. With a bit of practice, I can scroll the pane without causing the action events by swiping my finger quickly over the buttons. It's only when I linger for a fraction of a second too long on one of the buttons that one or more of the events are fired. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From alexsch at openjdk.java.net Sat Feb 20 07:43:40 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Sat, 20 Feb 2021 07:43:40 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 22:54:01 GMT, John Neffenger wrote: > The expected result isn't explicit in the bug report, so just to confirm, there should be no button action events received at all when you touch any of the buttons only for the purpose of scrolling the entire pane, right? Could you run Ensemble8 demo on the a Kobo Touch e-reader? On my Raspberry Pi with Touchscreen I run Ensemble8, slide a main page to scroll and the program opens the sample where my finger is released. It prevents me to scroll Ensemble8 main page to bottom. To avoid this I need to use places without samples to scroll the main page down. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From jhendrikx at openjdk.java.net Sat Feb 20 14:14:44 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 20 Feb 2021 14:14:44 GMT Subject: Integrated: 8252935: Add treeShowing listener only when needed In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Fri, 17 Apr 2020 08:06:23 GMT, John Hendrikx wrote: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. This pull request has now been integrated. Changeset: 47338244 Author: John Hendrikx Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/47338244 Stats: 771 lines in 8 files changed: 653 ins; 109 del; 9 mod 8252935: Add treeShowing listener only when needed Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From github.com+1413266+jgneff at openjdk.java.net Sat Feb 20 19:45:39 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 20 Feb 2021 19:45:39 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Sat, 20 Feb 2021 07:41:02 GMT, Alexander Scherbatiy wrote: >> In case it helps, I reproduced the problem on a Kobo Touch e-reader with an e-paper display. The expected result isn't explicit in the bug report, so just to confirm, there should be no button action events received at all when you touch any of the buttons only for the purpose of scrolling the entire pane, right? >> >> $ sudo $HOME/opt/jdk-15.0.2+7/bin/java \ >> --module-path=$HOME/lib/armv6hf-sdk/lib --add-modules=javafx.controls \ >> -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ >> -Dmonocle.input.18/0/0/0.minX=0 -Dmonocle.input.18/0/0/0.maxX=800 \ >> -Dmonocle.input.18/0/0/0.minY=0 -Dmonocle.input.18/0/0/0.maxY=600 ScrollPaneSample >> Button is pressed: 3 >> Button is pressed: 3 >> Button is pressed: 5 >> Button is pressed: 5 >> Button is pressed: 5 >> >> It's subtle, though. With a bit of practice, I can scroll the pane without causing the action events by swiping my finger quickly over the buttons. It's only when I linger for a fraction of a second too long on one of the buttons that one or more of the events are fired. > >> The expected result isn't explicit in the bug report, so just to confirm, there should be no button action events received at all when you touch any of the buttons only for the purpose of scrolling the entire pane, right? > > Could you run Ensemble8 demo on the a Kobo Touch e-reader? > > On my Raspberry Pi with Touchscreen I run Ensemble8, slide a main page to scroll and the program opens the sample where my finger is released. It prevents me to scroll Ensemble8 main page to bottom. To avoid this I need to use places without samples to scroll the main page down. > Could you run Ensemble8 demo on the Kobo Touch e-reader? Yes, I see the problem you describe using the Ensemble8 app on my Kobo e-reader. Thanks. And thank you for having the courage to fix this! ?? I also tested the changes in this pull request. I notice an improvement in that there are less "Button is pressed" action events received, but I still see the error. I added calls to `System.err.println` right before any calls to `arm()`, `fire()`, or `disarm()` in each of the mouse event handlers in `ButtonBehavior.java`. I swiped the buttons four times to scroll the pane. The output is shown below. The first three worked. The fourth one failed by firing Button 12 twice. The new method is marked with the prefix `***`. $ sudo $HOME/opt/jdk-15.0.2+7/bin/java \ --module-path=$HOME/lib/armv6hf-sdk/lib --add-modules=javafx.controls \ -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ -Dmonocle.input.18/0/0/0.minX=0 -Dmonocle.input.18/0/0/0.maxX=800 \ -Dmonocle.input.18/0/0/0.minY=0 -Dmonocle.input.18/0/0/0.maxY=600 \ ScrollPaneSample --> Arming button (mouse pressed) ... --> Disarming button (mouse exited) ... --> Arming button (mouse pressed) ... --> Disarming button (mouse exited) ... --> Arming button (mouse pressed) ... *** Disarming button (mouse dragged) ... --> Arming button (mouse pressed) ... --> Firing and disarming button (mouse released) ... Button is pressed: 12 --> Arming button (mouse pressed) ... --> Firing and disarming button (mouse released) ... Button is pressed: 12 --> Arming button (mouse pressed) ... *** Disarming button (mouse dragged) ... The trace below shows a similar test but this time with the system property `monocle.input.traceEvents` set to `true`. (There is also the property `monocle.input.traceEvents.verbose`, but I don't find the extra information helpful.) In this case, the first two swipes worked, and the third one failed. $ sudo $HOME/opt/jdk-15.0.2+7/bin/java \ --module-path=$HOME/lib/armv6hf-sdk/lib --add-modules=javafx.controls \ -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ -Dmonocle.input.18/0/0/0.minX=0 -Dmonocle.input.18/0/0/0.maxX=800 \ -Dmonocle.input.18/0/0/0.minY=0 -Dmonocle.input.18/0/0/0.maxY=600 \ -Dmonocle.input.traceEvents=true ScrollPaneSample traceEvent: Set MouseState[x=400,y=300,wheel=0,buttonsPressed=IntSet[]] traceEvent: Set TouchState[1,TouchState.Point[id=1,x=238,y=448]] traceEvent: Set MouseState[x=238,y=448,wheel=0,buttonsPressed=IntSet[212]] traceEvent: Set TouchState[1,TouchState.Point[id=1,x=253,y=110]] traceEvent: Set MouseState[x=253,y=110,wheel=0,buttonsPressed=IntSet[212]] traceEvent: Set TouchState[0] traceEvent: Set MouseState[x=253,y=110,wheel=0,buttonsPressed=IntSet[]] --> Arming button (mouse pressed) ... --> Disarming button (mouse exited) ... traceEvent: Set TouchState[1,TouchState.Point[id=1,x=209,y=450]] traceEvent: Set MouseState[x=209,y=450,wheel=0,buttonsPressed=IntSet[212]] --> Arming button (mouse pressed) ... traceEvent: Set TouchState[1,TouchState.Point[id=1,x=209,y=450]] traceEvent: Set TouchState[1,TouchState.Point[id=1,x=229,y=262]] traceEvent: Set MouseState[x=229,y=262,wheel=0,buttonsPressed=IntSet[212]] *** Disarming button (mouse dragged) ... traceEvent: Set TouchState[1,TouchState.Point[id=1,x=235,y=238]] traceEvent: Set MouseState[x=235,y=238,wheel=0,buttonsPressed=IntSet[212]] traceEvent: Set TouchState[1,TouchState.Point[id=1,x=265,y=109]] traceEvent: Set MouseState[x=265,y=109,wheel=0,buttonsPressed=IntSet[212]] traceEvent: Set TouchState[0] traceEvent: Set MouseState[x=265,y=109,wheel=0,buttonsPressed=IntSet[]] traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=403]] traceEvent: Set MouseState[x=260,y=403,wheel=0,buttonsPressed=IntSet[212]] --> Arming button (mouse pressed) ... traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=403]] traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=403]] traceEvent: Set TouchState[0] traceEvent: Set MouseState[x=260,y=403,wheel=0,buttonsPressed=IntSet[]] --> Firing and disarming button (mouse released) ... Button is pressed: 10 traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=400]] traceEvent: Set MouseState[x=260,y=400,wheel=0,buttonsPressed=IntSet[212]] traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=142]] traceEvent: Set MouseState[x=260,y=142,wheel=0,buttonsPressed=IntSet[212]] traceEvent: Set TouchState[0] traceEvent: Set MouseState[x=260,y=142,wheel=0,buttonsPressed=IntSet[]] --> Arming button (mouse pressed) ... *** Disarming button (mouse dragged) ... I find that any movement after touching a button will cause it to fire, even without lifting my finger. I don't think the button action should fire unless I lift my finger off the button from the same location or very near to where I first touched it. Can you reproduce the error I'm seeing? Hold your finger on a button. Then roll your finger back and forth while keeping contact. Then release the button. Android does nothing when I do that on a button, and it seems to fire an event only when I release my finger very close to where I first touched it. With Monocle, though, I can fire a hundred action events just by rolling my finger back and forth on the button without ever releasing it. It could be the sensitivity of my touch panel. The panel itself is double the resolution of the display, which is why I have to add all those `monocle.input` properties to set the correct 800 ? 600 touch points to match the pixel resolution. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From ghb at openjdk.java.net Sun Feb 21 09:26:41 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Sun, 21 Feb 2021 09:26:41 GMT Subject: RFR: 8261927: WebKit build fails with Visual Studio 2017 In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 13:25:14 GMT, Arun Joseph wrote: > The WebKit build fails with Visual Studio 2017. > > Issue: Visual Studio 2017 doesn't support if constexpr in lambda > > Test: Build webkit with the VS2017 compiler with and without this fix. It should fail without the fix and build with the fix. Compiled and verified on VS 2017. Changes looks good to me. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/405 From ajoseph at openjdk.java.net Sun Feb 21 14:37:45 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Sun, 21 Feb 2021 14:37:45 GMT Subject: Integrated: 8261927: WebKit build fails with Visual Studio 2017 In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 13:25:14 GMT, Arun Joseph wrote: > The WebKit build fails with Visual Studio 2017. > > Issue: Visual Studio 2017 doesn't support if constexpr in lambda > > Test: Build webkit with the VS2017 compiler with and without this fix. It should fail without the fix and build with the fix. This pull request has now been integrated. Changeset: 9e42eea4 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/9e42eea4 Stats: 33 lines in 1 file changed: 31 ins; 0 del; 2 mod 8261927: WebKit build fails with Visual Studio 2017 Reviewed-by: kcr, ghb ------------- PR: https://git.openjdk.java.net/jfx/pull/405 From fastegal at openjdk.java.net Mon Feb 22 15:03:14 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 22 Feb 2021 15:03:14 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners Message-ID: Changes in Lambda..Handler: - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners - added java doc - added tests Changes in SkinBase - added api (and implementation delegating to the handler) - copied java doc from the change listener un/register methods - added tests to verify that the new (and old) api is indeed delegating to the handler Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) ------------- Commit messages: - 8258777: SkinBase: add api to un-/register invalidation-/listChange Changes: https://git.openjdk.java.net/jfx/pull/409/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258777 Stats: 970 lines in 6 files changed: 946 ins; 9 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From ghb at openjdk.java.net Mon Feb 22 15:16:46 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Mon, 22 Feb 2021 15:16:46 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 14:14:35 GMT, Arun Joseph wrote: > Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. Looks good to me. Verified on Ubuntu 20.04 ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/404 From tsayao at openjdk.java.net Mon Feb 22 16:09:10 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 22 Feb 2021 16:09:10 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v13] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Default to 320x200 if no size is assigned ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/6766502e..0c89a4da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=11-12 Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From kevin.rushforth at oracle.com Mon Feb 22 17:34:39 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Feb 2021 09:34:39 -0800 Subject: Bulk request to backport 12 fixes to 11-dev for 11.0.11 Message-ID: <2149fb0b-566f-164c-192a-eb9fb4b84fa1@oracle.com> Hi Johan, I request approval to backport the following 12 bug fixes to 11-dev for FX 11.0.11: JDK-8254049: Update WebView to public suffix list 2020-04-24 JDK-8259635: Update to 610.2 version of WebKit JDK-8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows JDK-8254836: Cherry pick GTK WebKit 2.30.3 changes JDK-8261927: WebKit build fails with Visual Studio 2017 JDK-8202990: javafx webview css filter property with display scaling JDK-8242861: Update ImagePattern to apply SVG pattern transforms JDK-8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina JDK-8257897: Fix webkit build for XCode 12 JDK-8253356: JavaFX Terminology Refresh JDK-8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs JDK-8213135: HTMLEditorTest.checkStyleProperty fails intermittently Thanks. -- Kevin From kcr at openjdk.java.net Mon Feb 22 20:32:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Feb 2021 20:32:43 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 14:58:45 GMT, Jeanette Winzenburg wrote: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Not yet reviewed. All of the new API methods need to have an `@since 17` javadoc tag. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 250: > 248: * @param observable the observable to observe for invalidation events > 249: * @param consumer the consumer > 250: */ Add `@since 17` javadoc tag. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 269: > 267: * {@link #registerInvalidationListener(Observable, Consumer)}. If no consumers have been registered on this > 268: * property, null will be returned. > 269: * @since 9 Need to change `9` to `17`. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 285: > 283: * @param observableList the observable list to observe for list change events > 284: * @param consumer the consumer > 285: */ Add `@since 17` javadoc tag. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 305: > 303: * {@link #registerListChangeListener(ObservableList, Consumer)}. If no consumers have been registered on this > 304: * list, null will be returned. > 305: * @since 9 Need to change `9` to `17`. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From johan.vos at gluonhq.com Tue Feb 23 10:45:59 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 23 Feb 2021 11:45:59 +0100 Subject: Bulk request to backport 12 fixes to 11-dev for 11.0.11 In-Reply-To: <2149fb0b-566f-164c-192a-eb9fb4b84fa1@oracle.com> References: <2149fb0b-566f-164c-192a-eb9fb4b84fa1@oracle.com> Message-ID: Approved. On Mon, Feb 22, 2021 at 6:34 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the following 12 bug fixes to 11-dev for > FX 11.0.11: > > JDK-8254049: Update WebView to public suffix list 2020-04-24 > JDK-8259635: Update to 610.2 version of WebKit > JDK-8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test > fails on Windows > JDK-8254836: Cherry pick GTK WebKit 2.30.3 changes > JDK-8261927: WebKit build fails with Visual Studio 2017 > > JDK-8202990: javafx webview css filter property with display scaling > JDK-8242861: Update ImagePattern to apply SVG pattern transforms > JDK-8233678: [macos 10.15] System menu bar does not work initially on > macOS Catalina > JDK-8257897: Fix webkit build for XCode 12 > JDK-8253356: JavaFX Terminology Refresh > JDK-8242361: JavaFX Web View crashes with Segmentation Fault, when HTML > contains Data-URIs > JDK-8213135: HTMLEditorTest.checkStyleProperty fails intermittently > > Thanks. > > -- Kevin > > From aghaisas at openjdk.java.net Tue Feb 23 11:00:47 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 23 Feb 2021 11:00:47 GMT Subject: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 10:46:49 GMT, Pawe? Kruszczy?ski wrote: > `Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on overlaying tooltip also kills the tooltip, so the infinite duration tooltip can be closed. modules/javafx.controls/src/main/java/javafx/scene/control/Tooltip.java line 862: > 860: private boolean hideOnExit; > 861: private boolean cssForced = false; > 862: private boolean mouseInsideTooltip = true; Default value of this member should be false. This boolean indicates a state where mouse is inside a Tooltip - it cannot be assumed true to begin with. ------------- PR: https://git.openjdk.java.net/jfx/pull/395 From fastegal at openjdk.java.net Tue Feb 23 11:16:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 23 Feb 2021 11:16:42 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners In-Reply-To: References: Message-ID: <_2yWgSpILRQG-MruiR64N3Y6wawkAOnv9wyFfsmHtA4=.a92079fc-76f8-4857-a267-71a672501063@github.com> On Mon, 22 Feb 2021 20:25:42 GMT, Kevin Rushforth wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 269: > >> 267: * {@link #registerInvalidationListener(Observable, Consumer)}. If no consumers have been registered on this >> 268: * property, null will be returned. >> 269: * @since 9 > > Need to change `9` to `17`. darn .. bloody c&p ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Tue Feb 23 12:06:08 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 23 Feb 2021 12:06:08 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: fixed missing/incorrect @since tags in new api doc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/da0820a9..a342eba7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Tue Feb 23 12:08:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Feb 2021 12:08:45 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 15:13:55 GMT, Guru Hb wrote: >> Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. >> >> Reverting back to WebCore Timer for ScrollAnimation in Linux. > > Looks good to me. Verified on Ubuntu 20.04 As discussed offline, an automated test would be helpful to ensure no future regression. ------------- PR: https://git.openjdk.java.net/jfx/pull/404 From rlichten at openjdk.java.net Tue Feb 23 15:35:47 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 23 Feb 2021 15:35:47 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned Message-ID: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Reverting to the old way of showing the context menu but with application of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct size measurement of the menu. ------------- Commit messages: - 8261840: Submenus close to screen borders are no longer repositioned Changes: https://git.openjdk.java.net/jfx/pull/410/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=410&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261840 Stats: 58 lines in 1 file changed: 5 ins; 40 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/410.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/410/head:pull/410 PR: https://git.openjdk.java.net/jfx/pull/410 From kcr at openjdk.java.net Tue Feb 23 16:16:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Feb 2021 16:16:44 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger wrote: > Reverting to the old way of showing the context menu but with application > of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct > size measurement of the menu. modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 250: > 248: getScene().setNodeOrientation(anchor.getEffectiveNodeOrientation()); > 249: if (getScene().getStylesheets().isEmpty()) { > 250: getScene().getStylesheets().setAll(anchor.getScene().getStylesheets()); I need to verify this, but I presume that the `Scene` of the `ContextMenu` is something that is created by JavaFX (as opposed to something that can be set by the application)? If so, then this might be an OK fix, but we will need to ensure that there are no side effects of doing this. ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From github.com+1413266+jgneff at openjdk.java.net Tue Feb 23 17:29:56 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Feb 2021 17:29:56 GMT Subject: RFR: 8262236: Configure Gradle checksum verification Message-ID: The recent supply-chain attacks in the news are making me nervous! ?? The Gradle 6.3 distribution is the only software on my OpenJFX build system that doesn't come from an Ubuntu package or a GitHub repository. Ubuntu uses digital signatures to authenticate each package, and Git uses a secure hash algorithm to ensure the integrity of each file, but there is no such check of the Gradle distribution before running it. During my OpenJFX builds, Gradle is downloaded from a Cloudflare server through an HTTPS proxy server, and there's no guarantee that it's the same file as the one published by the Gradle developers. This pull requests adds the additional step of verifying the Gradle distribution on the build system before extracting its archive and running it. We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. ------------- Commit messages: - Configure Gradle checksum verification Changes: https://git.openjdk.java.net/jfx/pull/411/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=411&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262236 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/411.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/411/head:pull/411 PR: https://git.openjdk.java.net/jfx/pull/411 From kcr at openjdk.java.net Tue Feb 23 17:50:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Feb 2021 17:50:45 GMT Subject: RFR: 8262236: Configure Gradle checksum verification In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 17:25:47 GMT, John Neffenger wrote: > The recent supply-chain attacks in the news are making me nervous! ?? > > The Gradle 6.3 distribution is the only software on my OpenJFX build system that doesn't come from an Ubuntu package or a GitHub repository. Ubuntu uses digital signatures to authenticate each package, and Git uses a secure hash algorithm to ensure the integrity of each file, but there is no such check of the Gradle distribution before running it. During my OpenJFX builds, Gradle is downloaded from a Cloudflare server through an HTTPS proxy server, and there's no guarantee that it's the same file as the one published by the Gradle developers. > > This pull requests adds the additional step of verifying the Gradle distribution on the build system before extracting its archive and running it. > > We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. I presume that just adding the checksum will enable the validation? This sounds like a _very_ good idea. I'll review / test it. > We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. Feel free to file a bug and create a PR, if you are interested. I agree that this sounds like a good idea. ------------- PR: https://git.openjdk.java.net/jfx/pull/411 From pbansal at openjdk.java.net Tue Feb 23 17:55:43 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 23 Feb 2021 17:55:43 GMT Subject: RFR: 8260468: Wrong behavior of LocalDateTimeStringConverter [v2] In-Reply-To: References: Message-ID: <7SvZW6RZMqBqzH29HFvxzCWTXY64_nAQfbSKH_WlYYk=.84f4836a-ee4a-49df-81b4-f2083936bca5@github.com> On Wed, 10 Feb 2021 02:24:57 GMT, Nir Lisker wrote: >> Fixes a mutability issue for `LocalDateTimeStringConverter` (and `LocalDateStringConverter`) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made: >> >> * The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class. >> * The chronology field value does not change anymore when there is an exception due to inability to format the date. >> * Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand. >> >> Added a test that fails without this patch. The test creates a converter with an explicit `Chronology` and `null` parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Removed printing and narrowed the exception looks ok to me ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/393 From nlisker at openjdk.java.net Tue Feb 23 18:05:42 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 23 Feb 2021 18:05:42 GMT Subject: Integrated: 8260468: Wrong behavior of LocalDateTimeStringConverter In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 20:01:10 GMT, Nir Lisker wrote: > Fixes a mutability issue for `LocalDateTimeStringConverter` (and `LocalDateStringConverter`) where the chronology can change during the lifetime of the instance and cause an inconsistent state. The following changes were made: > > * The input is now formatted and parsed directly with the formatter and parser (which are configured with a chronology) without the chronology field value of the class. > * The chronology field value does not change anymore when there is an exception due to inability to format the date. > * Logging on failed formatting was removed as it did not seem useful. The formatter will throw the same exception that the chronology field does anyway, so there is not much use to catching the exception before hand. > > Added a test that fails without this patch. The test creates a converter with an explicit `Chronology` and `null` parser and formatter. The default formatter that is created with the given chronology formats a legal date (with respect to the chronology) to a string, which the parser should be able to convert back to a date. However, by forcing an exception in the formatting process using an illegal date, the chronology changes, and now when the parser is used it is configured with the new chronology and it can't parse the string correctly. This pull request has now been integrated. Changeset: e25d39b0 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/e25d39b0 Stats: 44 lines in 2 files changed: 15 ins; 25 del; 4 mod 8260468: Wrong behavior of LocalDateTimeStringConverter Reviewed-by: kcr, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/393 From github.com+1413266+jgneff at openjdk.java.net Tue Feb 23 18:46:44 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Feb 2021 18:46:44 GMT Subject: RFR: 8262236: Configure Gradle checksum verification In-Reply-To: References: Message-ID: <2Yw8ep-mTceBlNMt_YzU1E37E_pMGNQEHFtTXp-XAlE=.d1a74426-9804-4796-b530-28807dbd9c41@github.com> On Tue, 23 Feb 2021 17:45:53 GMT, Kevin Rushforth wrote: > I presume that just adding the checksum will enable the validation? It does in my tests. See the section "Steps to Reproduce" in the bug report for details. It would be nice to see a message that the distribution was validated successfully, but I can't find any command option to make the Gradle Wrapper do that. ------------- PR: https://git.openjdk.java.net/jfx/pull/411 From kcr at openjdk.java.net Tue Feb 23 19:00:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Feb 2021 19:00:40 GMT Subject: RFR: 8262236: Configure Gradle checksum verification In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 17:25:47 GMT, John Neffenger wrote: > The recent supply-chain attacks in the news are making me nervous! ?? > > The Gradle 6.3 distribution is the only software on my OpenJFX build system that doesn't come from an Ubuntu package or a GitHub repository. Ubuntu uses digital signatures to authenticate each package, and Git uses a secure hash algorithm to ensure the integrity of each file, but there is no such check of the Gradle distribution before running it. During my OpenJFX builds, Gradle is downloaded from a Cloudflare server through an HTTPS proxy server, and there's no guarantee that it's the same file as the one published by the Gradle developers. > > This pull requests adds the additional step of verifying the Gradle distribution on the build system before extracting its archive and running it. > > We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. Looks good. I confirmed that the checksum is correct, and that a bad checksum will fail the build. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/411 From github.com+1413266+jgneff at openjdk.java.net Tue Feb 23 19:00:40 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Feb 2021 19:00:40 GMT Subject: RFR: 8262236: Configure Gradle checksum verification In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 17:48:08 GMT, Kevin Rushforth wrote: > > We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. > > Feel free to file a bug and create a PR, if you are interested. I agree that this sounds like a good idea. Isn't this configured directly through GitHub rather than with a pull request? Once that GitHub Action is added, I was thinking of following up with a pull request that upgrades the Gradle Wrapper to version 6.3. The older wrapper is probably fine, but I think we should keep the Wrapper at the same version as the distribution it downloads. For example, when I followed the instructions for [Verifying the integrity of the Gradle Wrapper JAR](https://docs.gradle.org/current/userguide/gradle_wrapper.html#wrapper_checksum_verification) in the OpenJFX repository, it failed. Only after a brief panic did I reverse the check and discovered that we're still using the older Gradle 4.8 wrapper. ------------- PR: https://git.openjdk.java.net/jfx/pull/411 From kcr at openjdk.java.net Tue Feb 23 19:07:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Feb 2021 19:07:40 GMT Subject: RFR: 8262236: Configure Gradle checksum verification In-Reply-To: References: Message-ID: <7RAzPPrnaBdjhti88RPNJjjlAY1Z_0A9bm8xgvXMLcw=.a293838d-9907-48af-ab11-c9ecf06035db@github.com> On Tue, 23 Feb 2021 18:57:59 GMT, Kevin Rushforth wrote: >> The recent supply-chain attacks in the news are making me nervous! ?? >> >> The Gradle 6.3 distribution is the only software on my OpenJFX build system that doesn't come from an Ubuntu package or a GitHub repository. Ubuntu uses digital signatures to authenticate each package, and Git uses a secure hash algorithm to ensure the integrity of each file, but there is no such check of the Gradle distribution before running it. During my OpenJFX builds, Gradle is downloaded from a Cloudflare server through an HTTPS proxy server, and there's no guarantee that it's the same file as the one published by the Gradle developers. >> >> This pull requests adds the additional step of verifying the Gradle distribution on the build system before extracting its archive and running it. >> >> We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. > > Looks good. I confirmed that the checksum is correct, and that a bad checksum will fail the build. > > > > > We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. > > > > > > Feel free to file a bug and create a PR, if you are interested. I agree that this sounds like a good idea. > > Isn't this configured directly through GitHub rather than with a pull request? My reading of it [here](https://github.com/marketplace/actions/gradle-wrapper-validation#add-to-an-existing-workflow) is that we would add this action as a step to our workflow script, which is in [.github/workflows/submit.yml](https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml). > Once that GitHub Action is added, I was thinking of following up with a pull request that upgrades the Gradle Wrapper to version 6.3. The older wrapper is probably fine, but I think we should keep the Wrapper at the same version as the distribution it downloads. As you noticed, I generally haven't done that when updating gradle versions, but I can see the value in doing so. Since the gradle wrapper is a third-party file that needs to be checked into the repo, someone from Oracle needs to integrate it. As long as it's not causing any problems, I think I'd rather wait until the next time this comes up. ------------- PR: https://git.openjdk.java.net/jfx/pull/411 From github.com+1413266+jgneff at openjdk.java.net Tue Feb 23 19:17:39 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Feb 2021 19:17:39 GMT Subject: RFR: 8262236: Configure Gradle checksum verification In-Reply-To: <7RAzPPrnaBdjhti88RPNJjjlAY1Z_0A9bm8xgvXMLcw=.a293838d-9907-48af-ab11-c9ecf06035db@github.com> References: <7RAzPPrnaBdjhti88RPNJjjlAY1Z_0A9bm8xgvXMLcw=.a293838d-9907-48af-ab11-c9ecf06035db@github.com> Message-ID: On Tue, 23 Feb 2021 19:04:47 GMT, Kevin Rushforth wrote: > My reading of it [here](https://github.com/marketplace/actions/gradle-wrapper-validation#add-to-an-existing-workflow) is that we would add this action as a step to our workflow script, which is in [.github/workflows/submit.yml](https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml). Thanks, Kevin. I'll look into it and follow up with a bug report and pull request. Maybe I'll even add a commit with a bogus Gradle Wrapper to the pull request for testing, which we can then remove. > I think I'd rather wait until the next time this comes up. That's fine by me. ------------- PR: https://git.openjdk.java.net/jfx/pull/411 From github.com+1413266+jgneff at openjdk.java.net Tue Feb 23 19:38:40 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Feb 2021 19:38:40 GMT Subject: Integrated: 8262236: Configure Gradle checksum verification In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 17:25:47 GMT, John Neffenger wrote: > The recent supply-chain attacks in the news are making me nervous! ?? > > The Gradle 6.3 distribution is the only software on my OpenJFX build system that doesn't come from an Ubuntu package or a GitHub repository. Ubuntu uses digital signatures to authenticate each package, and Git uses a secure hash algorithm to ensure the integrity of each file, but there is no such check of the Gradle distribution before running it. During my OpenJFX builds, Gradle is downloaded from a Cloudflare server through an HTTPS proxy server, and there's no guarantee that it's the same file as the one published by the Gradle developers. > > This pull requests adds the additional step of verifying the Gradle distribution on the build system before extracting its archive and running it. > > We might also consider adding the [Gradle Wrapper Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) GitHub Action to the OpenJFX repository. This pull request has now been integrated. Changeset: dc342d33 Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/dc342d33 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8262236: Configure Gradle checksum verification Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/411 From ajoseph at openjdk.java.net Wed Feb 24 07:11:57 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 24 Feb 2021 07:11:57 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v2] In-Reply-To: References: Message-ID: > Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add system test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/404/files - new: https://git.openjdk.java.net/jfx/pull/404/files/480c0d98..903093ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=404&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=404&range=00-01 Stats: 161 lines in 3 files changed: 160 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/404.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/404/head:pull/404 PR: https://git.openjdk.java.net/jfx/pull/404 From jvos at openjdk.java.net Wed Feb 24 08:25:45 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 24 Feb 2021 08:25:45 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v2] In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 07:11:57 GMT, Arun Joseph wrote: >> Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. >> >> Reverting back to WebCore Timer for ScrollAnimation in Linux. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Add system test Great. The test fails before and succeeds after the patch. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/404 From ajoseph at openjdk.java.net Wed Feb 24 12:54:57 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 24 Feb 2021 12:54:57 GMT Subject: RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails Message-ID: Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). Fix: Re-introduce the initial layout delay. ------------- Commit messages: - Add comment - 8260165: CSSFilterTest.testCSSFilterRendering system test fails Changes: https://git.openjdk.java.net/jfx/pull/408/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=408&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260165 Stats: 8 lines in 2 files changed: 6 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/408.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/408/head:pull/408 PR: https://git.openjdk.java.net/jfx/pull/408 From kcr at openjdk.java.net Wed Feb 24 13:04:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Feb 2021 13:04:42 GMT Subject: RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 11:55:00 GMT, Arun Joseph wrote: > Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). > > Fix: Re-introduce the initial layout delay. This seems a safe enough fix to restore the layout delay that was removed in WebKit 610.2 (and which has caused a regression). Are there any drawbacks to doing this? ------------- PR: https://git.openjdk.java.net/jfx/pull/408 From ajoseph at openjdk.java.net Wed Feb 24 13:34:42 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 24 Feb 2021 13:34:42 GMT Subject: RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 13:01:50 GMT, Kevin Rushforth wrote: >> Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). >> >> Fix: Re-introduce the initial layout delay. > > This seems a safe enough fix to restore the layout delay that was removed in WebKit 610.2 (and which has caused a regression). Are there any drawbacks to doing this? The only drawback would be layout is calculated in the next updateContent cycle instead of right after loading the first page, which is same as before WebKit 610.2. This would only cause a delay of a few milliseconds (~10 ms for this test). ------------- PR: https://git.openjdk.java.net/jfx/pull/408 From kcr at openjdk.java.net Wed Feb 24 13:38:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Feb 2021 13:38:41 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v2] In-Reply-To: References: Message-ID: <6TUClxZmhjqaeb0spc1lAZ408fRFnltynFa2ne_LGdc=.418edc86-15b4-4ebe-b930-c4e5c52800a7@github.com> On Wed, 24 Feb 2021 07:11:57 GMT, Arun Joseph wrote: >> Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. >> >> Reverting back to WebCore Timer for ScrollAnimation in Linux. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Add system test The new test looks good, although in order to make it pass on my slower Ubuntu 20.04 VM, I had to increase the sleep time to 500 ms and also add a sleep after the focus latch and before the scroll. See below. tests/system/src/test/java/test/javafx/scene/web/WebPageTest.java line 135: > 133: > 134: assertTrue("Timeout when waiting for focus change ", Util.await(webViewStateLatch)); > 135: I needed to add a `sleep(500)` here. tests/system/src/test/java/test/javafx/scene/web/WebPageTest.java line 142: > 140: }); > 141: > 142: Util.sleep(100); I needed to change this to `sleep(500)` ------------- PR: https://git.openjdk.java.net/jfx/pull/404 From kcr at openjdk.java.net Wed Feb 24 14:06:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Feb 2021 14:06:45 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v2] In-Reply-To: <6TUClxZmhjqaeb0spc1lAZ408fRFnltynFa2ne_LGdc=.418edc86-15b4-4ebe-b930-c4e5c52800a7@github.com> References: <6TUClxZmhjqaeb0spc1lAZ408fRFnltynFa2ne_LGdc=.418edc86-15b4-4ebe-b930-c4e5c52800a7@github.com> Message-ID: On Wed, 24 Feb 2021 13:35:33 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Add system test > > The new test looks good, although in order to make it pass on my slower Ubuntu 20.04 VM, I had to increase the sleep time to 500 ms and also add a sleep after the focus latch and before the scroll. See below. I did a little more experimenting, and the important one on my Linux VM system is the addition of the 500 ms sleep between the await on the latch and initiating the scroll. I could leave the other delay at 100 ms and it still passes for me. It may be best to increase that latter sleep to 500 anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/404 From ajoseph at openjdk.java.net Wed Feb 24 15:33:00 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 24 Feb 2021 15:33:00 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v3] In-Reply-To: References: Message-ID: > Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add sleep ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/404/files - new: https://git.openjdk.java.net/jfx/pull/404/files/903093ac..aea26961 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=404&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=404&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/404.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/404/head:pull/404 PR: https://git.openjdk.java.net/jfx/pull/404 From ajoseph at openjdk.java.net Wed Feb 24 15:33:01 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 24 Feb 2021 15:33:01 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v2] In-Reply-To: <6TUClxZmhjqaeb0spc1lAZ408fRFnltynFa2ne_LGdc=.418edc86-15b4-4ebe-b930-c4e5c52800a7@github.com> References: <6TUClxZmhjqaeb0spc1lAZ408fRFnltynFa2ne_LGdc=.418edc86-15b4-4ebe-b930-c4e5c52800a7@github.com> Message-ID: On Wed, 24 Feb 2021 13:33:39 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Add system test > > tests/system/src/test/java/test/javafx/scene/web/WebPageTest.java line 135: > >> 133: >> 134: assertTrue("Timeout when waiting for focus change ", Util.await(webViewStateLatch)); >> 135: > > I needed to add a `sleep(500)` here. I've used `Util.sleep(1000)` instead to make it similar to the other system web tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/404 From kcr at openjdk.java.net Wed Feb 24 16:02:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Feb 2021 16:02:44 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v3] In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 15:33:00 GMT, Arun Joseph wrote: >> Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. >> >> Reverting back to WebCore Timer for ScrollAnimation in Linux. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Add sleep Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/404 From jvos at openjdk.java.net Wed Feb 24 16:10:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 24 Feb 2021 16:10:42 GMT Subject: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v3] In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 15:33:00 GMT, Arun Joseph wrote: >> Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. >> >> Reverting back to WebCore Timer for ScrollAnimation in Linux. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Add sleep Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/404 From kcr at openjdk.java.net Wed Feb 24 16:13:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Feb 2021 16:13:42 GMT Subject: RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 11:55:00 GMT, Arun Joseph wrote: > Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). > > Fix: Re-introduce the initial layout delay. Looks good. Tested on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/408 From kcr at openjdk.java.net Wed Feb 24 16:34:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Feb 2021 16:34:42 GMT Subject: RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 16:10:44 GMT, Kevin Rushforth wrote: >> Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). >> >> Fix: Re-introduce the initial layout delay. > > Looks good. Tested on all three platforms. @johanvos @guruhb can one of you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/408 From ajoseph at openjdk.java.net Wed Feb 24 16:36:44 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 24 Feb 2021 16:36:44 GMT Subject: Integrated: 8260257: [Linux] WebView no longer reacts to some mouse events In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 14:14:35 GMT, Arun Joseph wrote: > Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. This pull request has now been integrated. Changeset: dc91f64b Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/dc91f64b Stats: 170 lines in 5 files changed: 169 ins; 0 del; 1 mod 8260257: [Linux] WebView no longer reacts to some mouse events Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/404 From rob.nikander at gmail.com Thu Feb 25 14:18:15 2021 From: rob.nikander at gmail.com (Rob Nikander) Date: Thu, 25 Feb 2021 08:18:15 -0600 Subject: font color fringes on macOS, not a priority? Message-ID: Hi, Last year, I wanted to use JavaFX for a project, but did not because the font rendering on macOS looked bad compared to native apps. I was following this bug: https://bugs.openjdk.java.net/browse/JDK-8236689 . It was created over a year ago and recently its ?Fix version" was pushed back from 16 to 17. The way that bug is titled (?non-retina?) makes me wonder: do people realize that this is effecting even retina screens on macOS? I have a 2020 MacBook Pro and the JavaFX fonts have color fringes. I?d like to write a cross platform desktop app, but I need the text rendering to be as good as native. Maybe time to give up and write some Swift code, or a web app (ugh). Rob From john at status6.com Thu Feb 25 17:38:46 2021 From: john at status6.com (John Neffenger) Date: Thu, 25 Feb 2021 09:38:46 -0800 Subject: font color fringes on macOS, not a priority? In-Reply-To: References: Message-ID: <308df1e5-ed89-9a21-6b0b-c4058655bd9c@status6.com> On 2/25/21 6:18 AM, Rob Nikander wrote: > The way that bug is titled (?non-retina?) makes me wonder: do people realize that this is effecting even retina screens on macOS? Yeah, font bugs like this are frustrating. Both JavaFX[1] and the JDK[2] had the same problem on Linux for years. It can be an uphill battle to get them fixed, especially when they concern anti-aliasing, hinting, or sub-pixel rendering. I found one very effective trick: magnify by eight! I think that should be a requirement for any font bug reports. I want to fix this bug, but that shouldn't stop anyone else from fixing it first. I just haven't gotten around to it yet, and I never debugged Java or native code on macOS before, so I have a lot to learn. Those earlier font fixes taught me that if you can write and debug Java application code, you can write and debug code in JavaFX and the JDK, too. So you might consider trying to fix it yourself. When successful, it's like gaining a superpower. ?? John [1] https://github.com/javafxports/openjdk-jfx/issues/229 [2] https://github.com/jgneff/openjdk-freetype From john at status6.com Thu Feb 25 21:26:03 2021 From: john at status6.com (John Neffenger) Date: Thu, 25 Feb 2021 13:26:03 -0800 Subject: font color fringes on macOS, not a priority? In-Reply-To: References: Message-ID: On 2/25/21 6:18 AM, Rob Nikander wrote: > The way that bug is titled (?non-retina?) makes me wonder: do people realize that this is effecting even retina screens on macOS? I updated the bug report to remove the "on non-retina" in the title, along with magnified details of the four original screenshots for proof: macOS 10.15 Catalina: LCD text renders badly https://bugs.openjdk.java.net/browse/JDK-8236689 I'm starting to think the best fix might be to remove sub-pixel rendering entirely, just as Apple did, at least for JavaFX on macOS. John From almatvee at openjdk.java.net Fri Feb 26 04:02:54 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 26 Feb 2021 04:02:54 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon Message-ID: - Added support to compile media on arm. - libffi is based on 3.3. ------------- Commit messages: - 8257895: Allow building of JavaFX media libs for Apple Silicon Changes: https://git.openjdk.java.net/jfx/pull/412/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=412&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257895 Stats: 2856 lines in 17 files changed: 2821 ins; 5 del; 30 mod Patch: https://git.openjdk.java.net/jfx/pull/412.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/412/head:pull/412 PR: https://git.openjdk.java.net/jfx/pull/412 From jvos at openjdk.java.net Fri Feb 26 14:00:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 26 Feb 2021 14:00:41 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Sat, 20 Feb 2021 19:43:01 GMT, John Neffenger wrote: >>> The expected result isn't explicit in the bug report, so just to confirm, there should be no button action events received at all when you touch any of the buttons only for the purpose of scrolling the entire pane, right? >> >> Could you run Ensemble8 demo on the a Kobo Touch e-reader? >> >> On my Raspberry Pi with Touchscreen I run Ensemble8, slide a main page to scroll and the program opens the sample where my finger is released. It prevents me to scroll Ensemble8 main page to bottom. To avoid this I need to use places without samples to scroll the main page down. > >> Could you run Ensemble8 demo on the Kobo Touch e-reader? > > Yes, I see the problem you describe using the Ensemble8 app on my Kobo e-reader. Thanks. And thank you for having the courage to fix this! ?? > > I also tested the changes in this pull request. I notice an improvement in that there are less "Button is pressed" action events received, but I still see the error. I added calls to `System.err.println` right before any calls to `arm()`, `fire()`, or `disarm()` in each of the mouse event handlers in `ButtonBehavior.java`. I swiped the buttons four times to scroll the pane. The output is shown below. The first three worked. The fourth one failed by firing Button 12 twice. > > The new method is marked with the prefix `***`. > > $ sudo $HOME/opt/jdk-15.0.2+7/bin/java \ > --module-path=$HOME/lib/armv6hf-sdk/lib --add-modules=javafx.controls \ > -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ > -Dmonocle.input.18/0/0/0.minX=0 -Dmonocle.input.18/0/0/0.maxX=800 \ > -Dmonocle.input.18/0/0/0.minY=0 -Dmonocle.input.18/0/0/0.maxY=600 \ > ScrollPaneSample > > --> Arming button (mouse pressed) ... > --> Disarming button (mouse exited) ... > > --> Arming button (mouse pressed) ... > --> Disarming button (mouse exited) ... > > --> Arming button (mouse pressed) ... > *** Disarming button (mouse dragged) ... > > --> Arming button (mouse pressed) ... > --> Firing and disarming button (mouse released) ... > Button is pressed: 12 > --> Arming button (mouse pressed) ... > --> Firing and disarming button (mouse released) ... > Button is pressed: 12 > --> Arming button (mouse pressed) ... > *** Disarming button (mouse dragged) ... > > The trace below shows a similar test but this time with the system property `monocle.input.traceEvents` set to `true`. (There is also the property `monocle.input.traceEvents.verbose`, but I don't find the extra information helpful.) In this case, the first two swipes worked, and the third one failed. > > $ sudo $HOME/opt/jdk-15.0.2+7/bin/java \ > --module-path=$HOME/lib/armv6hf-sdk/lib --add-modules=javafx.controls \ > -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ > -Dmonocle.input.18/0/0/0.minX=0 -Dmonocle.input.18/0/0/0.maxX=800 \ > -Dmonocle.input.18/0/0/0.minY=0 -Dmonocle.input.18/0/0/0.maxY=600 \ > -Dmonocle.input.traceEvents=true ScrollPaneSample > traceEvent: Set MouseState[x=400,y=300,wheel=0,buttonsPressed=IntSet[]] > > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=238,y=448]] > traceEvent: Set MouseState[x=238,y=448,wheel=0,buttonsPressed=IntSet[212]] > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=253,y=110]] > traceEvent: Set MouseState[x=253,y=110,wheel=0,buttonsPressed=IntSet[212]] > traceEvent: Set TouchState[0] > traceEvent: Set MouseState[x=253,y=110,wheel=0,buttonsPressed=IntSet[]] > --> Arming button (mouse pressed) ... > --> Disarming button (mouse exited) ... > > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=209,y=450]] > traceEvent: Set MouseState[x=209,y=450,wheel=0,buttonsPressed=IntSet[212]] > --> Arming button (mouse pressed) ... > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=209,y=450]] > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=229,y=262]] > traceEvent: Set MouseState[x=229,y=262,wheel=0,buttonsPressed=IntSet[212]] > *** Disarming button (mouse dragged) ... > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=235,y=238]] > traceEvent: Set MouseState[x=235,y=238,wheel=0,buttonsPressed=IntSet[212]] > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=265,y=109]] > traceEvent: Set MouseState[x=265,y=109,wheel=0,buttonsPressed=IntSet[212]] > traceEvent: Set TouchState[0] > traceEvent: Set MouseState[x=265,y=109,wheel=0,buttonsPressed=IntSet[]] > > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=403]] > traceEvent: Set MouseState[x=260,y=403,wheel=0,buttonsPressed=IntSet[212]] > --> Arming button (mouse pressed) ... > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=403]] > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=403]] > traceEvent: Set TouchState[0] > traceEvent: Set MouseState[x=260,y=403,wheel=0,buttonsPressed=IntSet[]] > --> Firing and disarming button (mouse released) ... > Button is pressed: 10 > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=400]] > traceEvent: Set MouseState[x=260,y=400,wheel=0,buttonsPressed=IntSet[212]] > traceEvent: Set TouchState[1,TouchState.Point[id=1,x=260,y=142]] > traceEvent: Set MouseState[x=260,y=142,wheel=0,buttonsPressed=IntSet[212]] > traceEvent: Set TouchState[0] > traceEvent: Set MouseState[x=260,y=142,wheel=0,buttonsPressed=IntSet[]] > --> Arming button (mouse pressed) ... > *** Disarming button (mouse dragged) ... > > I find that any movement after touching a button will cause it to fire, even without lifting my finger. I don't think the button action should fire unless I lift my finger off the button from the same location or very near to where I first touched it. > > Can you reproduce the error I'm seeing? Hold your finger on a button. Then roll your finger back and forth while keeping contact. Then release the button. Android does nothing when I do that on a button, and it seems to fire an event only when I release my finger very close to where I first touched it. With Monocle, though, I can fire a hundred action events just by rolling my finger back and forth on the button without ever releasing it. > > It could be the sensitivity of my touch panel. The panel itself is double the resolution of the display, which is why I have to add all those `monocle.input` properties to set the correct 800 ? 600 touch points to match the pixel resolution. There is similar behavior on Android (using Monocle too), when scrolling through a list, as that may result in the list item to be "selected". The scrolled node receives a button_pressed event as well. The main difficulty I have is: What is the expected behavior? I would like to seen consistent behavior between the GTK and Monocle implementations, but the hardest part to me is getting a clear definition on what we would expect (as that is then what we can test). ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From rob.nikander at gmail.com Fri Feb 26 14:56:33 2021 From: rob.nikander at gmail.com (Rob Nikander) Date: Fri, 26 Feb 2021 08:56:33 -0600 Subject: font color fringes on macOS, not a priority? In-Reply-To: References: Message-ID: <5505E5E3-1166-4889-AF93-211CA43E9548@gmail.com> > On Feb 25, 2021, at 3:26 PM, John Neffenger wrote: > > Those earlier font fixes taught me that if you can write and debug Java application code, you can write and debug code in JavaFX and the JDK, too. So you might consider trying to fix it yourself. When successful, it's like gaining a superpower. ?? I wonder if I can get a dev setup with a quick edit-compile-run cycle, or if the compile step takes a long time. I may give it a shot in the next few days. If I can change C code, and test it in Java without waiting forever, maybe I could get into this. > I'm starting to think the best fix might be to remove sub-pixel rendering entirely, just as Apple did, at least for JavaFX on macOS. Do you know if the color fringes are being produced by the Core Text rendering to a bitmap, and not the subsequent OpenGL phase? Core Text is still alive and well on macOS, but OpenGL is deprecated in favor of Metal. From ghb at openjdk.java.net Fri Feb 26 15:32:40 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 26 Feb 2021 15:32:40 GMT Subject: RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 11:55:00 GMT, Arun Joseph wrote: > Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). > > Fix: Re-introduce the initial layout delay. Tested on Linux and Windows, Looks good to me. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/408 From ajoseph at openjdk.java.net Fri Feb 26 15:46:40 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 26 Feb 2021 15:46:40 GMT Subject: Integrated: 8260165: CSSFilterTest.testCSSFilterRendering system test fails In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 11:55:00 GMT, Arun Joseph wrote: > Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). > > Fix: Re-introduce the initial layout delay. This pull request has now been integrated. Changeset: 8ad18c32 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/8ad18c32 Stats: 8 lines in 2 files changed: 6 ins; 2 del; 0 mod 8260165: CSSFilterTest.testCSSFilterRendering system test fails Reviewed-by: kcr, ghb ------------- PR: https://git.openjdk.java.net/jfx/pull/408 From github.com+1413266+jgneff at openjdk.java.net Fri Feb 26 16:50:43 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 26 Feb 2021 16:50:43 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 26 Feb 2021 13:58:01 GMT, Johan Vos wrote: > What is the expected behavior? I think that's why I never raised the issue. I let the bug train me to avoid it! For better or for worse, I think the only answer to your question is whatever Android and iOS do. After playing around with the JavaFX test buttons on the touchscreen, I finally tried the same thing on my Android phone, and there it worked just as one would expect. I didn't have to be *careful* at all. As far as I can tell, on Android the rule is simple: the button fires only when it's released within a very small radius of where it was first touched. Furthermore, the button never fires at all if it was ever dragged at all. I'll try on an old iPad next. ------------- PR: https://git.openjdk.java.net/jfx/pull/406 From john at status6.com Fri Feb 26 17:39:17 2021 From: john at status6.com (John Neffenger) Date: Fri, 26 Feb 2021 09:39:17 -0800 Subject: font color fringes on macOS, not a priority? In-Reply-To: <5505E5E3-1166-4889-AF93-211CA43E9548@gmail.com> References: <5505E5E3-1166-4889-AF93-211CA43E9548@gmail.com> Message-ID: On 2/26/21 6:56 AM, Rob Nikander wrote: > I wonder if I can get a dev setup with a quick edit-compile-run cycle, or if the compile step takes a long time. The builds for macOS are taking just over 11 minutes on GitHub. To speed that up, I do my development in a project with only the JavaFX Graphics module, linked below, and then use a guest machine to do a full build for amd64 and armhf. Things go pretty quickly with the help of 'rsync'. Not sure whether the same setup would help on macOS. JavaFX Graphics https://github.com/jgneff/javafx-graphics > Do you know if the color fringes are being produced by the Core Text rendering to a bitmap, and not the subsequent OpenGL phase? No, I don't. I also don't know how the JavaFX code for macOS relates to what's going on with the Lanai Project: Lanai Project https://wiki.openjdk.java.net/display/lanai/Main Regarding my suggestion of removing the sub-pixel rendering, it would be good to check how many Macs out there are still running on macOS 10.13 High Sierra and earlier. Apple removed its sub-pixel rendering and switched to grayscale anti-aliasing in macOS 10.14 Mojave. John From kevin.rushforth at oracle.com Fri Feb 26 18:02:11 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 Feb 2021 10:02:11 -0800 Subject: font color fringes on macOS, not a priority? In-Reply-To: References: <5505E5E3-1166-4889-AF93-211CA43E9548@gmail.com> Message-ID: <6d813790-a02c-bca8-7bb8-7db3af07a021@oracle.com> Part of that 11+ minutes of the macOS build on GitHub Actions (which starts from a clean machine) is downloading and installing the JDK and other tools (gradle, etc), and cloning the repo. Also, incremental builds are much faster after the first one. So even if you do a full build once, subsequent builds for the debug-edit-build cycle is pretty quick. Phil might want to comment about the possibility of eliminating sub-pixel (LCD) text entirely on macOS. If it does turn out to be something worth doing, I note that macOS 10.13 is pretty old by now, so that wouldn't be a compelling reason to hold off (as long as it doesn't regress horribly). As for Project Lanai, that isn't related to this issue. Lanai is an implementation of the Java2D back end on Apple's Metal API (as an alternative to OpenGL). See JEP 382 [1] for more information. We will very likely do the same for FX starting in the not-too-distant future. -- Kevin [1] https://openjdk.java.net/jeps/382 On 2/26/2021 9:39 AM, John Neffenger wrote: > On 2/26/21 6:56 AM, Rob Nikander wrote: >> I wonder if I can get a dev setup with a quick edit-compile-run >> cycle, or if the compile step takes a long time. > > The builds for macOS are taking just over 11 minutes on GitHub. > > To speed that up, I do my development in a project with only the > JavaFX Graphics module, linked below, and then use a guest machine to > do a full build for amd64 and armhf. Things go pretty quickly with the > help of 'rsync'. Not sure whether the same setup would help on macOS. > > JavaFX Graphics > https://github.com/jgneff/javafx-graphics > >> Do you know if the color fringes are being produced by the Core Text >> rendering to a bitmap, and not the subsequent OpenGL phase? > > No, I don't. I also don't know how the JavaFX code for macOS relates > to what's going on with the Lanai Project: > > Lanai Project > https://wiki.openjdk.java.net/display/lanai/Main > > Regarding my suggestion of removing the sub-pixel rendering, it would > be good to check how many Macs out there are still running on macOS > 10.13 High Sierra and earlier. Apple removed its sub-pixel rendering > and switched to grayscale anti-aliasing in macOS 10.14 Mojave. > > John