From fastegal at openjdk.java.net Sun Mar 1 12:26:19 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 1 Mar 2020 12:26:19 GMT Subject: [Rev 02] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Sat, 15 Feb 2020 15:01:47 GMT, Kevin Rushforth wrote: >> The pull request has been updated with 1 additional commit. > > @kleopatra is right about the need to handle the case where the orientation of a node changes. As for the test, I think the idea of parameterizing it with LTR, RTL is good. I haven't reviewed it in detail, but added one minor suggestion for you to consider. After digging a bit, a couple of notes (not entirely certain if this here is the correct place for them?) **Changing existing tests** Don't know what the culture in the fx context is, but: personally I prefer to not touch existing methods. Obvious reason is that I might break a test or test the wrong thing or tweak it in any way that makes it rather useless. An example of testing the wrong thingy on changing a test method might be test_rt18488_selectToLeft (guard against [JDK-8120174](https://bugs.openjdk.java.net/browse/JDK-8120174)). The report describes the misbehaviour as 1. select last cell in a row 2. extend selection by keyboard backwards (that is to decreasing column indices), making cellMin selected 3. shrink selection by keyboard by one cell (that is increasing column index) 4. expected: cellMin unselected, actual (bug) cellMin still selected the block added for the rtl variant does test something else for 2. has no effect because it's already the upper boundary 3. nothing to shrink, instead it extends by one 4. nothing unselected **Parameterized Tests** repeating earlier comments (just to have it here for reading convenience): the goal of the parameterization is to make the test code (mostly) unaware of the parameters. In particular, if I feel the need for conditional test blocks - either in setup or in assert blocks - _on the parameters_, I often find out that something went wrong with the factoring. Not written in stone, though, could be me only :) **Alternative** My preference would be to not touch TableViewKeyInputTest at all, but to add a new test class exclusively for testing orientation-dependent horizontal navigation by keyboard. It should focus on what's actually changed, that is the _basic_ left/right/extend/shrink etc navigation and dynamic change of those. The class can be parameterized, the parameter being a triplet of orientation and forward/backward keys. The emphasis on _basic_ is intentional: I think that there is no need to cover all existing tests against bug reports nor more evolved navigation. Given all basic mappings are working as expected, everything built on top should work as well - might be wrong or there might be exceptions :) For a bit of clarity - hopefully- of what I mean, I put togeter a raw poc example [TableViewHorizontalArrowsTest](https://github.com/kleopatra/jfx/blob/experiment-tableview-navigation-rtl-bug-8235480/modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java)) ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From jpereda at openjdk.java.net Sun Mar 1 18:19:57 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 1 Mar 2020 18:19:57 GMT Subject: RFR: 8240262: iOS refresh rate is capped to 30 Hz Message-ID: There is a hardcoded limit to refresh the glass view on iOS at a half rate of the native refresh rate. This PR removes that limit. Since the default value for `frameInterval ` is 1 (which implies refreshing at the same rate as allowed by the device), doing `setFrameInterval:1` is not necessary. What's more, this method is [deprecated](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1621231-frameinterval?language=objc). ------------- Commits: - 892f6d52: Remove refreshment at half rate Changes: https://git.openjdk.java.net/jfx/pull/130/files Webrev: https://webrevs.openjdk.java.net/jfx/130/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240262 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/130.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/130/head:pull/130 PR: https://git.openjdk.java.net/jfx/pull/130 From jpereda at openjdk.java.net Sun Mar 1 19:46:09 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 1 Mar 2020 19:46:09 GMT Subject: RFR: 8240265: iOS: Unnecessary logging on pinch gestures Message-ID: <2M-W750a64IzrQZaUXOTLvNjop9APej7Eg0MziXRa_8=.0a6d0e2e-0379-44c1-ac0c-61b25cf6b18a@github.com> This PR removes unnecessary logging of the scale value during a pinch gesture on iOS ------------- Commits: - 2cfa3c7b: Remove unnecessary logging Changes: https://git.openjdk.java.net/jfx/pull/131/files Webrev: https://webrevs.openjdk.java.net/jfx/131/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240265 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/131.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/131/head:pull/131 PR: https://git.openjdk.java.net/jfx/pull/131 From arapte at openjdk.java.net Mon Mar 2 05:56:01 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 Mar 2020 05:56:01 GMT Subject: [Rev 01] RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: <7JHzTXfVEGxv2IT_vmXU099ZCv_qBHElImRP5q_6Feo=.46239464-e16f-4f2d-95f5-1b8aa5d3b039@github.com> Message-ID: On Fri, 28 Feb 2020 08:03:45 GMT, Nir Lisker wrote: >> I finished my review and tested this on all platforms. It looks good to me. >> >> The only comment I have is the one inline comment I left in `KeyCodeMap.java` about renaming the "put" method to something with "entry" in the name to reflect what it now does. > >> The only comment I have is the one inline comment I left in KeyCodeMap.java about renaming the "put" method to something with "entry" in the name to reflect what it now does. > > Will fix it after Ambarish reviews. The fix looks good to me too, Shall approve once PR is updated for Kevin's comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/104 From arapte at openjdk.java.net Mon Mar 2 05:58:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 Mar 2020 05:58:06 GMT Subject: [Rev 02] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case In-Reply-To: References: Message-ID: <1uZDOuzphuLCGkCRi_IwGWHizk2CPaqSoRArOJR6LY8=.cd062174-1f3c-4566-990b-13715e789c03@github.com> On Wed, 26 Feb 2020 22:17:31 GMT, Kevin Rushforth wrote: >> The pull request has been updated with a new target base due to a merge or a rebase. > > Marked as reviewed by kcr (Lead). @johanvos , @arajkumar Could you please take a re-look at the updated PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/54 From github.com+6702882+dannygonzalez at openjdk.java.net Mon Mar 2 08:33:59 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Mon, 2 Mar 2020 08:33:59 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: On Thu, 27 Feb 2020 03:17:14 GMT, yosbits wrote: >>> >>> >>> I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. >> >> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal code does it .. > > In use cases where a large number of listeners are being discarded, it may be better to first consider changing the design to receive event notifications on nodes whose listener registrations are not frequently discarded. > Hmm .. personally, I would consider changing such a basic (and probably highly optimized) implementation used all over the framework is a very high risk change that at the worst outcome would detoriate internal and external code. So before going that lane, I would try - as you probably have, just me not seeing it :) - to tackle the problem from the other end: > > > I know that in our application, the **thousands of listeners** unregistering when using a TableView was stalling the JavaFX thread. > > .. sounds like a lot. Any idea, where exactly they come into play? I did start to look at why there were so many change listeners unregistering but felt that would take a deeper understanding of the architecture and design decisions of JavaFX scene graph and I didn't have that time to invest. I do know that there are thousands of them unregistering in a TableView and unregistering them is a bottleneck for the JavaFX thread. There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow. To get our application usable I profiled the code and saw this unregistering as a major bottleneck, hence why I looked at this more obvious solution. I'm happy to look at the problem from the other angle and happy to listen to suggestions from people with more experience of the design and architecture but tackling the problem from the perspective of re-architecting the behaviour of listeners in the scene graph would be more work than I could feasibly take on. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Mon Mar 2 09:31:25 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 Mar 2020 09:31:25 GMT Subject: RFR: 8240287: SelectedItemsReadOnlyObservableList cleanup: remove unused code. Message-ID: The below member variables and method of class SelectedItemsReadOnlyObservableList are not required anymore. Variables: itemsList, itemsListChanged, itemsListChange, itemsListListener. Method: setItemsList These members were added when this class was created for [JDK-8154216](https://bugs.openjdk.java.net/browse/JDK-8154216). But after the fix for [JDK-8152396](https://bugs.openjdk.java.net/browse/JDK-8152396), these class members are not required. This change also fixes the leak issue : [JDK-8237926](https://bugs.openjdk.java.net/browse/JDK-8237926) Verification: No build and test failures. ------------- Commits: - c859a929: [WIP]8240287: SelectedItemsReadOnlyObservableList cleanup: remove unused code. Changes: https://git.openjdk.java.net/jfx/pull/132/files Webrev: https://webrevs.openjdk.java.net/jfx/132/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240287 Stats: 37 lines in 3 files changed: 0 ins; 37 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/132/head:pull/132 PR: https://git.openjdk.java.net/jfx/pull/132 From fkirmaier at openjdk.java.net Mon Mar 2 10:09:57 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 2 Mar 2020 10:09:57 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> Message-ID: <6OhviYNgO41FTyjthrckuI_FiLCNAbBOvAmhc6kkNOI=.94f9d129-d32c-4616-afbf-0c4aecce14db@github.com> > Hi everyone, > > ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 > > The fix itself is quite straight forward. > It basically just removed the listener which causes the leak. > > The unit-test for the fix is a bit more complicated. > > I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks. > I think there are many places in the JavaFX-codebase that could highly benefit from this library. > It could also simplify many of the already existing unit tests. > It makes testing for memory-leaks readably and reliable. > It would also be possible to just copy the code of the library into the JavaFX-codebase. > It only contains a single class. > > I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. The pull request has been updated with 1 additional commit. ------------- Added commits: - 740fe2a1: JDK-8236259 Changes: - all: https://git.openjdk.java.net/jfx/pull/71/files - new: https://git.openjdk.java.net/jfx/pull/71/files/768f70c7..740fe2a1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/71/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/71/webrev.02-03 Stats: 112 lines in 1 file changed: 112 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/71/head:pull/71 PR: https://git.openjdk.java.net/jfx/pull/71 From fkirmaier at openjdk.java.net Mon Mar 2 10:10:12 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 2 Mar 2020 10:10:12 GMT Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com> <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com> <93BQsq7oqMhSbwgKo6P_PKT-rnnRu6AA2U_IxJgI-QI=.7acd2a16-1167-4771-9f07-d33a7af29532@github.com> Message-ID: <7Az6qZTQdeBAcWapaOhnq3ea2oykXpB7nMfmC-9K8_I=.0e6ab4ec-abdf-47e0-86cf-a10c09a1e605@github.com> On Tue, 4 Feb 2020 23:19:17 GMT, Kevin Rushforth wrote: >> A little bit late ... >> I have now removed unit-test and it's dependency. >> I will add a ticket about adding them again. > > Rather than removing the test, I was suggesting that you create a test for memory leaks using the same ad hoc approach that our other memory leak tests use. This could later be modified to use the new GC test utility as part of creating that utility. The pattern used in, for example, [TabPaneHeaderLeakTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java), works well enough, even though it repeats a fair amount of boilerplate code. I've now readded the unit-test. It based on the "InitialNodesMemoryLeakTest". Command to execute: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.scene.control.ProgressIndicatorLeakTest` It's now part of the systemtests, because the memory-semantics for the tests in controls is changed due to the TestToolkit. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From fastegal at openjdk.java.net Mon Mar 2 11:01:27 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 2 Mar 2020 11:01:27 GMT Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <7Az6qZTQdeBAcWapaOhnq3ea2oykXpB7nMfmC-9K8_I=.0e6ab4ec-abdf-47e0-86cf-a10c09a1e605@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com> <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com> <93BQsq7oqMhSbwgKo6P_PKT-rnnRu6AA2U_IxJgI-QI=.7acd2a16-1167-4771-9f07-d33a7af29532@github.com> <7Az6qZTQdeBAcWapaOhnq3ea2oykXpB7nMfmC-9K8_I=.0e6ab4ec-abdf-47e0-86cf-a10c09a1e605@github.com> Message-ID: On Mon, 2 Mar 2020 10:07:24 GMT, Florian Kirmaier wrote: >> Rather than removing the test, I was suggesting that you create a test for memory leaks using the same ad hoc approach that our other memory leak tests use. This could later be modified to use the new GC test utility as part of creating that utility. The pattern used in, for example, [TabPaneHeaderLeakTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java), works well enough, even though it repeats a fair amount of boilerplate code. > > I've now readded the unit-test. It based on the "InitialNodesMemoryLeakTest". > > Command to execute: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.scene.control.ProgressIndicatorLeakTest` > > It's now part of the systemtests, because the memory-semantics for the tests in controls is changed due to the TestToolkit. > It's now part of the systemtests, because the memory-semantics for the tests in controls is changed due to the TestToolkit. just curious: does that imply that you think the tests in controls ... rather useless? ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From nlisker at openjdk.java.net Mon Mar 2 11:25:22 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 2 Mar 2020 11:25:22 GMT Subject: [Rev 02] RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: <71KpyOmliyS_CyquHuxIfpQoNFd-xshPN13AK80jBhc=.64fc53c7-8807-4b23-a976-05e3689e38cc@github.com> > Resubmitting from before the transition to this repo. See linked issue for details. The pull request has been updated with 1 additional commit. ------------- Added commits: - 12178c7f: Renamed `put` to `entry` as per review comment Changes: - all: https://git.openjdk.java.net/jfx/pull/104/files - new: https://git.openjdk.java.net/jfx/pull/104/files/8bf73ca1..12178c7f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/104/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/104/webrev.01-02 Stats: 154 lines in 1 file changed: 0 ins; 0 del; 154 mod Patch: https://git.openjdk.java.net/jfx/pull/104.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/104/head:pull/104 PR: https://git.openjdk.java.net/jfx/pull/104 From nlisker at openjdk.java.net Mon Mar 2 11:49:14 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 2 Mar 2020 11:49:14 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: On Mon, 2 Mar 2020 08:31:47 GMT, dannygonzalez wrote: >> In use cases where a large number of listeners are being discarded, it may be better to first consider changing the design to receive event notifications on nodes whose listener registrations are not frequently discarded. > >> Hmm .. personally, I would consider changing such a basic (and probably highly optimized) implementation used all over the framework is a very high risk change that at the worst outcome would detoriate internal and external code. So before going that lane, I would try - as you probably have, just me not seeing it :) - to tackle the problem from the other end: >> >> > I know that in our application, the **thousands of listeners** unregistering when using a TableView was stalling the JavaFX thread. >> >> .. sounds like a lot. Any idea, where exactly they come into play? > > I did start to look at why there were so many change listeners unregistering but felt that would take a deeper understanding of the architecture and design decisions of JavaFX scene graph and I didn't have that time to invest. > I do know that there are thousands of them unregistering in a TableView and unregistering them is a bottleneck for the JavaFX thread. > > There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow. > > To get our application usable I profiled the code and saw this unregistering as a major bottleneck, hence why I looked at this more obvious solution. > > I'm happy to look at the problem from the other angle and happy to listen to suggestions from people with more experience of the design and architecture but tackling the problem from the perspective of re-architecting the behaviour of listeners in the scene graph would be more work than I could feasibly take on. > technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal code does it .. So we can choose to specify it as ordered. These are the 2 options I mentioned: 1. Not specify the behavior and change the implementation in favor of performance. This could break applications as you've mentioned. 2. Specify that the order is preserved and keep the ordered implementation behavior. This will allow applications to rely on the behavior safely. Right now we're losing on both sides. We keep a promise and we don't tell anyone about it. The only reason for this is if we intend to change the behavior in the future, in which case we should add a doc comment saying that the order is unspecified and is planned to change in the future, so there will be at least some warning. Once we choose what to do here it will make sense to continue to review the code with that decision in mind. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fkirmaier at openjdk.java.net Mon Mar 2 12:55:36 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 2 Mar 2020 12:55:36 GMT Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com> <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com> <93BQsq7oqMhSbwgKo6P_PKT-rnnRu6AA2U_IxJgI-QI=.7acd2a16-1167-4771-9f07-d33a7af29532@github.com> <7Az6qZTQdeBAcWapaOhnq3ea2oykXpB7nMfmC-9K8_I=.0e6ab4ec-abdf-47e0-86cf-a10c09a1e605@github.com> Message-ID: <5UxdrfrbAYmJpkUaomZyYWPIc2DfjNruyhse2nLvGZo=.05402690-f3e4-435b-84ae-fa661d0189eb@github.com> On Mon, 2 Mar 2020 10:59:12 GMT, Jeanette Winzenburg wrote: >> I've now readded the unit-test. It based on the "InitialNodesMemoryLeakTest". >> >> Command to execute: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.scene.control.ProgressIndicatorLeakTest` >> >> It's now part of the systemtests, because the memory-semantics for the tests in controls is changed due to the TestToolkit. > >> It's now part of the systemtests, because the memory-semantics for the tests in controls is changed due to the TestToolkit. > > just curious: does that imply that you think the tests in controls ... rather useless? @kleopatra It's not useless, but having a special Toolkit which is only used inside of JavaFX itself is very unreasonable. It would make much more sense, to use the same basis for unit-test as the rest of the JavaFX-Community which is monocle. The systemTests also seem to work quite well. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Mon Mar 2 13:05:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Mar 2020 13:05:38 GMT Subject: [Integrated] RFR: 8237889: Update libxml2 to version 2.9.10 In-Reply-To: References: Message-ID: Changeset: 4c132cdf Author: Arun Joseph Committer: Kevin Rushforth Date: 2020-03-02 13:04:20 +0000 URL: https://git.openjdk.java.net/jfx/commit/4c132cdf 8237889: Update libxml2 to version 2.9.10 Reviewed-by: kcr, jvos ! modules/javafx.web/src/main/legal/libxml2.md ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/config.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/include/libxml/xmlversion.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/mac/config.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/mac/include/libxml/xmlversion.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLtree.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/Makefile.am ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/NEWS ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/README ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/README.zOS ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/SAX2.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/aclocal.m4 ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/buf.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/configure.ac ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/dict.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/elfgcchack.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/enc.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/encoding.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/entities.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/error.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/globals.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/hash.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/c14n.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/catalog.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/dict.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/hash.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/parser.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/parserInternals.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/schemasInternals.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/tree.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/xlink.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/xmlIO.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/xmlerror.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/xmlexports.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/xmlversion.h.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/libxml/xpath.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/win32config.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/include/wsockcompat.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/libxml.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/libxml.spec.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/libxml2.spec ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/libxml2.syms ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/nanohttp.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/parser.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/parserInternals.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/pattern.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/save.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/threads.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/timsort.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/tree.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/trionan.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/uri.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/valid.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/Makefile.bcb ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/Makefile.mingw ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/Makefile.msvc ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/configure.js ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/win32/libxml2.def.src ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xml2-config.1 ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xml2Conf.sh.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xmlIO.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xmlreader.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xmlsave.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xmlwriter.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xpath.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/xzlib.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/win32/config.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxml/win32/include/libxml/xmlversion.h From kcr at openjdk.java.net Mon Mar 2 13:24:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Mar 2020 13:24:25 GMT Subject: [Rev 02] RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: <71KpyOmliyS_CyquHuxIfpQoNFd-xshPN13AK80jBhc=.64fc53c7-8807-4b23-a976-05e3689e38cc@github.com> References: <71KpyOmliyS_CyquHuxIfpQoNFd-xshPN13AK80jBhc=.64fc53c7-8807-4b23-a976-05e3689e38cc@github.com> Message-ID: On Mon, 2 Mar 2020 11:25:22 GMT, Nir Lisker wrote: >> Resubmitting from before the transition to this repo. See linked issue for details. > > The pull request has been updated with 1 additional commit. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/104 From kcr at openjdk.java.net Mon Mar 2 16:50:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Mar 2020 16:50:07 GMT Subject: RFR: 8240287: SelectedItemsReadOnlyObservableList cleanup: remove unused code. In-Reply-To: References: Message-ID: On Mon, 2 Mar 2020 16:47:05 GMT, Kevin Rushforth wrote: >> The below member variables and method of class SelectedItemsReadOnlyObservableList are not required anymore. >> Variables: itemsList, itemsListChanged, itemsListChange, itemsListListener. >> Method: setItemsList >> >> These members were added when this class was created for [JDK-8154216](https://bugs.openjdk.java.net/browse/JDK-8154216). >> But after the fix for [JDK-8152396](https://bugs.openjdk.java.net/browse/JDK-8152396), these class members are not required. >> This change also fixes the leak issue : [JDK-8237926](https://bugs.openjdk.java.net/browse/JDK-8237926) >> >> Verification: >> No build and test failures. > > As I mentioned in the bug report for [JDK-8240287](https://bugs.openjdk.java.net/browse/JDK-8240287), I recommend using [JDK-8227619](https://bugs.openjdk.java.net/browse/JDK-8227619) as the bug ID for this fix (and closing JDK-8240287 in JBS as a duplicate). I think that you should be able to just change the title of this PR. Is it possible to create a test for the leak? ------------- PR: https://git.openjdk.java.net/jfx/pull/132 From kcr at openjdk.java.net Mon Mar 2 16:50:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Mar 2020 16:50:07 GMT Subject: RFR: 8240287: SelectedItemsReadOnlyObservableList cleanup: remove unused code. In-Reply-To: References: Message-ID: On Mon, 2 Mar 2020 09:26:19 GMT, Ambarish Rapte wrote: > The below member variables and method of class SelectedItemsReadOnlyObservableList are not required anymore. > Variables: itemsList, itemsListChanged, itemsListChange, itemsListListener. > Method: setItemsList > > These members were added when this class was created for [JDK-8154216](https://bugs.openjdk.java.net/browse/JDK-8154216). > But after the fix for [JDK-8152396](https://bugs.openjdk.java.net/browse/JDK-8152396), these class members are not required. > This change also fixes the leak issue : [JDK-8237926](https://bugs.openjdk.java.net/browse/JDK-8237926) > > Verification: > No build and test failures. As I mentioned in the bug report for [JDK-8240287](https://bugs.openjdk.java.net/browse/JDK-8240287), I recommend using [JDK-8227619](https://bugs.openjdk.java.net/browse/JDK-8227619) as the bug ID for this fix (and closing JDK-8240287 in JBS as a duplicate). I think that you should be able to just change the title of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/132 From kcr at openjdk.java.net Mon Mar 2 16:51:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Mar 2020 16:51:55 GMT Subject: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> <9bB6LCXUWSjh_soInsnyv63Igy2ZeJKVkzIyR_vKhzU=.1ee8dda6-4776-42d1-9d47-4106b28b680a@github.com> Message-ID: <4Msst48GfgK5UZvfe7CCgBB0uCJtNr60y56EHZsFmNw=.73e8df74-4bb4-4255-a7e9-9a250349f507@github.com> On Thu, 27 Feb 2020 14:36:17 GMT, Rony G. Flatscher wrote: >> Overall this looks good to me. As I mentioned in PR #123 you should fold that the unit test into this PR. > > Removed executable bits from gradlew (which I manually have added to become able to run ./gradlew) and pushed it, however the commit has not appeared. Not wanting to add more noise, I stop until advised differently. Btw, I recommend to run `sh gradlew ...` so you don't have to change the permission locally. ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From jvos at openjdk.java.net Mon Mar 2 16:54:45 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 Mar 2020 16:54:45 GMT Subject: RFR: 8240265: iOS: Unnecessary logging on pinch gestures In-Reply-To: <2M-W750a64IzrQZaUXOTLvNjop9APej7Eg0MziXRa_8=.0a6d0e2e-0379-44c1-ac0c-61b25cf6b18a@github.com> References: <2M-W750a64IzrQZaUXOTLvNjop9APej7Eg0MziXRa_8=.0a6d0e2e-0379-44c1-ac0c-61b25cf6b18a@github.com> Message-ID: On Sun, 1 Mar 2020 19:41:44 GMT, Jose Pereda wrote: > This PR removes unnecessary logging of the scale value during a pinch gesture on iOS Looks trivial. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/131 From Rony.Flatscher at wu.ac.at Mon Mar 2 18:08:36 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 2 Mar 2020 19:08:36 +0100 Subject: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: <4Msst48GfgK5UZvfe7CCgBB0uCJtNr60y56EHZsFmNw=.73e8df74-4bb4-4255-a7e9-9a250349f507@github.com> References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> <9bB6LCXUWSjh_soInsnyv63Igy2ZeJKVkzIyR_vKhzU=.1ee8dda6-4776-42d1-9d47-4106b28b680a@github.com> <4Msst48GfgK5UZvfe7CCgBB0uCJtNr60y56EHZsFmNw=.73e8df74-4bb4-4255-a7e9-9a250349f507@github.com> Message-ID: <95f6d314-c5df-ddb6-9eaa-2ebbc41b010f@wu.ac.at> Hi Kevin, On 02.03.2020 17:51, Kevin Rushforth wrote: > On Thu, 27 Feb 2020 14:36:17 GMT, Rony G. Flatscher wrote: > >>> Overall this looks good to me. As I mentioned in PR #123 you should fold that the unit test into this PR. >> Removed executable bits from gradlew (which I manually have added to become able to run ./gradlew) and pushed it, however the commit has not appeared. Not wanting to add more noise, I stop until advised differently. > Btw, I recommend to run `sh gradlew ...` so you don't have to change the permission locally. > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/122 thank you very much for this hint! As you can probably tell I have never really worked with git (other than pulling open source projects for inspection, experiments) I learn my lessons step by step (svn would be another story). Just trying to not bother experts like yourself and others, but then, not everything can be accounted for by a git-rookie! :) When learning that the executable bit caused a problem on the push, I felt quite embarrassed to have caused noise and stopped doing a "chmod +x gradlew" (did that out of pure laziness in the first place to forgo the 'sh' command) and restarted doing the 'sh gradlew ...' (needless to say now that I have never worked with gradle beforehand, but being? *very* impressed about it, making the creation of such complex libraries like JavaFX or webkit on Linux a breeze, wow). BTW, mistakingly (pressed "Reply" instead of "Reply-to-all") sent my answer to your e-mail address only, resending it via the list now, because currently there seems to be a problem with : The original message was received at Mon, 2 Mar 2020 17:50:57 GMT from aserp3030.oracle.com [127.0.0.1] ?? ----- The following addresses had permanent fatal errors ----- ??? (reason: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table) ?? ----- Transcript of session follows ----- ... while talking to [137.254.59.6]: >>> DATA <<< 550 5.1.1 : Recipient address rejected: User unknown in local recipient table 550 5.1.1 ... User unknown <<< 554 5.5.1 Error: no valid recipients Best regards ---rony From jvos at openjdk.java.net Mon Mar 2 18:29:39 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 Mar 2020 18:29:39 GMT Subject: [Integrated] RFR: 8240265: iOS: Unnecessary logging on pinch gestures In-Reply-To: <2M-W750a64IzrQZaUXOTLvNjop9APej7Eg0MziXRa_8=.0a6d0e2e-0379-44c1-ac0c-61b25cf6b18a@github.com> References: <2M-W750a64IzrQZaUXOTLvNjop9APej7Eg0MziXRa_8=.0a6d0e2e-0379-44c1-ac0c-61b25cf6b18a@github.com> Message-ID: Changeset: 10c9528e Author: Jose Pereda Committer: Johan Vos Date: 2020-03-02 18:29:15 +0000 URL: https://git.openjdk.java.net/jfx/commit/10c9528e 8240265: iOS: Unnecessary logging on pinch gestures Reviewed-by: jvos ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/ios/IosGestureSupport.java From kcr at openjdk.java.net Mon Mar 2 20:54:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Mar 2020 20:54:39 GMT Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <5UxdrfrbAYmJpkUaomZyYWPIc2DfjNruyhse2nLvGZo=.05402690-f3e4-435b-84ae-fa661d0189eb@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com> <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com> <93BQsq7oqMhSbwgKo6P_PKT-rnnRu6AA2U_IxJgI-QI=.7acd2a16-1167-4771-9f07-d33a7af29532@github.com> <7Az6qZTQdeBAcWapaOhnq3ea2oykXpB7nMfmC-9K8_I=.0e6ab4ec-abdf-47e0-86cf-a10c09a1e605@github.com> <5UxdrfrbAYmJpkUaomZyYWPIc2DfjNruyhse2nLvGZo=.05402690-f3e4-435b-84ae-fa661d0189eb@github.com> Message-ID: On Mon, 2 Mar 2020 12:53:21 GMT, Florian Kirmaier wrote: >>> It's now part of the systemtests, because the memory-semantics for the tests in controls is changed due to the TestToolkit. >> >> just curious: does that imply that you think the tests in controls ... rather useless? > > @kleopatra > It's not useless, but having a special Toolkit which is only used inside of JavaFX itself is very unreasonable. It would make much more sense, to use the same basis for unit-test as the rest of the JavaFX-Community which is monocle. The systemTests also seem to work quite well. The unit tests in the `javafx.controls` and `javafx.graphics modules` have used the StubToolkit since the early days. These tests are actually quite useful, but are not able to test anything that depends on the glass toolkit, prism rendering, etc. [JDK-8090538](https://bugs.openjdk.java.net/browse/JDK-8090538) was filed several years ago to explore replacing the StubToolkit with a headless, Monocle-based glass toolkit, but it didn't get very far. There would be some advantages in doing this, but some drawbacks as well (see the discussion thread referred by the above JBS issue). More importantly, it would be a lot of work to do it right, and it isn't clear at this point whether it would be justified by the benefit. So as far as _this_ PR goes, a test in the systemTests project seems fine. I'll put this back on my review queue. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From arapte at openjdk.java.net Tue Mar 3 05:21:46 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 3 Mar 2020 05:21:46 GMT Subject: [Rev 02] RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: <71KpyOmliyS_CyquHuxIfpQoNFd-xshPN13AK80jBhc=.64fc53c7-8807-4b23-a976-05e3689e38cc@github.com> References: <71KpyOmliyS_CyquHuxIfpQoNFd-xshPN13AK80jBhc=.64fc53c7-8807-4b23-a976-05e3689e38cc@github.com> Message-ID: On Mon, 2 Mar 2020 11:25:22 GMT, Nir Lisker wrote: >> Resubmitting from before the transition to this repo. See linked issue for details. > > The pull request has been updated with 1 additional commit. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/104 From tsayao at openjdk.java.net Tue Mar 3 11:12:19 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 3 Mar 2020 11:12:19 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> Message-ID: On Thu, 13 Feb 2020 23:56:42 GMT, Kevin Rushforth wrote: >> **Code Changes** >> >> * glass_window.cpp / glass_window.h >> * Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to >> one class named WindowContext (since inheritance was no required anymore) >> * Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; >> * Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); >> * Frame Extents: Removed the code to request extents and gtk already does it by default; >> * Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJfx uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. >> * Other Size calculation changes: >> * Use gtk_window_set_default_size() for initial size which is the appropriate function; >> * Gravity is now ignored as it is on Windows glass impl; >> * Avoid sending same sizes to Java; >> * Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); >> * Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on >> apply_geometry(). >> * Mouse grab: Reworked it to use to correct functions according to gtk+ version; >> * Draw: Reworked it to use the correct calls accord to gtk+ version changes; >> * Fixed JDK-8237491; >> * Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; >> * Reorganized function order on glass_window.cpp to match glass_window.h >> >> >> * GlassCursor.cpp >> * Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; >> * Reworked Gtk+2 to use a function instead of manual calls to find the cursor; >> >> * GtkWindow.java >> * Moved the extents special case to native glass; >> >> * GlassApplication.cpp >> * Removed Gdk events where possible (it's now on glass_window as signals); >> * Removed applet/web start code; >> >> * GlassView.cpp >> * Changes to reflect frame extents rework on glass_window >> >> * GlassWindow.cpp >> * WindowContextTop -> WindowContext >> * Removed applet / web start code; >> * Removed frame extents (which is not called anymore due to GtkWindow.java change); >> >> * glass_general.cpp >> * Removed functions that became unused; >> * Added is_grab_disabled() that is used on glass_window >> >> * glass_window_ime.cpp >> * WindowContextTop -> WindowContext; >> >> * glass_dnd.cpp / glass_dnd.h >> * Ported to Gtk signals; >> * Use all possible image formats (supported by GdkPixbuf / OpenJfx) - .gif is now possible (for ex.); >> * Allow COMPOUND_TEXT; >> * Do not request content while dragging; >> * Reduce overall code size. > > This is going to need further discussion on the mailing list as indicated above, so it is still premature to review it (i.e., it should still be considered effectively a "WIP" until that discussion happens). Additionally, this is a significant and risky change, so I'd like additional eyes on it when we do get to the point of reviewing it. I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 and Scenebuilder. Will have to do some tests on 16.04. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From arapte at openjdk.java.net Tue Mar 3 13:06:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 3 Mar 2020 13:06:52 GMT Subject: RFR: 8237926: Potential memory leak of model data in javafx.scene.control.ListView In-Reply-To: References: Message-ID: On Mon, 2 Mar 2020 16:47:50 GMT, Kevin Rushforth wrote: >> As I mentioned in the bug report for [JDK-8240287](https://bugs.openjdk.java.net/browse/JDK-8240287), I recommend using [JDK-8227619](https://bugs.openjdk.java.net/browse/JDK-8227619) as the bug ID for this fix (and closing JDK-8240287 in JBS as a duplicate). I think that you should be able to just change the title of this PR. > > Is it possible to create a test for the leak? Hi Kevin, I have updated the PR according to both the comments. Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/132 From arapte at openjdk.java.net Tue Mar 3 13:06:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 3 Mar 2020 13:06:52 GMT Subject: [Rev 01] RFR: 8237926: Potential memory leak of model data in javafx.scene.control.ListView In-Reply-To: References: Message-ID: > The selection model of ListView stores a strong reference to the most recently changed item in `SelectedItemsReadOnlyObservableList.itemsListChange`, which causes a leak. > > Fix: > The below member variables and method of class SelectedItemsReadOnlyObservableList are not required anymore. > Variables: itemsList, itemsListChanged, itemsListChange, itemsListListener. > Method: setItemsList > > These members were added when this class was created for [JDK-8154216](https://bugs.openjdk.java.net/browse/JDK-8154216). > But after the fix for [JDK-8152396](https://bugs.openjdk.java.net/browse/JDK-8152396), these class members are not required. > > Verification: > No failure in existing tests and added a new test. The pull request has been updated with 1 additional commit. ------------- Added commits: - 42b454e0: adding test Changes: - all: https://git.openjdk.java.net/jfx/pull/132/files - new: https://git.openjdk.java.net/jfx/pull/132/files/c859a929..42b454e0 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/132/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/132/webrev.00-01 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/132/head:pull/132 PR: https://git.openjdk.java.net/jfx/pull/132 From kcr at openjdk.java.net Tue Mar 3 13:06:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Mar 2020 13:06:52 GMT Subject: RFR: 8237926: Potential memory leak of model data in javafx.scene.control.ListView In-Reply-To: References: Message-ID: On Tue, 3 Mar 2020 12:56:28 GMT, Ambarish Rapte wrote: >> Is it possible to create a test for the leak? > > Hi Kevin, I have updated the PR according to both the comments. Please take a look. Thanks. I'll put it on my review queue. ------------- PR: https://git.openjdk.java.net/jfx/pull/132 From nlisker at openjdk.java.net Tue Mar 3 14:05:50 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 3 Mar 2020 14:05:50 GMT Subject: [Integrated] RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: Changeset: 960f0390 Author: Nir Lisker Date: 2020-03-03 14:04:34 +0000 URL: https://git.openjdk.java.net/jfx/commit/960f0390 8208761: Update constant collections to use the new immutable collections Reviewed-by: arapte, kcr ! modules/javafx.controls/src/main/java/javafx/scene/control/skin/ColorPickerSkin.java ! modules/javafx.fxml/src/main/java/com/sun/javafx/fxml/builder/ProxyBuilder.java ! modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/ES2Backend.java ! modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/GLSLBackend.java ! modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/HLSLBackend.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ios/IosImageLoader.java ! modules/javafx.graphics/src/main/java/com/sun/javafx/scene/input/InputEventUtils.java ! modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java ! modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/PrRenderer.java ! modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java ! modules/javafx.graphics/src/main/java/javafx/scene/paint/Stop.java ! modules/javafx.web/src/main/java/com/sun/javafx/webkit/KeyCodeMap.java ! modules/javafx.web/src/main/java/com/sun/webkit/network/DateParser.java ! modules/javafx.web/src/main/java/com/sun/webkit/network/URLs.java ! modules/javafx.web/src/main/java/com/sun/webkit/text/TextCodec.java ! modules/javafx.web/src/main/java/javafx/scene/web/WebView.java From danny.gonzalez at screamingfrog.co.uk Tue Mar 3 16:14:15 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Tue, 3 Mar 2020 16:14:15 +0000 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView Message-ID: There is currently an open bug to do with the issue of selection flickering when using single cell selection and when adding data to a TableView. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8177945 This bug seems to be low priority because it hasn?t been looked at since I submitted it at the start of 2017. This is quite a major issue for us so I have narrowed down when the issue was first introduced. Here is the changeset: commit 05afad6b528e871d607b76aea2642cf788b417fe Author: David Grieve > Date: Tue Apr 15 11:51:38 2014 -0400 RT-36672: move code to process css during layout back to impl_reapplyCSS, which is where it was priort to RT-36559 I can?t search the bug database for this bug ID as I believe it was submitted when a previous bug tracking system was in use. Does anyone have any knowledge as to why this fix was needed and what the repercussions would be if I reverted it out for our local OpenJFX build. Alternatively I would be glad to receive any suggestions of how to fix the flickering issue if this changeset is important to leave in. Thanks Danny From kcr at openjdk.java.net Tue Mar 3 16:19:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Mar 2020 16:19:08 GMT Subject: RFR: 8240451: JavaFX javadoc build fails with JDK 14 Message-ID: The JDK 14 javadoc will emit a warning for an `@pram` tag of a generic parameter if not surrounded by `<` and `>`. This will in turn fail the build, since we treat warnings as errors. There are 5 classes in JavaFX with this error. The fix is to replace `@param T` with `@param ` in those 5 places. I have tested this fix using javadoc from both JDK 13 and JDK 14. ------------- Commits: - f68f8e69: 8240451: JavaFX javadoc build fails with JDK 14 Changes: https://git.openjdk.java.net/jfx/pull/133/files Webrev: https://webrevs.openjdk.java.net/jfx/133/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240451 Stats: 6 lines in 5 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/133.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/133/head:pull/133 PR: https://git.openjdk.java.net/jfx/pull/133 From David.Grieve at microsoft.com Tue Mar 3 16:50:57 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Tue, 3 Mar 2020 16:50:57 +0000 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: References: Message-ID: The importance of 05afad6 Is there in the commit itself: + // + // One idiom employed by developers is to, during the layout pass, + // add or remove nodes from the scene. For example, a ScrollPane + // might add scroll bars to itself if it determines during layout + // that it needs them, or a ListView might add cells to itself if + // it determines that it needs to. In such situations we must + // apply the CSS immediately and not add it to the scene's queue + // for deferred action. + If you revert 05afad6, you'll break this. This is the first time I've become aware of this flickering issue. I'll have to look at it. I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK-8193445 has any impact on this. > -----Original Message----- > From: openjfx-dev On Behalf Of > Danny Gonzalez > Sent: Tuesday, March 3, 2020 11:14 AM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding > data to TableView > > > There is currently an open bug to do with the issue of selection flickering > when using single cell selection and when adding data to a TableView. > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da > ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 > d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 > 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb > 8AwcRXVrfLo%3D&reserved=0 > > This bug seems to be low priority because it hasn?t been looked at since I > submitted it at the start of 2017. > > This is quite a major issue for us so I have narrowed down when the issue > was first introduced. > > Here is the changeset: > > commit 05afad6b528e871d607b76aea2642cf788b417fe > Author: David Grieve > > > Date: Tue Apr 15 11:51:38 2014 -0400 > > RT-36672: move code to process css during layout back to impl_reapplyCSS, > which is where it was priort to RT-36559 > > > I can?t search the bug database for this bug ID as I believe it was submitted > when a previous bug tracking system was in use. > > Does anyone have any knowledge as to why this fix was needed and what > the repercussions would be if I reverted it out for our local OpenJFX build. > > Alternatively I would be glad to receive any suggestions of how to fix the > flickering issue if this changeset is important to leave in. > > Thanks > > Danny From kcr at openjdk.java.net Tue Mar 3 22:57:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Mar 2020 22:57:03 GMT Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang Message-ID: While testing JavaFX using gradle 6.3-nightly and JDK 14, I ran into what turned out to be a latent test bug in the AppJSCallback* apps that are launched by ModuleLauncherTest. The launched apps construct a WebView instance, obtain a WebEngine instance from the WebView, add a state listener to the WebEngine, load the web content, and then return from the Application::start method. The WebView instance is held a local variable, and so is subject to garbage collection once it goes out of scope when the start method returns. In addition, the test apps did not check for successful launching of the application or successful loading of the web content, which led to the test suite hanging (else it would have been a simple test failure). Note that I don't know (nor care) what changed in JDK 14 to make this more likely to occur, but since the test itself is demonstrably wrong, it needs to be fixed. The main part of the fix was to make the WebEngine an instance variable. In order to make the test more robust, I also modified it to launch the application in another thread, and having the main thread check that the application launched successfully and that the web content was loaded successfully, after which I did the assertion check for the correct number of callbacks. The 5 different apps only differ from each other in the name of the class, the name of the package from which MyCallback is imported, and possibly the expected number of callbacks. I diffed AppJSCallbackExported.java against the other 4 test files and the diffs are essentially the same as they were before this change. Reviewers thus only need to review one of the tests in detail. For example, here are the diffs between AppJSCallbackExported and AppJSCallbackUnexported: $ diff .../AppJSCallbackExported.java .../AppJSCallbackUnexported.java 37c37 < import myapp5.pkg2.MyCallback; --- > import myapp5.pkg1.MyCallback; 45c45 < public class AppJSCallbackExported extends Application { --- > public class AppJSCallbackUnexported extends Application { 77c77 < Util.assertEquals(1, callbackCount); --- > Util.assertEquals(0, callbackCount); ------------- Commits: - c70d3995: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang Changes: https://git.openjdk.java.net/jfx/pull/134/files Webrev: https://webrevs.openjdk.java.net/jfx/134/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240466 Stats: 265 lines in 5 files changed: 205 ins; 5 del; 55 mod Patch: https://git.openjdk.java.net/jfx/pull/134.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/134/head:pull/134 PR: https://git.openjdk.java.net/jfx/pull/134 From kcr at openjdk.java.net Wed Mar 4 00:23:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 Mar 2020 00:23:23 GMT Subject: [Rev 01] RFR: 8237926: Potential memory leak of model data in javafx.scene.control.ListView In-Reply-To: References: Message-ID: <9Dn9pC-hFI8TjuKRsAaxaxPRLfFt_2a8X8yvFIFhDN4=.fdde1669-d6a4-49a1-8374-119d90e59c30@github.com> On Tue, 3 Mar 2020 13:06:52 GMT, Ambarish Rapte wrote: >> The selection model of ListView stores a strong reference to the most recently changed item in `SelectedItemsReadOnlyObservableList.itemsListChange`, which causes a leak. >> >> Fix: >> The below member variables and method of class SelectedItemsReadOnlyObservableList are not required anymore. >> Variables: itemsList, itemsListChanged, itemsListChange, itemsListListener. >> Method: setItemsList >> >> These members were added when this class was created for [JDK-8154216](https://bugs.openjdk.java.net/browse/JDK-8154216). >> But after the fix for [JDK-8152396](https://bugs.openjdk.java.net/browse/JDK-8152396), these class members are not required. >> >> Verification: >> No failure in existing tests and added a new test. > > The pull request has been updated with 1 additional commit. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/132 From danny.gonzalez at screamingfrog.co.uk Wed Mar 4 07:46:16 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Wed, 4 Mar 2020 07:46:16 +0000 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: References: Message-ID: Thanks for taking a look at this David. Danny > On 3 Mar 2020, at 16:50, David Grieve wrote: > > The importance of 05afad6 Is there in the commit itself: > > + // > + // One idiom employed by developers is to, during the layout pass, > + // add or remove nodes from the scene. For example, a ScrollPane > + // might add scroll bars to itself if it determines during layout > + // that it needs them, or a ListView might add cells to itself if > + // it determines that it needs to. In such situations we must > + // apply the CSS immediately and not add it to the scene's queue > + // for deferred action. > + > > If you revert 05afad6, you'll break this. > > This is the first time I've become aware of this flickering issue. I'll have to look at it. > I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK-8193445 has any impact on this. > >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Danny Gonzalez >> Sent: Tuesday, March 3, 2020 11:14 AM >> To: openjfx-dev at openjdk.java.net >> Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding >> data to TableView >> >> >> There is currently an open bug to do with the issue of selection flickering >> when using single cell selection and when adding data to a TableView. >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs >> .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da >> ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 >> d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 >> 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb >> 8AwcRXVrfLo%3D&reserved=0 >> >> This bug seems to be low priority because it hasn?t been looked at since I >> submitted it at the start of 2017. >> >> This is quite a major issue for us so I have narrowed down when the issue >> was first introduced. >> >> Here is the changeset: >> >> commit 05afad6b528e871d607b76aea2642cf788b417fe >> Author: David Grieve >> > >> Date: Tue Apr 15 11:51:38 2014 -0400 >> >> RT-36672: move code to process css during layout back to impl_reapplyCSS, >> which is where it was priort to RT-36559 >> >> >> I can?t search the bug database for this bug ID as I believe it was submitted >> when a previous bug tracking system was in use. >> >> Does anyone have any knowledge as to why this fix was needed and what >> the repercussions would be if I reverted it out for our local OpenJFX build. >> >> Alternatively I would be glad to receive any suggestions of how to fix the >> flickering issue if this changeset is important to leave in. >> >> Thanks >> >> Danny From danny.gonzalez at screamingfrog.co.uk Wed Mar 4 09:33:46 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Wed, 4 Mar 2020 09:33:46 +0000 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: References: Message-ID: <03DF5DCD-BE78-43E1-9F79-2828B847BE4D@screamingfrog.co.uk> Hi David, Just wanted to add some more information. The cell selection flashing issue goes away If I put back the following code in the layout function in Parent.java: // // One idiom employed by developers is to, during the layout pass, // add or remove nodes from the scene. For example, a ScrollPane // might add scroll bars to itself if it determines during layout // that it needs them, or a ListView might add cells to itself if // it determines that it needs to. In such situations we must // apply the CSS immediately and not add it to the scene's queue // for deferred action. // // Note that we only call processCSS if the flag is update. If the // flag is DIRTY_BRANCH, then the whatever children need UPDATE // will be visited during this layout anyway. On the next pulse, // doCSSPass will clean up the DIRTY_BRANCH nodes. // if (cssFlag == CssFlags.UPDATE) { processCSS(); } This code was originally added in in the following commit: commit e76b5755d4d2752037cc95eb75cb2615a740cc30 Author: David Grieve > Date: Thu Apr 10 15:40:34 2014 -0400 RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply css to child nodes if nothing has changed. 2 - on applyCss, only look for ancestor node with css state = UPDATE. 3 - only recalculate checksum of css file if the file has been removed from a scene or parent It was reverted out in this commit: commit 05afad6b528e871d607b76aea2642cf788b417fe Author: David Grieve > Date: Tue Apr 15 11:51:38 2014 -0400 RT-36672: move code to process css during layout back to impl_reapplyCSS, which is where it was priort to RT-36559 This was the point at which the cell selection flashing appeared. Thanks Danny On 3 Mar 2020, at 16:50, David Grieve > wrote: The importance of 05afad6 Is there in the commit itself: + // + // One idiom employed by developers is to, during the layout pass, + // add or remove nodes from the scene. For example, a ScrollPane + // might add scroll bars to itself if it determines during layout + // that it needs them, or a ListView might add cells to itself if + // it determines that it needs to. In such situations we must + // apply the CSS immediately and not add it to the scene's queue + // for deferred action. + If you revert 05afad6, you'll break this. This is the first time I've become aware of this flickering issue. I'll have to look at it. I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK-8193445 has any impact on this. -----Original Message----- From: openjfx-dev > On Behalf Of Danny Gonzalez Sent: Tuesday, March 3, 2020 11:14 AM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding data to TableView There is currently an open bug to do with the issue of selection flickering when using single cell selection and when adding data to a TableView. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb 8AwcRXVrfLo%3D&reserved=0 This bug seems to be low priority because it hasn?t been looked at since I submitted it at the start of 2017. This is quite a major issue for us so I have narrowed down when the issue was first introduced. Here is the changeset: commit 05afad6b528e871d607b76aea2642cf788b417fe Author: David Grieve > Date: Tue Apr 15 11:51:38 2014 -0400 RT-36672: move code to process css during layout back to impl_reapplyCSS, which is where it was priort to RT-36559 I can?t search the bug database for this bug ID as I believe it was submitted when a previous bug tracking system was in use. Does anyone have any knowledge as to why this fix was needed and what the repercussions would be if I reverted it out for our local OpenJFX build. Alternatively I would be glad to receive any suggestions of how to fix the flickering issue if this changeset is important to leave in. Thanks Danny From aghaisas at openjdk.java.net Wed Mar 4 12:07:16 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 4 Mar 2020 12:07:16 GMT Subject: [Rev 01] RFR: 8237926: Potential memory leak of model data in javafx.scene.control.ListView In-Reply-To: References: Message-ID: On Tue, 3 Mar 2020 13:06:52 GMT, Ambarish Rapte wrote: >> The selection model of ListView stores a strong reference to the most recently changed item in `SelectedItemsReadOnlyObservableList.itemsListChange`, which causes a leak. >> >> Fix: >> The below member variables and method of class SelectedItemsReadOnlyObservableList are not required anymore. >> Variables: itemsList, itemsListChanged, itemsListChange, itemsListListener. >> Method: setItemsList >> >> These members were added when this class was created for [JDK-8154216](https://bugs.openjdk.java.net/browse/JDK-8154216). >> But after the fix for [JDK-8152396](https://bugs.openjdk.java.net/browse/JDK-8152396), these class members are not required. >> >> Verification: >> No failure in existing tests and added a new test. > > The pull request has been updated with 1 additional commit. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/132 From ehelin at openjdk.java.net Wed Mar 4 14:05:05 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Wed, 4 Mar 2020 14:05:05 GMT Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: References: Message-ID: On Tue, 3 Mar 2020 22:51:43 GMT, Kevin Rushforth wrote: > While testing JavaFX using gradle 6.3-nightly and JDK 14, I ran into what turned out to be a latent test bug in the AppJSCallback* apps that are launched by ModuleLauncherTest. The launched apps construct a WebView instance, obtain a WebEngine instance from the WebView, add a state listener to the WebEngine, load the web content, and then return from the Application::start method. The WebView instance is held a local variable, and so is subject to garbage collection once it goes out of scope when the start method returns. > > In addition, the test apps did not check for successful launching of the application or successful loading of the web content, which led to the test suite hanging (else it would have been a simple test failure). > > Note that I don't know (nor care) what changed in JDK 14 to make this more likely to occur, but since the test itself is demonstrably wrong, it needs to be fixed. > > The main part of the fix was to make the WebEngine an instance variable. In order to make the test more robust, I also modified it to launch the application in another thread, and having the main thread check that the application launched successfully and that the web content was loaded successfully, after which I did the assertion check for the correct number of callbacks. > > The 5 different apps only differ from each other in the name of the class, the name of the package from which MyCallback is imported, and possibly the expected number of callbacks. I diffed AppJSCallbackExported.java against the other 4 test files and the diffs are essentially the same as they were before this change. Reviewers thus only need to review one of the tests in detail. > > For example, here are the diffs between AppJSCallbackExported and AppJSCallbackUnexported: > > $ diff .../AppJSCallbackExported.java .../AppJSCallbackUnexported.java > > 37c37 > < import myapp5.pkg2.MyCallback; > --- >> import myapp5.pkg1.MyCallback; > 45c45 > < public class AppJSCallbackExported extends Application { > --- >> public class AppJSCallbackUnexported extends Application { > 77c77 > < Util.assertEquals(1, callbackCount); > --- >> Util.assertEquals(0, callbackCount); Please ignore this comment, this is for debugging Skara that might have some mailing list mirroring issues ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/134 From ehelin at openjdk.java.net Wed Mar 4 14:13:53 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Wed, 4 Mar 2020 14:13:53 GMT Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: References: Message-ID: On Wed, 4 Mar 2020 14:02:51 GMT, Erik Helin wrote: >> While testing JavaFX using gradle 6.3-nightly and JDK 14, I ran into what turned out to be a latent test bug in the AppJSCallback* apps that are launched by ModuleLauncherTest. The launched apps construct a WebView instance, obtain a WebEngine instance from the WebView, add a state listener to the WebEngine, load the web content, and then return from the Application::start method. The WebView instance is held a local variable, and so is subject to garbage collection once it goes out of scope when the start method returns. >> >> In addition, the test apps did not check for successful launching of the application or successful loading of the web content, which led to the test suite hanging (else it would have been a simple test failure). >> >> Note that I don't know (nor care) what changed in JDK 14 to make this more likely to occur, but since the test itself is demonstrably wrong, it needs to be fixed. >> >> The main part of the fix was to make the WebEngine an instance variable. In order to make the test more robust, I also modified it to launch the application in another thread, and having the main thread check that the application launched successfully and that the web content was loaded successfully, after which I did the assertion check for the correct number of callbacks. >> >> The 5 different apps only differ from each other in the name of the class, the name of the package from which MyCallback is imported, and possibly the expected number of callbacks. I diffed AppJSCallbackExported.java against the other 4 test files and the diffs are essentially the same as they were before this change. Reviewers thus only need to review one of the tests in detail. >> >> For example, here are the diffs between AppJSCallbackExported and AppJSCallbackUnexported: >> >> $ diff .../AppJSCallbackExported.java .../AppJSCallbackUnexported.java >> >> 37c37 >> < import myapp5.pkg2.MyCallback; >> --- >>> import myapp5.pkg1.MyCallback; >> 45c45 >> < public class AppJSCallbackExported extends Application { >> --- >>> public class AppJSCallbackUnexported extends Application { >> 77c77 >> < Util.assertEquals(1, callbackCount); >> --- >>> Util.assertEquals(0, callbackCount); > > Please ignore this comment, this is for debugging Skara that might have some mailing list mirroring issues ?? Please ignore this comment as well, it is also for debugging issues with Skara and mailman :email: ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/134 From kcr at openjdk.java.net Wed Mar 4 20:35:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 Mar 2020 20:35:34 GMT Subject: RFR: 8236685: [macOs] Remove obsolete file dialog subclasses Message-ID: This is a follow-on to [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474). This fix removes the custom subclasses of NSSavePanel and NSOpenPanel that are optionally used by the glass implementation of file open, directory open, and file save. These subclasses were originally added to provide support for keyboard shortcuts for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V) operations that the standard Apple dialogs do not support directly; applications can add their own support, but JavaFX is a library not an application. Note that as of macOS 10.15, all file dialogs on Mac are run in a spearate process. Attempts to subclass NSSavePanel and NSOpenPanel are no longer supported. They are either ineffective (silently ignored) or else crash the application. As a result of the crashes that were happening in some environments, the fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474) uses the NSSavePanel and NSOpenPanel base classes directly when running on macOS 10.15 or later. The proposed fix for this follow-on issue, [JDK-8236685](https://bugs.openjdk.java.net/browse/JDK-8236685), will use NSSavePanel and NSOpenPanel directly on all versions of macOS. Note that Copy, Cut, and Paste functionality are available with the menu before and after this fix. This only impacts the keyboard shortcuts. ------------- Commits: - 1075250a: 8236685: [macOs] Remove obsolete file dialog subclasses Changes: https://git.openjdk.java.net/jfx/pull/135/files Webrev: https://webrevs.openjdk.java.net/jfx/135/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236685 Stats: 121 lines in 3 files changed: 0 ins; 118 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/135.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/135/head:pull/135 PR: https://git.openjdk.java.net/jfx/pull/135 From kcr at openjdk.java.net Wed Mar 4 21:00:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 Mar 2020 21:00:55 GMT Subject: RFR: 8236685: [macOs] Remove obsolete file dialog subclasses In-Reply-To: References: Message-ID: <7zr9ww6HxEDT_aLLmX2F6mnEbOOLSO6hMiyzcumVYf8=.2c5d5b81-3e22-4f27-8aba-09bcadcf73c6@github.com> On Wed, 4 Mar 2020 20:27:46 GMT, Kevin Rushforth wrote: > This is a follow-on to [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474). > > This fix removes the custom subclasses of NSSavePanel and NSOpenPanel that are optionally used by the glass implementation of file open, directory open, and file save. These subclasses were originally added to provide support for keyboard shortcuts for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V) operations that the standard Apple dialogs do not support directly; applications can add their own support, but JavaFX is a library not an application. > > Note that as of macOS 10.15, all file dialogs on Mac are run in a spearate process. Attempts to subclass NSSavePanel and NSOpenPanel are no longer supported. They are either ineffective (silently ignored) or else crash the application. As a result of the crashes that were happening in some environments, the fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474) uses the NSSavePanel and NSOpenPanel base classes directly when running on macOS 10.15 or later. The proposed fix for this follow-on issue, [JDK-8236685](https://bugs.openjdk.java.net/browse/JDK-8236685), will use NSSavePanel and NSOpenPanel directly on all versions of macOS. > > Note that Copy, Cut, and Paste functionality are available with the menu before and after this fix. This only impacts the keyboard shortcuts. @arapte @prrace can you review this follow-on fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/135 From arapte at openjdk.java.net Thu Mar 5 03:39:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 5 Mar 2020 03:39:45 GMT Subject: [Integrated] RFR: 8240287: SelectedItemsReadOnlyObservableList cleanup: remove unused code. In-Reply-To: References: Message-ID: <9033e53e-2f4d-493d-bb59-53bda0fbb95e@openjdk.org> Changeset: 337ed722 Author: Ambarish Rapte Date: 2020-03-05 03:38:39 +0000 URL: https://git.openjdk.java.net/jfx/commit/337ed722 8237926: Potential memory leak of model data in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas ! modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableList.java ! modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java ! modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java From jvos at openjdk.java.net Thu Mar 5 08:51:13 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Mar 2020 08:51:13 GMT Subject: [Rev 02] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case In-Reply-To: References: Message-ID: On Mon, 10 Feb 2020 13:27:27 GMT, Ambarish Rapte wrote: >> Memory allocated in initDecompressor() and decompressIndirect() is not freed in error case. >> In error case, >> 1. Allocated memory should be freed. >> 2. Appropriate de-initialization jpeg library calls should be added. >> >> Verified that, >> 1. All unit and systems tests pass on three platforms, and >> 2. Memory consumption with and without fix is similar by comparing memory before and after showing 10 jpeg images for 100 times. > > The pull request has been updated with a new target base due to a merge or a rebase. Looks good to me. I paid special attention to null pointer dereferencing when cleaning up resources, but I couldn't spot a trace that could cause this. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/54 From abhinay_agarwal at live.com Thu Mar 5 10:43:53 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Thu, 5 Mar 2020 10:43:53 +0000 Subject: ComboBox keypress discrepancy Message-ID: Hi, We have come across a behavioural change in ComboBox b/w JavaFX 8 and 9+. We are not sure if its a regression or a bug fix which is causing it. Therefore, I am reaching out to the community for insight. If you run the following example, open the popup window in ComboBox and press TAB: JavaFX 8 registers the key press event, where as, JavaFX 9 and later do not register it. The TAB keypress is registered successfully in bot cases when the popup window is not showing. import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.ComboBox; import javafx.scene.input.KeyEvent; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class Main extends Application { @Override public void start(Stage primaryStage) { final ComboBox stringComboBox = new ComboBox<>(); stringComboBox.getItems().addAll("John", "Jacob", "Schmidt"); stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> System.out.println(kp.getCode())); final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 275); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } From dlemmermann at gmail.com Thu Mar 5 13:09:13 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 5 Mar 2020 14:09:13 +0100 Subject: ComboBox keypress discrepancy In-Reply-To: References: Message-ID: So what info do you need? What test do you want us to run? I ran it on MacOS X with Java 14ea and I DO NOT see the ?TAB? output. Dirk > Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal : > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.ComboBox; > import javafx.scene.input.KeyEvent; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class Main extends Application { > > @Override > public void start(Stage primaryStage) { > final ComboBox stringComboBox = new ComboBox<>(); > stringComboBox.getItems().addAll("John", "Jacob", "Schmidt"); > stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> System.out.println(kp.getCode())); > > final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 275); > primaryStage.setScene(scene); > primaryStage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } From ajoseph at openjdk.java.net Thu Mar 5 14:57:27 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 5 Mar 2020 14:57:27 GMT Subject: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash Message-ID: Issue: The stack pointer is checked close to the stack limit during the last iteration of calling frameLoaded() and then, grows beyond the thread's stack range causing a stack overflow and crashes. This occurs as the stack grows by an amount larger than the reserved zone at the end of the stack. Fix: Reduce the stack range visible to the thread in [StackBounds.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp) similar to Mac and Linux. This causes the stack pointer check to throw a StackOverflowError during the last iteration. ------------- Commits: - f780c079: 8240211: Stack overflow on Windows 32-bit can lead to crash Changes: https://git.openjdk.java.net/jfx/pull/137/files Webrev: https://webrevs.openjdk.java.net/jfx/137/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240211 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/137.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/137/head:pull/137 PR: https://git.openjdk.java.net/jfx/pull/137 From rlichten at openjdk.java.net Thu Mar 5 16:06:16 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 5 Mar 2020 16:06:16 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Message-ID: This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. ------------- Commits: - e78e8793: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException - d849c67c: Merge remote-tracking branch 'upstream/master' - 846d0483: Merge remote-tracking branch 'upstream/master' - 9ceb21bc: Merge remote-tracking branch 'upstream/master' - 2109d5a0: Merge remote-tracking branch 'upstream/master' - acfa63be: Merge remote-tracking branch 'upstream/master' - 7c5cf198: 8232524: Test cleanup: terminate background thread upon failure. - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating - 8ecf3545: JDK-8232524 fixed. Changes: https://git.openjdk.java.net/jfx/pull/138/files Webrev: https://webrevs.openjdk.java.net/jfx/138/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8176270 Stats: 20 lines in 3 files changed: 19 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138 PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Thu Mar 5 16:20:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 16:20:25 GMT Subject: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last iteration of calling frameLoaded() and then, grows beyond the thread's stack range causing a stack overflow and crashes. This occurs as the stack grows by an amount larger than the reserved zone at the end of the stack. > > Fix: Reduce the stack range visible to the thread in [StackBounds.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp) similar to Mac and Linux. This causes the stack pointer check to throw a StackOverflowError during the last iteration. I will review this. @guruhb can you also review it? ------------- PR: https://git.openjdk.java.net/jfx/pull/137 From ghb at openjdk.java.net Thu Mar 5 16:53:03 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 5 Mar 2020 16:53:03 GMT Subject: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last iteration of calling frameLoaded() and then, grows beyond the thread's stack range causing a stack overflow and crashes. This occurs as the stack grows by an amount larger than the reserved zone at the end of the stack. > > Fix: Reduce the stack range visible to the thread in [StackBounds.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp) similar to Mac and Linux. This causes the stack pointer check to throw a StackOverflowError during the last iteration. Looks good to me. I believe you have executed DRT on both 64 & 32 bit build. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/137 From fastegal at openjdk.java.net Thu Mar 5 17:03:34 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 5 Mar 2020 17:03:34 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 16:01:10 GMT, Robert Lichtenberger wrote: > This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. why a second pr for the same issue (see https://github.com/openjdk/jfx/pull/73)? particularly one that doesn't do much more/else/better (than clamping, which isn't good enough)? ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From nlisker at openjdk.java.net Thu Mar 5 17:20:14 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 5 Mar 2020 17:20:14 GMT Subject: RFR: 8240451: JavaFX javadoc build fails with JDK 14 In-Reply-To: References: Message-ID: On Tue, 3 Mar 2020 16:12:23 GMT, Kevin Rushforth wrote: > The JDK 14 javadoc will emit a warning for an `@pram` tag of a generic parameter if not surrounded by `<` and `>`. This will in turn fail the build, since we treat warnings as errors. There are 5 classes in JavaFX with this error. The fix is to replace `@param T` with `@param ` in those 5 places. > > > I have tested this fix using javadoc from both JDK 13 and JDK 14. Using a rough regex search of `@param [A-Z]\s` I also found: `com.sun.glass.ui.Window#requestInput`: `@param M` `com.sun.javafx.tk.TKStage#requestInput`: `@param M` Though those are internal. ------------- Marked as reviewed by nlisker (Committer). PR: https://git.openjdk.java.net/jfx/pull/133 From jvos at openjdk.java.net Thu Mar 5 17:48:22 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Mar 2020 17:48:22 GMT Subject: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 16:50:55 GMT, Guru Hb wrote: >> Issue: The stack pointer is checked close to the stack limit during the last iteration of calling frameLoaded() and then, grows beyond the thread's stack range causing a stack overflow and crashes. This occurs as the stack grows by an amount larger than the reserved zone at the end of the stack. >> >> Fix: Reduce the stack range visible to the thread in [StackBounds.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp) similar to Mac and Linux. This causes the stack pointer check to throw a StackOverflowError during the last iteration. > > Looks good to me. > I believe you have executed DRT on both 64 & 32 bit build. This looks correct and very valuable to me. Would be great if there was a test that results in a crash before? ------------- PR: https://git.openjdk.java.net/jfx/pull/137 From kcr at openjdk.java.net Thu Mar 5 18:02:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 18:02:34 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 17:01:25 GMT, Jeanette Winzenburg wrote: >> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. > > why a second pr for the same issue (see https://github.com/openjdk/jfx/pull/73)? particularly one that doesn't do much more/else/better (than clamping, which isn't good enough)? I have exactly the same question. In general, it's better to work with the author of an existing PR instead of creating a new one. If the original PR #73 is completely stalled, then it might make sense, but not until then. ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Thu Mar 5 18:30:44 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 18:30:44 GMT Subject: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 17:46:17 GMT, Johan Vos wrote: >> Looks good to me. >> I believe you have executed DRT on both 64 & 32 bit build. > > This looks correct and very valuable to me. Would be great if there was a test that results in a crash before? Here is a pointer to the [apply-style-iframe-crash.html](https://github.com/WebKit/webkit/blob/8e46d906531cf38fd860e30fafdf5a3021568d6c/LayoutTests/editing/style/apply-style-iframe-crash.html) test case that crashes on Windows 32-bit without this fix and passes with this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/137 From kcr at openjdk.java.net Thu Mar 5 18:33:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 18:33:04 GMT Subject: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last iteration of calling frameLoaded() and then, grows beyond the thread's stack range causing a stack overflow and crashes. This occurs as the stack grows by an amount larger than the reserved zone at the end of the stack. > > Fix: Reduce the stack range visible to the thread in [StackBounds.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp) similar to Mac and Linux. This causes the stack pointer check to throw a StackOverflowError during the last iteration. I did a full build / test and verified that on Windows 32-bit the apply-style-iframe-crash.html test crashes without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/137 From jvos at openjdk.java.net Thu Mar 5 18:52:10 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Mar 2020 18:52:10 GMT Subject: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last iteration of calling frameLoaded() and then, grows beyond the thread's stack range causing a stack overflow and crashes. This occurs as the stack grows by an amount larger than the reserved zone at the end of the stack. > > Fix: Reduce the stack range visible to the thread in [StackBounds.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp) similar to Mac and Linux. This causes the stack pointer check to throw a StackOverflowError during the last iteration. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/137 From kcr at openjdk.java.net Thu Mar 5 19:28:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 19:28:58 GMT Subject: [Integrated] RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash In-Reply-To: References: Message-ID: Changeset: cf0bba62 Author: Arun Joseph Committer: Kevin Rushforth Date: 2020-03-05 19:28:25 +0000 URL: https://git.openjdk.java.net/jfx/commit/cf0bba62 8240211: Stack overflow on Windows 32-bit can lead to crash Reviewed-by: ghb, kcr, jvos ! modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp From jvos at openjdk.java.net Thu Mar 5 20:43:33 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Mar 2020 20:43:33 GMT Subject: RFR: 8240451: JavaFX javadoc build fails with JDK 14 In-Reply-To: References: Message-ID: On Tue, 3 Mar 2020 16:12:23 GMT, Kevin Rushforth wrote: > The JDK 14 javadoc will emit a warning for an `@pram` tag of a generic parameter if not surrounded by `<` and `>`. This will in turn fail the build, since we treat warnings as errors. There are 5 classes in JavaFX with this error. The fix is to replace `@param T` with `@param ` in those 5 places. > > > I have tested this fix using javadoc from both JDK 13 and JDK 14. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/133 From kcr at openjdk.java.net Thu Mar 5 20:33:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 20:33:04 GMT Subject: RFR: 8240451: JavaFX javadoc build fails with JDK 14 In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 17:17:57 GMT, Nir Lisker wrote: >> The JDK 14 javadoc will emit a warning for an `@pram` tag of a generic parameter if not surrounded by `<` and `>`. This will in turn fail the build, since we treat warnings as errors. There are 5 classes in JavaFX with this error. The fix is to replace `@param T` with `@param ` in those 5 places. >> >> >> I have tested this fix using javadoc from both JDK 13 and JDK 14. > > Using a rough regex search of `@param [A-Z]\s` I also found: > > `com.sun.glass.ui.Window#requestInput`: `@param M` > `com.sun.javafx.tk.TKStage#requestInput`: `@param M` > > Though those are internal. Thanks for the review. Yeah, I only looked at the public API classes. Can I get a "R"eviewer to look at this? Maybe @arapte or @aghaisas ? ------------- PR: https://git.openjdk.java.net/jfx/pull/133 From kcr at openjdk.java.net Thu Mar 5 20:58:48 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 20:58:48 GMT Subject: [Integrated] RFR: 8240451: JavaFX javadoc build fails with JDK 14 In-Reply-To: References: Message-ID: Changeset: b2ac76a9 Author: Kevin Rushforth Date: 2020-03-05 20:58:03 +0000 URL: https://git.openjdk.java.net/jfx/commit/b2ac76a9 8240451: JavaFX javadoc build fails with JDK 14 Reviewed-by: nlisker, jvos ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanObjectProperty.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanObjectPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectProperty.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/value/WritableObjectValue.java From kcr at openjdk.java.net Thu Mar 5 22:21:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 22:21:56 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <6OhviYNgO41FTyjthrckuI_FiLCNAbBOvAmhc6kkNOI=.94f9d129-d32c-4616-afbf-0c4aecce14db@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <6OhviYNgO41FTyjthrckuI_FiLCNAbBOvAmhc6kkNOI=.94f9d129-d32c-4616-afbf-0c4aecce14db@github.com> Message-ID: <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> On Mon, 2 Mar 2020 10:09:57 GMT, Florian Kirmaier wrote: >> Hi everyone, >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 >> >> The fix itself is quite straight forward. >> It basically just removed the listener which causes the leak. >> >> The unit-test for the fix is a bit more complicated. >> >> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks. >> I think there are many places in the JavaFX-codebase that could highly benefit from this library. >> It could also simplify many of the already existing unit tests. >> It makes testing for memory-leaks readably and reliable. >> It would also be possible to just copy the code of the library into the JavaFX-codebase. >> It only contains a single class. >> >> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. > > The pull request has been updated with 1 additional commit. The fix looks good to me. I've verified that it fixes the leak. The newly added test looks good as well, with some comments left inline (formatting, a missing copyright header, and a couple other suggestions). modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 331: > 330: // clean up the old determinateIndicator > 331: if(determinateIndicator != null) { > 332: determinateIndicator.unregisterListener(); Minor: add a space after the `if`. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 1: > 1: package test.javafx.scene.control; > 2: You need a copyright header for this file. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 60: > 59: import javafx.scene.shape.Circle; > 60: import javafx.scene.text.Font; > 61: import javafx.scene.text.Text; You don't use any of the 3 newly added imports in this patch, so they can be removed (reverted). tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 42: > 41: indicator.setProgress(1.0); > 42: Assert.assertTrue("size was: " + indicator.getChildrenUnmodifiable().size(), indicator.getChildrenUnmodifiable().size() == 1); > 43: detIndicator = new WeakReference(indicator.getChildrenUnmodifiable().get(0)); This assertion can be done as: assertEquals("size is wrong", 1, indicator.getChildrenUnmodifiable().size()); It will be easier to read and more straight-forward. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 57: > 56: @BeforeClass > 57: public static void initFX() { > 58: startupLatch = new CountDownLatch(1); The `initFX` method can be simplified a bit using a pattern we've adopted in our newer tests. See [QuadraticCssTimeTest.java](https://github.com/openjdk/jfx/blob/jfx14/tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java#L84). tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 72: > 71: public void memoryTest() throws NoSuchFieldException,IllegalAccessException { > 72: System.out.println("detIndicator: " + detIndicator.get()); > 73: assertCollectable(detIndicator); I recommend to comment out this debugging statement. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 80: > 79: createGarbage(); > 80: System.gc(); > 81: We recommend also calling `System.runFinalization();` for GC related tests. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 85: > 84: Thread.sleep(100); > 85: } catch (InterruptedException e) {} > 86: counter = counter + 1; You can skip the try / catch if you declare the test method as `throws Exception` tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 82: > 81: > 82: while(counter < 10 && weakReference.get() != null) { > 83: try { Please add a space after the `while`. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 91: > 90: > 91: if(weakReference.get() != null) { > 92: throw new AssertionError("Content of WeakReference was not collected. content: " + weakReference.get()); Add a space after the `if` tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 95: > 94: } > 95: public static void createGarbage() { > 96: LinkedList list = new LinkedList(); I think this is fine, but I'm curious as to whether you've actually found this (creating garbage) to be necessary. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 98: > 97: int counter = 0; > 98: while(counter < 999999) { > 99: counter += 1; Space after the `while` tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 88: > 87: createGarbage(); > 88: System.gc(); > 89: } Same comment as earlier about also calling `System.runFinalization()`; ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Thu Mar 5 22:21:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Mar 2020 22:21:56 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <6126ZbZJAQnIkjbSLBEHMokret4fi4266QMA9AWkrQo=.bd490049-dc1a-48b9-add5-bbe32da45873@github.com> <9NZtsyDeTXHfn2oFJyWffHzj4JdzGvHYN2MBmSmegFg=.26f69f11-52c6-49d5-995b-0cf85607073b@github.com> Message-ID: On Thu, 19 Dec 2019 14:43:29 GMT, Jeanette Winzenburg wrote: >> I don't see an API in the discussion, on how to remove a specific listener. Did i miss something? It seems to me, that the API is written to support only a single listener per property. > > the api is in a related issue (should be noted in the issue above). The use-cases mentioned in the isssue: it's a do-once scenario with the skin (and its subclasses) as the only user: multiple listeners can be registered, typically by a skin and/or its subclasses, each can be pre/postpended (or replaced) in the chain for that property and all are unregistered at dispose time. So I think it's really bad to use it in another collaborator like the indicator, particularly if that is re-created often and each of the instances need to remove the listener. I think this will be fine. The `text` node is private to the `DeterminateIndicator` inner class and not exposed, so there would never be another listener. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From abhinay_agarwal at live.com Fri Mar 6 04:59:08 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 6 Mar 2020 04:59:08 +0000 Subject: ComboBox keypress discrepancy In-Reply-To: References: , Message-ID: Hi Dirk, Thanks for reaching out. As stated earlier, I want to know what exactly is causing this change in behaviour. I also want to know what is the expected behaviour in this case: should TAB key press trigger when the popupwindow is showing? -- Abhinay ________________________________ From: Dirk Lemmermann Sent: Thursday, March 5, 2020 6:39 PM To: Abhinay Agarwal Cc: openjfx-dev at openjdk.java.net Subject: Re: ComboBox keypress discrepancy So what info do you need? What test do you want us to run? I ran it on MacOS X with Java 14ea and I DO NOT see the ?TAB? output. Dirk Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal >: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.ComboBox; import javafx.scene.input.KeyEvent; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class Main extends Application { @Override public void start(Stage primaryStage) { final ComboBox stringComboBox = new ComboBox<>(); stringComboBox.getItems().addAll("John", "Jacob", "Schmidt"); stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> System.out.println(kp.getCode())); final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 275); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } From rlichten at openjdk.java.net Fri Mar 6 06:02:46 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 6 Mar 2020 06:02:46 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: Message-ID: On Thu, 5 Mar 2020 18:00:25 GMT, Kevin Rushforth wrote: >> why a second pr for the same issue (see https://github.com/openjdk/jfx/pull/73)? particularly one that doesn't do much more/else/better (than clamping, which isn't good enough)? > > I have exactly the same question. > > In general, it's better to work with the author of an existing PR instead of creating a new one. If the original PR #73 is completely stalled, then it might make sense, but not until then. I wasn't aware of PR #73, I only saw the (very old) issue in the JDK Bug System and started to look into the issue. The fact that two different people start to look into the same issue shows it is important however :-). Should I close this PR and participate in PR #73? ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From arapte at openjdk.java.net Fri Mar 6 08:24:00 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 6 Mar 2020 08:24:00 GMT Subject: [Integrated] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case In-Reply-To: References: Message-ID: Changeset: f25e8cf2 Author: Ambarish Rapte Date: 2020-03-06 08:23:04 +0000 URL: https://git.openjdk.java.net/jfx/commit/f25e8cf2 8212034: Potential memory leaks in jpegLoader.c in error case Reviewed-by: jvos, kcr ! modules/javafx.graphics/src/main/native-iio/jpegloader.c From arapte at openjdk.java.net Fri Mar 6 08:30:47 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 6 Mar 2020 08:30:47 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Wed, 12 Feb 2020 13:21:03 GMT, Frederic Thevenet wrote: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be larger than the running platform's maximum supported texture size, was addressed in openjfx14. > The fix, based around the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is currently only attempted after the original, non-tiled, strategy has already failed. > This was decided to avoid any risk of regressions, either in terms of performances and correctness, while still offering some relief to the original issue. > > This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is necessary while still introducing no regressions compared to the original solution. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1527: > 1526: private int computeOptimumTileSize(int size, int maxSize, AtomicBoolean isDivExact) { > 1527: for (int n = 2; n <= 6; n++) { > 1528: int optimumSize = size / n; It would be helpful if you add explanation about the constants 2 and 6 here. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From dlemmermann at gmail.com Fri Mar 6 09:25:00 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Fri, 6 Mar 2020 10:25:00 +0100 Subject: ComboBox keypress discrepancy In-Reply-To: References: Message-ID: <0F5B44EE-E337-48BE-BD23-E1DB4D7B43A2@gmail.com> Regarding expected behaviour: in native combo boxes / dropdowns on Mac the TAB key is doing nothing when the popup is open. If you want to select an item you need to use the arrow keys. So I guess that is what I would expect for navigating the element. But that does not mean that the key event can?t fire, right? Some subclass / custom control might have a need for it. Dirk > Am 06.03.2020 um 05:59 schrieb Abhinay Agarwal : > > Hi Dirk, > > Thanks for reaching out. As stated earlier, I want to know what exactly is causing this change in behaviour. I also want to know what is the expected behaviour in this case: should TAB key press trigger when the popupwindow is showing? > > -- Abhinay > From: Dirk Lemmermann > Sent: Thursday, March 5, 2020 6:39 PM > To: Abhinay Agarwal > Cc: openjfx-dev at openjdk.java.net > Subject: Re: ComboBox keypress discrepancy > > So what info do you need? What test do you want us to run? > > I ran it on MacOS X with Java 14ea and I DO NOT see the ?TAB? output. > > Dirk > >> Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal >: >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.ComboBox; >> import javafx.scene.input.KeyEvent; >> import javafx.scene.layout.BorderPane; >> import javafx.stage.Stage; >> >> public class Main extends Application { >> >> @Override >> public void start(Stage primaryStage) { >> final ComboBox stringComboBox = new ComboBox<>(); >> stringComboBox.getItems().addAll("John", "Jacob", "Schmidt"); >> stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> System.out.println(kp.getCode())); >> >> final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 275); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } From arapte at openjdk.java.net Fri Mar 6 10:34:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 6 Mar 2020 10:34:13 GMT Subject: RFR: 8236685: [macOs] Remove obsolete file dialog subclasses In-Reply-To: References: Message-ID: On Wed, 4 Mar 2020 20:27:46 GMT, Kevin Rushforth wrote: > This is a follow-on to [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474). > > This fix removes the custom subclasses of NSSavePanel and NSOpenPanel that are optionally used by the glass implementation of file open, directory open, and file save. These subclasses were originally added to provide support for keyboard shortcuts for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V) operations that the standard Apple dialogs do not support directly; applications can add their own support, but JavaFX is a library not an application. > > Note that as of macOS 10.15, all file dialogs on Mac are run in a spearate process. Attempts to subclass NSSavePanel and NSOpenPanel are no longer supported. They are either ineffective (silently ignored) or else crash the application. As a result of the crashes that were happening in some environments, the fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474) uses the NSSavePanel and NSOpenPanel base classes directly when running on macOS 10.15 or later. The proposed fix for this follow-on issue, [JDK-8236685](https://bugs.openjdk.java.net/browse/JDK-8236685), will use NSSavePanel and NSOpenPanel directly on all versions of macOS. > > Note that Copy, Cut, and Paste functionality are available with the menu before and after this fix. This only impacts the keyboard shortcuts. Looks good to me, Build and test run shows no failures. Test attached to [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474) runs as expected. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/135 From github.com+7450507+fthevenet at openjdk.java.net Fri Mar 6 10:46:44 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 6 Mar 2020 10:46:44 GMT Subject: [Rev 01] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be larger than the running platform's maximum supported texture size, was addressed in openjfx14. > The fix, based around the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is currently only attempted after the original, non-tiled, strategy has already failed. > This was decided to avoid any risk of regressions, either in terms of performances and correctness, while still offering some relief to the original issue. > > This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is necessary while still introducing no regressions compared to the original solution. The pull request has been updated with 1 additional commit. ------------- Added commits: - 9ec2d25c: Added comments to computeOptimumTileSize. Also, Ensure isDivExact is set to false if needed. Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/e13b5a06..9ec2d25c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Fri Mar 6 10:46:44 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 6 Mar 2020 10:46:44 GMT Subject: [Rev 01] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 08:28:34 GMT, Ambarish Rapte wrote: >> The pull request has been updated with 1 additional commit. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1527: > >> 1526: private int computeOptimumTileSize(int size, int maxSize, AtomicBoolean isDivExact) { >> 1527: for (int n = 2; n <= 6; n++) { >> 1528: int optimumSize = size / n; > > It would be helpful if you add explanation about the constants 2 and 6 here. Good point. I've added the following comment: >// This methods attempts to find the smallest integer divider for the provided `size` >// while the result of the division is less than `maxSize`. >// It tests all potential dividers from 2 to 6 and returns the result of the division >// if all conditions can be satisfied or, failing that, `maxSize`. >// The value for `isDivExact` reflects whether or not an exact divider could be found. Please note that my choice of 6 for the largest attempted divider is totally arbitrary; we ideally want to maximize the chances to find an exact divider, but we also need to avoid making the tiles too small in the process and it seemed a good compromise. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From fastegal at openjdk.java.net Fri Mar 6 11:03:04 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 6 Mar 2020 11:03:04 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <6126ZbZJAQnIkjbSLBEHMokret4fi4266QMA9AWkrQo=.bd490049-dc1a-48b9-add5-bbe32da45873@github.com> <9NZtsyDeTXHfn2oFJyWffHzj4JdzGvHYN2MBmSmegFg=.26f69f11-52c6-49d5-995b-0cf85607073b@github.com> Message-ID: On Thu, 5 Mar 2020 21:47:35 GMT, Kevin Rushforth wrote: >> the api is in a related issue (should be noted in the issue above). The use-cases mentioned in the isssue: it's a do-once scenario with the skin (and its subclasses) as the only user: multiple listeners can be registered, typically by a skin and/or its subclasses, each can be pre/postpended (or replaced) in the chain for that property and all are unregistered at dispose time. So I think it's really bad to use it in another collaborator like the indicator, particularly if that is re-created often and each of the instances need to remove the listener. > > I think this will be fine. The `text` node is private to the `DeterminateIndicator` inner class and not exposed, so there would never be another listener. ahh yeah, you are right - somehow missed that text is private to the private indicator ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From aghaisas at openjdk.java.net Fri Mar 6 11:41:42 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 6 Mar 2020 11:41:42 GMT Subject: [Rev 03] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. > > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) The pull request has been updated with 1 additional commit. ------------- Added commits: - 3678da05: Add a simpler test for horizontal arrow press Changes: - all: https://git.openjdk.java.net/jfx/pull/114/files - new: https://git.openjdk.java.net/jfx/pull/114/files/bf67b084..3678da05 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/114/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/114/webrev.02-03 Stats: 226 lines in 1 file changed: 226 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/114.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/114/head:pull/114 PR: https://git.openjdk.java.net/jfx/pull/114 From aghaisas at openjdk.java.net Fri Mar 6 11:47:42 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 6 Mar 2020 11:47:42 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. > > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) The pull request has been updated with 1 additional commit. ------------- Added commits: - b987fcc8: extra space removed Changes: - all: https://git.openjdk.java.net/jfx/pull/114/files - new: https://git.openjdk.java.net/jfx/pull/114/files/3678da05..b987fcc8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/114/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/114/webrev.03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/114.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/114/head:pull/114 PR: https://git.openjdk.java.net/jfx/pull/114 From aghaisas at openjdk.java.net Fri Mar 6 12:03:43 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 6 Mar 2020 12:03:43 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: <0tRDVI5OpWjtsNdUxLNGfqRA_pw-yzEQHhW6Z6kVM1k=.6e8917b9-57a6-4bf7-bfc2-7319bbc2772d@github.com> On Sun, 1 Mar 2020 12:24:06 GMT, Jeanette Winzenburg wrote: >> @kleopatra is right about the need to handle the case where the orientation of a node changes. As for the test, I think the idea of parameterizing it with LTR, RTL is good. I haven't reviewed it in detail, but added one minor suggestion for you to consider. > > After digging a bit, a couple of notes (not entirely certain if this here is the correct place for them?) > > **Changing existing tests** > > Don't know what the culture in the fx context is, but: personally I prefer to not touch existing methods. Obvious reason is that I might break a test or test the wrong thing or tweak it in any way that makes it rather useless. > > An example of testing the wrong thingy on changing a test method might be test_rt18488_selectToLeft (guard against [JDK-8120174](https://bugs.openjdk.java.net/browse/JDK-8120174)). The report describes the misbehaviour as > > 1. select last cell in a row > 2. extend selection by keyboard backwards (that is to decreasing column indices), making cellMin selected > 3. shrink selection by keyboard by one cell (that is increasing column index) > 4. expected: cellMin unselected, actual (bug) cellMin still selected > > the block added for the rtl variant does test something else for > > 2. has no effect because it's already the upper boundary > 3. nothing to shrink, instead it extends by one > 4. nothing unselected > > **Parameterized Tests** > > repeating earlier comments (just to have it here for reading convenience): the goal of the parameterization is to make the test code (mostly) unaware of the parameters. In particular, if I feel the need for conditional test blocks - either in setup or in assert blocks - _on the parameters_, I often find out that something went wrong with the factoring. Not written in stone, though, could be me only :) > > **Alternative** > > My preference would be to not touch TableViewKeyInputTest at all, but to add a new test class exclusively for testing orientation-dependent horizontal navigation by keyboard. It should focus on what's actually changed, that is the _basic_ left/right/extend/shrink etc navigation and dynamic change of those. The class can be parameterized, the parameter being a triplet of orientation and forward/backward keys. > > The emphasis on _basic_ is intentional: I think that there is no need to cover all existing tests against bug reports nor more evolved navigation. Given all basic mappings are working as expected, everything built on top should work as well - might be wrong or there might be exceptions :) > > For a bit of clarity - hopefully- of what I mean, I put togeter a raw poc example [TableViewHorizontalArrowsTest](https://github.com/kleopatra/jfx/blob/experiment-tableview-navigation-rtl-bug-8235480/modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java)) Thanks @kleopatra for thinking through clearly about testing and providing a simpler test approach with PoC. I agree with *NOT* modifying existing horizontal key navigation tests to test for NodeOrientation. Testing this separately in a new test does make sense. 1. I liked the approach proposed in PoC except the need to send KeyMapping as a parameter to the test. It unnecessarily makes test look complex. We already have backward() and forward() helper functions in this test class. The Key presses can easily be decided based on orientation in these methods. I have modified the PoC test provided by you to make it simpler. 2. Also, in PoC, testChangeOrientationSimpleForwardSelect does not respect forward selection after Node orientation is changed. The comment says it all - `// same arrow as initial,now should have inverse effect` The forward movement should still be forward even after Node orientation change and not inverse. I have done modifications to the PoC code provided and added this test in latest commit. Please review. Once we agree on the approach- - I will add other tests for horizontal keyMappings with modifiers to TableViewHorizontalArrowsTest - I will revert changes done to TableViewKeyInputTest ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From kcr at openjdk.java.net Fri Mar 6 12:53:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 12:53:53 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 06:00:36 GMT, Robert Lichtenberger wrote: >> I have exactly the same question. >> >> In general, it's better to work with the author of an existing PR instead of creating a new one. If the original PR #73 is completely stalled, then it might make sense, but not until then. > > I wasn't aware of PR #73, I only saw the (very old) issue in the JDK Bug System and started to look into the issue. > The fact that two different people start to look into the same issue shows it is important however :-). > Should I close this PR and participate in PR #73? Yes, that seems best. If that one stalls, you can always reopen this. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From David.Grieve at microsoft.com Fri Mar 6 14:29:24 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Fri, 6 Mar 2020 14:29:24 +0000 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: <03DF5DCD-BE78-43E1-9F79-2828B847BE4D@screamingfrog.co.uk> References: <03DF5DCD-BE78-43E1-9F79-2828B847BE4D@screamingfrog.co.uk> Message-ID: This might fix the issue, but I?d like to understand better what the root of the problem is. My concern is that this fix might cause a performance regression. I?m using the code in JDK-8177945. I want to look at what TableView does when it adds a cell. Is there something about the selected state that changes? Or is this just the CSS implementation recalculating styles and un-necessarily clearing old values? Some debugging is in order. From: Danny Gonzalez Sent: Wednesday, March 4, 2020 4:34 AM To: David Grieve Cc: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when adding data to TableView Hi David, Just wanted to add some more information. The cell selection flashing issue goes away If I put back the following code in the layout function in Parent.java: // // One idiom employed by developers is to, during the layout pass, // add or remove nodes from the scene. For example, a ScrollPane // might add scroll bars to itself if it determines during layout // that it needs them, or a ListView might add cells to itself if // it determines that it needs to. In such situations we must // apply the CSS immediately and not add it to the scene's queue // for deferred action. // // Note that we only call processCSS if the flag is update. If the // flag is DIRTY_BRANCH, then the whatever children need UPDATE // will be visited during this layout anyway. On the next pulse, // doCSSPass will clean up the DIRTY_BRANCH nodes. // if (cssFlag == CssFlags.UPDATE) { processCSS(); } This code was originally added in in the following commit: commit e76b5755d4d2752037cc95eb75cb2615a740cc30 Author: David Grieve > Date: Thu Apr 10 15:40:34 2014 -0400 RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply css to child nodes if nothing has changed. 2 - on applyCss, only look for ancestor node with css state = UPDATE. 3 - only recalculate checksum of css file if the file has been removed from a scene or parent It was reverted out in this commit: commit 05afad6b528e871d607b76aea2642cf788b417fe Author: David Grieve > Date: Tue Apr 15 11:51:38 2014 -0400 RT-36672: move code to process css during layout back to impl_reapplyCSS, which is where it was priort to RT-36559 This was the point at which the cell selection flashing appeared. Thanks Danny On 3 Mar 2020, at 16:50, David Grieve > wrote: The importance of 05afad6 Is there in the commit itself: + // + // One idiom employed by developers is to, during the layout pass, + // add or remove nodes from the scene. For example, a ScrollPane + // might add scroll bars to itself if it determines during layout + // that it needs them, or a ListView might add cells to itself if + // it determines that it needs to. In such situations we must + // apply the CSS immediately and not add it to the scene's queue + // for deferred action. + If you revert 05afad6, you'll break this. This is the first time I've become aware of this flickering issue. I'll have to look at it. I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK-8193445 has any impact on this. -----Original Message----- From: openjfx-dev > On Behalf Of Danny Gonzalez Sent: Tuesday, March 3, 2020 11:14 AM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding data to TableView There is currently an open bug to do with the issue of selection flickering when using single cell selection and when adding data to a TableView. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb 8AwcRXVrfLo%3D&reserved=0 This bug seems to be low priority because it hasn?t been looked at since I submitted it at the start of 2017. This is quite a major issue for us so I have narrowed down when the issue was first introduced. Here is the changeset: commit 05afad6b528e871d607b76aea2642cf788b417fe Author: David Grieve >> Date: Tue Apr 15 11:51:38 2014 -0400 RT-36672: move code to process css during layout back to impl_reapplyCSS, which is where it was priort to RT-36559 I can?t search the bug database for this bug ID as I believe it was submitted when a previous bug tracking system was in use. Does anyone have any knowledge as to why this fix was needed and what the repercussions would be if I reverted it out for our local OpenJFX build. Alternatively I would be glad to receive any suggestions of how to fix the flickering issue if this changeset is important to leave in. Thanks Danny From jvos at openjdk.java.net Fri Mar 6 15:21:56 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 6 Mar 2020 15:21:56 GMT Subject: [jfx14] RFR: 8240631: Create release notes for JavaFX 14 Message-ID: Add release notes for JavaFX 14 release Fix for JDK-8240631 ------------- Commits: - 9db2ff25: Add release notes for JavaFX 14 release Changes: https://git.openjdk.java.net/jfx/pull/139/files Webrev: https://webrevs.openjdk.java.net/jfx/139/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240631 Stats: 81 lines in 1 file changed: 81 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/139.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/139/head:pull/139 PR: https://git.openjdk.java.net/jfx/pull/139 From kcr at openjdk.java.net Fri Mar 6 16:06:44 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 16:06:44 GMT Subject: [jfx14] RFR: 8240631: Create release notes for JavaFX 14 In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 15:16:43 GMT, Johan Vos wrote: > Add release notes for JavaFX 14 release > Fix for JDK-8240631 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/139 From nlisker at openjdk.java.net Fri Mar 6 17:55:37 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 Mar 2020 17:55:37 GMT Subject: RFR: 8240689: Remove the JavaBeanXxxPropertyBuilders constructors Message-ID: Followup to the deprecation of the JavaBeanXxxPropertyBuilders constructors. [CSR](https://bugs.openjdk.java.net/browse/JDK-8240689) ------------- Commits: - 7548c723: Initial commit Changes: https://git.openjdk.java.net/jfx/pull/140/files Webrev: https://webrevs.openjdk.java.net/jfx/140/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240689 Stats: 70 lines in 14 files changed: 0 ins; 56 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/140.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/140/head:pull/140 PR: https://git.openjdk.java.net/jfx/pull/140 From nlisker at openjdk.java.net Fri Mar 6 18:24:44 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 Mar 2020 18:24:44 GMT Subject: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: <_HNFVDsQ85Z0KGW0RBp3d82tVdLlpK_rJL8i3bI6tHM=.ddd98a4f-2e6e-44e5-af3e-2db37364cbf0@github.com> On Fri, 6 Mar 2020 17:51:08 GMT, Nir Lisker wrote: > Followup to the deprecation of the JavaBeanXxxPropertyBuilders constructors. > > [CSR](https://bugs.openjdk.java.net/browse/JDK-8240689) Why was the rfr label not reinstated? ------------- PR: https://git.openjdk.java.net/jfx/pull/140 From kcr at openjdk.java.net Fri Mar 6 18:29:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 18:29:34 GMT Subject: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: <_HNFVDsQ85Z0KGW0RBp3d82tVdLlpK_rJL8i3bI6tHM=.ddd98a4f-2e6e-44e5-af3e-2db37364cbf0@github.com> References: <_HNFVDsQ85Z0KGW0RBp3d82tVdLlpK_rJL8i3bI6tHM=.ddd98a4f-2e6e-44e5-af3e-2db37364cbf0@github.com> Message-ID: On Fri, 6 Mar 2020 18:22:24 GMT, Nir Lisker wrote: >> Followup to the deprecation of the JavaBeanXxxPropertyBuilders constructors. >> >> [CSR](https://bugs.openjdk.java.net/browse/JDK-8240689) > > Why was the rfr label not reinstated? @edvbld @rwestberg This is affected by https://bugs.openjdk.java.net/browse/SKARA-262 ------------- PR: https://git.openjdk.java.net/jfx/pull/140 From prr at openjdk.java.net Fri Mar 6 19:15:04 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 Mar 2020 19:15:04 GMT Subject: RFR: 8236685: [macOs] Remove obsolete file dialog subclasses In-Reply-To: References: Message-ID: On Wed, 4 Mar 2020 20:27:46 GMT, Kevin Rushforth wrote: > This is a follow-on to [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474). > > This fix removes the custom subclasses of NSSavePanel and NSOpenPanel that are optionally used by the glass implementation of file open, directory open, and file save. These subclasses were originally added to provide support for keyboard shortcuts for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V) operations that the standard Apple dialogs do not support directly; applications can add their own support, but JavaFX is a library not an application. > > Note that as of macOS 10.15, all file dialogs on Mac are run in a spearate process. Attempts to subclass NSSavePanel and NSOpenPanel are no longer supported. They are either ineffective (silently ignored) or else crash the application. As a result of the crashes that were happening in some environments, the fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474) uses the NSSavePanel and NSOpenPanel base classes directly when running on macOS 10.15 or later. The proposed fix for this follow-on issue, [JDK-8236685](https://bugs.openjdk.java.net/browse/JDK-8236685), will use NSSavePanel and NSOpenPanel directly on all versions of macOS. > > Note that Copy, Cut, and Paste functionality are available with the menu before and after this fix. This only impacts the keyboard shortcuts. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/135 From kcr at openjdk.java.net Fri Mar 6 19:19:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 19:19:42 GMT Subject: [Integrated] RFR: 8236685: [macOs] Remove obsolete file dialog subclasses In-Reply-To: References: Message-ID: <380dde53-2b58-4c66-bc2f-6f378eb0aed5@openjdk.org> Changeset: cfa11934 Author: Kevin Rushforth Date: 2020-03-06 19:19:17 +0000 URL: https://git.openjdk.java.net/jfx/commit/cfa11934 8236685: [macOs] Remove obsolete file dialog subclasses Reviewed-by: arapte, prr ! modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.h ! modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m ! modules/javafx.graphics/src/main/native-glass/mac/GlassDialogs.m From kcr at openjdk.java.net Fri Mar 6 19:55:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 19:55:15 GMT Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: References: Message-ID: On Wed, 4 Mar 2020 14:11:42 GMT, Erik Helin wrote: >> Please ignore this comment, this is for debugging Skara that might have some mailing list mirroring issues ?? > > Please ignore this comment as well, it is also for debugging issues with Skara and mailman :email: ?? @aghaisas can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/134 From kcr at openjdk.java.net Fri Mar 6 20:48:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 20:48:53 GMT Subject: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 17:51:08 GMT, Nir Lisker wrote: > Followup to the deprecation of the JavaBeanXxxPropertyBuilders constructors. > > [CSR](https://bugs.openjdk.java.net/browse/JDK-8240689) Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/140 From kcr at openjdk.java.net Fri Mar 6 20:48:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 20:48:53 GMT Subject: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 20:45:23 GMT, Kevin Rushforth wrote: >> Followup to the deprecation of the JavaBeanXxxPropertyBuilders constructors. >> >> [CSR](https://bugs.openjdk.java.net/browse/JDK-8240689) > > Marked as reviewed by kcr (Lead). @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/140 From kcr at openjdk.java.net Fri Mar 6 21:40:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 21:40:25 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 11:47:42 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 >> >> Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. >> >> Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. >> >> Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) > > The pull request has been updated with 1 additional commit. I think the fix looks good and the approach you took for the new test looks good to me. If @kleopatra is OK with it, then please proceed. I left a couple minor comments. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java line 150: > 149: new KeyMapping(LEFT, e -> { if(isRTL()) selectRightCell(); else selectLeftCell(); }), > 150: new KeyMapping(KP_LEFT,e -> { if(isRTL()) selectRightCell(); else selectLeftCell(); }), > 151: new KeyMapping(RIGHT, e -> { if(isRTL()) selectLeftCell(); else selectRightCell(); }), OK, I checked into this a little more closely and I can't think if a cleaner way to do it. What I originally suggested (using a ternary operator) doesn't work. And the other thing I was going to suggest, that of creating new methods like `selectForwardCell` (kind of like you did in the test) isn't worth the effort, since each is only repeated twice and it would likely result in code that isn't any easier to understand or maintain. So I think what you've done is fine. Btw, I guess you didn't mean to remove the space after the `,` here? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 202: > 201: > 202: // Now, test that the forward select resprects change in NodeOrientation > 203: forward(); Typo: should be "respects" modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 51: > 50: /** > 51: * Test basic horizontal navigation mappings for TableView. It's parametrized on NodeOrientation > 52: */ Typo: should be parameterized modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 219: > 218: > 219: // Now, test that the backward select resprects change in NodeOrientation > 220: backward(); "respects" ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From nlisker at openjdk.java.net Fri Mar 6 22:53:45 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 Mar 2020 22:53:45 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects Message-ID: A simple readability cleanup for the files that were changed in #113. Note that the boolean property has an `instanceof` check that doesn't exist in the other properties. ------------- Commits: - 15f50f17: Initial commit Changes: https://git.openjdk.java.net/jfx/pull/141/files Webrev: https://webrevs.openjdk.java.net/jfx/141/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240692 Stats: 167 lines in 6 files changed: 12 ins; 124 del; 31 mod Patch: https://git.openjdk.java.net/jfx/pull/141.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/141/head:pull/141 PR: https://git.openjdk.java.net/jfx/pull/141 From kcr at openjdk.java.net Fri Mar 6 23:15:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Mar 2020 23:15:15 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 22:43:50 GMT, Nir Lisker wrote: > A simple readability cleanup for the files that were changed in #113. > > Note that the boolean property has an `instanceof` check that doesn't exist in the other properties. I note that this also changes the wrapper property objects from anonymous subclasses of XxxxxPropertyBase to SimpleXxxxxProperty. This is more than just a readability cleanup. It's probably fine for this case, but that's why I want a second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From nlisker at openjdk.java.net Fri Mar 6 23:38:03 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 6 Mar 2020 23:38:03 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 23:12:57 GMT, Kevin Rushforth wrote: >> A simple readability cleanup for the files that were changed in #113. >> >> Note that the boolean property has an `instanceof` check that doesn't exist in the other properties. > > I note that this also changes the wrapper property objects from anonymous subclasses of XxxxxPropertyBase to SimpleXxxxxProperty. This is more than just a readability cleanup. It's probably fine for this case, but that's why I want a second reviewer. > I note that this also changes the wrapper property objects from anonymous subclasses of XxxxxPropertyBase to SimpleXxxxxProperty. This is more than just a readability cleanup. It's probably fine for this case, but that's why I want a second reviewer. Isn't SimpleXxxxxProperty exactly made for XxxxxPropertyBase with the built-in overrides for the bean and the name? When is this substitution not fine? ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From nlisker at openjdk.java.net Sat Mar 7 00:25:13 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 7 Mar 2020 00:25:13 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 23:35:56 GMT, Nir Lisker wrote: >> I note that this also changes the wrapper property objects from anonymous subclasses of XxxxxPropertyBase to SimpleXxxxxProperty. This is more than just a readability cleanup. It's probably fine for this case, but that's why I want a second reviewer. > >> I note that this also changes the wrapper property objects from anonymous subclasses of XxxxxPropertyBase to SimpleXxxxxProperty. This is more than just a readability cleanup. It's probably fine for this case, but that's why I want a second reviewer. > > Isn't SimpleXxxxxProperty exactly made for XxxxxPropertyBase with the built-in overrides for the bean and the name? When is this substitution not fine? That doesn't seem right. The additional fields are captured in the anonymous class anyway (same as in lambdas). On Sat, Mar 7, 2020 at 1:53 AM Tom Schindl wrote: > I can somehow remember asking Richard Bair why JavaFX internally does not > use Simple* but creates the anonymous subclasses and he said it's memory > reason - Simple* uses more memory because of the additional fields > > ? > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From github.com+52631+tomsontom at openjdk.java.net Sat Mar 7 00:32:32 2020 From: github.com+52631+tomsontom at openjdk.java.net (Tom Schindl) Date: Sat, 7 Mar 2020 00:32:32 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Sat, 7 Mar 2020 00:22:59 GMT, Nir Lisker wrote: >> I can somehow remember asking Richard Bair why JavaFX internally does not use Simple* but creates the anonymous subclasses and he said it's memory reason - Simple* uses more memory because of the additional fields > > That doesn't seem right. The additional fields are captured in the > anonymous class anyway (same as in lambdas). > > On Sat, Mar 7, 2020 at 1:53 AM Tom Schindl wrote: > >> I can somehow remember asking Richard Bair why JavaFX internally does not >> use Simple* but creates the anonymous subclasses and he said it's memory >> reason - Simple* uses more memory because of the additional fields >> >> ? >> You are receiving this because you were assigned. >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> >> . >> the subclass saves the owner field who is a static null, not? ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From github.com+52631+tomsontom at openjdk.java.net Sat Mar 7 00:28:44 2020 From: github.com+52631+tomsontom at openjdk.java.net (Tom Schindl) Date: Sat, 7 Mar 2020 00:28:44 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 23:35:56 GMT, Nir Lisker wrote: >> I note that this also changes the wrapper property objects from anonymous subclasses of XxxxxPropertyBase to SimpleXxxxxProperty. This is more than just a readability cleanup. It's probably fine for this case, but that's why I want a second reviewer. > >> I note that this also changes the wrapper property objects from anonymous subclasses of XxxxxPropertyBase to SimpleXxxxxProperty. This is more than just a readability cleanup. It's probably fine for this case, but that's why I want a second reviewer. > > Isn't SimpleXxxxxProperty exactly made for XxxxxPropertyBase with the built-in overrides for the bean and the name? When is this substitution not fine? I can somehow remember asking Richard Bair why JavaFX internally does not use Simple* but creates the anonymous subclasses and he said it's memory reason - Simple* uses more memory because of the additional fields ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From nlisker at openjdk.java.net Sat Mar 7 00:51:43 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 7 Mar 2020 00:51:43 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Sat, 7 Mar 2020 00:30:21 GMT, Tom Schindl wrote: >> That doesn't seem right. The additional fields are captured in the >> anonymous class anyway (same as in lambdas). >> >> On Sat, Mar 7, 2020 at 1:53 AM Tom Schindl wrote: >> >>> I can somehow remember asking Richard Bair why JavaFX internally does not >>> use Simple* but creates the anonymous subclasses and he said it's memory >>> reason - Simple* uses more memory because of the additional fields >>> >>> ? >>> You are receiving this because you were assigned. >>> Reply to this email directly, view it on GitHub >>> , >>> or unsubscribe >>> >>> . >>> > > the subclass saves the owner field who is a static null, not? >From what I see, they save the same data. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From jvos at openjdk.java.net Sat Mar 7 09:13:39 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 7 Mar 2020 09:13:39 GMT Subject: [Integrated] [jfx14] RFR: 8240631: Create release notes for JavaFX 14 In-Reply-To: References: Message-ID: <99b8d18e-85e6-42f7-8d6f-669cfe9be067@openjdk.org> Changeset: f8c235bb Author: Johan Vos Date: 2020-03-07 09:12:44 +0000 URL: https://git.openjdk.java.net/jfx/commit/f8c235bb 8240631: Create release notes for JavaFX 14 Reviewed-by: kcr + doc-files/release-notes-14.md From kcr at openjdk.java.net Sat Mar 7 14:14:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 7 Mar 2020 14:14:13 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Sat, 7 Mar 2020 00:49:28 GMT, Nir Lisker wrote: >> the subclass saves the owner field who is a static null, not? > > From what I see, they save the same data. The anonymous subclasses don't have an instance field for the `bean` or the `name`, so the tradeoff is one of static footprint (an extra anonymous inner class) for dynamic footprint (slightly larger instances). Note, however, that this savings is reduced by the fact that the inner classes have a `this$0` pointer to the enclosing class. I think this means that we are really only saving one reference variable per instance of the anonymous inner class versus an instance of SimpleXxxxProperty. That's why I think that in the specific case of this proposed fix, it should be fine. I just want to take a closer look. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From kcr at openjdk.java.net Sat Mar 7 14:25:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 7 Mar 2020 14:25:02 GMT Subject: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: <2QEHNYmpJCI0cwl1klk5ANi0xVqXOtxbELg1EtA-XGs=.9289afb2-8aa8-4b16-ae50-b46373254fa4@github.com> On Fri, 6 Mar 2020 20:46:39 GMT, Kevin Rushforth wrote: >> Marked as reviewed by kcr (Lead). > > @arapte can you also review this? Now the the CSR is approved, we need something to "wake up" the Skara bot to notice that. @edvbld @rwestberg is there a command that you would recommend to do this? Maybe typing `/summary` without actually adding a summary? Failing that we can wait for the second reviewer, but it would be nice to test Skara's CSR support prior to that (this is the first one where we've had an approved CSR since starting to use the `/csr` feature). ------------- PR: https://git.openjdk.java.net/jfx/pull/140 From lior.yaffe at jelurida.com Sat Mar 7 19:04:19 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Sat, 7 Mar 2020 21:04:19 +0200 Subject: NPE during webview shutdown Message-ID: After calling Platform.exit() of a webview running inside a Java FX frame we sometimes see the following Exception in the console printed one or more times without any functional impact: Exception in thread "jfx" java.lang.NullPointerException at com.sun.javafx.tk.quantum.QuantumToolkit.isSupported(QuantumToolkit.java:1164) at com.sun.javafx.application.PlatformImpl.isSupportedImpl(PlatformImpl.java:954) at com.sun.javafx.application.PlatformImpl.isSupported(PlatformImpl.java:627) at javafx.application.Platform.isSupported(Platform.java:250) at com.sun.javafx.scene.input.PickResultChooser.processOffer(PickResultChooser.java:182) at com.sun.javafx.scene.input.PickResultChooser.offer(PickResultChooser.java:143) at javafx.scene.Node.doComputeIntersects(Node.java:5252) at javafx.scene.Node.access$600(Node.java:398) at javafx.scene.Node$1.doComputeIntersects(Node.java:456) at com.sun.javafx.scene.NodeHelper.computeIntersectsImpl(NodeHelper.java:180) at com.sun.javafx.scene.NodeHelper.computeIntersects(NodeHelper.java:133) at javafx.scene.Node.intersects(Node.java:5223) at javafx.scene.Node$1.intersects(Node.java:543) at com.sun.javafx.scene.NodeHelper.intersects(NodeHelper.java:258) at javafx.scene.web.WebView.doPickNodeLocal(WebView.java:1214) at javafx.scene.web.WebView.access$2800(WebView.java:101) at javafx.scene.web.WebView$11.doPickNodeLocal(WebView.java:1301) at com.sun.java.scene.web.WebViewHelper.pickNodeLocalImpl(WebViewHelper.java:89) at com.sun.javafx.scene.NodeHelper.pickNodeLocal(NodeHelper.java:128) at javafx.scene.Node.pickNode(Node.java:5192) at javafx.scene.Scene$MouseHandler.pickNode(Scene.java:3993) at javafx.scene.Scene$MouseHandler.access$1300(Scene.java:3579) at javafx.scene.Scene.pick(Scene.java:2029) at javafx.scene.Scene.access$6800(Scene.java:172) at javafx.scene.Scene$MouseHandler.process(Scene.java:3805) at javafx.scene.Scene$MouseHandler.access$1200(Scene.java:3579) at javafx.scene.Scene.processMouseEvent(Scene.java:1849) at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2588) at com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:397) at com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:295) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:434) at com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:390) at com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:433) at com.sun.glass.ui.View.handleMouseEvent(View.java:556) at com.sun.glass.ui.View.notifyMouse(View.java:942) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) at java.base/java.lang.Thread.run(Thread.java:830) This Exception appears in several past bug reports as fixed but I can still reproduce it with all versions. From nlisker at gmail.com Sat Mar 7 21:12:18 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 7 Mar 2020 23:12:18 +0200 Subject: Release notes presentation Message-ID: Hi, I posted the release notes for OpenJFX 14 on Reddit. The top comment [1] complained about the presentation. Maybe on openjfx.io the Release Notes link could show a more "friendly" summary with a link to the detailed table. I suggest: 1. Including only changes that matter to the users of the library with separate sections for new API and for (non-internal) bug fixes. 2. Highlighting significant changes. Some example bug fixes to include: - TableView, ListView: unexpected scrolling behaviour on up/down keys - DragAndDrop no longer works with GTK3 - Window order is not correct when Modality.WINDOW_MODAL Don't include: - [WebView] Sub-resource integrity check fails on Windows and Linux - javafx.web build fails on XCode 10.2 - Cherry pick GTK WebKit ___ changes Enhancements to include: - Add support for e-paper displays - Add exclusion scope for LightBase - Point2D and Point3D should implement Interpolatable Don't include: - Color, Point2D and Point3D's fields should be made final Thoughts? - Nir [1] https://www.reddit.com/r/java/comments/fegcv9/release_notes_for_javafx_14/fjphqfn?utm_source=share&utm_medium=web2x From abhinay_agarwal at live.com Sun Mar 8 08:21:35 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Sun, 8 Mar 2020 08:21:35 +0000 Subject: ComboBox keypress discrepancy In-Reply-To: <0F5B44EE-E337-48BE-BD23-E1DB4D7B43A2@gmail.com> References: , <0F5B44EE-E337-48BE-BD23-E1DB4D7B43A2@gmail.com> Message-ID: Hi Dirk, Exactly. The TAB key press event not firing at all seems fishy. -- Abhinay ________________________________ From: Dirk Lemmermann Sent: Friday, March 6, 2020 2:55 PM To: Abhinay Agarwal Cc: openjfx-dev at openjdk.java.net Subject: Re: ComboBox keypress discrepancy Regarding expected behaviour: in native combo boxes / dropdowns on Mac the TAB key is doing nothing when the popup is open. If you want to select an item you need to use the arrow keys. So I guess that is what I would expect for navigating the element. But that does not mean that the key event can?t fire, right? Some subclass / custom control might have a need for it. Dirk Am 06.03.2020 um 05:59 schrieb Abhinay Agarwal >: Hi Dirk, Thanks for reaching out. As stated earlier, I want to know what exactly is causing this change in behaviour. I also want to know what is the expected behaviour in this case: should TAB key press trigger when the popupwindow is showing? -- Abhinay ________________________________ From: Dirk Lemmermann > Sent: Thursday, March 5, 2020 6:39 PM To: Abhinay Agarwal > Cc: openjfx-dev at openjdk.java.net > Subject: Re: ComboBox keypress discrepancy So what info do you need? What test do you want us to run? I ran it on MacOS X with Java 14ea and I DO NOT see the ?TAB? output. Dirk Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal >: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.ComboBox; import javafx.scene.input.KeyEvent; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class Main extends Application { @Override public void start(Stage primaryStage) { final ComboBox stringComboBox = new ComboBox<>(); stringComboBox.getItems().addAll("John", "Jacob", "Schmidt"); stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> System.out.println(kp.getCode())); final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 275); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } From nlisker at openjdk.java.net Sun Mar 8 12:50:06 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 8 Mar 2020 12:50:06 GMT Subject: [Rev 01] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 10:46:44 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be larger than the running platform's maximum supported texture size, was addressed in openjfx14. >> The fix, based around the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is currently only attempted after the original, non-tiled, strategy has already failed. >> This was decided to avoid any risk of regressions, either in terms of performances and correctness, while still offering some relief to the original issue. >> >> This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is necessary while still introducing no regressions compared to the original solution. > > The pull request has been updated with 1 additional commit. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1296: > 1295: int width = Math.max(xMax - xMin, 1); > 1296: int height = Math.max(yMax - yMin, 1); > 1297: if (wimg == null) { The changes here do not need to be reverted, this is still extra calculation. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From debayansutradhar3 at gmail.com Mon Mar 9 07:48:00 2020 From: debayansutradhar3 at gmail.com (Debayan Sutradhar) Date: Mon, 9 Mar 2020 13:18:00 +0530 Subject: Raspberry Pi 4 hw support Message-ID: I have a large embedded project for raspberry pis (https://stream-pi.com) and recently its discord server crosses 60 members and growing every month. Unfortunately it seems that Hardware acceleration doesnt work on VideoCore VI. If es2 pipeline is used, the program exits after the output "* failed to add service - already in use?" Hence for now we are using sw pipeline to use javafx apps. That makes them very slow and touch gestures don't work as expect. Regards, Debayan Sutradhar From github.com+7450507+fthevenet at openjdk.java.net Mon Mar 9 10:01:53 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 9 Mar 2020 10:01:53 GMT Subject: [Rev 02] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be larger than the running platform's maximum supported texture size, was addressed in openjfx14. > The fix, based around the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is currently only attempted after the original, non-tiled, strategy has already failed. > This was decided to avoid any risk of regressions, either in terms of performances and correctness, while still offering some relief to the original issue. > > This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is necessary while still introducing no regressions compared to the original solution. The pull request has been updated with 1 additional commit. ------------- Added commits: - 9c5b0d4a: Avoid useless width and height calculation Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/9ec2d25c..9c5b0d4a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.01-02 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Mon Mar 9 10:01:54 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 9 Mar 2020 10:01:54 GMT Subject: [Rev 01] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Sun, 8 Mar 2020 12:47:52 GMT, Nir Lisker wrote: >> The pull request has been updated with 1 additional commit. > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1296: > >> 1295: int width = Math.max(xMax - xMin, 1); >> 1296: int height = Math.max(yMax - yMin, 1); >> 1297: if (wimg == null) { > > The changes here do not need to be reverted, this is still extra calculation. Well spotted. I've re-applied that change. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From arapte at openjdk.java.net Mon Mar 9 12:13:33 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 9 Mar 2020 12:13:33 GMT Subject: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 17:51:08 GMT, Nir Lisker wrote: > Followup to the deprecation of the JavaBeanXxxPropertyBuilders constructors. > > [CSR](https://bugs.openjdk.java.net/browse/JDK-8240689) Looks good to me. Observed no build errors for apps, tests. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/140 From fastegal at swingempire.de Mon Mar 9 12:53:58 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 09 Mar 2020 13:53:58 +0100 Subject: Release notes presentation In-Reply-To: References: Message-ID: <20200309135358.Horde.CKAp2hMc0Pf6S-M1_A0LYQ1@webmail.df.eu> agree with better highlighting of the important changes/issues disagree with leaving out the not so important - that's in the eye of the reader, anyway - changes/issues: after all, the target readership are technicians, not suits :) -- Jeanette Zitat von Nir Lisker : > Hi, > > I posted the release notes for OpenJFX 14 on Reddit. The top comment [1] > complained about the presentation. Maybe on openjfx.io the Release Notes > link could show a more "friendly" summary with a link to the detailed > table. I suggest: > > 1. Including only changes that matter to the users of the library with > separate sections for new API and for (non-internal) bug fixes. > 2. Highlighting significant changes. > > Some example bug fixes to include: > - TableView, ListView: unexpected scrolling behaviour on up/down keys > - DragAndDrop no longer works with GTK3 > - Window order is not correct when Modality.WINDOW_MODAL > > Don't include: > - [WebView] Sub-resource integrity check fails on Windows and Linux > - javafx.web build fails on XCode 10.2 > - Cherry pick GTK WebKit ___ changes > > Enhancements to include: > - Add support for e-paper displays > - Add exclusion scope for LightBase > - Point2D and Point3D should implement Interpolatable > > Don't include: > - Color, Point2D and Point3D's fields should be made final > > Thoughts? > > - Nir > > [1] > https://www.reddit.com/r/java/comments/fegcv9/release_notes_for_javafx_14/fjphqfn?utm_source=share&utm_medium=web2x From nlisker at openjdk.java.net Mon Mar 9 16:38:48 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 9 Mar 2020 16:38:48 GMT Subject: [Integrated] RFR: 8240689: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: <7ccc2787-ee27-4daf-8167-d42b07e1c58e@openjdk.org> Changeset: e3026b9c Author: Nir Lisker Date: 2020-03-09 16:38:20 +0000 URL: https://git.openjdk.java.net/jfx/commit/e3026b9c 8240688: Remove the JavaBeanXxxPropertyBuilders constructors Reviewed-by: kcr, arapte ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanDoublePropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanIntegerPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanLongPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanObjectPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanStringPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyBuilder.java From arapte at openjdk.java.net Tue Mar 10 06:08:02 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 10 Mar 2020 06:08:02 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <0_XCcksGLJ7c4JWWxHLiTILxdojcsoZevBk9p1ZhDd8=.8d142a85-38fb-4aeb-bb2a-25c4659e02e4@github.com> Message-ID: On Fri, 28 Feb 2020 18:06:30 GMT, Frederic Thevenet wrote: >> I've marked this PR as a WIP for the time being because I've only tested it on the d3d rendering pipeline so far, so I >> think it is too early to call for a formal review yet. Still, I welcome feedback if someone wants to have a look at it >> already. >> In a nutshell, this is what this PR does: >> >> - Reverts changes from 8088198 >> - Implements tiling within `QuantumToolkit::renderToImage` instead >> - Gets the maxTextureSize directly from the `ResourceFactory` instance instead of relying on >> `PrismSettings.maxTextureSize` (which may be wrong in the event the maxTexture size supported by the hardware is less >> than the clamped value set in PrismSettings) Tries to align the PixelFomat for the target `WritableImage` with that of >> the `RTTexture` when possible, since converting IntARGB to ByteBGRA (or the other way round) is a major cost factor >> when copying large amounts of pixels. Avoids as much as possible having to resize the tile in between subsequent calls >> to `RTTexture::readPixels`, as it is another major cost factor, under the d3d rendering pipeline at least. (Native >> method `D3DResourceFactory_nReadPixels` attempts to reuse the same surface in between calls but is forced to create a >> new one if dimensions are not exactly the same, which is quite costly). >> >> TODO: >> >> - [x] Make sure chosen PixelFormat is optimum when using es2 pipeline. >> - [ ] Consider using subtexture pixel read with es2 (SW and d3d don't support it) as a better alternative to relying on >> same size tiles to avoid surface thrashing. > > I finally got a chance to do some more extensive testing when running this patch with the es2 pipeline on Linux. > It works as expected, and from what I saw, using a IntARGB pixelBuffer when no WritableImage is provided avoids > swapping around pixel components, like under d3d. I've also verified than the patch's behaviour is correct when a > writable image is provided as a parameter to Node.snapshot, whether the underlying image is actually a PlatformImage or > a wrapper for a PixelBuffer, which corrects another limitation of the previous implementation. On My windows10 machine, I can observe 20 to 30 % reduction in time to take snapshot. Can you please capture the time the way you did [here](https://github.com/openjdk/jfx/pull/68#issuecomment-578192074) for previous PR ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7517141+yososs at openjdk.java.net Tue Mar 10 06:10:34 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 10 Mar 2020 06:10:34 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: On Mon, 2 Mar 2020 11:47:03 GMT, Nir Lisker wrote: >>> >>> >>> I think that a starting point would be to decide on a spec for the listener notification order: is it specified by >>> their registration order, or that is it unspecified, in which case we can take advantage of this for better >>> performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. >> >> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time >> (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, >> we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing >> it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin >> has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal >> code does it .. > >> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time >> (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, >> we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing >> it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin >> has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal >> code does it .. > > So we can choose to specify it as ordered. > > These are the 2 options I mentioned: > 1. Not specify the behavior and change the implementation in favor of performance. This could break applications as > you've mentioned. 2. Specify that the order is preserved and keep the ordered implementation behavior. This will allow > applications to rely on the behavior safely. > Right now we're losing on both sides. We keep a promise and we don't tell anyone about it. The only reason for this is > if we intend to change the behavior in the future, in which case we should add a doc comment saying that the order is > unspecified and is planned to change in the future, so there will be at least some warning. Once we choose what to do > here it will make sense to continue to review the code with that decision in mind. In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce the performance improvement. I have attached a test program in my PR(#125) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 10 10:31:52 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 10 Mar 2020 10:31:52 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <0_XCcksGLJ7c4JWWxHLiTILxdojcsoZevBk9p1ZhDd8=.8d142a85-38fb-4aeb-bb2a-25c4659e02e4@github.com> Message-ID: On Tue, 10 Mar 2020 10:29:11 GMT, Frederic Thevenet wrote: >> On My windows10 machine, I can observe 20 to 30 % reduction in time to take snapshot. >> Can you please capture the time the way you did [here](https://github.com/openjdk/jfx/pull/68#issuecomment-578192074) >> for previous PR > > ### 14-ea+9 > > -------- > | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | > |---|---|---|---|---|---|---|---|---|---| > | 1024 | 5.607827 | 9.380503 | 13.835523 | 17.514362 | 21.776304 | 27.918815 | 36.929480 | 35.647317 | 74.274598 | > | 2048 | 11.271960 | 17.774451 | 26.468146 | 34.555745 | 42.699573 | 52.027568 | 74.481450 | 68.349699 | 135.902502 | > | 3072 | 13.953309 | 26.320822 | 42.652327 | 51.534650 | 65.202531 | 78.406419 | 103.512338 | 109.125337 | 214.305998 | > | 4096 | 17.776236 | 35.800101 | 57.483720 | 70.221125 | 98.024908 | 106.510784 | 109.940266 | 150.731465 | 265.632840 | > | 5120 | 22.756799 | 44.809926 | 69.324931 | 85.589418 | 106.649450 | 137.122404 | 146.470563 | 149.845737 | 371.508604 > | | 6144 | 26.218716 | 53.103478 | 78.157447 | 122.467283 | 129.644202 | 162.408603 | 160.861559 | 172.865197 | > 460.078507 | | 7168 | 31.095109 | 60.251328 | 91.299751 | 133.693702 | 143.813523 | 154.496892 | 171.049670 | > 186.519441 | 527.541763 | | 8192 | 34.609033 | 71.258569 | 107.084557 | 143.252194 | 163.108854 | 165.619014 | > 178.134480 | 220.085044 | 514.600669 | | 9216 | 69.133873 | 135.713363 | 198.200679 | 277.606301 | 355.598066 | > 480.710904 | 450.875668 | 577.701980 | 623.690198 | > ![14-ea+9](https://user-images.githubusercontent.com/7450507/76303509-29a3ce80-62c2-11ea-8b79-befe446b39e3.png) ### 14-internal -------- | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | |---|---|---|---|---|---|---|---|---|---| | 1024 | 5.740508 | 9.337537 | 13.489849 | 17.611105 | 38.898909 | 48.165735 | 53.596876 | 49.449740 | 66.032570 | | 2048 | 9.845097 | 17.799415 | 26.109529 | 34.607728 | 79.345622 | 94.082500 | 107.777644 | 100.901349 | 135.826890 | | 3072 | 14.654498 | 26.183649 | 39.781191 | 51.871491 | 113.010307 | 143.613631 | 184.883820 | 167.076202 | 200.852633 | | 4096 | 18.706278 | 36.115871 | 51.477296 | 68.457649 | 156.240888 | 186.159272 | 222.876505 | 237.387683 | 290.125942 | | 5120 | 50.566276 | 106.465632 | 140.506406 | 161.687151 | 203.644875 | 237.260330 | 279.108632 | 311.002566 | 371.704115 | | 6144 | 53.501341 | 106.726656 | 160.191733 | 216.969484 | 264.996201 | 287.375425 | 335.294473 | 365.035267 | 419.995978 | | 7168 | 66.422026 | 110.882355 | 187.978455 | 239.014528 | 308.817056 | 335.838550 | 394.270828 | 445.987300 | 506.974069 | | 8192 | 60.315442 | 108.770069 | 164.424088 | 205.330331 | 305.201833 | 343.846336 | 392.867668 | 454.540147 | 503.808112 | | 9216 | 71.070811 | 132.708328 | 188.411172 | 256.130225 | 320.028449 | 400.748559 | 471.542252 | 595.355103 | 589.240851 | ![14-internal](https://user-images.githubusercontent.com/7450507/76303535-31fc0980-62c2-11ea-8b65-c8e104dcb042.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 10 10:31:52 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 10 Mar 2020 10:31:52 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <0_XCcksGLJ7c4JWWxHLiTILxdojcsoZevBk9p1ZhDd8=.8d142a85-38fb-4aeb-bb2a-25c4659e02e4@github.com> Message-ID: On Tue, 10 Mar 2020 06:05:53 GMT, Ambarish Rapte wrote: >> I finally got a chance to do some more extensive testing when running this patch with the es2 pipeline on Linux. >> It works as expected, and from what I saw, using a IntARGB pixelBuffer when no WritableImage is provided avoids >> swapping around pixel components, like under d3d. I've also verified than the patch's behaviour is correct when a >> writable image is provided as a parameter to Node.snapshot, whether the underlying image is actually a PlatformImage or >> a wrapper for a PixelBuffer, which corrects another limitation of the previous implementation. > > On My windows10 machine, I can observe 20 to 30 % reduction in time to take snapshot. > Can you please capture the time the way you did [here](https://github.com/openjdk/jfx/pull/68#issuecomment-578192074) > for previous PR ### 14-ea+9 -------- | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | |---|---|---|---|---|---|---|---|---|---| | 1024 | 5.607827 | 9.380503 | 13.835523 | 17.514362 | 21.776304 | 27.918815 | 36.929480 | 35.647317 | 74.274598 | | 2048 | 11.271960 | 17.774451 | 26.468146 | 34.555745 | 42.699573 | 52.027568 | 74.481450 | 68.349699 | 135.902502 | | 3072 | 13.953309 | 26.320822 | 42.652327 | 51.534650 | 65.202531 | 78.406419 | 103.512338 | 109.125337 | 214.305998 | | 4096 | 17.776236 | 35.800101 | 57.483720 | 70.221125 | 98.024908 | 106.510784 | 109.940266 | 150.731465 | 265.632840 | | 5120 | 22.756799 | 44.809926 | 69.324931 | 85.589418 | 106.649450 | 137.122404 | 146.470563 | 149.845737 | 371.508604 | | 6144 | 26.218716 | 53.103478 | 78.157447 | 122.467283 | 129.644202 | 162.408603 | 160.861559 | 172.865197 | 460.078507 | | 7168 | 31.095109 | 60.251328 | 91.299751 | 133.693702 | 143.813523 | 154.496892 | 171.049670 | 186.519441 | 527.541763 | | 8192 | 34.609033 | 71.258569 | 107.084557 | 143.252194 | 163.108854 | 165.619014 | 178.134480 | 220.085044 | 514.600669 | | 9216 | 69.133873 | 135.713363 | 198.200679 | 277.606301 | 355.598066 | 480.710904 | 450.875668 | 577.701980 | 623.690198 | ![14-ea+9](https://user-images.githubusercontent.com/7450507/76303509-29a3ce80-62c2-11ea-8b79-befe446b39e3.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 10 10:31:52 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 10 Mar 2020 10:31:52 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <0_XCcksGLJ7c4JWWxHLiTILxdojcsoZevBk9p1ZhDd8=.8d142a85-38fb-4aeb-bb2a-25c4659e02e4@github.com> Message-ID: On Tue, 10 Mar 2020 10:29:31 GMT, Frederic Thevenet wrote: >> ### 14-ea+9 >> >> -------- >> | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | >> |---|---|---|---|---|---|---|---|---|---| >> | 1024 | 5.607827 | 9.380503 | 13.835523 | 17.514362 | 21.776304 | 27.918815 | 36.929480 | 35.647317 | 74.274598 | >> | 2048 | 11.271960 | 17.774451 | 26.468146 | 34.555745 | 42.699573 | 52.027568 | 74.481450 | 68.349699 | 135.902502 | >> | 3072 | 13.953309 | 26.320822 | 42.652327 | 51.534650 | 65.202531 | 78.406419 | 103.512338 | 109.125337 | 214.305998 | >> | 4096 | 17.776236 | 35.800101 | 57.483720 | 70.221125 | 98.024908 | 106.510784 | 109.940266 | 150.731465 | 265.632840 | >> | 5120 | 22.756799 | 44.809926 | 69.324931 | 85.589418 | 106.649450 | 137.122404 | 146.470563 | 149.845737 | 371.508604 >> | | 6144 | 26.218716 | 53.103478 | 78.157447 | 122.467283 | 129.644202 | 162.408603 | 160.861559 | 172.865197 | >> 460.078507 | | 7168 | 31.095109 | 60.251328 | 91.299751 | 133.693702 | 143.813523 | 154.496892 | 171.049670 | >> 186.519441 | 527.541763 | | 8192 | 34.609033 | 71.258569 | 107.084557 | 143.252194 | 163.108854 | 165.619014 | >> 178.134480 | 220.085044 | 514.600669 | | 9216 | 69.133873 | 135.713363 | 198.200679 | 277.606301 | 355.598066 | >> 480.710904 | 450.875668 | 577.701980 | 623.690198 | >> ![14-ea+9](https://user-images.githubusercontent.com/7450507/76303509-29a3ce80-62c2-11ea-8b79-befe446b39e3.png) > > ### 14-internal > > -------- > | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | > |---|---|---|---|---|---|---|---|---|---| > | 1024 | 5.740508 | 9.337537 | 13.489849 | 17.611105 | 38.898909 | 48.165735 | 53.596876 | 49.449740 | 66.032570 | > | 2048 | 9.845097 | 17.799415 | 26.109529 | 34.607728 | 79.345622 | 94.082500 | 107.777644 | 100.901349 | 135.826890 | > | 3072 | 14.654498 | 26.183649 | 39.781191 | 51.871491 | 113.010307 | 143.613631 | 184.883820 | 167.076202 | 200.852633 > | | 4096 | 18.706278 | 36.115871 | 51.477296 | 68.457649 | 156.240888 | 186.159272 | 222.876505 | 237.387683 | > 290.125942 | | 5120 | 50.566276 | 106.465632 | 140.506406 | 161.687151 | 203.644875 | 237.260330 | 279.108632 | > 311.002566 | 371.704115 | | 6144 | 53.501341 | 106.726656 | 160.191733 | 216.969484 | 264.996201 | 287.375425 | > 335.294473 | 365.035267 | 419.995978 | | 7168 | 66.422026 | 110.882355 | 187.978455 | 239.014528 | 308.817056 | > 335.838550 | 394.270828 | 445.987300 | 506.974069 | | 8192 | 60.315442 | 108.770069 | 164.424088 | 205.330331 | > 305.201833 | 343.846336 | 392.867668 | 454.540147 | 503.808112 | | 9216 | 71.070811 | 132.708328 | 188.411172 | > 256.130225 | 320.028449 | 400.748559 | 471.542252 | 595.355103 | 589.240851 | > ![14-internal](https://user-images.githubusercontent.com/7450507/76303535-31fc0980-62c2-11ea-8b65-c8e104dcb042.png) ### 15-internal: -------- | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | |---|---|---|---|---|---|---|---|---|---| | 1024 | 5.381051 | 9.261115 | 14.033219 | 20.608201 | 26.159817 | 33.599632 | 36.669261 | 43.042338 | 46.086088 | | 2048 | 9.752862 | 17.698869 | 27.004541 | 38.437578 | 52.297443 | 60.757880 | 68.101838 | 80.162117 | 93.852856 | | 3072 | 15.564961 | 27.304138 | 40.255866 | 56.636476 | 80.472402 | 86.346635 | 105.154089 | 121.048263 | 130.458981 | | 4096 | 19.436113 | 35.556343 | 53.277865 | 71.623899 | 95.814932 | 122.543003 | 136.833771 | 160.199834 | 178.356125 | | 5120 | 27.246498 | 65.875784 | 73.171492 | 103.380029 | 126.486761 | 147.666102 | 165.833885 | 199.005331 | 220.659671 | | 6144 | 31.843301 | 62.101937 | 93.646729 | 125.531512 | 150.914608 | 175.553034 | 209.835003 | 241.114596 | 253.512648 | | 7168 | 40.507918 | 70.843435 | 101.075064 | 137.284040 | 165.808501 | 197.015259 | 254.286955 | 304.928104 | 299.992601 | | 8192 | 43.206941 | 80.290957 | 121.946965 | 157.016439 | 193.509481 | 243.514969 | 268.151933 | 359.562281 | 352.102850 | | 9216 | 49.529493 | 90.895186 | 149.422784 | 179.512616 | 217.260338 | 267.610592 | 309.706685 | 354.950852 | 383.275751 | ![15-internal](https://user-images.githubusercontent.com/7450507/76303560-3a544480-62c2-11ea-9860-030a0110a9fe.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 10 11:16:52 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 10 Mar 2020 11:16:52 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <0_XCcksGLJ7c4JWWxHLiTILxdojcsoZevBk9p1ZhDd8=.8d142a85-38fb-4aeb-bb2a-25c4659e02e4@github.com> Message-ID: On Tue, 10 Mar 2020 10:29:38 GMT, Frederic Thevenet wrote: >> ### 14-internal >> >> -------- >> | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | >> |---|---|---|---|---|---|---|---|---|---| >> | 1024 | 5.740508 | 9.337537 | 13.489849 | 17.611105 | 38.898909 | 48.165735 | 53.596876 | 49.449740 | 66.032570 | >> | 2048 | 9.845097 | 17.799415 | 26.109529 | 34.607728 | 79.345622 | 94.082500 | 107.777644 | 100.901349 | 135.826890 | >> | 3072 | 14.654498 | 26.183649 | 39.781191 | 51.871491 | 113.010307 | 143.613631 | 184.883820 | 167.076202 | 200.852633 >> | | 4096 | 18.706278 | 36.115871 | 51.477296 | 68.457649 | 156.240888 | 186.159272 | 222.876505 | 237.387683 | >> 290.125942 | | 5120 | 50.566276 | 106.465632 | 140.506406 | 161.687151 | 203.644875 | 237.260330 | 279.108632 | >> 311.002566 | 371.704115 | | 6144 | 53.501341 | 106.726656 | 160.191733 | 216.969484 | 264.996201 | 287.375425 | >> 335.294473 | 365.035267 | 419.995978 | | 7168 | 66.422026 | 110.882355 | 187.978455 | 239.014528 | 308.817056 | >> 335.838550 | 394.270828 | 445.987300 | 506.974069 | | 8192 | 60.315442 | 108.770069 | 164.424088 | 205.330331 | >> 305.201833 | 343.846336 | 392.867668 | 454.540147 | 503.808112 | | 9216 | 71.070811 | 132.708328 | 188.411172 | >> 256.130225 | 320.028449 | 400.748559 | 471.542252 | 595.355103 | 589.240851 | >> ![14-internal](https://user-images.githubusercontent.com/7450507/76303535-31fc0980-62c2-11ea-8b65-c8e104dcb042.png) > > ### 15-internal: > > -------- > | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | > |---|---|---|---|---|---|---|---|---|---| > | 1024 | 5.381051 | 9.261115 | 14.033219 | 20.608201 | 26.159817 | 33.599632 | 36.669261 | 43.042338 | 46.086088 | > | 2048 | 9.752862 | 17.698869 | 27.004541 | 38.437578 | 52.297443 | 60.757880 | 68.101838 | 80.162117 | 93.852856 | > | 3072 | 15.564961 | 27.304138 | 40.255866 | 56.636476 | 80.472402 | 86.346635 | 105.154089 | 121.048263 | 130.458981 | > | 4096 | 19.436113 | 35.556343 | 53.277865 | 71.623899 | 95.814932 | 122.543003 | 136.833771 | 160.199834 | 178.356125 | > | 5120 | 27.246498 | 65.875784 | 73.171492 | 103.380029 | 126.486761 | 147.666102 | 165.833885 | 199.005331 | > 220.659671 | | 6144 | 31.843301 | 62.101937 | 93.646729 | 125.531512 | 150.914608 | 175.553034 | 209.835003 | > 241.114596 | 253.512648 | | 7168 | 40.507918 | 70.843435 | 101.075064 | 137.284040 | 165.808501 | 197.015259 | > 254.286955 | 304.928104 | 299.992601 | | 8192 | 43.206941 | 80.290957 | 121.946965 | 157.016439 | 193.509481 | > 243.514969 | 268.151933 | 359.562281 | 352.102850 | | 9216 | 49.529493 | 90.895186 | 149.422784 | 179.512616 | > 217.260338 | 267.610592 | 309.706685 | 354.950852 | 383.275751 | > ![15-internal](https://user-images.githubusercontent.com/7450507/76303560-3a544480-62c2-11ea-9860-030a0110a9fe.png) I've uploaded 3 sets of results, from 3 different implementations: 1. **14-ea+9** is the implementation merged into openjfx14 following #68; it only use tiling if the original implementation fails; on Windows that would typically be when the snapshot dimensions are larger than 8192 pixels. 2. **14-internal** uses the same tiling implementation than the above, but start using tiling as soon as snapshot dimensions are larger than `PrismSettings.maxTextureSize`; i.e. typically 4096 pixels. NB: This implementation was never merged into openJFX; results are only provided for comparison's sake. 3. **15-internal** uses the tiling implementation proposed in the PR. Compared to the ones above, it attempt to align pixel formats to avoid the cost of transformation from one format to another (e.g. ByteBRGA to IntARGB) and it tries to divide up the final snapshots into tiles of the same dimensions to prevent creating a new GPU surface for every tile. **Please note that these results are for the best possible scenario with regard to the above optimizations; in the worst case scenario (a user provided image with a different pixel format and no way to divide the snapshot into equal size tiles), then the performances are the same as that of implementation 2** My conclusions from the above results are twofold: - Tiling has a cost in terms of performance, but as far as I can tell it remains the only practical way to work around the underlying issue (i.e. taking snapshot larger than the supported texture size) and the optimizations proposed in this PR arguably do mitigate that cost, even if it is only true in some of the cases. - The original implementation, which is preserved in 14-ea+9, ignores texture clamping to 4096 which means it doesn't has to resort to tiling until the target snapshot size is >8192 on d3d or 16384 on es2. If this is an incorrect behaviour on the part of the original implementation (which I'm led to believe is the case), it gives it an unfair advantage in this benchmark, i.e. it is faster because is does things it shouldn't do. If however it turns out it is actually safe to ignore clamping when taking snapshot, then it would make sense to do so in the implementation proposed by this PR as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From aghaisas at openjdk.java.net Tue Mar 10 11:22:01 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 10 Mar 2020 11:22:01 GMT Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: References: Message-ID: On Tue, 3 Mar 2020 22:51:43 GMT, Kevin Rushforth wrote: > While testing JavaFX using gradle 6.3-nightly and JDK 14, I ran into what turned out to be a latent test bug in the > AppJSCallback* apps that are launched by ModuleLauncherTest. The launched apps construct a WebView instance, obtain a > WebEngine instance from the WebView, add a state listener to the WebEngine, load the web content, and then return from > the Application::start method. The WebView instance is held a local variable, and so is subject to garbage collection > once it goes out of scope when the start method returns. In addition, the test apps did not check for successful > launching of the application or successful loading of the web content, which led to the test suite hanging (else it > would have been a simple test failure). Note that I don't know (nor care) what changed in JDK 14 to make this more > likely to occur, but since the test itself is demonstrably wrong, it needs to be fixed. The main part of the fix was > to make the WebEngine an instance variable. In order to make the test more robust, I also modified it to launch the > application in another thread, and having the main thread check that the application launched successfully and that the > web content was loaded successfully, after which I did the assertion check for the correct number of callbacks. The 5 > different apps only differ from each other in the name of the class, the name of the package from which MyCallback is > imported, and possibly the expected number of callbacks. I diffed AppJSCallbackExported.java against the other 4 test > files and the diffs are essentially the same as they were before this change. Reviewers thus only need to review one of > the tests in detail. For example, here are the diffs between AppJSCallbackExported and AppJSCallbackUnexported: $ > diff .../AppJSCallbackExported.java .../AppJSCallbackUnexported.java 37c37 < import myapp5.pkg2.MyCallback; > --- >> import myapp5.pkg1.MyCallback; > 45c45 > < public class AppJSCallbackExported extends Application { > --- >> public class AppJSCallbackUnexported extends Application { > 77c77 > < Util.assertEquals(1, callbackCount); > --- >> Util.assertEquals(0, callbackCount); Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/134 From aghaisas at openjdk.java.net Tue Mar 10 11:22:01 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 10 Mar 2020 11:22:01 GMT Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: References: Message-ID: <4g5XsVJFFAXGyq2L9r0PtOz_vSt7g5fFusntxEKlMf8=.be0ee2a8-8bca-48f1-a0ab-21e7d9e027c3@github.com> On Fri, 6 Mar 2020 19:53:04 GMT, Kevin Rushforth wrote: >> Please ignore this comment as well, it is also for debugging issues with Skara and mailman :email: ?? > > @aghaisas can you review this? I executed these tests without this patch. They did not hang on my Macbook. I applied patch and executed the tests. They continue to pass. I see the merit of this change to make tests predictable. +1. ------------- PR: https://git.openjdk.java.net/jfx/pull/134 From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 10 11:25:52 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 10 Mar 2020 11:25:52 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <0_XCcksGLJ7c4JWWxHLiTILxdojcsoZevBk9p1ZhDd8=.8d142a85-38fb-4aeb-bb2a-25c4659e02e4@github.com> Message-ID: On Tue, 10 Mar 2020 11:13:54 GMT, Frederic Thevenet wrote: >> ### 15-internal: >> >> -------- >> | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | >> |---|---|---|---|---|---|---|---|---|---| >> | 1024 | 5.381051 | 9.261115 | 14.033219 | 20.608201 | 26.159817 | 33.599632 | 36.669261 | 43.042338 | 46.086088 | >> | 2048 | 9.752862 | 17.698869 | 27.004541 | 38.437578 | 52.297443 | 60.757880 | 68.101838 | 80.162117 | 93.852856 | >> | 3072 | 15.564961 | 27.304138 | 40.255866 | 56.636476 | 80.472402 | 86.346635 | 105.154089 | 121.048263 | 130.458981 | >> | 4096 | 19.436113 | 35.556343 | 53.277865 | 71.623899 | 95.814932 | 122.543003 | 136.833771 | 160.199834 | 178.356125 | >> | 5120 | 27.246498 | 65.875784 | 73.171492 | 103.380029 | 126.486761 | 147.666102 | 165.833885 | 199.005331 | >> 220.659671 | | 6144 | 31.843301 | 62.101937 | 93.646729 | 125.531512 | 150.914608 | 175.553034 | 209.835003 | >> 241.114596 | 253.512648 | | 7168 | 40.507918 | 70.843435 | 101.075064 | 137.284040 | 165.808501 | 197.015259 | >> 254.286955 | 304.928104 | 299.992601 | | 8192 | 43.206941 | 80.290957 | 121.946965 | 157.016439 | 193.509481 | >> 243.514969 | 268.151933 | 359.562281 | 352.102850 | | 9216 | 49.529493 | 90.895186 | 149.422784 | 179.512616 | >> 217.260338 | 267.610592 | 309.706685 | 354.950852 | 383.275751 | >> ![15-internal](https://user-images.githubusercontent.com/7450507/76303560-3a544480-62c2-11ea-9860-030a0110a9fe.png) > > I've uploaded 3 sets of results, from 3 different implementations: > > 1. **14-ea+9** is the implementation merged into openjfx14 following #68; it only use tiling if the original > implementation fails; on Windows that would typically be when the snapshot dimensions are larger than 8192 pixels. > 2. **14-internal** uses the same tiling implementation than the above, but start using tiling as soon as snapshot > dimensions are larger than `PrismSettings.maxTextureSize`; i.e. typically 4096 pixels. NB: This implementation was > never merged into openJFX; results are only provided for comparison's sake. > 3. **15-internal** uses the tiling implementation proposed in the PR. Compared to the ones above, it attempt to align > pixel formats to avoid the cost of transformation from one format to another (e.g. ByteBRGA to IntARGB) and it tries to > divide up the final snapshots into tiles of the same dimensions to prevent creating a new GPU surface for every tile. > **Please note that these results are for the best possible scenario with regard to the above optimizations; in the worst > case scenario (a user provided image with a different pixel format and no way to divide the snapshot into equal size > tiles), then the performances are the same as that of implementation 2** > > My conclusions from the above results are twofold: > > - Tiling has a cost in terms of performance, but as far as I can tell it remains the only practical way to work around > the underlying issue (i.e. taking snapshot larger than the supported texture size) and the optimizations proposed in > this PR arguably do mitigate that cost, even if it is only true in some of the cases. > > - The original implementation, which is preserved in 14-ea+9, ignores texture clamping to 4096 which means it doesn't has > to resort to tiling until the target snapshot size is >8192 on d3d or 16384 on es2. > If this is an incorrect behaviour on the part of the original implementation (which I'm led to believe is the case), it > gives it an unfair advantage in this benchmark, i.e. it is faster because is does things it shouldn't do. If however it > turns out it is actually safe to ignore clamping when taking snapshot, then it would make sense to do so in the > implementation proposed by this PR as well. By the way, the code for the above benchmark is available here: https://github.com/fthevenet/snapshot-perf-meter Would it make sense to include it into the OpenJFX repo, maybe under jfx/apps/performance ? ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Tue Mar 10 12:42:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Mar 2020 12:42:21 GMT Subject: [Integrated] RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: References: Message-ID: Changeset: 50e15fce Author: Kevin Rushforth Date: 2020-03-10 12:42:02 +0000 URL: https://git.openjdk.java.net/jfx/commit/50e15fce 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang Reviewed-by: aghaisas ! tests/system/src/testapp5/java/mymod/myapp5/AppJSCallbackExported.java ! tests/system/src/testapp5/java/mymod/myapp5/AppJSCallbackOpened.java ! tests/system/src/testapp5/java/mymod/myapp5/AppJSCallbackQualExported.java ! tests/system/src/testapp5/java/mymod/myapp5/AppJSCallbackQualOpened.java ! tests/system/src/testapp5/java/mymod/myapp5/AppJSCallbackUnexported.java From fkirmaier at openjdk.java.net Tue Mar 10 14:26:55 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 10 Mar 2020 14:26:55 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <6OhviYNgO41FTyjthrckuI_FiLCNAbBOvAmhc6kkNOI=.94f9d129-d32c-4616-afbf-0c4aecce14db@github.com> <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> Message-ID: On Thu, 5 Mar 2020 22:11:26 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8236259 >> readded unit-test without any dependency > > tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 80: > >> 79: createGarbage(); >> 80: System.gc(); >> 81: > > We recommend also calling `System.runFinalization();` for GC related tests. Interesting, Thank you for the Information. Never heard about this method. I will have to add it also to JMemoryBuddy. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From fkirmaier at openjdk.java.net Tue Mar 10 14:35:59 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 10 Mar 2020 14:35:59 GMT Subject: [Rev 04] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> Message-ID: <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> > Hi everyone, > > ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 > > The fix itself is quite straight forward. > It basically just removed the listener which causes the leak. > > The unit-test for the fix is a bit more complicated. > > I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for > memory leaks. I think there are many places in the JavaFX-codebase that could highly benefit from this library. > It could also simplify many of the already existing unit tests. > It makes testing for memory-leaks readably and reliable. > It would also be possible to just copy the code of the library into the JavaFX-codebase. > It only contains a single class. > > I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8200224 cleaned up code based on code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/71/files - new: https://git.openjdk.java.net/jfx/pull/71/files/740fe2a1..d8589a95 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/71/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/71/webrev.03-04 Stats: 50 lines in 2 files changed: 27 ins; 11 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/71/head:pull/71 PR: https://git.openjdk.java.net/jfx/pull/71 From fkirmaier at openjdk.java.net Tue Mar 10 14:36:00 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 10 Mar 2020 14:36:00 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <6OhviYNgO41FTyjthrckuI_FiLCNAbBOvAmhc6kkNOI=.94f9d129-d32c-4616-afbf-0c4aecce14db@github.com> <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> Message-ID: <0QyKs9ZdLJIgdCmp4AlpRSHVB0mgNHuAL0vP3agqV-0=.a90bf0c4-635f-440c-a1ee-6a5cf40de1a0@github.com> On Thu, 5 Mar 2020 22:15:07 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8236259 >> readded unit-test without any dependency > > tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 95: > >> 94: } >> 95: public static void createGarbage() { >> 96: LinkedList list = new LinkedList(); > > I think this is fine, but I'm curious as to whether you've actually found this (creating garbage) to be necessary. Usually, it doesn't make a difference, but it's necessary to make the tests stable. If nothing happens in the JVM then even System.gc won't do anything anymore. Creating garbage stimulates the JVM enough to make GC-based tests stable. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From fkirmaier at openjdk.java.net Tue Mar 10 14:37:13 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 10 Mar 2020 14:37:13 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <6OhviYNgO41FTyjthrckuI_FiLCNAbBOvAmhc6kkNOI=.94f9d129-d32c-4616-afbf-0c4aecce14db@github.com> <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> Message-ID: On Thu, 5 Mar 2020 22:19:45 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8236259 >> readded unit-test without any dependency > > The fix looks good to me. I've verified that it fixes the leak. > > The newly added test looks good as well, with some comments left inline (formatting, a missing copyright header, and a > couple other suggestions). @kevinrushforth I've now cleaned it up based on your suggestions. It would be great when Travis could validate the formatting. It would save a lot of time for everyone. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Tue Mar 10 15:40:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Mar 2020 15:40:32 GMT Subject: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <6OhviYNgO41FTyjthrckuI_FiLCNAbBOvAmhc6kkNOI=.94f9d129-d32c-4616-afbf-0c4aecce14db@github.com> <7GiTiiA0bqczS-U5uciSjVSrzG8HSbMDsYs-hpBjfls=.b9f46a17-bdb4-4df4-8ffa-549ca274982c@github.com> Message-ID: On Tue, 10 Mar 2020 14:34:57 GMT, Florian Kirmaier wrote: >> The fix looks good to me. I've verified that it fixes the leak. >> >> The newly added test looks good as well, with some comments left inline (formatting, a missing copyright header, and a >> couple other suggestions). > > @kevinrushforth > I've now cleaned it up based on your suggestions. > It would be great when Travis could validate the formatting. > It would save a lot of time for everyone. Thanks, I'll take a look. As for automating this, we no longer have Travis builds hooked up. I have a pending task to look into using GitHub Actions to do a sanity build / test (which would be a big help). We could look into adding a checkstyle task to that to check for at least some of the style guidelines. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Tue Mar 10 16:30:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Mar 2020 16:30:13 GMT Subject: [Rev 04] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> Message-ID: On Tue, 10 Mar 2020 14:35:59 GMT, Florian Kirmaier wrote: >> Hi everyone, >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 >> >> The fix itself is quite straight forward. >> It basically just removed the listener which causes the leak. >> >> The unit-test for the fix is a bit more complicated. >> >> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for >> memory leaks. I think there are many places in the JavaFX-codebase that could highly benefit from this library. >> It could also simplify many of the already existing unit tests. >> It makes testing for memory-leaks readably and reliable. >> It would also be possible to just copy the code of the library into the JavaFX-codebase. >> It only contains a single class. >> >> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8200224 > cleaned up code based on code review Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Tue Mar 10 16:37:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Mar 2020 16:37:52 GMT Subject: [Rev 04] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> Message-ID: On Tue, 10 Mar 2020 16:28:03 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8200224 >> cleaned up code based on code review > > Marked as reviewed by kcr (Lead). @arapte or @kleopatra can one of you be the second reviewer? ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From David.Grieve at microsoft.com Tue Mar 10 16:48:27 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Tue, 10 Mar 2020 16:48:27 +0000 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: References: <03DF5DCD-BE78-43E1-9F79-2828B847BE4D@screamingfrog.co.uk> Message-ID: The flickering is happening because of the way VirtualFlow reuses cells. The selected state gets cleared and reset, which is the flicker. This change fixed the flickering for me. I'm not sure why the index of a cell was being set to -1, but the effect of doing so is that when the cell is pulled out of the pile, it looks like a new cell that has to have its index set, selected state set, etc, etc. By commenting out the updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected state, etc turns into noops (more or less). Again, there may have been a good reason for setting index to -1 in this condition. More investigation needs to be done. diff --git a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java index 728e7c5513..a58859bd05 100644 --- a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java +++ b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java @@ -991,9 +991,9 @@ public class VirtualFlow extends Region { lastWidth = -1; lastHeight = -1; releaseCell(accumCell); - for (int i = 0, max = cells.size(); i < max; i++) { - cells.get(i).updateIndex(-1); - } +// for (int i = 0, max = cells.size(); i < max; i++) { +// cells.get(i).updateIndex(-1); +// } addAllToPile(); releaseAllPrivateCells(); } else if (needsReconfigureCells) { > -----Original Message----- > From: openjfx-dev On Behalf Of > David Grieve > Sent: Friday, March 6, 2020 9:29 AM > To: Danny Gonzalez > Cc: openjfx-dev at openjdk.java.net > Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to > TableView > > This might fix the issue, but I?d like to understand better what the root of the > problem is. My concern is that this fix might cause a performance regression. > I?m using the code in JDK-8177945. I want to look at what TableView does > when it adds a cell. Is there something about the selected state that > changes? Or is this just the CSS implementation recalculating styles and un- > necessarily clearing old values? Some debugging is in order. > > From: Danny Gonzalez > Sent: Wednesday, March 4, 2020 4:34 AM > To: David Grieve > Cc: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when > adding data to TableView > > Hi David, > > Just wanted to add some more information. > > The cell selection flashing issue goes away If I put back the following code in > the layout function in Parent.java: > > // > // One idiom employed by developers is to, during the layout pass, > // add or remove nodes from the scene. For example, a ScrollPane > // might add scroll bars to itself if it determines during layout > // that it needs them, or a ListView might add cells to itself if > // it determines that it needs to. In such situations we must > // apply the CSS immediately and not add it to the scene's queue > // for deferred action. > // > // Note that we only call processCSS if the flag is update. If the > // flag is DIRTY_BRANCH, then the whatever children need UPDATE > // will be visited during this layout anyway. On the next pulse, > // doCSSPass will clean up the DIRTY_BRANCH nodes. > // > if (cssFlag == CssFlags.UPDATE) { > processCSS(); > } > > This code was originally added in in the following commit: > > commit e76b5755d4d2752037cc95eb75cb2615a740cc30 > Author: David Grieve > > > Date: Thu Apr 10 15:40:34 2014 -0400 > > RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply > css to child nodes if nothing has changed. 2 - on applyCss, only look for > ancestor node with css state = UPDATE. 3 - only recalculate checksum of css > file if the file has been removed from a scene or parent > > > It was reverted out in this commit: > > commit 05afad6b528e871d607b76aea2642cf788b417fe > Author: David Grieve > > > Date: Tue Apr 15 11:51:38 2014 -0400 > > RT-36672: move code to process css during layout back to impl_reapplyCSS, > which is where it was priort to RT-36559 > > > > > This was the point at which the cell selection flashing appeared. > > > Thanks > > > Danny > > > > On 3 Mar 2020, at 16:50, David Grieve > > > wrote: > > The importance of 05afad6 Is there in the commit itself: > > + // > + // One idiom employed by developers is to, during the layout pass, > + // add or remove nodes from the scene. For example, a ScrollPane > + // might add scroll bars to itself if it determines during layout > + // that it needs them, or a ListView might add cells to itself if > + // it determines that it needs to. In such situations we must > + // apply the CSS immediately and not add it to the scene's queue > + // for deferred action. > + > > If you revert 05afad6, you'll break this. > > This is the first time I've become aware of this flickering issue. I'll have to look > at it. > I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK- > 8193445 F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK- > 8193445&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C9148c860ff5 > 24a32ac3208d7c01f2523%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C637189112753556661&sdata=mZrjldSw%2Fjbd0ita58XMU%2BaKM2GlvObq > 3aaQmQb5Poc%3D&reserved=0> has any impact on this. > > > -----Original Message----- > From: openjfx-dev bounces at openjdk.java.net bounces at openjdk.java.net>> On Behalf Of Danny Gonzalez > Sent: Tuesday, March 3, 2020 11:14 AM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding > data to TableView > > > There is currently an open bug to do with the issue of selection flickering > when using single cell selection and when adding data to a TableView. > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da > ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 > d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 > 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb > 8AwcRXVrfLo%3D&reserved=0 > > This bug seems to be low priority because it hasn?t been looked at since I > submitted it at the start of 2017. > > This is quite a major issue for us so I have narrowed down when the issue > was first introduced. > > Here is the changeset: > > commit 05afad6b528e871d607b76aea2642cf788b417fe > Author: David Grieve > jdk.org%3cmailto:dgrieve at openjdk.org>>> > Date: Tue Apr 15 11:51:38 2014 -0400 > > RT-36672: move code to process css during layout back to impl_reapplyCSS, > which is where it was priort to RT-36559 > > > I can?t search the bug database for this bug ID as I believe it was submitted > when a previous bug tracking system was in use. > > Does anyone have any knowledge as to why this fix was needed and what > the repercussions would be if I reverted it out for our local OpenJFX build. > > Alternatively I would be glad to receive any suggestions of how to fix the > flickering issue if this changeset is important to leave in. > > Thanks > > Danny From kcr at openjdk.java.net Tue Mar 10 18:41:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Mar 2020 18:41:14 GMT Subject: RFR: 8240832: Remove unused applecoreaudio.md third-party legal file In-Reply-To: References: Message-ID: On Tue, 10 Mar 2020 18:37:50 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this is a follow-on bug to > [https://bugs.openjdk.java.net/browse/JDK-8232589](https://bugs.openjdk.java.net/browse/JDK-8232589) to remove the > applecoreaudio.md third-party legal file now that we no longer include or use CoreAudio. @sashamatveev can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/142 From kcr at openjdk.java.net Tue Mar 10 18:41:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Mar 2020 18:41:14 GMT Subject: RFR: 8240832: Remove unused applecoreaudio.md third-party legal file Message-ID: As noted in the JBS issue, this is a follow-on bug to [https://bugs.openjdk.java.net/browse/JDK-8232589](https://bugs.openjdk.java.net/browse/JDK-8232589) to remove the applecoreaudio.md third-party legal file now that we no longer include or use CoreAudio. ------------- Commit messages: - 8240832: Remove unused applecoreaudio.md third-party legal file Changes: https://git.openjdk.java.net/jfx/pull/142/files Webrev: https://webrevs.openjdk.java.net/jfx/142/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240832 Stats: 53 lines in 1 file changed: 0 ins; 53 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/142.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/142/head:pull/142 PR: https://git.openjdk.java.net/jfx/pull/142 From nlisker at openjdk.java.net Tue Mar 10 18:54:34 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 10 Mar 2020 18:54:34 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> Message-ID: On Wed, 5 Feb 2020 13:48:45 GMT, Kevin Rushforth wrote: >> We have a few performance tests in apps/performance, but I don't know how up to date they are. They might give you a >> starting point on how to measure FPS, but really the harder part is going to be coming up with a workload -- a scene >> with a number of Shape3Ds with large triangles (so that they are fill-rate limited) and 1-3 lights, etc -- that you can >> use to measure rendering performance without measuring overhead. Typically you want a scene that is rendering >> continuously in the < 30 fps range, and more like 10 fps to minimize the overhead even more. Before we figure out >> whether we need to double the number of shaders (which was one of the ideas that I had as well), we need to know how >> much of a problem it is. Is it < 2% performance drop on typical cases on a variety of machines or it is a 25% drop (or >> more likely somewhere in between). If the perf drop is negligible, then it isn't worth doubling the shaders. If it is >> significant, then we probably need to. If we do need to double the shaders, I wouldn't do it based on the maxRange >> being infinite, rather I would do it based on whether attenuation is being used. That way the existing shaders would be >> unchanged, while the new shader would deal with both attenuation and the maxRange test. Hopefully, there won't be >> enough of a perf hit to require doubling the shaders, but we need to be able to measure it. For functional testing, in >> addition to the simple API tests, we want to make sure that the basic rendering is working with and without >> attenuation. Some sort of visual test where you verify that attenuation is / isn't happening as well as testing the >> cutoff. I wouldn't get too fancy with these...just a sanity test. > > Looks like the `jcheck` bot removed the `rfr` label because the CSR isn't complete. An incomplete CSR should be treated > the same way as an insufficient number of reviewers. I filed > [SKARA-262](https://bugs.openjdk.java.net/browse/SKARA-262) to track this. @kevinrushforth Can you have a look at the test app? I would like to get this moving so we would have time to get the rest of the lighting enhancements into 15. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From almatvee at openjdk.java.net Tue Mar 10 21:26:21 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 10 Mar 2020 21:26:21 GMT Subject: RFR: 8240832: Remove unused applecoreaudio.md third-party legal file In-Reply-To: References: Message-ID: <7_ogkwLKaSPDHbaYMqtYxuP4L-Lanfw8wpFOdcyzDo8=.bafae645-4d58-4de0-96d1-fc3d62393db4@github.com> On Tue, 10 Mar 2020 18:37:50 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this is a follow-on bug to > [https://bugs.openjdk.java.net/browse/JDK-8232589](https://bugs.openjdk.java.net/browse/JDK-8232589) to remove the > applecoreaudio.md third-party legal file now that we no longer include or use CoreAudio. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/142 From kcr at openjdk.java.net Tue Mar 10 22:43:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Mar 2020 22:43:43 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> Message-ID: On Tue, 10 Mar 2020 18:52:23 GMT, Nir Lisker wrote: >> Looks like the `jcheck` bot removed the `rfr` label because the CSR isn't complete. An incomplete CSR should be treated >> the same way as an insufficient number of reviewers. I filed >> [SKARA-262](https://bugs.openjdk.java.net/browse/SKARA-262) to track this. > > @kevinrushforth Can you have a look at the test app? I would like to get this moving so we would have time to get the > rest of the lighting enhancements into 15. I'll take a look. My quick thought is that we need some sort of test with a reasonable number of large boxes (so that it is fill-limited). If there isn't such a case, and the 3D rendering is always node-limited, then the shader performance doesn't really matter all that much. I suspect we should be able to find a case where it does, but we'll see. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Wed Mar 11 12:47:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 11 Mar 2020 12:47:48 GMT Subject: [Rev 04] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> Message-ID: <1-w5IvbGvhcSt2Z73Vsg94tV_cJPhWToSd6rIhryALM=.d9e8a7ef-6453-40e3-8463-d4030e3f39f1@github.com> On Tue, 10 Mar 2020 14:35:59 GMT, Florian Kirmaier wrote: >> Hi everyone, >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 >> >> The fix itself is quite straight forward. >> It basically just removed the listener which causes the leak. >> >> The unit-test for the fix is a bit more complicated. >> >> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for >> memory leaks. I think there are many places in the JavaFX-codebase that could highly benefit from this library. >> It could also simplify many of the already existing unit tests. >> It makes testing for memory-leaks readably and reliable. >> It would also be possible to just copy the code of the library into the JavaFX-codebase. >> It only contains a single class. >> >> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8200224 > cleaned up code based on code review Requested few changes in test and a suggestion for fix. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 45: > 44: import java.util.concurrent.TimeUnit; > 45: > 46: import junit.framework.Assert; Please remove the unused imports. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 78: > 77: primaryStage.show(); > 78: } > 79: } Use `stage` or `primaryStage` uniformly to make `Stage` calls in the `start()` method. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 76: > 75: }); > 76: }); > 77: primaryStage.show(); This call can be changed as, primaryStage.setOnShown(l -> { Platform.runLater(() -> startupLatch.countDown()); }); tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 112: > 111: throw new AssertionError("Content of WeakReference was not collected. content: " + > weakReference.get()); 112: } > 113: } This can be replaced using `Assert.assertNull()` tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 131: > 130: > 131: } You can get rid of some empty lines like 130, 89, 85. tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 114: > 113: } > 114: public static void createGarbage() { > 115: LinkedList list = new LinkedList(); I think the test should consistently pass or fail without using this method. Can you please check and remove this method if can be. I tested once and it passes. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 550: > 549: } > 550: > 551: private void setFillOverride(Paint fillOverride) { The issue can be alternatively fixed using below change at line#510 text.fontProperty().addListener(new WeakChangeListener<>((observable, oldValue, newValue) -> { doneTextWidth = Utils.computeTextWidth(text.getFont(), DONE, 0); doneTextHeight = Utils.computeTextHeight(text.getFont(), DONE, 0, TextBoundsType.LOGICAL_VERTICAL_CENTER); })); I am not sure which one is better. As there are no objections, I am good with the any. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Wed Mar 11 12:53:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 11 Mar 2020 12:53:26 GMT Subject: [Rev 04] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <1-w5IvbGvhcSt2Z73Vsg94tV_cJPhWToSd6rIhryALM=.d9e8a7ef-6453-40e3-8463-d4030e3f39f1@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> <1-w5IvbGvhcSt2Z73Vsg94tV_cJPhWToSd6rIhryALM=.d9e8a7ef-6453-40e3-8463-d4030e3f39f1@github.com> Message-ID: On Wed, 11 Mar 2020 12:43:40 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8200224 >> cleaned up code based on code review > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 550: > >> 549: } >> 550: >> 551: private void setFillOverride(Paint fillOverride) { > > The issue can be alternatively fixed using below change at line#510 > text.fontProperty().addListener(new WeakChangeListener<>((observable, oldValue, newValue) -> { > doneTextWidth = Utils.computeTextWidth(text.getFont(), DONE, 0); > doneTextHeight = Utils.computeTextHeight(text.getFont(), DONE, 0, TextBoundsType.LOGICAL_VERTICAL_CENTER); > })); > > I am not sure which one is better. > As there are no objections, I am good with the any. Nope. This won't work, since the listener will be garbage collected and stop being called. It could be done by keeping the listener is an instance variable, but I recommend the original fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Wed Mar 11 21:38:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 11 Mar 2020 21:38:06 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> Message-ID: <6lYtvW-vewjslQOkAIzCCHx_bImXGZZ6qOIhWYzr0yE=.5928e24b-6529-4d72-a6cf-2c589ced8d5d@github.com> On Tue, 10 Mar 2020 22:41:26 GMT, Kevin Rushforth wrote: >> @kevinrushforth Can you have a look at the test app? I would like to get this moving so we would have time to get the >> rest of the lighting enhancements into 15. > > I'll take a look. My quick thought is that we need some sort of test with a reasonable number of large boxes (so that > it is fill-limited). If there isn't such a case, and the 3D rendering is always node-limited, then the shader > performance doesn't really matter all that much. I suspect we should be able to find a case where it does, but we'll > see. I did some limited testing today with a modification to the test program you attached to create a MeshView with 200 large quads (400 triangles) in a single node. This will eliminate the node overhead. I can confirm that it is fill rate limited, because when I send the exact same amount of data, but make the triangles small, the frame rate goes up as expected. It sill looks like it isn't shader limited, though, at least on my Windows 10 machine, which has an Intel UHD Graphics 630. More testing is needed on other platforms. I'll share the mods to the test program when I have time, but it's basically just creating a set of quads on top of each other by reusing the same 4 points in each pair of faces. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Thu Mar 12 06:44:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Mar 2020 06:44:02 GMT Subject: [Integrated] RFR: 8240832: Remove unused applecoreaudio.md third-party legal file In-Reply-To: References: Message-ID: <9eed1bf5-f1f2-4f8a-b2cc-86fcc3723439@openjdk.org> Changeset: 9ea7f96e Author: Kevin Rushforth Date: 2020-03-10 21:33:51 +0000 URL: https://git.openjdk.java.net/jfx/commit/9ea7f96e 8240832: Remove unused applecoreaudio.md third-party legal file Reviewed-by: almatvee - modules/javafx.media/src/main/legal/applecoreaudio.md From arapte at openjdk.java.net Thu Mar 12 10:47:26 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 12 Mar 2020 10:47:26 GMT Subject: RFR: 8239107: Update libjpeg to version 9d Message-ID: Currently we use IJG libjpeg version 9c released on 14-Jan-2018 We should update the libjpeg to latest version [9d](http://www.ijg.org/) released on 12-Jan-2020 reference: https://jpegclub.org/reference/reference-sources/ ------------- Commit messages: - [WIP] 8239107: Update libjpeg to version 9d Changes: https://git.openjdk.java.net/jfx/pull/143/files Webrev: https://webrevs.openjdk.java.net/jfx/143/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239107 Stats: 858 lines in 26 files changed: 320 ins; 224 del; 314 mod Patch: https://git.openjdk.java.net/jfx/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/143/head:pull/143 PR: https://git.openjdk.java.net/jfx/pull/143 From fastegal at openjdk.java.net Thu Mar 12 11:51:46 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 12 Mar 2020 11:51:46 GMT Subject: [Rev 04] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> <1-w5IvbGvhcSt2Z73Vsg94tV_cJPhWToSd6rIhryALM=.d9e8a7ef-6453-40e3-8463-d4030e3f39f1@github.com> Message-ID: <4aP3Gdyp6LWI0xnh-YiZov7N_lYYWpJx4glyUxLfl40=.39580791-483a-4fdc-a58e-e8af57e2c356@github.com> On Wed, 11 Mar 2020 12:51:12 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 550: >> >>> 549: } >>> 550: >>> 551: private void setFillOverride(Paint fillOverride) { >> >> The issue can be alternatively fixed using below change at line#510 >> text.fontProperty().addListener(new WeakChangeListener<>((observable, oldValue, newValue) -> { >> doneTextWidth = Utils.computeTextWidth(text.getFont(), DONE, 0); >> doneTextHeight = Utils.computeTextHeight(text.getFont(), DONE, 0, TextBoundsType.LOGICAL_VERTICAL_CENTER); >> })); >> >> I am not sure which one is better. >> As there are no objections, I am good with the any. > > Nope. This won't work, since the listener will be garbage collected and stop being called. It could be done by keeping > the listener is an instance variable, but I recommend the original fix. @arapte the (mine :) general rule to follow is to use the highest abstraction available - here that would be to favour skin's api to un/register listeners to properties (which ideally is thoroughly tested) over ad-hoc manual code (which might not work as expected ) sry if I confused anybody with my earlier comment ... ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From fastegal at openjdk.java.net Thu Mar 12 12:34:26 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 12 Mar 2020 12:34:26 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 21:38:15 GMT, Kevin Rushforth wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> extra space removed > > I think the fix looks good and the approach you took for the new test looks good to me. If @kleopatra is OK with it, > then please proceed. > I left a couple minor comments. > > 1. I liked the approach proposed in PoC except the need to send KeyMapping as a parameter to the test. It unnecessarily > makes test look complex. > We already have backward() and forward() helper functions in this test class. The Key presses can easily be decided > based on orientation in these methods. I have modified the PoC test provided by you to make it simpler. > Well, I disagree with your notion of "simpler" - replacing conditional blocks in tests by parameterized tests is the whole point of these. But at the end of the day, it's probably a matter of personal preferences :) > 2. Also, in PoC, testChangeOrientationSimpleForwardSelect does not respect forward selection after Node orientation is > changed. The comment says it all - > `// same arrow as initial,now should have inverse effect` > The forward movement should still be forward even after Node orientation change and not inverse. > the difference between my and your code in changeNodeOrientation is that mine only changes the table's orientation and yours additionally changes the parameter nodeOrientation - resulting in your navigational methods using keys based on the orientation while mine uses those for the old orientation. Changing the parameter smells, IMO. > > I have done modifications to the PoC code provided and added this test in latest commit. > Please review. > Once we agree on the approach- > > * I will add other tests for horizontal keyMappings with modifiers to TableViewHorizontalArrowsTest > > * I will revert changes done to TableViewKeyInputTest agreed on the overall approach, will add a couple of inline comments ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From fastegal at openjdk.java.net Thu Mar 12 12:44:35 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 12 Mar 2020 12:44:35 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: <_Mwfh7fCpZB3c7A7ogfngllzVmlDxaa-BjlXXL2XSO0=.83a97715-6db6-4dba-b1a7-efb5f7f87a95@github.com> On Fri, 6 Mar 2020 11:47:42 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 >> >> Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. >> >> Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press >> tests have been modified to address LTR and RTL orientations. >> Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create >> a test JBS issue and address later) > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > extra space removed sry for the spelling errors you inherited :) modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 31: > 30: import java.util.function.BiConsumer; > 31: > 32: import org.junit.After; unused import (as you don't parameterize on the keys) modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 90: > 89: sm.setCellSelectionEnabled(false); > 90: > 91: tableView.getItems().setAll("1", "2", "3", "4", "5", "6", "7", "8", "9", this test is exclusively about cell navigation, which requires cellSelectionEnabled - so should probably do it here (and remove the setting per test method modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 122: > 121: } > 122: > 123: /** changing the parameter of the test is at least unusual, should be doc'ed so future contributors are aware of it modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 152: > 151: public void testForwardSelect() { > 152: sm.setCellSelectionEnabled(true); > 153: sm.select(0, col0); here (and in other test methods) not needed if cellSelection is enabled in setup ------------- Changes requested by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/114 From fkirmaier at openjdk.java.net Thu Mar 12 14:37:13 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 12 Mar 2020 14:37:13 GMT Subject: [Rev 05] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> Message-ID: > Hi everyone, > > ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 > > The fix itself is quite straight forward. > It basically just removed the listener which causes the leak. > > The unit-test for the fix is a bit more complicated. > > I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for > memory leaks. I think there are many places in the JavaFX-codebase that could highly benefit from this library. > It could also simplify many of the already existing unit tests. > It makes testing for memory-leaks readably and reliable. > It would also be possible to just copy the code of the library into the JavaFX-codebase. > It only contains a single class. > > I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8200224 updated comment based on codereview ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/71/files - new: https://git.openjdk.java.net/jfx/pull/71/files/d8589a95..ba595494 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/71/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/71/webrev.04-05 Stats: 14 lines in 1 file changed: 0 ins; 11 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/71/head:pull/71 PR: https://git.openjdk.java.net/jfx/pull/71 From fkirmaier at openjdk.java.net Thu Mar 12 15:54:23 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 12 Mar 2020 15:54:23 GMT Subject: [Rev 06] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> Message-ID: > Hi everyone, > > ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 > > The fix itself is quite straight forward. > It basically just removed the listener which causes the leak. > > The unit-test for the fix is a bit more complicated. > > I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for > memory leaks. I think there are many places in the JavaFX-codebase that could highly benefit from this library. > It could also simplify many of the already existing unit tests. > It makes testing for memory-leaks readably and reliable. > It would also be possible to just copy the code of the library into the JavaFX-codebase. > It only contains a single class. > > I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8200224 removed create garbage ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/71/files - new: https://git.openjdk.java.net/jfx/pull/71/files/ba595494..bfb6d1c7 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/71/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/71/webrev.05-06 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/71/head:pull/71 PR: https://git.openjdk.java.net/jfx/pull/71 From fkirmaier at openjdk.java.net Thu Mar 12 15:54:24 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 12 Mar 2020 15:54:24 GMT Subject: [Rev 04] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <1-w5IvbGvhcSt2Z73Vsg94tV_cJPhWToSd6rIhryALM=.d9e8a7ef-6453-40e3-8463-d4030e3f39f1@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <1j5ZEUUq6rDKkbz16DG3XNmrTB1tzQhOpR_5UUlFQpE=.cc28f781-2f06-4d1b-b76f-d11740a86976@github.com> <1-w5IvbGvhcSt2Z73Vsg94tV_cJPhWToSd6rIhryALM=.d9e8a7ef-6453-40e3-8463-d4030e3f39f1@github.com> Message-ID: On Wed, 11 Mar 2020 12:38:48 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8200224 >> cleaned up code based on code review > > tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java line 114: > >> 113: } >> 114: public static void createGarbage() { >> 115: LinkedList list = new LinkedList(); > > I think the test should consistently pass or fail without using this method. > Can you please check and remove this method if can be. > I tested once and it passes. It's quite dependent on how the JVM and the GC are implemented. It might be only really required when elements get into a very old generation of the heap. I remember that I required this method to make similar tests stable. Nevertheless, I've now removed the method. This way the test is also more similar to the other memory tests in the jfx project.. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Thu Mar 12 16:18:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Mar 2020 16:18:47 GMT Subject: [Rev 06] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> Message-ID: On Thu, 12 Mar 2020 15:54:23 GMT, Florian Kirmaier wrote: >> Hi everyone, >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 >> >> The fix itself is quite straight forward. >> It basically just removed the listener which causes the leak. >> >> The unit-test for the fix is a bit more complicated. >> >> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for >> memory leaks. I think there are many places in the JavaFX-codebase that could highly benefit from this library. >> It could also simplify many of the already existing unit tests. >> It makes testing for memory-leaks readably and reliable. >> It would also be possible to just copy the code of the library into the JavaFX-codebase. >> It only contains a single class. >> >> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8200224 > removed create garbage Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kevin.rushforth at oracle.com Thu Mar 12 17:11:00 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Mar 2020 10:11:00 -0700 Subject: Proposed schedule for JavaFX 15 Message-ID: Here is the proposed schedule for JavaFX 15. RDP1: Jul 2, 2020 (aka ?feature freeze?) RDP2: Jul 30, 2020 Freeze: Aug 20, 2020 GA: September 8, 2020 We plan to fork a jfx15 stabilization branch at RDP1. The GA date is expected to be one week ahead of JDK 15, matching what we did for 14. As a slight change from previous releases, the start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin From David.Grieve at microsoft.com Thu Mar 12 18:18:31 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Thu, 12 Mar 2020 18:18:31 +0000 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: References: <03DF5DCD-BE78-43E1-9F79-2828B847BE4D@screamingfrog.co.uk> , Message-ID: This fix causes several unit tests to fail. ________________________________ From: David Grieve Sent: Tuesday, March 10, 2020 12:48 PM To: David Grieve ; Danny Gonzalez Cc: openjfx-dev at openjdk.java.net Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to TableView The flickering is happening because of the way VirtualFlow reuses cells. The selected state gets cleared and reset, which is the flicker. This change fixed the flickering for me. I'm not sure why the index of a cell was being set to -1, but the effect of doing so is that when the cell is pulled out of the pile, it looks like a new cell that has to have its index set, selected state set, etc, etc. By commenting out the updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected state, etc turns into noops (more or less). Again, there may have been a good reason for setting index to -1 in this condition. More investigation needs to be done. diff --git a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java index 728e7c5513..a58859bd05 100644 --- a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java +++ b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java @@ -991,9 +991,9 @@ public class VirtualFlow extends Region { lastWidth = -1; lastHeight = -1; releaseCell(accumCell); - for (int i = 0, max = cells.size(); i < max; i++) { - cells.get(i).updateIndex(-1); - } +// for (int i = 0, max = cells.size(); i < max; i++) { +// cells.get(i).updateIndex(-1); +// } addAllToPile(); releaseAllPrivateCells(); } else if (needsReconfigureCells) { > -----Original Message----- > From: openjfx-dev On Behalf Of > David Grieve > Sent: Friday, March 6, 2020 9:29 AM > To: Danny Gonzalez > Cc: openjfx-dev at openjdk.java.net > Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to > TableView > > This might fix the issue, but I?d like to understand better what the root of the > problem is. My concern is that this fix might cause a performance regression. > I?m using the code in JDK-8177945. I want to look at what TableView does > when it adds a cell. Is there something about the selected state that > changes? Or is this just the CSS implementation recalculating styles and un- > necessarily clearing old values? Some debugging is in order. > > From: Danny Gonzalez > Sent: Wednesday, March 4, 2020 4:34 AM > To: David Grieve > Cc: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when > adding data to TableView > > Hi David, > > Just wanted to add some more information. > > The cell selection flashing issue goes away If I put back the following code in > the layout function in Parent.java: > > // > // One idiom employed by developers is to, during the layout pass, > // add or remove nodes from the scene. For example, a ScrollPane > // might add scroll bars to itself if it determines during layout > // that it needs them, or a ListView might add cells to itself if > // it determines that it needs to. In such situations we must > // apply the CSS immediately and not add it to the scene's queue > // for deferred action. > // > // Note that we only call processCSS if the flag is update. If the > // flag is DIRTY_BRANCH, then the whatever children need UPDATE > // will be visited during this layout anyway. On the next pulse, > // doCSSPass will clean up the DIRTY_BRANCH nodes. > // > if (cssFlag == CssFlags.UPDATE) { > processCSS(); > } > > This code was originally added in in the following commit: > > commit e76b5755d4d2752037cc95eb75cb2615a740cc30 > Author: David Grieve > > > Date: Thu Apr 10 15:40:34 2014 -0400 > > RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply > css to child nodes if nothing has changed. 2 - on applyCss, only look for > ancestor node with css state = UPDATE. 3 - only recalculate checksum of css > file if the file has been removed from a scene or parent > > > It was reverted out in this commit: > > commit 05afad6b528e871d607b76aea2642cf788b417fe > Author: David Grieve > > > Date: Tue Apr 15 11:51:38 2014 -0400 > > RT-36672: move code to process css during layout back to impl_reapplyCSS, > which is where it was priort to RT-36559 > > > > > This was the point at which the cell selection flashing appeared. > > > Thanks > > > Danny > > > > On 3 Mar 2020, at 16:50, David Grieve > > > wrote: > > The importance of 05afad6 Is there in the commit itself: > > + // > + // One idiom employed by developers is to, during the layout pass, > + // add or remove nodes from the scene. For example, a ScrollPane > + // might add scroll bars to itself if it determines during layout > + // that it needs them, or a ListView might add cells to itself if > + // it determines that it needs to. In such situations we must > + // apply the CSS immediately and not add it to the scene's queue > + // for deferred action. > + > > If you revert 05afad6, you'll break this. > > This is the first time I've become aware of this flickering issue. I'll have to look > at it. > I wonder if the fix for https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C037e24d8c7a04b55302908d7c512db63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637194557096877039&sdata=SVf8aTwumI0cSp8WQExMJaXZRV7JVxywHXqYt6ye4gI%3D&reserved=0 > 8193445 F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK- > 8193445&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C9148c860ff5 > 24a32ac3208d7c01f2523%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C637189112753556661&sdata=mZrjldSw%2Fjbd0ita58XMU%2BaKM2GlvObq > 3aaQmQb5Poc%3D&reserved=0> has any impact on this. > > > -----Original Message----- > From: openjfx-dev bounces at openjdk.java.net bounces at openjdk.java.net>> On Behalf Of Danny Gonzalez > Sent: Tuesday, March 3, 2020 11:14 AM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding > data to TableView > > > There is currently an open bug to do with the issue of selection flickering > when using single cell selection and when adding data to a TableView. > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da > ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 > d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 > 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb > 8AwcRXVrfLo%3D&reserved=0 > > This bug seems to be low priority because it hasn?t been looked at since I > submitted it at the start of 2017. > > This is quite a major issue for us so I have narrowed down when the issue > was first introduced. > > Here is the changeset: > > commit 05afad6b528e871d607b76aea2642cf788b417fe > Author: David Grieve > jdk.org%3cmailto:dgrieve at openjdk.org>>> > Date: Tue Apr 15 11:51:38 2014 -0400 > > RT-36672: move code to process css during layout back to impl_reapplyCSS, > which is where it was priort to RT-36559 > > > I can?t search the bug database for this bug ID as I believe it was submitted > when a previous bug tracking system was in use. > > Does anyone have any knowledge as to why this fix was needed and what > the repercussions would be if I reverted it out for our local OpenJFX build. > > Alternatively I would be glad to receive any suggestions of how to fix the > flickering issue if this changeset is important to leave in. > > Thanks > > Danny From tsayao at openjdk.java.net Fri Mar 13 00:31:39 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 13 Mar 2020 00:31:39 GMT Subject: [Rev 28] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) 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 five additional commits since the last revision: - Merge branch 'master' into jdk_8236651 - Merge pull request #7 from openjdk/master merge from jfx - Merge pull request #6 from openjdk/master Merge - JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment - Merge pull request #5 from openjdk/master Merge from jfx ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/f7a84fdb..11ca96c7 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.28 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.27-28 Stats: 17809 lines in 174 files changed: 7955 ins; 3779 del; 6075 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From arapte at openjdk.java.net Fri Mar 13 05:34:07 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 13 Mar 2020 05:34:07 GMT Subject: [Rev 06] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> Message-ID: <-iJFt9jWpM5Hz-v0WQ8yFQQVDiHt3qYu7sM_LeekH0M=.f0f51143-901a-4c82-8834-dd9064498b4c@github.com> On Thu, 12 Mar 2020 15:54:23 GMT, Florian Kirmaier wrote: >> Hi everyone, >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 >> >> The fix itself is quite straight forward. >> It basically just removed the listener which causes the leak. >> >> The unit-test for the fix is a bit more complicated. >> >> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for >> memory leaks. I think there are many places in the JavaFX-codebase that could highly benefit from this library. >> It could also simplify many of the already existing unit tests. >> It makes testing for memory-leaks readably and reliable. >> It would also be possible to just copy the code of the library into the JavaFX-codebase. >> It only contains a single class. >> >> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8200224 > removed create garbage Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From jvos at openjdk.java.net Fri Mar 13 12:24:04 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 13 Mar 2020 12:24:04 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: Message-ID: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> On Thu, 24 Oct 2019 16:42:14 GMT, Tobias Diez wrote: > Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url > start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. Hi Tobias, A PR needs to refer a bug in JBS. (see https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) Do you have an account in JBS? If not, I can file one for you. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Mar 13 12:24:04 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 13 Mar 2020 12:24:04 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications Message-ID: Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. ------------- Commit messages: - WebView: Allow to load style sheet from jlink images Changes: https://git.openjdk.java.net/jfx/pull/22/files Webrev: https://webrevs.openjdk.java.net/jfx/22/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240969 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/22/head:pull/22 PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Mar 13 12:24:04 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 13 Mar 2020 12:24:04 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> Message-ID: On Thu, 7 Nov 2019 12:11:39 GMT, Tobias Diez wrote: >> @tobiasdiez are you still interested in pursuing this fix? > > Yes, I am. But, to be honest, it's a bit overly complicated to contribute here with the JBS bug requirement and the > oracle agreement. Hopefully I'll find the time to do this next week. /signed The OCA should be ok now. Is there something else that needs to be done? ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From kcr at openjdk.java.net Fri Mar 13 12:24:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Mar 2020 12:24:04 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> Message-ID: On Tue, 29 Oct 2019 09:44:00 GMT, Johan Vos wrote: >> Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url >> start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. > > Hi Tobias, > A PR needs to refer a bug in JBS. (see https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) > Do you have an account in JBS? If not, I can file one for you. @tobiasdiez are you still interested in pursuing this fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Mar 13 12:24:04 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 13 Mar 2020 12:24:04 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> Message-ID: On Thu, 7 Nov 2019 10:26:12 GMT, Kevin Rushforth wrote: >> Hi Tobias, >> A PR needs to refer a bug in JBS. (see https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) >> Do you have an account in JBS? If not, I can file one for you. > > @tobiasdiez are you still interested in pursuing this fix? Yes, I am. But, to be honest, it's a bit overly complicated to contribute here with the JBS bug requirement and the oracle agreement. Hopefully I'll find the time to do this next week. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From kcr at openjdk.java.net Fri Mar 13 12:24:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Mar 2020 12:24:05 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> Message-ID: On Fri, 20 Dec 2019 14:59:45 GMT, Tobias Diez wrote: >> Yes, I am. But, to be honest, it's a bit overly complicated to contribute here with the JBS bug requirement and the >> oracle agreement. Hopefully I'll find the time to do this next week. > > /signed > > The OCA should be ok now. Is there something else that needs to be done? Once your GitHub account is linked to your OCA, the bot will remove the `oca*` labels. The other thing that is needed is a bug report in JBS. You can file one at [bugreport.java.com](https://bugreport.java.com/). This should include a test program, ideally one that you can turn into an automated unit test. @tobiasdiez Your OCA has now been processed and linked with your GitHub account. This can proceed once we have a bug filed in JBS with a test case. @tobiasdiez in case you missed the earlier comment, this is now ready for you to proceed. All we need is a bug report with a test case. You can file the bug at [bugreport.java.com](https://bugreport.java.com/). ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+13982707+HGuillemet at openjdk.java.net Fri Mar 13 12:24:05 2020 From: github.com+13982707+HGuillemet at openjdk.java.net (HGuillemet) Date: Fri, 13 Mar 2020 12:24:05 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> Message-ID: On Wed, 12 Feb 2020 16:53:11 GMT, Kevin Rushforth wrote: >> /signed >> >> The OCA should be ok now. Is there something else that needs to be done? > > @tobiasdiez in case you missed the earlier comment, this is now ready for you to proceed. All we need is a bug report > with a test case. You can file the bug at [bugreport.java.com](https://bugreport.java.com/). Has this bug been finally reported ? I can do it if it didn't. I'm having the same problem than Tobias. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Mar 13 12:24:05 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 13 Mar 2020 12:24:05 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> Message-ID: <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> On Tue, 25 Feb 2020 16:14:05 GMT, HGuillemet wrote: >> @tobiasdiez in case you missed the earlier comment, this is now ready for you to proceed. All we need is a bug report >> with a test case. You can file the bug at [bugreport.java.com](https://bugreport.java.com/). > > Has this bug been finally reported ? I can do it if it didn't. > I'm having the same problem than Tobias. Sorry for the delay, but I've finally managed to create the required bug report (internal review ID : 9063979) ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From kcr at openjdk.java.net Fri Mar 13 12:24:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Mar 2020 12:24:05 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> Message-ID: <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> On Wed, 11 Mar 2020 22:50:11 GMT, Tobias Diez wrote: >> Has this bug been finally reported ? I can do it if it didn't. >> I'm having the same problem than Tobias. > > Sorry for the delay, but I've finally managed to create the required bug report (internal review ID : 9063979) This has now been transferred to the JDK project as [JDK-8240969](https://bugs.openjdk.java.net/browse/JDK-8240969). You can update the title of this PR to include the bug ID, followed by a `:`, then a space, then the exact title from the bug you are fixing. So: 8240969: WebView does not allow to load style sheet in modularized applications I note that we still need a test program that fails currently, and passes with your patch. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Mar 13 12:26:05 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 13 Mar 2020 12:26:05 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Thu, 12 Mar 2020 21:31:22 GMT, Kevin Rushforth wrote: >> Sorry for the delay, but I've finally managed to create the required bug report (internal review ID : 9063979) > > This has now been transferred to the JDK project as [JDK-8240969](https://bugs.openjdk.java.net/browse/JDK-8240969). > You can update the title of this PR to include the bug ID, followed by a `:`, then a space, then the exact title from > the bug you are fixing. So: 8240969: WebView does not allow to load style sheet in modularized applications > > I note that we still need a test program that fails currently, and passes with your patch. I've changed the title accordingly. However, I've no idea how to add a test and couldn't find any unit test concerning `UserStyleSheetLocation` (apart from some tests that make sure it was invoked on the Javafx thread). ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From kcr at openjdk.java.net Fri Mar 13 12:57:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Mar 2020 12:57:36 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Fri, 13 Mar 2020 12:23:50 GMT, Tobias Diez wrote: >> This has now been transferred to the JDK project as [JDK-8240969](https://bugs.openjdk.java.net/browse/JDK-8240969). >> You can update the title of this PR to include the bug ID, followed by a `:`, then a space, then the exact title from >> the bug you are fixing. So: 8240969: WebView does not allow to load style sheet in modularized applications >> >> I note that we still need a test program that fails currently, and passes with your patch. > > I've changed the title accordingly. However, I've no idea how to add a test and couldn't find any unit test concerning > `UserStyleSheetLocation` (apart from some tests that make sure it was invoked on the Javafx thread). You must have some use case that fails without this proposed fix (else why are you proposing it), right? ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Mar 13 13:08:05 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 13 Mar 2020 13:08:05 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Fri, 13 Mar 2020 12:55:27 GMT, Kevin Rushforth wrote: >> I've changed the title accordingly. However, I've no idea how to add a test and couldn't find any unit test concerning >> `UserStyleSheetLocation` (apart from some tests that make sure it was invoked on the Javafx thread). > > You must have some use case that fails without this proposed fix (else why are you proposing it), right? Yes, we had this exception in our application which was (temporarily) fixed with https://github.com/JabRef/jabref/pull/5497. But JabRef is 100k lines of code, so I doubt this counts as a unit test. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From kcr at openjdk.java.net Fri Mar 13 13:13:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Mar 2020 13:13:06 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Fri, 13 Mar 2020 13:05:29 GMT, Tobias Diez wrote: >> You must have some use case that fails without this proposed fix (else why are you proposing it), right? > > Yes, we had this exception in our application which was (temporarily) fixed with > https://github.com/JabRef/jabref/pull/5497. But JabRef is 100k lines of code, so I doubt this counts as a unit test. In that case, we will need you to distill it down to a simple, standalone test program. It seems that it might not be suitable for a unit test, but we need some test to show that the fix is failing now, and works after your proposed fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+60214806+ronyfla at openjdk.java.net Fri Mar 13 14:11:20 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Fri, 13 Mar 2020 14:11:20 GMT Subject: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: <4Msst48GfgK5UZvfe7CCgBB0uCJtNr60y56EHZsFmNw=.73e8df74-4bb4-4255-a7e9-9a250349f507@github.com> References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> <9bB6LCXUWSjh_soInsnyv63Igy2ZeJKVkzIyR_vKhzU=.1ee8dda6-4776-42d1-9d47-4106b28b680a@github.com> <4Msst48GfgK5UZvfe7CCgBB0uCJtNr60y56EHZsFmNw=.73e8df74-4bb4-4255-a7e9-9a250349f507@github.com> Message-ID: On Mon, 2 Mar 2020 16:49:45 GMT, Kevin Rushforth wrote: >> Removed executable bits from gradlew (which I manually have added to become able to run ./gradlew) and pushed it, >> however the commit has not appeared. Not wanting to add more noise, I stop until advised differently. > > Btw, I recommend to run `sh gradlew ...` so you don't have to change the permission locally. Is there anything I can do to keep the ball rolling ? ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From kcr at openjdk.java.net Fri Mar 13 15:05:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Mar 2020 15:05:06 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Sat, 7 Mar 2020 14:11:59 GMT, Kevin Rushforth wrote: >> From what I see, they save the same data. > > The anonymous subclasses don't have an instance field for the `bean` or the `name`, so the tradeoff is one of static > footprint (an extra anonymous inner class) for dynamic footprint (slightly larger instances). > Note, however, that this savings is reduced by the fact that the inner classes have a `this$0` pointer to the enclosing > class. I think this means that we are really only saving one reference variable per instance of the anonymous inner > class versus an instance of SimpleXxxxProperty. That's why I think that in the specific case of this proposed fix, it > should be fine. I just want to take a closer look. I ran tests to validate my above assumption, and the results match my expectations. Using a `SimpleXxxxxProperty` takes an extra 8 bytes (one object reference) of storage versus an anonymous inner class. I used a null bean and a `this$0` reference to get the name. I measured it by checking the memory needed for 1,000,000 instances of an anonymous subclass of `DoublePropertyBase` objects versus 1,000,000 instances of `SimpleDoubleProperty`. The former takes 40 bytes per instance while the latter takes 48 bytes. This represents a 20% increase in memory used. To see how much this affects the case of the wrapped property objects, I ran two tests on the current code and the same two tests with your proposed fix. The first test creates an `ObjectProperty` object from a `DoubleProperty` using `DoubleProperty::asObject`. The second test created a `DoubleProperty` object from an `ObjectProperty` using `DoubleProperty::doubleProperty`. I got the same results as for the earlier tests: 8 additional bytes (one object reference) using `SimpleXxxxProperty` to create the new wrapped property object. Since these objects are already fairly large due to the bidirectional binding created between the original property and the wrapping property, the percentage increase is not all that great -- about 3.8% in the case of `xxxxProperty`. | Method | bytes/object current | bytes/object with patch | | --- | --- | --- | | DoubleProperty::asObject | 232 | 240 | | DoubleProperty::doubleProperty | 208 | 216 | So this begs the question: Do we still want to do this? Is the cleanup worth the extra memory used? ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From kcr at openjdk.java.net Fri Mar 13 15:17:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Mar 2020 15:17:58 GMT Subject: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> <9bB6LCXUWSjh_soInsnyv63Igy2ZeJKVkzIyR_vKhzU=.1ee8dda6-4776-42d1-9d47-4106b28b680a@github.com> <4Msst48GfgK5UZvfe7CCgBB0uCJtNr60y56EHZsFmNw=.73e8df74-4bb4-4255-a7e9-9a250349f507@github.com> Message-ID: On Fri, 13 Mar 2020 14:09:04 GMT, Rony G. Flatscher wrote: >> Btw, I recommend to run `sh gradlew ...` so you don't have to change the permission locally. > > Is there anything I can do to keep the ball rolling ? I just need time to do final testing of this, along with the review of the updated test. @aghaisas will also review. ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From tsayao at openjdk.java.net Fri Mar 13 17:19:25 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 13 Mar 2020 17:19:25 GMT Subject: [Rev 29] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: <6DRDYhabyH_OhdtoBMRHX6KzTxbu11_eeKE7LC11fvM=.fa98ba9b-21ed-49cd-8624-041e65614f4b@github.com> > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk_8236651' into jdk_8236651 - Fix compile error on implicit function declaration on updated g++ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/11ca96c7..31080932 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.29 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.28-29 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From aghaisas at openjdk.java.net Fri Mar 13 17:26:06 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 13 Mar 2020 17:26:06 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: <_Mwfh7fCpZB3c7A7ogfngllzVmlDxaa-BjlXXL2XSO0=.83a97715-6db6-4dba-b1a7-efb5f7f87a95@github.com> References: <_Mwfh7fCpZB3c7A7ogfngllzVmlDxaa-BjlXXL2XSO0=.83a97715-6db6-4dba-b1a7-efb5f7f87a95@github.com> Message-ID: On Thu, 12 Mar 2020 12:39:16 GMT, Jeanette Winzenburg wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> extra space removed > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 122: > >> 121: } >> 122: >> 123: /** > > changing the parameter of the test is at least unusual, should be doc'ed so future contributors are aware of it Good catch!!! It definitely would have unintentional side effect of incorrect orientation in subsequent tests. I updated the test to restore the orientation at the end of the test. Also documented the same. ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From arapte at openjdk.java.net Fri Mar 13 17:30:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 13 Mar 2020 17:30:06 GMT Subject: [Rev 02] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Mon, 9 Mar 2020 10:01:53 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Avoid useless width and height calculation The change seems good to me. Suggested few minor corrections and a query. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1493: > 1492: } > 1493: else { > 1494: rt.readPixels(buffer, rt.getContentX(), rt.getContentY(), w, h); Please correct the `if` `else` formatting here and other places. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1527: > 1526: private int computeOptimumTileSize(int size, int maxSize, AtomicBoolean isDivExact) { > 1527: // This methods attempts to find the smallest integer divider for the provided `size` > 1528: // while the result of the division is less than `maxSize`. This **method** attempts to.... modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1575: > 1574: } > 1575: // Find out it is is possible to divide up the image in tiles of the same size > 1576: AtomicBoolean exactWidthDivFound = new AtomicBoolean(false); Find out **if it** is possible... modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1600: > 1599: } > 1600: } > 1601: } The `if (exactHeightDivFound.get())` and `else` block here look effectively same. Could you please take a re-look or explain what am I missing here. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1576: > 1575: // Find out it is is possible to divide up the image in tiles of the same size > 1576: AtomicBoolean exactWidthDivFound = new AtomicBoolean(false); > 1577: int tileWidth = computeOptimumTileSize(w, maxTextureSize, exactWidthDivFound); `exactWidthDivFound` is unused, may be can skip creating a named variable and just pass a unnamed `AtomicBoolean` in next call to `computeOptimumTileSize` ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/112 From aghaisas at openjdk.java.net Fri Mar 13 17:48:31 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 13 Mar 2020 17:48:31 GMT Subject: [Rev 05] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press > tests have been modified to address LTR and RTL orientations. > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create > a test JBS issue and address later) Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Fixed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/114/files - new: https://git.openjdk.java.net/jfx/pull/114/files/b987fcc8..c17d6fdc Webrevs: - full: https://webrevs.openjdk.java.net/jfx/114/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/114/webrev.04-05 Stats: 915 lines in 3 files changed: 194 ins; 470 del; 251 mod Patch: https://git.openjdk.java.net/jfx/pull/114.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/114/head:pull/114 PR: https://git.openjdk.java.net/jfx/pull/114 From aghaisas at openjdk.java.net Fri Mar 13 17:53:02 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 13 Mar 2020 17:53:02 GMT Subject: [Rev 06] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press > tests have been modified to address LTR and RTL orientations. > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create > a test JBS issue and address later) Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: whitespaces removed ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/114/files - new: https://git.openjdk.java.net/jfx/pull/114/files/c17d6fdc..49f9d484 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/114/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/114/webrev.05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/114.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/114/head:pull/114 PR: https://git.openjdk.java.net/jfx/pull/114 From johan.vos at gluonhq.com Fri Mar 13 18:25:21 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 13 Mar 2020 19:25:21 +0100 Subject: RFR: 8241021: Change JavaFX release version in 11-dev to 11.0.7 Message-ID: Hi Kevin, Please review http://cr.openjdk.java.net/~jvos/8241021/webrev.00/ which fixes https://bugs.openjdk.java.net/browse/JDK-8241021 Thanks, - Johan From kevin.rushforth at oracle.com Fri Mar 13 18:28:07 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Mar 2020 11:28:07 -0700 Subject: RFR: 8241021: Change JavaFX release version in 11-dev to 11.0.7 In-Reply-To: References: Message-ID: +1 -- Kevin On 3/13/2020 11:25 AM, Johan Vos wrote: > Hi Kevin, > > Please review http://cr.openjdk.java.net/~jvos/8241021/webrev.00/ which > fixes https://bugs.openjdk.java.net/browse/JDK-8241021 > > Thanks, > > - Johan From github.com+7450507+fthevenet at openjdk.java.net Sat Mar 14 13:14:51 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Sat, 14 Mar 2020 13:14:51 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Fixed code style and typo following review. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/9c5b0d4a..50ac8c22 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.02-03 Stats: 154 lines in 1 file changed: 52 ins; 85 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Sat Mar 14 13:17:26 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Sat, 14 Mar 2020 13:17:26 GMT Subject: [Rev 02] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: <5USkyWoIR0r77s0aM-BhgaXVwc2hp9feH42wYgzuGHA=.a19aee1f-3ee6-4517-8759-c1068ba36909@github.com> On Fri, 13 Mar 2020 17:26:35 GMT, Ambarish Rapte wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid useless width and height calculation > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1576: > >> 1575: // Find out it is is possible to divide up the image in tiles of the same size >> 1576: AtomicBoolean exactWidthDivFound = new AtomicBoolean(false); >> 1577: int tileWidth = computeOptimumTileSize(w, maxTextureSize, exactWidthDivFound); > > `exactWidthDivFound` is unused, may be can skip creating a named variable and just pass a unnamed `AtomicBoolean` in > next call to `computeOptimumTileSize` I've made a change so that null can be passed to the method if the AtomicBoolean instance is not needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Sat Mar 14 13:27:16 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Sat, 14 Mar 2020 13:27:16 GMT Subject: [Rev 02] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Fri, 13 Mar 2020 17:24:02 GMT, Ambarish Rapte wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid useless width and height calculation > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1600: > >> 1599: } >> 1600: } >> 1601: } > > The `if (exactHeightDivFound.get())` and `else` block here look effectively same. Could you please take a re-look or > explain what am I missing here. Functionally, both side of the condition actually do the exact same thing, but the side effects of which dimension is processed in the inner loop sometime have measurable consequences in terms of performances; I've added the following comment to the code to better explain this: // In order to minimize the number of time we have to resize the underlying // surface for capturing a tile, choose a dimension that has an exact divider // (if any) to be processed in the inner most loop. // E.g. looping on width then height in the example bellow requires four // surface resizing, whereas the opposite requires only two: // // for (w;;) for (h;;) // for(h;;) for(w;;) // ----------------- ----------------- // | | | | | | // | 1 | 3 | | 1 | 2 | // h | | | h | | | // ----------------- ----------------- // | 2 | 4 | | 3 | 4 | // ----------------- ----------------- // w w ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Sat Mar 14 15:21:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 14 Mar 2020 15:21:04 GMT Subject: RFR: 8239107: Update libjpeg to version 9d In-Reply-To: References: Message-ID: <9VNfEgECXwQe87f-QGVyastFpl6_BxLg2nKApPRWdLU=.3b353c98-c96f-4270-b0ad-d0b4076899b5@github.com> On Thu, 12 Mar 2020 10:43:37 GMT, Ambarish Rapte wrote: > Currently we use IJG libjpeg version 9c released on 14-Jan-2018 > We should update the libjpeg to latest version [9d](http://www.ijg.org/) released on 12-Jan-2020 > > reference: https://jpegclub.org/reference/reference-sources/ Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/143 From kcr at openjdk.java.net Sat Mar 14 15:33:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 14 Mar 2020 15:33:27 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <6lYtvW-vewjslQOkAIzCCHx_bImXGZZ6qOIhWYzr0yE=.5928e24b-6529-4d72-a6cf-2c589ced8d5d@github.com> References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> <6lYtvW-vewjslQOkAIzCCHx_bImXGZZ6qOIhWYzr0yE=.5928e24b-6529-4d72-a6cf-2c589ced8d5d@github.com> Message-ID: On Wed, 11 Mar 2020 21:35:55 GMT, Kevin Rushforth wrote: >> I'll take a look. My quick thought is that we need some sort of test with a reasonable number of large boxes (so that >> it is fill-limited). If there isn't such a case, and the 3D rendering is always node-limited, then the shader >> performance doesn't really matter all that much. I suspect we should be able to find a case where it does, but we'll >> see. > > I did some limited testing today with a modification to the test program you attached to create a MeshView with 200 > large quads (400 triangles) in a single node. This will eliminate the node overhead. I can confirm that it is fill rate > limited, because when I send the exact same amount of data, but make the triangles small, the frame rate goes up as > expected. It sill looks like it isn't shader limited, though, at least on my Windows 10 machine, which has an Intel > UHD Graphics 630. More testing is needed on other platforms. I'll share the mods to the test program when I have time, > but it's basically just creating a set of quads on top of each other by reusing the same 4 points in each pair of faces. I'll attach the above modified testcase that I ran. I ran it on a relatively new Windows 10 laptop and a rather ancient MacBook Pro. I had to drastically reduce the number of quads on the Mac, but the results are similar: no significant difference between the current code and the proposed patch for point lights (without attenuation). I'd like to see results on a recent machine with a graphics accelerator (either NVIDIA or AMD/ATI) to see if the new shader hurts performance there, but I suspect it will be fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Sat Mar 14 15:33:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 14 Mar 2020 15:33:27 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> <6lYtvW-vewjslQOkAIzCCHx_bImXGZZ6qOIhWYzr0yE=.5928e24b-6529-4d72-a6cf-2c589ced8d5d@github.com> Message-ID: On Sat, 14 Mar 2020 15:29:59 GMT, Kevin Rushforth wrote: >> I did some limited testing today with a modification to the test program you attached to create a MeshView with 200 >> large quads (400 triangles) in a single node. This will eliminate the node overhead. I can confirm that it is fill rate >> limited, because when I send the exact same amount of data, but make the triangles small, the frame rate goes up as >> expected. It sill looks like it isn't shader limited, though, at least on my Windows 10 machine, which has an Intel >> UHD Graphics 630. More testing is needed on other platforms. I'll share the mods to the test program when I have time, >> but it's basically just creating a set of quads on top of each other by reusing the same 4 points in each pair of faces. > > I'll attach the above modified testcase that I ran. I ran it on a relatively new Windows 10 laptop and a rather ancient > MacBook Pro. I had to drastically reduce the number of quads on the Mac, but the results are similar: no significant > difference between the current code and the proposed patch for point lights (without attenuation). I'd like to see > results on a recent machine with a graphics accelerator (either NVIDIA or AMD/ATI) to see if the new shader hurts > performance there, but I suspect it will be fine. Updated test case: [attenTest2.zip](https://github.com/openjdk/jfx/files/4332937/attenTest2.zip) ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From ebresie at gmail.com Sun Mar 15 13:34:12 2020 From: ebresie at gmail.com (Eric Bresie) Date: Sun, 15 Mar 2020 08:34:12 -0500 Subject: Request for adding my github userid .. In-Reply-To: 2c82ebfe-f3c3-47e7-42fd-d4dfbec6b95d@oracle.com References: 5dced4eb-b855-d789-b6bb-10bb445b352e@wu.ac.at 540a9ae7-2388-197b-0a79-80d7f008bee8@oracle.com 5E5157D5.1070701@oracle.com ed7da44f-a80d-756a-7fe1-e9673500ec65@wu.ac.at fed600e6-0a86-1706-4bf3-2e1153003839@oracle.com fed600e6-0a86-1706-4bf3-2e1153003839@oracle.com Message-ID: <1978ed4c-360c-42c7-977b-d14cc77de9b3@Erics-iPhone-X> Silly question... Is this whole new contributor process (i.e. including the GitHub id association, sakara notations in the ticket, etc.) documented someplace outside of mailing list? Eric Bresie Ebresie at gmail.com > On February 26, 2020 at 4:17:59 AM CST, Dalibor Topic wrote: > Yeah, he did. ;) > > On 22.02.2020 17:58, Kevin Rushforth wrote: > > You should be all set now. Dalibor will likely take care of this early > > next week. > > > > -- Kevin > > > > > > On 2/22/2020 8:42 AM, Rony G. Flatscher wrote: > > > On 22.02.2020 17:33, Philip Race wrote: > > > > What openjdk ID would this be associated with ? > > > 8234959 (tel:8234959): FXMLLoader does not populate ENGINE_SCOPE Bindings with > > > FILENAME and ARGV #122 > > > > > > One PR is the fix another one is dubbed as WIP and has the test unit > > > for this bug (such that one can > > > apply it before and after the fix). > > > > > > > I don't see a Rony Flatscher in the census : > > > > https://openjdk.java.net/census > > > > > > > > Rony, Have you made contributions and been granted author status ? > > > No, this is the first time I try to contribute code. > > > > If yes, where is it on that page ? If not, then you need to make > > > > contributions > > > > (not just sign the OCA) before you get author status and until then > > > > there is nothing > > > > with which to associate your github id. > > > Hmm, how should I then submit a fix/a pull request? > > > > > > The OCA was processed in 2017-03-01 (reported by Dalibor Topic), as > > > suggested I introduced myself in > > > [1]. However, for various reasons I got side tracked and only came > > > back this last November. > > > > > > @Kevin: thank you for your advice, did comment on both PR > > > > > > ---rony > > > > > > [1] "Introduction": > > > > > > > > > > > > > > > > On 2/22/20, 8:27 AM, Kevin Rushforth wrote: > > > > > What you need to do is this: > > > > > > > > > > > Once you have signed the OCA, please let us know by writing > > > > > > `/signed` in a comment in this pull > > > > > request. > > > > > > > > > > Omit the quotes in the command. > > > > > > > > > > This will alert the Skara maintainers to check your OCA status and > > > > > make the association. > > > > > > > > > > -- Kevin > > > > > > > > > > > > > > > On 2/22/2020 8:20 AM, Rony G. Flatscher wrote: > > > > > > Trying to place my first pull requests via github and received the > > > > > > following e-mail: > > > > > > > > > > > > --- cut --- > > > > > > > > > > > > Hi ronyfla, welcome to this OpenJDK project and thanks for > > > > > > contributing! > > > > > > > > > > > > We do not recognize you as Contributor > > > > > > and need to > > > > > > ensure you have signed the Oracle Contributor Agreement (OCA). If > > > > > > you have not signed the OCA, > > > > > > please follow the instructions > > > > > > . > > > > > > Please fill in your GitHub username in the "Username" field of the > > > > > > application. Once you have > > > > > > signed > > > > > > the OCA, please let us know by writing |/signed| in a comment in > > > > > > this pull request. > > > > > > > > > > > > If you already are an OpenJDK Author > > > > > > , Committer > > > > > > or Reviewer > > > > > > , > > > > > > please click here > > > > > > > > > > > > to > > > > > > open a new issue so that we can record that fact. Please use "Add > > > > > > GitHub user ronyfla" as summary > > > > > > for the issue. > > > > > > > > > > > > If you are contributing this work on behalf of your employer and > > > > > > your employer has signed the OCA, > > > > > > please let us know by writing |/covered| in a comment in this pull > > > > > > request. > > > > > > > > > > > > --- cut --- > > > > > > > > > > > > So I am kindly requesting to associate my github user id 'ronyfla' > > > > > > with my signed OCA form such > > > > > > that > > > > > > the pull requests can go forward. > > > > > > > > > > > > TIA > > > > > > > > > > > > ---rony > > > > > > > > > > > > P.S.: In the meantime I have changed the github e-mail address for > > > > > > 'ronyfla' to the one in the OCA > > > > > > if that makes a difference. > > > > -- > Dalibor Topic > Consulting Product Manager > Phone: +494089091214 (tel:+494089091214) , Mobile: +491737185961 (tel:+491737185961) > , Video: dalibor.topic at oracle.com > > > Oracle Global Services Germany GmbH > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRB 246209 > Gesch?ftsf?hrer: Ralf Herrmann > From philip.race at oracle.com Sun Mar 15 18:03:17 2020 From: philip.race at oracle.com (Philip Race) Date: Sun, 15 Mar 2020 11:03:17 -0700 Subject: Request for adding my github userid .. In-Reply-To: <1978ed4c-360c-42c7-977b-d14cc77de9b3@Erics-iPhone-X> References: 5dced4eb-b855-d789-b6bb-10bb445b352e@wu.ac.at 540a9ae7-2388-197b-0a79-80d7f008bee8@oracle.com 5E5157D5.1070701@oracle.com ed7da44f-a80d-756a-7fe1-e9673500ec65@wu.ac.at fed600e6-0a86-1706-4bf3-2e1153003839@oracle.com fed600e6-0a86-1706-4bf3-2e1153003839@oracle.com <1978ed4c-360c-42c7-977b-d14cc77de9b3@Erics-iPhone-X> Message-ID: <5E6E6DE5.2080201@oracle.com> https://wiki.openjdk.java.net/display/SKARA/Skara#Skara-AssociatingyourGitHubaccountandyourOpenJDKusername -phil. On 3/15/20, 6:34 AM, Eric Bresie wrote: > Silly question... > > Is this whole new contributor process (i.e. including the GitHub id association, sakara notations in the ticket, etc.) documented someplace outside of mailing list? > > Eric Bresie > Ebresie at gmail.com >> On February 26, 2020 at 4:17:59 AM CST, Dalibor Topic wrote: >> Yeah, he did. ;) >> >> On 22.02.2020 17:58, Kevin Rushforth wrote: >>> You should be all set now. Dalibor will likely take care of this early >>> next week. >>> >>> -- Kevin >>> >>> >>> On 2/22/2020 8:42 AM, Rony G. Flatscher wrote: >>>> On 22.02.2020 17:33, Philip Race wrote: >>>>> What openjdk ID would this be associated with ? >>>> 8234959 (tel:8234959): FXMLLoader does not populate ENGINE_SCOPE Bindings with >>>> FILENAME and ARGV #122 >>>> >>>> One PR is the fix another one is dubbed as WIP and has the test unit >>>> for this bug (such that one can >>>> apply it before and after the fix). >>>> >>>>> I don't see a Rony Flatscher in the census : >>>>> https://openjdk.java.net/census >>>>> >>>>> Rony, Have you made contributions and been granted author status ? >>>> No, this is the first time I try to contribute code. >>>>> If yes, where is it on that page ? If not, then you need to make >>>>> contributions >>>>> (not just sign the OCA) before you get author status and until then >>>>> there is nothing >>>>> with which to associate your github id. >>>> Hmm, how should I then submit a fix/a pull request? >>>> >>>> The OCA was processed in 2017-03-01 (reported by Dalibor Topic), as >>>> suggested I introduced myself in >>>> [1]. However, for various reasons I got side tracked and only came >>>> back this last November. >>>> >>>> @Kevin: thank you for your advice, did comment on both PR >>>> >>>> ---rony >>>> >>>> [1] "Introduction": >>>> >>>> >>>> >>>> >>>>> On 2/22/20, 8:27 AM, Kevin Rushforth wrote: >>>>>> What you need to do is this: >>>>>> >>>>>>> Once you have signed the OCA, please let us know by writing >>>>>>> `/signed` in a comment in this pull >>>>>> request. >>>>>> >>>>>> Omit the quotes in the command. >>>>>> >>>>>> This will alert the Skara maintainers to check your OCA status and >>>>>> make the association. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 2/22/2020 8:20 AM, Rony G. Flatscher wrote: >>>>>>> Trying to place my first pull requests via github and received the >>>>>>> following e-mail: >>>>>>> >>>>>>> --- cut --- >>>>>>> >>>>>>> Hi ronyfla, welcome to this OpenJDK project and thanks for >>>>>>> contributing! >>>>>>> >>>>>>> We do not recognize you as Contributor >>>>>>> and need to >>>>>>> ensure you have signed the Oracle Contributor Agreement (OCA). If >>>>>>> you have not signed the OCA, >>>>>>> please follow the instructions >>>>>>> . >>>>>>> Please fill in your GitHub username in the "Username" field of the >>>>>>> application. Once you have >>>>>>> signed >>>>>>> the OCA, please let us know by writing |/signed| in a comment in >>>>>>> this pull request. >>>>>>> >>>>>>> If you already are an OpenJDK Author >>>>>>> , Committer >>>>>>> or Reviewer >>>>>>> , >>>>>>> please click here >>>>>>> >>>>>>> to >>>>>>> open a new issue so that we can record that fact. Please use "Add >>>>>>> GitHub user ronyfla" as summary >>>>>>> for the issue. >>>>>>> >>>>>>> If you are contributing this work on behalf of your employer and >>>>>>> your employer has signed the OCA, >>>>>>> please let us know by writing |/covered| in a comment in this pull >>>>>>> request. >>>>>>> >>>>>>> --- cut --- >>>>>>> >>>>>>> So I am kindly requesting to associate my github user id 'ronyfla' >>>>>>> with my signed OCA form such >>>>>>> that >>>>>>> the pull requests can go forward. >>>>>>> >>>>>>> TIA >>>>>>> >>>>>>> ---rony >>>>>>> >>>>>>> P.S.: In the meantime I have changed the github e-mail address for >>>>>>> 'ronyfla' to the one in the OCA >>>>>>> if that makes a difference. >> -- >> Dalibor Topic >> Consulting Product Manager >> Phone: +494089091214 (tel:+494089091214), Mobile: +491737185961 (tel:+491737185961) >> , Video: dalibor.topic at oracle.com >> >> >> Oracle Global Services Germany GmbH >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRB 246209 >> Gesch?ftsf?hrer: Ralf Herrmann >> From nlisker at openjdk.java.net Sun Mar 15 20:51:05 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 15 Mar 2020 20:51:05 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Fri, 13 Mar 2020 15:02:48 GMT, Kevin Rushforth wrote: > So this begs the question: Do we still want to do this? Is the cleanup worth the extra memory used? I'm not sure. This raises the opposite question: are there any places where we can benefit from introducing anonymous classes instead of the current implementation? In my own code, I prefer the readability and conciseness over performance. However, since JavaFX is a library, we might want to go with the performance route. I don't know how important the memory consumption is for users in this case or the other similar cases. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From fastegal at openjdk.java.net Mon Mar 16 12:49:55 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 16 Mar 2020 12:49:55 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Sun, 15 Mar 2020 20:48:57 GMT, Nir Lisker wrote: >> I ran tests to validate my above assumption, and the results match my expectations. Using a `SimpleXxxxxProperty` takes >> an extra 8 bytes (one object reference) of storage versus an anonymous inner class. I used a null bean and a `this$0` >> reference to get the name. I measured it by checking the memory needed for 1,000,000 instances of an anonymous subclass >> of `DoublePropertyBase` objects versus 1,000,000 instances of `SimpleDoubleProperty`. The former takes 40 bytes per >> instance while the latter takes 48 bytes. This represents a 20% increase in memory used. To see how much this affects >> the case of the wrapped property objects, I ran two tests on the current code and the same two tests with your proposed >> fix. The first test creates an `ObjectProperty` object from a `DoubleProperty` using >> `DoubleProperty::asObject`. The second test created a `DoubleProperty` object from an `ObjectProperty` using >> `DoubleProperty::doubleProperty`. I got the same results as for the earlier tests: 8 additional bytes (one object >> reference) using `SimpleXxxxProperty` to create the new wrapped property object. Since these objects are already fairly >> large due to the bidirectional binding created between the original property and the wrapping property, the percentage >> increase is not all that great -- about 3.8% in the case of `xxxxProperty`. | Method | bytes/object current | >> bytes/object with patch | | --- | --- | --- | | DoubleProperty::asObject | 232 | 240 | | DoubleProperty::doubleProperty >> | 208 | 216 | So this begs the question: Do we still want to do this? Is the cleanup worth the extra memory used? > >> So this begs the question: Do we still want to do this? Is the cleanup worth the extra memory used? > > I'm not sure. This raises the opposite question: are there any places where we can benefit from introducing anonymous > classes instead of the current implementation? > In my own code, I prefer the readability and conciseness over performance. However, since JavaFX is a library, we might > want to go with the performance route. I don't know how important the memory consumption is for users in this case or > the other similar cases. Just playing devil's advocate :) Technically, there's a functional difference between the inline extension and useage of SimpleXX: in the former, getName returns the current name of mapped property, in the latter it returns its name at the time of creating the mapped property. Afaics, there is nothing in the spec of getName that prevents custom implementations with name (and bean) being mutable (the SimpleXX have implemented them immutable, but then they are only default implementations). Not that I can imagine any use-case for it, but if they exist, the new mappings might break existing code. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From fastegal at openjdk.java.net Mon Mar 16 13:02:41 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 16 Mar 2020 13:02:41 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: <_Mwfh7fCpZB3c7A7ogfngllzVmlDxaa-BjlXXL2XSO0=.83a97715-6db6-4dba-b1a7-efb5f7f87a95@github.com> Message-ID: <5OGtw62TFw3n02pHTr0jajHzPb0EFXU_D9sAxdtxNzI=.ba0a34fa-3441-42a3-9ea4-b15e05c998b8@github.com> On Fri, 13 Mar 2020 17:23:52 GMT, Ajit Ghaisas wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 122: >> >>> 121: } >>> 122: >>> 123: /** >> >> changing the parameter of the test is at least unusual, should be doc'ed so future contributors are aware of it > > Good catch!!! > It definitely would have unintentional side effect of incorrect orientation in subsequent tests. > I updated the test to restore the orientation at the end of the test. Also documented the same. hmm ... don't think that it will effect subsequent tests, though might be mis-understanding the api doc of Parameterized: > When running a parameterized test class, instances are created for the cross-product of the test methods and the test > data elements. So just suggested to change the doc of the method, something like Changes the parameter nodeOrientation and sets the table's orientation to the new value Alternatively, leave the parameter alone, just toggle the table's orientation and change the forward/backward methods to choose the keys based on the table's current orientation. Or fully parameterize on the keys - sry, can't resist :) ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From nlisker at openjdk.java.net Tue Mar 17 02:52:36 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 17 Mar 2020 02:52:36 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> <6lYtvW-vewjslQOkAIzCCHx_bImXGZZ6qOIhWYzr0yE=.5928e24b-6529-4d72-a6cf-2c589ced8d5d@github.com> Message-ID: On Sat, 14 Mar 2020 15:31:18 GMT, Kevin Rushforth wrote: >> I'll attach the above modified testcase that I ran. I ran it on a relatively new Windows 10 laptop and a rather ancient >> MacBook Pro. I had to drastically reduce the number of quads on the Mac, but the results are similar: no significant >> difference between the current code and the proposed patch for point lights (without attenuation). I'd like to see >> results on a recent machine with a graphics accelerator (either NVIDIA or AMD/ATI) to see if the new shader hurts >> performance there, but I suspect it will be fine. > > Updated test case: [attenTest2.zip](https://github.com/openjdk/jfx/files/4332937/attenTest2.zip) On Win 10 with an AMD RX 470 4GB I get the following: Without the patch: 200 quads average 113 fps 5000 quads average 11.5 fps With the patch: 200 quads average 106 fps fps 5000 quads average 8.5 fps Will test on Ubuntu later. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From aghaisas at openjdk.java.net Tue Mar 17 07:44:06 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 17 Mar 2020 07:44:06 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: <5OGtw62TFw3n02pHTr0jajHzPb0EFXU_D9sAxdtxNzI=.ba0a34fa-3441-42a3-9ea4-b15e05c998b8@github.com> References: <_Mwfh7fCpZB3c7A7ogfngllzVmlDxaa-BjlXXL2XSO0=.83a97715-6db6-4dba-b1a7-efb5f7f87a95@github.com> <5OGtw62TFw3n02pHTr0jajHzPb0EFXU_D9sAxdtxNzI=.ba0a34fa-3441-42a3-9ea4-b15e05c998b8@github.com> Message-ID: On Mon, 16 Mar 2020 13:00:32 GMT, Jeanette Winzenburg wrote: >> Good catch!!! >> It definitely would have unintentional side effect of incorrect orientation in subsequent tests. >> I updated the test to restore the orientation at the end of the test. Also documented the same. > > hmm ... don't think that it will effect subsequent tests, though might be mis-understanding the api doc of > Parameterized: >> When running a parameterized test class, instances are created for the cross-product of the test methods and the test >> data elements. > > So just suggested to change the doc of the method, something like > > Changes the parameter nodeOrientation and sets the table's orientation to the new value > > Alternatively, leave the parameter alone, just toggle the table's orientation and change the forward/backward methods > to choose the keys based on the table's current orientation. Or fully parameterize on the keys - sry, can't resist :) Thanks for clarifying my impression about side effect on subsequent tests. I have the updated the method documentation (also changed the method name to toggleNodeOrientation() to clearly reflect what it does) There would always be different ways to test the same thing. I think, current test is in good shape and suffices the purpose of unit testing this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From aghaisas at openjdk.java.net Tue Mar 17 07:38:45 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 17 Mar 2020 07:38:45 GMT Subject: [Rev 07] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press > tests have been modified to address LTR and RTL orientations. > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create > a test JBS issue and address later) Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: minor test corrections ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/114/files - new: https://git.openjdk.java.net/jfx/pull/114/files/49f9d484..43680c79 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/114/webrev.07 - incr: https://webrevs.openjdk.java.net/jfx/114/webrev.06-07 Stats: 14 lines in 1 file changed: 1 ins; 9 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/114.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/114/head:pull/114 PR: https://git.openjdk.java.net/jfx/pull/114 From arapte at openjdk.java.net Tue Mar 17 11:04:07 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 17 Mar 2020 11:04:07 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Sat, 14 Mar 2020 13:14:51 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Fixed code style and typo following review. The PR looks good to me, Please revert the changes in import. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 47: > 46: import com.sun.javafx.tk.*; > 47: import com.sun.prism.*; > 48: import com.sun.prism.Texture.WrapMode; Please revert these changes in imports. rest looks good to me. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/112 From arapte at openjdk.java.net Tue Mar 17 11:04:08 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 17 Mar 2020 11:04:08 GMT Subject: [Rev 02] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: <3Xvc43pO76yoefpBZq03u-QREGZNAXSzKKCyocleS5k=.bf1947a3-b10a-4ac6-b64a-baa81d4db033@github.com> On Sat, 14 Mar 2020 13:25:00 GMT, Frederic Thevenet wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1600: >> >>> 1599: } >>> 1600: } >>> 1601: } >> >> The `if (exactHeightDivFound.get())` and `else` block here look effectively same. Could you please take a re-look or >> explain what am I missing here. > > Functionally, both side of the condition actually do the exact same thing, but the side effects of which dimension is > processed in the inner loop sometime have measurable consequences in terms of performances; I've added the following > comment to the code to better explain this: > // In order to minimize the number of time we have to resize the underlying > // surface for capturing a tile, choose a dimension that has an exact divider > // (if any) to be processed in the inner most loop. > // E.g. looping on width then height in the example bellow requires four > // surface resizing, whereas the opposite requires only two: > // > // for (w;;) for (h;;) > // for(h;;) for(w;;) > // ----------------- ----------------- > // | | | | | | > // | 1 | 3 | | 1 | 2 | > // h | | | h | | | > // ----------------- ----------------- > // | 2 | 4 | | 3 | 4 | > // ----------------- ----------------- > // w w Than for the additional comment, this will reduce the number of textures created by below call in `renderTile()` `com.sun.prism.RTTexture rt = tileImg.getRT(w, h, rf);` ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From arapte at openjdk.java.net Tue Mar 17 11:10:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 17 Mar 2020 11:10:48 GMT Subject: [Rev 06] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <-iJFt9jWpM5Hz-v0WQ8yFQQVDiHt3qYu7sM_LeekH0M=.f0f51143-901a-4c82-8834-dd9064498b4c@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <-iJFt9jWpM5Hz-v0WQ8yFQQVDiHt3qYu7sM_LeekH0M=.f0f51143-901a-4c82-8834-dd9064498b4c@github.com> Message-ID: On Fri, 13 Mar 2020 05:31:52 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8200224 >> removed create garbage > > Marked as reviewed by arapte (Reviewer). @FlorianKirmaier Please integrate this PR by issuing `/integrate` command in a new comment. After that one of us can sponsor it. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 17 11:43:16 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 17 Mar 2020 11:43:16 GMT Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Revert changes in import statements ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/50ac8c22..7f5f2890 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.03-04 Stats: 112 lines in 1 file changed: 79 ins; 28 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From youngty1997 at gmail.com Tue Mar 17 11:54:52 2020 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 17 Mar 2020 06:54:52 -0500 Subject: sane default option values for Linux Message-ID: <51ae7a41-c3ff-d407-ebff-ae1629b4bbad@gmail.com> Hi all, After many months of being unable to run my JavaFX application due to transitioning to the new Project Panama MemoryAccess API(for native C calling, of course), I've finally gotten things to semi-working order and able to tryout JavaFX 14... only to find out that JavaFX on Linux is still buggy without specifying runtime args. To recap for those who don't develop JavaFX on Linux or use it, if you don't have -Dprism.forceUploadingPainter=true set, JavaFX applications will suffer from buffer zeroing when resizing an application. This affects *ALL* JavaFX applications. There are still GTK3 bugs and regressions that, since it was enabled by default back in JavaFX 11(IIRC) still haven't been fixed. If you try to use GTK3 right now with JavaFX 14 you get a GDK warning: (java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or taller than 32767 pixels are not supported This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. No application code requests a window that tall or wide. As a bonus, something new that was introduced in Java 13(12?) and later is that exiting a JavaFX application will cause a segfault: # A fatal error has been detected by the Java Runtime Environment: # #? SIGSEGV (0xb) at pc=0x00007fbfbad22d9d, pid=68034, tid=68044 # # JRE version: OpenJDK Runtime Environment (15.0) (build 15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew) # Java VM: OpenJDK 64-Bit Server VM (15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C? [libnvidia-glcore.so.440.64+0xa95d9d] ...although I honestly don't think this was a regression introduced in JavaFX... literally every graphical application segfaults now, including games like Minecraft... but regardless it happens when exiting a JavaFX application too. Originally I thought it was a bug caused by the Project Panama builds but it's been persistent for over a year now. I'm guessing something broke in JDK proper. Anyway, point of this email isn't to complain that no one is testing JavaFX on Linux(clearly no one is, by the by), but to ask why sane defaults aren't being used. Anyone developing a JavaFX application on and/or for Linux(god help them) is not going to know how to fix problems caused by GTK3 or by not forcing painter uploading, so, if no one is going to fix these issues(which is fine, I guess), why not use config options that are known to work properly? From fastegal at openjdk.java.net Tue Mar 17 12:35:36 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 17 Mar 2020 12:35:36 GMT Subject: [Rev 04] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: <_Mwfh7fCpZB3c7A7ogfngllzVmlDxaa-BjlXXL2XSO0=.83a97715-6db6-4dba-b1a7-efb5f7f87a95@github.com> References: <_Mwfh7fCpZB3c7A7ogfngllzVmlDxaa-BjlXXL2XSO0=.83a97715-6db6-4dba-b1a7-efb5f7f87a95@github.com> Message-ID: On Thu, 12 Mar 2020 12:42:28 GMT, Jeanette Winzenburg wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> extra space removed > > sry for the spelling errors you inherited :) @aghaisas can't see your last response here (looks like I'm fighting the system here - and loosing again ;) So copying from the mailing list: > I have the updated the method documentation (also changed the method name to toggleNodeOrientation() to clearly reflect > what it does) good move! > There would always be different ways to test the same thing. I think, current test is in good shape and suffices the > purpose of unit testing this fix. > yeah, I agree - with a minor matter: the dynamic change testing is for a single key combination only. Personally, I prefer test completeness to really grab all changes (here all key combinations): future maintainers sometimes have ideas (f.i. inlining the isRTL, and accidentally not doing it on the simple keys) which they should be protected from doing - up to you, though. Assuming that Behaviours will move into public scope, shouldn't public/protected api documented when added (as isRtL())? Not sure about fx team internal conventions. Anyway, all side-thought, so feel free to commit ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From nlisker at openjdk.java.net Tue Mar 17 13:31:06 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 17 Mar 2020 13:31:06 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Tue, 17 Mar 2020 11:01:55 GMT, Ambarish Rapte wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed code style and typo following review. > > The PR looks good to me, Please revert the changes in import. Now that the tiling is done in the `QuantumRenderer` level, I'll bring back [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this tiling be used to fix that? ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From arapte at openjdk.java.net Tue Mar 17 13:45:12 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 17 Mar 2020 13:45:12 GMT Subject: [Integrated] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> Message-ID: <2bb671bf-4175-46fa-82b0-041673ba8da9@openjdk.org> Changeset: b81cf32b Author: Florian Kirmaier Committer: Ambarish Rapte Date: 2020-03-17 13:44:41 +0000 URL: https://git.openjdk.java.net/jfx/commit/b81cf32b 8236259: MemoryLeak in ProgressIndicator Reviewed-by: kcr, arapte ! modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java + tests/system/src/test/java/test/javafx/scene/control/ProgressIndicatorLeakTest.java From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 17 14:21:59 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 17 Mar 2020 14:21:59 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Tue, 17 Mar 2020 13:28:57 GMT, Nir Lisker wrote: > > > Now that the tiling is done in the `QuantumRenderer` level, I'll bring back > [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this tiling be used to fix that? It won't help with thing in their current state, as the `RenderToImage` method that is modified in this PR is currently called only by the snapshot feature in `Scene` But of course I suspect the same technique could also be used to solve [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) and now is indeed a good time to investigate it further. I'll have a look to see if it is possible to factorize the tiling implementation for both classes of issues, in which case it would make sense to do prior to merging this PR. If it is different enough that the implementation cannot be shared but only the general idea, then I suggest we address it in a different PR. What do you all think ? ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From ajoseph at openjdk.java.net Tue Mar 17 15:12:05 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 17 Mar 2020 15:12:05 GMT Subject: RFR: 8239107: Update libjpeg to version 9d In-Reply-To: References: Message-ID: <87q6BHIZepjdfG8GN4IwIEm13PV3elTpZ9zvSy0IriQ=.0764091f-9a83-4ded-8f53-8d5bb881cccf@github.com> On Thu, 12 Mar 2020 10:43:37 GMT, Ambarish Rapte wrote: > Currently we use IJG libjpeg version 9c released on 14-Jan-2018 > We should update the libjpeg to latest version [9d](http://www.ijg.org/) released on 12-Jan-2020 > > reference: https://jpegclub.org/reference/reference-sources/ Marked as reviewed by ajoseph (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/143 From github.com+7450507+fthevenet at openjdk.java.net Tue Mar 17 15:34:26 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 17 Mar 2020 15:34:26 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: <3KFaFGV14nY90FsyOZ0VTySsogloizqfaV5FIU_iX88=.a44be05b-c0c5-43b1-b90d-0dcb793746c3@github.com> On Tue, 17 Mar 2020 14:19:45 GMT, Frederic Thevenet wrote: >> Now that the tiling is done in the `QuantumRenderer` level, I'll bring back >> [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this tiling be used to fix that? > >> >> >> Now that the tiling is done in the `QuantumRenderer` level, I'll bring back >> [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this tiling be used to fix that? > > It won't help with thing in their current state, as the `RenderToImage` method that is modified in this PR is currently > called only by the snapshot feature in `Scene` But of course I suspect the same technique could also be used to solve > [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) and now is indeed a good time to investigate it > further. I'll have a look to see if it is possible to factorize the tiling implementation for both classes of issues, > in which case it would make sense to do prior to merging this PR. If it is different enough that the implementation > cannot be shared but only the general idea, then I suggest we address it in a different PR. What do you all think ? At first glance, the NPE in [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) occurs in the Prism layer, which is one level _below_ Quantum where the tiling is currently implemented, so I'm not sure tit is reachable from there; if we want the code to be shared, it looks like it would need to be moved even further down (maybe in the `ResourceFactory`?) Also, while reusing code is generally the way to go, in such lower layers, very closely intertwined with the actual rendering, I'm afraid that insisting on having a "one-size-fits-all" implementation might get in the way of necessary case-by-case optimizations, so I'd like to have someone with a deeper knowledge of the code base to weight in before starting work in that direction. Maybe @kevinrushforth could advise? ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kevin.rushforth at oracle.com Wed Mar 18 00:03:23 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Mar 2020 17:03:23 -0700 Subject: Bulk request to backport 21 fixes to 11-dev for 11.0.7 Message-ID: Hi Johan, We request approval to backport the following 21 fixes, which Guru and I prepared. Two of the 21 fixes, the GStreamer and Glib upgrades, were done as a single commit, so there will be a single changeset pushed for those two. By coincidence, that commit is the only one that didn't apply cleanly due to a minor merge conflict in one file as a result of an earlier fix (I had earlier fixed this same conflict in mainline). I uploaded the changeset patch with the conflict fixed here if you want to take a look: http://cr.openjdk.java.net/~kcr/8230610/8230610.patch.zip All other patches apply cleanly, ignoring the copyright year in one file for one of the patches. Here is the list of bugs JDK-8222746 -- Cleanup third-party legal files JDK-8232210 -- Update Mesa 3-D Headers to version 19.2.1 JDK-8233421 -- Upgrade to Visual Studio 2017 version 15.9.16 JDK-8233420 -- Upgrade to gcc 8.3 on Linux JDK-8231188 -- Update SQLite to version 3.30.1 JDK-8231126 -- libxslt.md has incorrect version string JDK-8234056 -- Upgrade to libxslt 1.1.34 JDK-8234704 -- Fix attribution in libxslt.md JDK-8230610 -- Upgrade GStreamer to version 1.16.1? / JDK-8230609 -- Upgrade glib to version 2.62.2 JDK-8232589 -- Remove CoreAudio Utility Classes JDK-8233747 -- JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute JDK-8233942 -- Update to 609.1 version of WebKit JDK-8237003 -- Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree JDK-8231513 -- JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) JDK-8238526 -- Cherry pick GTK WebKit 2.26.3 changes JDK-8239454 -- LLIntData : invalid opcode returned for 16 and 32 bit wide instructions JDK-8239109 -- Update SQLite to version 3.31.1 JDK-8240211 -- Stack overflow on Windows 32-bit can lead to crash JDK-8240832 -- Remove unused applecoreaudio.md third-party legal file JDK-8201539 -- Crash in DirectWrite CreateBitmap code when running TestFX test suite Let us know if you have any questions. -- Kevin From arapte at openjdk.java.net Wed Mar 18 05:58:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 18 Mar 2020 05:58:09 GMT Subject: [Integrated] RFR: 8239107: Update libjpeg to version 9d In-Reply-To: References: Message-ID: <08618841-eaa5-459c-9f98-01328f3f40ea@openjdk.org> Changeset: 90289a23 Author: Ambarish Rapte Date: 2020-03-18 05:57:46 +0000 URL: https://git.openjdk.java.net/jfx/commit/90289a23 8239107: Update libjpeg to version 9d Reviewed-by: kcr, ajoseph ! modules/javafx.graphics/src/main/legal/jpeg_fx.md ! modules/javafx.graphics/src/main/native-iio/libjpeg/README ! modules/javafx.graphics/src/main/native-iio/libjpeg/UPDATING.txt ! modules/javafx.graphics/src/main/native-iio/libjpeg/jccolor.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jchuff.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jcinit.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jcmarker.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jcmaster.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jcomapi.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jcparam.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jdcolor.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jdct.h ! modules/javafx.graphics/src/main/native-iio/libjpeg/jdhuff.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jdmarker.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jdmaster.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jdmerge.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jdtrans.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jerror.h ! modules/javafx.graphics/src/main/native-iio/libjpeg/jfdctint.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jidctint.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jmemmgr.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jmemnobs.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jpegint.h ! modules/javafx.graphics/src/main/native-iio/libjpeg/jpeglib.h ! modules/javafx.graphics/src/main/native-iio/libjpeg/jutils.c ! modules/javafx.graphics/src/main/native-iio/libjpeg/jversion.h From youngty1997 at gmail.com Wed Mar 18 07:48:29 2020 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 18 Mar 2020 02:48:29 -0500 Subject: sane default option values for Linux In-Reply-To: <51ae7a41-c3ff-d407-ebff-ae1629b4bbad@gmail.com> References: <51ae7a41-c3ff-d407-ebff-ae1629b4bbad@gmail.com> Message-ID: After going through varies JDK versions from OpenJDK from 8 to present, it seems like the segfault issues was introduced elsewhere at about JDK12/13. Regardless, the other issues are still valid. Can we please have GTK2 set as default along with force painter uploading? On 3/17/20 6:54 AM, Ty Young wrote: > Hi all, > > > After many months of being unable to run my JavaFX application due to > transitioning to the new Project Panama MemoryAccess API(for native C > calling, of course), I've finally gotten things to semi-working order > and able to tryout JavaFX 14... only to find out that JavaFX on Linux > is still buggy without specifying runtime args. > > > To recap for those who don't develop JavaFX on Linux or use it, if you > don't have -Dprism.forceUploadingPainter=true set, JavaFX applications > will suffer from buffer zeroing when resizing an application. This > affects *ALL* JavaFX applications. There are still GTK3 bugs and > regressions that, since it was enabled by default back in JavaFX > 11(IIRC) still haven't been fixed. If you try to use GTK3 right now > with JavaFX 14 you get a GDK warning: > > > (java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or > taller than 32767 pixels are not supported > > > This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. No > application code requests a window that tall or wide. > > > As a bonus, something new that was introduced in Java 13(12?) and > later is that exiting a JavaFX application will cause a segfault: > > > # A fatal error has been detected by the Java Runtime Environment: > # > #? SIGSEGV (0xb) at pc=0x00007fbfbad22d9d, pid=68034, tid=68044 > # > # JRE version: OpenJDK Runtime Environment (15.0) (build > 15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew) > # Java VM: OpenJDK 64-Bit Server VM > (15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed > mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) > # Problematic frame: > # C? [libnvidia-glcore.so.440.64+0xa95d9d] > > > ...although I honestly don't think this was a regression introduced in > JavaFX... literally every graphical application segfaults now, > including games like Minecraft... but regardless it happens when > exiting a JavaFX application too. Originally I thought it was a bug > caused by the Project Panama builds but it's been persistent for over > a year now. I'm guessing something broke in JDK proper. > > > Anyway, point of this email isn't to complain that no one is testing > JavaFX on Linux(clearly no one is, by the by), but to ask why sane > defaults aren't being used. Anyone developing a JavaFX application on > and/or for Linux(god help them) is not going to know how to fix > problems caused by GTK3 or by not forcing painter uploading, so, if no > one is going to fix these issues(which is fine, I guess), why not use > config options that are known to work properly? > From tsayao at openjdk.java.net Wed Mar 18 11:53:08 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 18 Mar 2020 11:53:08 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> Message-ID: On Tue, 3 Mar 2020 11:10:07 GMT, Thiago Milczarek Sayao wrote: >> This is going to need further discussion on the mailing list as indicated above, so it is still premature to review it >> (i.e., it should still be considered effectively a "WIP" until that discussion happens). Additionally, this is a >> significant and risky change, so I'd like additional eyes on it when we do get to the point of reviewing it. > > I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 > and Scenebuilder. > Will have to do some tests on 16.04. Results with Ubuntu **16.04** ![image](https://user-images.githubusercontent.com/30704286/76957765-2ed1d080-68f5-11ea-88c4-9d81528f792e.png) Will look into test.javafx.stage.DeiconifiedWithChildTest and test.robot.javafx.scene.layout.RegionBackgroundFillUITest. I've used a VM, so might be related. Also ran Ensemble8 and the Drag and Drop test app with no apparent issues. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kevin.rushforth at oracle.com Wed Mar 18 12:04:10 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Mar 2020 05:04:10 -0700 Subject: sane default option values for Linux In-Reply-To: References: <51ae7a41-c3ff-d407-ebff-ae1629b4bbad@gmail.com> Message-ID: <19ed0f3b-ceb4-17e3-ba4f-9b82c32591e5@oracle.com> > Regardless, the other issues are still valid. Can we please have GTK2 set as default along with force painter uploading? No, we are not going to do this. GTK 2 is on its way out. GTK 3 has been the default for both AWT and JavaFX since JDK 11 / JavaFX 11. I'd much rather see energy going into fixing any remaining GTK 3 issues than take a step backwards. The other issues you are seeing relating to the need for "forceUploadingPainter" and the crash in libnvidia-glcore are indicative of a possible graphics driver bug. We do plenty of testing on Linux and haven't see reports of the problems you are having. The likely solution would be to blacklist that driver and fall back to the software pipeline. You might consider "-Dprism.order=sw" rather than using forceUploadingPainter (the latter is only intended for testing and not recommended for production). -- Kevin On 3/18/2020 12:48 AM, Ty Young wrote: > After going through varies JDK versions from OpenJDK from 8 to > present, it seems like the segfault issues was introduced elsewhere at > about JDK12/13. > > > Regardless, the other issues are still valid. Can we please have GTK2 > set as default along with force painter uploading? > > > On 3/17/20 6:54 AM, Ty Young wrote: >> Hi all, >> >> >> After many months of being unable to run my JavaFX application due to >> transitioning to the new Project Panama MemoryAccess API(for native C >> calling, of course), I've finally gotten things to semi-working order >> and able to tryout JavaFX 14... only to find out that JavaFX on Linux >> is still buggy without specifying runtime args. >> >> >> To recap for those who don't develop JavaFX on Linux or use it, if >> you don't have -Dprism.forceUploadingPainter=true set, JavaFX >> applications will suffer from buffer zeroing when resizing an >> application. This affects *ALL* JavaFX applications. There are still >> GTK3 bugs and regressions that, since it was enabled by default back >> in JavaFX 11(IIRC) still haven't been fixed. If you try to use GTK3 >> right now with JavaFX 14 you get a GDK warning: >> >> >> (java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or >> taller than 32767 pixels are not supported >> >> >> This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. >> No application code requests a window that tall or wide. >> >> >> As a bonus, something new that was introduced in Java 13(12?) and >> later is that exiting a JavaFX application will cause a segfault: >> >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> #? SIGSEGV (0xb) at pc=0x00007fbfbad22d9d, pid=68034, tid=68044 >> # >> # JRE version: OpenJDK Runtime Environment (15.0) (build >> 15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew) >> # Java VM: OpenJDK 64-Bit Server VM >> (15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed >> mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) >> # Problematic frame: >> # C? [libnvidia-glcore.so.440.64+0xa95d9d] >> >> >> ...although I honestly don't think this was a regression introduced >> in JavaFX... literally every graphical application segfaults now, >> including games like Minecraft... but regardless it happens when >> exiting a JavaFX application too. Originally I thought it was a bug >> caused by the Project Panama builds but it's been persistent for over >> a year now. I'm guessing something broke in JDK proper. >> >> >> Anyway, point of this email isn't to complain that no one is testing >> JavaFX on Linux(clearly no one is, by the by), but to ask why sane >> defaults aren't being used. Anyone developing a JavaFX application on >> and/or for Linux(god help them) is not going to know how to fix >> problems caused by GTK3 or by not forcing painter uploading, so, if >> no one is going to fix these issues(which is fine, I guess), why not >> use config options that are known to work properly? >> From nlisker at gmail.com Wed Mar 18 12:52:08 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 18 Mar 2020 14:52:08 +0200 Subject: Raspberry Pi 4 hw support In-Reply-To: References: Message-ID: I thought that Johan Vos's team did some work on Raspberry, maybe he can comment on this. On Mon, Mar 9, 2020 at 9:50 AM Debayan Sutradhar < debayansutradhar3 at gmail.com> wrote: > I have a large embedded project for raspberry pis (https://stream-pi.com) > and recently its discord server crosses 60 members and growing every month. > Unfortunately it seems that Hardware acceleration doesnt work on VideoCore > VI. > > If es2 pipeline is used, the program exits after the output "* failed to > add service - already in use?" > > Hence for now we are using sw pipeline to use javafx apps. That makes them > very slow and touch gestures don't work as expect. > > Regards, > Debayan Sutradhar > From johan.vos at gluonhq.com Wed Mar 18 12:54:46 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 18 Mar 2020 13:54:46 +0100 Subject: Bulk request to backport 21 fixes to 11-dev for 11.0.7 In-Reply-To: References: Message-ID: Approved. On Wed, Mar 18, 2020 at 1:03 AM Kevin Rushforth wrote: > Hi Johan, > > We request approval to backport the following 21 fixes, which Guru and I > prepared. Two of the 21 fixes, the GStreamer and Glib upgrades, were done > as a single commit, so there will be a single changeset pushed for those > two. By coincidence, that commit is the only one that didn't apply cleanly > due to a minor merge conflict in one file as a result of an earlier fix (I > had earlier fixed this same conflict in mainline). I uploaded the changeset > patch with the conflict fixed here if you want to take a look: > > http://cr.openjdk.java.net/~kcr/8230610/8230610.patch.zip > > All other patches apply cleanly, ignoring the copyright year in one file > for one of the patches. > > Here is the list of bugs > > JDK-8222746 -- Cleanup > third-party legal files > JDK-8232210 -- Update > Mesa 3-D Headers to version 19.2.1 > JDK-8233421 -- Upgrade > to Visual Studio 2017 version 15.9.16 > JDK-8233420 -- Upgrade > to gcc 8.3 on Linux > JDK-8231188 -- Update > SQLite to version 3.30.1 > JDK-8231126 -- > libxslt.md has incorrect version string > JDK-8234056 -- Upgrade > to libxslt 1.1.34 > JDK-8234704 -- Fix > attribution in libxslt.md > JDK-8230610 -- Upgrade > GStreamer to version 1.16.1 / JDK-8230609 > -- Upgrade glib to > version 2.62.2 > JDK-8232589 -- Remove > CoreAudio Utility Classes > JDK-8233747 -- JVM > crash in com.sun.webkit.dom.DocumentImpl.createAttribute > JDK-8233942 -- Update > to 609.1 version of WebKit > JDK-8237003 -- Remove > hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree > JDK-8231513 -- JavaFX > cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) > JDK-8238526 -- Cherry > pick GTK WebKit 2.26.3 changes > JDK-8239454 -- > LLIntData : invalid opcode returned for 16 and 32 bit wide instructions > JDK-8239109 -- Update > SQLite to version 3.31.1 > JDK-8240211 -- Stack > overflow on Windows 32-bit can lead to crash > JDK-8240832 -- Remove > unused applecoreaudio.md third-party legal file > JDK-8201539 -- Crash > in DirectWrite CreateBitmap code when running TestFX test suite > > Let us know if you have any questions. > > -- Kevin > > From johan.vos at gluonhq.com Wed Mar 18 12:56:40 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 18 Mar 2020 13:56:40 +0100 Subject: Raspberry Pi 4 hw support In-Reply-To: References: Message-ID: Hi, The later Raspian distributions are using new drivers that require different configurations to be used with HW acceleration. The JavaFX ARM builds are dependent on a specific set of libraries. We'll have to document this better. - Johan On Mon, Mar 9, 2020 at 8:50 AM Debayan Sutradhar < debayansutradhar3 at gmail.com> wrote: > I have a large embedded project for raspberry pis (https://stream-pi.com) > and recently its discord server crosses 60 members and growing every month. > Unfortunately it seems that Hardware acceleration doesnt work on VideoCore > VI. > > If es2 pipeline is used, the program exits after the output "* failed to > add service - already in use?" > > Hence for now we are using sw pipeline to use javafx apps. That makes them > very slow and touch gestures don't work as expect. > > Regards, > Debayan Sutradhar > From nlisker at openjdk.java.net Wed Mar 18 13:47:19 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 18 Mar 2020 13:47:19 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> <6lYtvW-vewjslQOkAIzCCHx_bImXGZZ6qOIhWYzr0yE=.5928e24b-6529-4d72-a6cf-2c589ced8d5d@github.com> Message-ID: On Tue, 17 Mar 2020 02:50:28 GMT, Nir Lisker wrote: >> Updated test case: [attenTest2.zip](https://github.com/openjdk/jfx/files/4332937/attenTest2.zip) > > On Win 10 with an AMD RX 470 4GB I get the following: > > Without the patch: > 200 quads average 113 fps > 5000 quads average 11.5 fps > > With the patch: > 200 quads average 106 fps fps > 5000 quads average 8.5 fps > > Will test on Ubuntu later. On Ubuntu 18 with an AMD RX 470 4GB I get the following: Without the patch: 200 quads average 107 fps 5000 quads average 11.5 fps With the patch: 200 quads average 107 fps fps 5000 quads average 11 fps ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From debayansutradhar3 at gmail.com Wed Mar 18 14:42:26 2020 From: debayansutradhar3 at gmail.com (Debayan Sutradhar) Date: Wed, 18 Mar 2020 20:12:26 +0530 Subject: Raspberry Pi 4 hw support In-Reply-To: References: Message-ID: Ok, thanks for the clarification. Will be waiting. You all are doing a really great job. This looks really promising. JavaFX is getting the love it actually deserved. On Wed, 18 Mar 2020 at 6:26 PM, Johan Vos wrote: > Hi, > > The later Raspian distributions are using new drivers that require > different configurations to be used with HW acceleration. > The JavaFX ARM builds are dependent on a specific set of libraries. We'll > have to document this better. > > - Johan > > On Mon, Mar 9, 2020 at 8:50 AM Debayan Sutradhar < > debayansutradhar3 at gmail.com> wrote: > >> I have a large embedded project for raspberry pis (https://stream-pi.com) >> and recently its discord server crosses 60 members and growing every >> month. >> Unfortunately it seems that Hardware acceleration doesnt work on VideoCore >> VI. >> >> If es2 pipeline is used, the program exits after the output "* failed to >> add service - already in use?" >> >> Hence for now we are using sw pipeline to use javafx apps. That makes them >> very slow and touch gestures don't work as expect. >> >> Regards, >> Debayan Sutradhar >> > From aghaisas at openjdk.java.net Wed Mar 18 15:21:36 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 18 Mar 2020 15:21:36 GMT Subject: RFR: 8089134: [2D traversal, RTL] TraversalEngine only handles left/right key traversal correctly in RTL for top-level engine in ToolBar Message-ID: <47gsjAi3Ess6DKPd-C43iboVLy0D0t_BDDWKBRFv9v8=.8830d1fb-2b85-40b7-8330-72d853732f0f@github.com> **Issue** https://bugs.openjdk.java.net/browse/JDK-8089134 **Fix** Added a fix to modify selection direction based on NodeOrientation of the ToolBar. **Testing** Added a unit test to test common focus movement scenarios using tab and arrow keys for the ToolBar. ------------- Commit messages: - whitespace_removal - toolbar_rtl_focus_fix Changes: https://git.openjdk.java.net/jfx/pull/144/files Webrev: https://webrevs.openjdk.java.net/jfx/144/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8089134 Stats: 348 lines in 2 files changed: 348 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/144.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/144/head:pull/144 PR: https://git.openjdk.java.net/jfx/pull/144 From philip.race at oracle.com Wed Mar 18 19:36:33 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 18 Mar 2020 12:36:33 -0700 Subject: sane default option values for Linux In-Reply-To: <19ed0f3b-ceb4-17e3-ba4f-9b82c32591e5@oracle.com> References: <51ae7a41-c3ff-d407-ebff-ae1629b4bbad@gmail.com> <19ed0f3b-ceb4-17e3-ba4f-9b82c32591e5@oracle.com> Message-ID: <5E727841.50606@oracle.com> Some of the latest Linuxes don't even include GTK2 by default ! Its only a step away from them not being even available as an optional download. > ...although I honestly don't think this was a regression introduced in JavaFX... > literally every graphical application segfaults now, including games like Minecraft.. Since Minecraft does not use Swing, Java2D, AWT or JavaFx *at all* - not even loading them - it definitely there can't be anything in the Java client stack that is causing it. So if switching to GTK2 miraculously cures it, then that seems like a coincidence and not anything we are doing. It could be a change elsewhere in the JDK, if it reproduces today with 12+ but not 11, but bringing it up on this list, or requesting this workaround, both seem to be pointing in the wrong direction. And Kevin's suggestion of a driver bug seems possible + worth looking into. -phl On 3/18/20, 5:04 AM, Kevin Rushforth wrote: > > > Regardless, the other issues are still valid. Can we please have > GTK2 set as default along with force painter uploading? > > No, we are not going to do this. GTK 2 is on its way out. GTK 3 has > been the default for both AWT and JavaFX since JDK 11 / JavaFX 11. I'd > much rather see energy going into fixing any remaining GTK 3 issues > than take a step backwards. > > The other issues you are seeing relating to the need for > "forceUploadingPainter" and the crash in libnvidia-glcore are > indicative of a possible graphics driver bug. We do plenty of testing > on Linux and haven't see reports of the problems you are having. The > likely solution would be to blacklist that driver and fall back to the > software pipeline. You might consider "-Dprism.order=sw" rather than > using forceUploadingPainter (the latter is only intended for testing > and not recommended for production). > > -- Kevin > > > On 3/18/2020 12:48 AM, Ty Young wrote: >> After going through varies JDK versions from OpenJDK from 8 to >> present, it seems like the segfault issues was introduced elsewhere >> at about JDK12/13. >> >> >> Regardless, the other issues are still valid. Can we please have GTK2 >> set as default along with force painter uploading? >> >> >> On 3/17/20 6:54 AM, Ty Young wrote: >>> Hi all, >>> >>> >>> After many months of being unable to run my JavaFX application due >>> to transitioning to the new Project Panama MemoryAccess API(for >>> native C calling, of course), I've finally gotten things to >>> semi-working order and able to tryout JavaFX 14... only to find out >>> that JavaFX on Linux is still buggy without specifying runtime args. >>> >>> >>> To recap for those who don't develop JavaFX on Linux or use it, if >>> you don't have -Dprism.forceUploadingPainter=true set, JavaFX >>> applications will suffer from buffer zeroing when resizing an >>> application. This affects *ALL* JavaFX applications. There are still >>> GTK3 bugs and regressions that, since it was enabled by default back >>> in JavaFX 11(IIRC) still haven't been fixed. If you try to use GTK3 >>> right now with JavaFX 14 you get a GDK warning: >>> >>> >>> (java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or >>> taller than 32767 pixels are not supported >>> >>> >>> This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. >>> No application code requests a window that tall or wide. >>> >>> >>> As a bonus, something new that was introduced in Java 13(12?) and >>> later is that exiting a JavaFX application will cause a segfault: >>> >>> >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # SIGSEGV (0xb) at pc=0x00007fbfbad22d9d, pid=68034, tid=68044 >>> # >>> # JRE version: OpenJDK Runtime Environment (15.0) (build >>> 15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew) >>> # Java VM: OpenJDK 64-Bit Server VM >>> (15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed >>> mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) >>> # Problematic frame: >>> # C [libnvidia-glcore.so.440.64+0xa95d9d] >>> >>> >>> ...although I honestly don't think this was a regression introduced >>> in JavaFX... literally every graphical application segfaults now, >>> including games like Minecraft... but regardless it happens when >>> exiting a JavaFX application too. Originally I thought it was a bug >>> caused by the Project Panama builds but it's been persistent for >>> over a year now. I'm guessing something broke in JDK proper. >>> >>> >>> Anyway, point of this email isn't to complain that no one is testing >>> JavaFX on Linux(clearly no one is, by the by), but to ask why sane >>> defaults aren't being used. Anyone developing a JavaFX application >>> on and/or for Linux(god help them) is not going to know how to fix >>> problems caused by GTK3 or by not forcing painter uploading, so, if >>> no one is going to fix these issues(which is fine, I guess), why not >>> use config options that are known to work properly? >>> > From tsayao at openjdk.java.net Thu Mar 19 14:37:05 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 19 Mar 2020 14:37:05 GMT Subject: [Rev 30] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: fix compilation on ubuntu 16.04 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/31080932..086143ac Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.30 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.29-30 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From aghaisas at openjdk.java.net Fri Mar 20 11:31:14 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 20 Mar 2020 11:31:14 GMT Subject: [Rev 02] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: On Thu, 27 Feb 2020 15:56:25 GMT, Rony G. Flatscher wrote: >> ?9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > corrected wrong test string tests/system/src/testscriptapp1/java/mymod/myapp1/Util.java line 2: > 1: /* > 2: * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Please remove "2017, " tests/system/src/testscriptapp1/java/mymod/myapp1/Constants.java line 2: > 1: /* > 2: * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Please remove "2017, " ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From aghaisas at openjdk.java.net Fri Mar 20 12:12:53 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 20 Mar 2020 12:12:53 GMT Subject: RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> <9bB6LCXUWSjh_soInsnyv63Igy2ZeJKVkzIyR_vKhzU=.1ee8dda6-4776-42d1-9d47-4106b28b680a@github.com> <4Msst48GfgK5UZvfe7CCgBB0uCJtNr60y56EHZsFmNw=.73e8df74-4bb4-4255-a7e9-9a250349f507@github.com> Message-ID: On Fri, 13 Mar 2020 15:15:39 GMT, Kevin Rushforth wrote: >> Is there anything I can do to keep the ball rolling ? > > I just need time to do final testing of this, along with the review of the updated test. > > @aghaisas will also review. The changes look good to me. I verified that the test fails without fix and passes with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From kcr at openjdk.java.net Fri Mar 20 12:17:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 20 Mar 2020 12:17:13 GMT Subject: [Rev 02] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: On Fri, 20 Mar 2020 11:28:46 GMT, Ajit Ghaisas wrote: >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> corrected wrong test string > > tests/system/src/testscriptapp1/java/mymod/myapp1/Util.java line 2: > >> 1: /* >> 2: * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > Please remove "2017, " Since this file was copied verbatim from one of the other test apps, the initial `2017,` is correct. > tests/system/src/testscriptapp1/java/mymod/myapp1/Constants.java line 2: > >> 1: /* >> 2: * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > Please remove "2017, " Same as above. The `2017,` is correct. ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From debayansutradhar3 at gmail.com Fri Mar 20 19:23:57 2020 From: debayansutradhar3 at gmail.com (Debayan Sutradhar) Date: Sat, 21 Mar 2020 00:53:57 +0530 Subject: JavaFX Swipe Events Glitch On Mobile Message-ID: Swipe Events like swipeup and swipedown don't get registered and their related set methods don't get called. OnTouch works rarely. JavaFX Version : 14 Gluon Client Plugin : 0.0.18 Regards, Debayan From kcr at openjdk.java.net Sat Mar 21 17:22:44 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 21 Mar 2020 17:22:44 GMT Subject: RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Mon, 16 Mar 2020 12:47:44 GMT, Jeanette Winzenburg wrote: >>> So this begs the question: Do we still want to do this? Is the cleanup worth the extra memory used? >> >> I'm not sure. This raises the opposite question: are there any places where we can benefit from introducing anonymous >> classes instead of the current implementation? >> In my own code, I prefer the readability and conciseness over performance. However, since JavaFX is a library, we might >> want to go with the performance route. I don't know how important the memory consumption is for users in this case or >> the other similar cases. > > Just playing devil's advocate :) > > Technically, there's a functional difference between the inline extension and useage of SimpleXX: in the former, > getName returns the current name of mapped property, in the latter it returns its name at the time of creating the > mapped property. Afaics, there is nothing in the spec of getName that prevents custom implementations with name (and > bean) being mutable (the SimpleXX have implemented them immutable, but then they are only default implementations). Not > that I can imagine any use-case for it, but if they exist, the new mappings might break existing code. Getting back to this, I think we shouldn't make the change from inner classes to SimpleXxxxProperty objects proposed by this PR. As for whether we should consider changing some internal instance of SimpleXxxxProperty (which I think wouldn't run afoul of the hypothetical problem raised by @kleopatra ), we could file a new Enhancement request if you like, but it's probably not all that critical, unless we were to find a few in the base Node or Control classes that could yield big savings. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From kcr at openjdk.java.net Sat Mar 21 19:21:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 21 Mar 2020 19:21:36 GMT Subject: [Rev 02] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: On Thu, 27 Feb 2020 15:56:25 GMT, Rony G. Flatscher wrote: >> ?9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > corrected wrong test string The fix looks good. I left a few comments on the test. One of them is substantive, the rest are formatting. Once you make those changes, I'll approve it. tests/system/src/testscriptapp1/java/mymod/myapp1/FXMLScriptDeployment.java line 104: > 103: ioe.printStackTrace(); > 104: System.exit(-1); > 105: } This should be `System.exit(ERROR_UNEXPECTED_EXCEPTION);` tests/system/src/testscriptapp1/java/mymod/myapp1/FXMLScriptDeployment.java line 185: > 184: > 185: // global Bindings > 186: Util.assertExists(IDROOT + " in global scope Bindings", globalBindings.containsKey(IDROOT)); Minor: indentation is wrong (indented too far) tests/system/src/testscriptapp1/java/mymod/myapp1/FXMLScriptDeployment.java line 208: > 207: > 208: // engine Bindings > 209: Util.assertExists(FILENAME + " in engine scope Bindings", engineBindings.containsKey(FILENAME)); Minor: indentation tests/system/src/testscriptapp1/java/mymod/pseudoScriptEngine/InvocationInfos.java line 55: > 54: * @return string formatted to ease debugging > 55: */ > 56: public String toDebugFormat(String indentation) { Minor: the `/**` should be on a line by itself. Also, the closing `*/` needs one more space of indentation. tests/system/src/testscriptapp1/java/mymod/myapp1/FXMLScriptDeployment.java line 109: > 108: btn.fireEvent(new ActionEvent()); > 109: btn.fireEvent(new MouseEvent( MouseEvent.MOUSE_CLICKED, > 110: 0, // double x, Minor: remove the extra space after the last `(` tests/system/src/testscriptapp1/java/mymod/myapp1/FXMLScriptDeployment.java line 229: > 228: } > 229: else { > 230: Util.assertType(EVENT, ActionEvent.class, obj); Minor: the `}` should be on the same line as the `else {` tests/system/src/testscriptapp1/java/mymod/pseudoScriptEngine/RgfPseudoScriptEngine.java line 47: > 46: public class RgfPseudoScriptEngine extends AbstractScriptEngine > 47: { > 48: static final boolean bDebug = false; // true; The `{` should be on the previous line. tests/system/src/testscriptapp1/java/mymod/pseudoScriptEngine/RgfPseudoScriptEngine.java line 89: > 88: // create copies of the Bindings for later inspection as they may > 89: // get reused and changed on each eval() invocation > 90: TreeMap bindings = new TreeMap(); Minor: indentation ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From nlisker at gmail.com Mon Mar 23 03:08:52 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 23 Mar 2020 05:08:52 +0200 Subject: Behavior of jumpTo Message-ID: Hi, As I'm continuing my work on the animations front, I came across an ambiguous behavior of JumpTo. The specifications don't say anything about it, but in FiniteClipEnvelop, if the rate is negative, it jumps to the specified time *counted from the end*. This seems intentional because it's checked explicitly: pos = ticks % cycleTicks; if (rate < 0) { pos = cycleTicks - pos; } if ((pos == 0) && (ticks > 0)) { pos = cycleTicks; } SingleLoopClipEnvelope does not behave this way. I submitted [1] to track this. This also causes an issue with jumping when rate=0, however, there are other issues with rate=0, for example [2], and it's hard to separate them. What should be the proper behavior of jumpTo with respect to the rate? I think that they shouldn't be coupled: jumping should always be calculated from the start. The application can always calculate (totalTime - requiredTime) and send that to jumpTo. - Nir [1] https://bugs.openjdk.java.net/browse/JDK-8237973 [2] https://bugs.openjdk.java.net/browse/JDK-8237757 From nlisker at openjdk.java.net Mon Mar 23 05:32:29 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 23 Mar 2020 05:32:29 GMT Subject: [Rev 01] RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: <44nlvUAwalvjI2zxOA0ZjqVeT2fCxqhyopQfpkbJKRU=.a85f37fa-7ff9-4cac-b6c5-2f5b3b79dd24@github.com> > A simple readability cleanup for the files that were changed in #113. > > Note that the boolean property has an `instanceof` check that doesn't exist in the other properties. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Revert changes of anonymous classes usage ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/141/files - new: https://git.openjdk.java.net/jfx/pull/141/files/15f50f17..6876a037 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/141/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/141/webrev.00-01 Stats: 111 lines in 5 files changed: 100 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/141.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/141/head:pull/141 PR: https://git.openjdk.java.net/jfx/pull/141 From aghaisas at openjdk.java.net Mon Mar 23 06:43:42 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 23 Mar 2020 06:43:42 GMT Subject: RFR: 8089828: RTL Orientation, the flag of a mnemonic is not placed under the mnemonic letter. Message-ID: **Bug :** https://bugs.openjdk.java.net/browse/JDK-8089828 **Root Cause :** RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position calculation. **Fix :** Corrected code to consider RIGHT_TO_LEFT NodeOrientation while calculating mnemonic position. **Testing :** Existing manual test is modified to test RTL buttons as well. ------------- Commit messages: - rtl_mnemonic_fix Changes: https://git.openjdk.java.net/jfx/pull/146/files Webrev: https://webrevs.openjdk.java.net/jfx/146/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8089828 Stats: 46 lines in 3 files changed: 37 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/146.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/146/head:pull/146 PR: https://git.openjdk.java.net/jfx/pull/146 From arapte at openjdk.java.net Mon Mar 23 07:31:23 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 23 Mar 2020 07:31:23 GMT Subject: RFR: 8236840: Memory leak when switching ButtonSkin Message-ID: ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves the issue. Please take a look. ------------- Commit messages: - 8236840: Memory leak when switching ButtonSkin Changes: https://git.openjdk.java.net/jfx/pull/147/files Webrev: https://webrevs.openjdk.java.net/jfx/147/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236840 Stats: 84 lines in 2 files changed: 64 ins; 17 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/147.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/147/head:pull/147 PR: https://git.openjdk.java.net/jfx/pull/147 From ebresie at gmail.com Mon Mar 23 12:49:10 2020 From: ebresie at gmail.com (Eric Bresie) Date: Mon, 23 Mar 2020 07:49:10 -0500 Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: 4g5XsVJFFAXGyq2L9r0PtOz_vSt7g5fFusntxEKlMf8=.be0ee2a8-8bca-48f1-a0ab-21e7d9e027c3@github.com References: GeapT28im5lgaSQ2UpcGkoh3NmEFv05Dzy8l5wdmixE=.ccb64642-6c4f-4645-9c2f-7a24dc5d37a8@github.com oqYJrj4tQdzkwKsLH9x87RimHQU-k6F7yIPMabXlIF4=.fc5811cc-049e-4a33-8162-0b8d2b63034c@github.com O6VWIPeAvnV7CEVyiALYp2q1VQz7psaz4pXu4gPTSlk=.a11bab43-ec53-498e-b5da-3e4cb0660401@github.com PWMvUUplhOa6oXP61Sp-rQ0eFRUQ4rVAc2x0IcOZNvs=.6f415540-16d7-438f-a439-8c264fc48292@github.com PWMvUUplhOa6oXP61Sp-rQ0eFRUQ4rVAc2x0IcOZNvs=.6f415540-16d7-438f-a439-8c264fc48292@github.com Message-ID: <5942d081-41c4-45af-807f-04a5e0378fb3@Erics-iPhone-X> This may be a little off topic but given this is a Javascript concern, is this (or will this) be impacted by Nashhorns depreciation (as of jdk11 I believe) and potential removal at some point? I see reference to Netscape JObject do maybe that circumvents some of that but does this need to eventually transition to graalvm or other means? Eric Bresie Ebresie at gmail.com > On March 10, 2020 at 6:22:01 AM CDT, Ajit Ghaisas wrote: > On Fri, 6 Mar 2020 19:53:04 GMT, Kevin Rushforth wrote: > > > > Please ignore this comment as well, it is also for debugging issues with Skara and mailman :email: ?? > > > > @aghaisas can you review this? > > I executed these tests without this patch. They did not hang on my Macbook. > > I applied patch and executed the tests. They continue to pass. > I see the merit of this change to make tests predictable. +1. > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/134 From ebresie at gmail.com Mon Mar 23 12:52:23 2020 From: ebresie at gmail.com (Eric Bresie) Date: Mon, 23 Mar 2020 07:52:23 -0500 Subject: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors In-Reply-To: 2QEHNYmpJCI0cwl1klk5ANi0xVqXOtxbELg1EtA-XGs=.9289afb2-8aa8-4b16-ae50-b46373254fa4@github.com References: CARp7WBIBct2R_CC2oQS8SWlaI6rAWAYmwUYpTEwZiw=.7d2dc198-4452-49aa-afd8-1920429984a7@github.com OYN29CDbYM9wu6phNxoV8OGCW4bCqGoRPaefGpqCNGU=.7b8360d1-ddf9-4e21-a0d7-ce7f1eedb44a@github.com NyWaXe3H641O3QM0bVxlSMMk6CjA02SsJk8YNZ5BbKM=.8a2d89b1-55d8-47e6-bf7c-35eb5807015b@github.com NyWaXe3H641O3QM0bVxlSMMk6CjA02SsJk8YNZ5BbKM=.8a2d89b1-55d8-47e6-bf7c-35eb5807015b@github.com Message-ID: Is there any external skara documentation available on all these flags etc? Eric Bresie Ebresie at gmail.com > On March 7, 2020 at 8:25:02 AM CST, Kevin Rushforth wrote: > On Fri, 6 Mar 2020 20:46:39 GMT, Kevin Rushforth wrote: > > > > Marked as reviewed by kcr (Lead). > > > > @arapte can you also review this? > > Now the the CSR is approved, we need something to "wake up" the Skara bot to notice that. > @edvbld @rwestberg is there a command that you would recommend to do this? Maybe typing `/summary` without actually adding a summary? Failing that we can wait for the second reviewer, but it would be nice to test Skara's CSR support prior to that (this is the first one where we've had an approved CSR since starting to use the `/csr` feature). > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/140 From kevin.rushforth at oracle.com Mon Mar 23 12:57:16 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Mar 2020 05:57:16 -0700 Subject: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang In-Reply-To: <5942d081-41c4-45af-807f-04a5e0378fb3@Erics-iPhone-X> References: <5942d081-41c4-45af-807f-04a5e0378fb3@Erics-iPhone-X> Message-ID: <582ba38f-f076-b91c-52a7-a2872c697448@oracle.com> WebKit has never used Nashorn so this is unrelated to the impending Nashorn removal. -- Kevin On 3/23/2020 5:49 AM, Eric Bresie wrote: > This may be a little off topic but given this is a Javascript concern, is this (or will this) be impacted by Nashhorns depreciation (as of jdk11 I believe) and potential removal at some point? > > I see reference to Netscape JObject do maybe that circumvents some of that but does this need to eventually transition to graalvm or other means? > > Eric Bresie > Ebresie at gmail.com >> On March 10, 2020 at 6:22:01 AM CDT, Ajit Ghaisas wrote: >> On Fri, 6 Mar 2020 19:53:04 GMT, Kevin Rushforth wrote: >> >>>> Please ignore this comment as well, it is also for debugging issues with Skara and mailman :email: ?? >>> @aghaisas can you review this? >> I executed these tests without this patch. They did not hang on my Macbook. >> >> I applied patch and executed the tests. They continue to pass. >> I see the merit of this change to make tests predictable. +1. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jfx/pull/134 From kevin.rushforth at oracle.com Mon Mar 23 13:13:08 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Mar 2020 06:13:08 -0700 Subject: Behavior of jumpTo In-Reply-To: References: Message-ID: I agree. If jumpTo took a relative (delta) Duration then it would make sense for it to take the direction of rate into account. Given that it is an absolute position, the current behavior just seems wrong. The spec says: ??? Jumps to a given position in this |Animation| I would interpret that as being an absolute position, but clarifying that with a spec change sounds like a good idea. The only possible concern is compatibility. It's possible that some applications have worked around this bug, but that doesn't seem compelling enough to keep the buggy behavior. -- Kevin On 3/22/2020 8:08 PM, Nir Lisker wrote: > Hi, > > As I'm continuing my work on the animations front, I came across an > ambiguous behavior of JumpTo. The specifications don't say anything about > it, but in FiniteClipEnvelop, if the rate is negative, it jumps to the > specified time *counted from the end*. This seems intentional because it's > checked explicitly: > > pos = ticks % cycleTicks; > if (rate < 0) { > pos = cycleTicks - pos; > } > if ((pos == 0) && (ticks > 0)) { > pos = cycleTicks; > } > > SingleLoopClipEnvelope does not behave this way. I submitted [1] to track > this. This also causes an issue with jumping when rate=0, however, there > are other issues with rate=0, for example [2], and it's hard to separate > them. > > What should be the proper behavior of jumpTo with respect to the rate? I > think that they shouldn't be coupled: jumping should always be calculated > from the start. The application can always calculate (totalTime - > requiredTime) and send that to jumpTo. > > - Nir > > [1] https://bugs.openjdk.java.net/browse/JDK-8237973 > [2] https://bugs.openjdk.java.net/browse/JDK-8237757 From fastegal at openjdk.java.net Mon Mar 23 16:36:49 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 23 Mar 2020 16:36:49 GMT Subject: RFR: 8241455: ChoiceBox - memory leak on replacing selectionModel Message-ID: ChoiceBox leaves a memory leak when replacing the selectionModel. Culprit is ChoiceBoxSelectionModel which registers listener with strong references. Fix is to change these to weak references. Added test that fails before and passes after the test. for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 ------------- Commit messages: - 8241455: ChoiceBox - memory leak on replacing selectionModel Changes: https://git.openjdk.java.net/jfx/pull/148/files Webrev: https://webrevs.openjdk.java.net/jfx/148/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241455 Stats: 50 lines in 2 files changed: 42 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/148.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/148/head:pull/148 PR: https://git.openjdk.java.net/jfx/pull/148 From kcr at openjdk.java.net Mon Mar 23 21:45:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 21:45:09 GMT Subject: [Rev 02] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: <_7uTovlrYnTZ-Gcj1brPO_UavNxYdthVioP3vrmTGew=.d84cc476-92d9-4cac-920f-e87411fdacd0@github.com> On Sat, 21 Mar 2020 19:19:18 GMT, Kevin Rushforth wrote: >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> corrected wrong test string > > The fix looks good. I left a few comments on the test. One of them is substantive, the rest are formatting. Once you > make those changes, I'll approve it. One more minor observation. I noticed the following have DOS line endings: tests/system/src/testscriptapp1/resources/mymod/META-INF/services/javax.script.ScriptEngineFactory: ASCII text, with CRLF line terminators tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_bottomscript.rpsl: ASCII text, with CRLF line terminators tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_middlescript.rpsl: ASCII text, with CRLF line terminators tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_topscript.rpsl: ASCII text, with CRLF line terminators Since they aren't source code files, `git jcheck` won't complain, but as long as you are fixing the other issues, would you mind fixing these too? ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From kcr at openjdk.java.net Mon Mar 23 21:55:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 21:55:17 GMT Subject: [Rev 01] RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: <44nlvUAwalvjI2zxOA0ZjqVeT2fCxqhyopQfpkbJKRU=.a85f37fa-7ff9-4cac-b6c5-2f5b3b79dd24@github.com> References: <44nlvUAwalvjI2zxOA0ZjqVeT2fCxqhyopQfpkbJKRU=.a85f37fa-7ff9-4cac-b6c5-2f5b3b79dd24@github.com> Message-ID: On Mon, 23 Mar 2020 05:32:29 GMT, Nir Lisker wrote: >> A simple readability cleanup for the files that were changed in #113. >> >> Note that the boolean property has an `instanceof` check that doesn't exist in the other properties. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes of anonymous classes usage Looks good with one minor formatting comment (which applies to all files). modules/javafx.base/src/main/java/javafx/beans/property/BooleanProperty.java line 183: > 182: } > 183: } Minor: can you add the trailing newline back in? We typically end each file with a single new-line; also this shows up as an unnecessary diff. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From kcr at openjdk.java.net Mon Mar 23 22:11:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 22:11:58 GMT Subject: [Rev 07] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Tue, 17 Mar 2020 07:38:45 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 >> >> Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. >> >> Testing : Added a test to take NodeOrientation as a parameter and test horizontal key navigation for the TableView. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > minor test corrections Looks good to me. This needs one more reviewer. @kleopatra would you be willing? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/114 From kcr at openjdk.java.net Mon Mar 23 22:25:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 22:25:07 GMT Subject: RFR: 8089134: [2D traversal, RTL] TraversalEngine only handles left/right key traversal correctly in RTL for top-level engine in ToolBar In-Reply-To: <47gsjAi3Ess6DKPd-C43iboVLy0D0t_BDDWKBRFv9v8=.8830d1fb-2b85-40b7-8330-72d853732f0f@github.com> References: <47gsjAi3Ess6DKPd-C43iboVLy0D0t_BDDWKBRFv9v8=.8830d1fb-2b85-40b7-8330-72d853732f0f@github.com> Message-ID: On Wed, 18 Mar 2020 15:13:40 GMT, Ajit Ghaisas wrote: > **Issue** > https://bugs.openjdk.java.net/browse/JDK-8089134 > > **Fix** > Added a fix to modify selection direction based on NodeOrientation of the ToolBar. > > **Testing** > Added a unit test to test common focus movement scenarios using tab and arrow keys for the ToolBar. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/144 From kcr at openjdk.java.net Mon Mar 23 22:45:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 22:45:06 GMT Subject: RFR: 8089828: RTL Orientation, the flag of a mnemonic is not placed under the mnemonic letter. In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 06:36:26 GMT, Ajit Ghaisas wrote: > **Bug :** > https://bugs.openjdk.java.net/browse/JDK-8089828 > > **Root Cause :** > RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position calculation. > > **Fix :** > Corrected code to consider RIGHT_TO_LEFT NodeOrientation while calculating mnemonic position. > > **Testing :** > Existing manual test is modified to test RTL buttons as well. The fix looks good to me, although I'd like a second reviewer. I did note one issue with the format of the copyright year. tests/manual/UI/ButtonMnemonicPositionTest.java line 2: > 1: /* > 2: * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. There is a missing `,` after `2020` ------------- PR: https://git.openjdk.java.net/jfx/pull/146 From fastegal at openjdk.java.net Mon Mar 23 23:29:58 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 23 Mar 2020 23:29:58 GMT Subject: [Rev 07] RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Tue, 17 Mar 2020 07:38:45 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 >> >> Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. >> >> Testing : Added a test to take NodeOrientation as a parameter and test horizontal key navigation for the TableView. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > minor test corrections yeah sure .. thought I did already approve, looks like I didn't find the correct way - trying again ------------- Marked as reviewed by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/114 From kcr at openjdk.java.net Mon Mar 23 23:49:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 23:49:38 GMT Subject: RFR: 8241455: ChoiceBox - memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 23:45:21 GMT, Kevin Rushforth wrote: >> ChoiceBox leaves a memory leak when replacing the selectionModel. Culprit is ChoiceBoxSelectionModel which registers >> listener with strong references. Fix is to change these to weak references. >> Added test that fails before and passes after the test. >> >> for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 > > I have basically the same comment / question as I asked in #147 > > In general, there are two approaches to avoiding listener-related memory leaks. One is to use a WeakListener; the other > is to explicitly remove the listener when the object is removed or otherwise no longer needed. > Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up > after itself. I'm not suggesting that's the case here, but it is worth looking at. @arapte @aghaisas - Can you both review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From kcr at openjdk.java.net Mon Mar 23 23:49:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 23:49:37 GMT Subject: RFR: 8241455: ChoiceBox - memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 16:32:16 GMT, Jeanette Winzenburg wrote: > ChoiceBox leaves a memory leak when replacing the selectionModel. Culprit is ChoiceBoxSelectionModel which registers > listener with strong references. Fix is to change these to weak references. > Added test that fails before and passes after the test. > > for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 I have basically the same comment / question as I asked in #147 In general, there are two approaches to avoiding listener-related memory leaks. One is to use a WeakListener; the other is to explicitly remove the listener when the object is removed or otherwise no longer needed. Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up after itself. I'm not suggesting that's the case here, but it is worth looking at. ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From kcr at openjdk.java.net Mon Mar 23 23:42:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Mar 2020 23:42:47 GMT Subject: RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 07:26:46 GMT, Ambarish Rapte wrote: > ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when > the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves > the issue. > Please take a look. In general, there are two approaches to avoiding listener-related memory leaks. One is to use a WeakListener; the other is to explicitly remove the listener when the object is removed or otherwise no longer needed. Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up after itself. I'm not suggesting that's the case here, but it is worth looking at. The one thing I would ask you to take a look at is whether it would matter if the old skin didn't call `setDefaultButton(oldScene, false)` when removed (and similarly `setCancelButton`). ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From kcr at openjdk.java.net Tue Mar 24 00:02:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 00:02:30 GMT Subject: RFR: 8234471: Canvas in webview displayed with wrong scale on Windows In-Reply-To: References: Message-ID: On Mon, 6 Jan 2020 04:42:54 GMT, Guru Hb wrote: >> This bug can be reproduced when the screen resolution is at 125%, 150% and 175% for Windows, which correpsonds to >> `pixelScale` values of 1.25, 1.5 and 1.75, respectively. >> Issue: The rectangle inside canvas is rendered on `pixelScale` while the borders are rendered on `Math.ceil(pixelScale)` >> >> Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform` > > have you tested this on Linux and Mac by changing JVM option -Dglass.win.uiScale=. This looks like the correct fix, and I can confirm that it does fix the problem. I'll run a set of regression tests on Windows 10 with 125% scaling (which is my normal environment) and then finish my review. ------------- PR: https://git.openjdk.java.net/jfx/pull/62 From kcr at openjdk.java.net Tue Mar 24 00:09:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 00:09:30 GMT Subject: [Rev 02] RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Tue, 24 Mar 2020 00:07:04 GMT, Nir Lisker wrote: >> A simple readability cleanup for the files that were changed in #113. >> >> Note that the boolean property has an `instanceof` check that doesn't exist in the other properties. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Re-added newline at the end Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From nlisker at openjdk.java.net Tue Mar 24 00:07:04 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 24 Mar 2020 00:07:04 GMT Subject: [Rev 02] RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: > A simple readability cleanup for the files that were changed in #113. > > Note that the boolean property has an `instanceof` check that doesn't exist in the other properties. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Re-added newline at the end ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/141/files - new: https://git.openjdk.java.net/jfx/pull/141/files/6876a037..93f50005 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/141/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/141/webrev.01-02 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/141.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/141/head:pull/141 PR: https://git.openjdk.java.net/jfx/pull/141 From kcr at openjdk.java.net Tue Mar 24 00:09:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 00:09:30 GMT Subject: [Rev 02] RFR: 8240692: Cleanup of the javafx property objects In-Reply-To: References: Message-ID: On Tue, 24 Mar 2020 00:06:21 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-added newline at the end > > Marked as reviewed by kcr (Lead). Given that this PR is now just a cleanup fix, it is simple enough that it doesn't need a second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/141 From thiago.sayao at clamed.com.br Tue Mar 24 01:25:46 2020 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Tue, 24 Mar 2020 01:25:46 +0000 Subject: Build instructions for Ubuntu 20.04 Message-ID: Hi, Can someone update https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX for Ubuntu 20.04? 1) libavformat-ffmpeg57 -> libavformat58 2) Need to add libxxf86vm-dev Thanks From tsayao at openjdk.java.net Tue Mar 24 01:33:06 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 24 Mar 2020 01:33:06 GMT Subject: RFR: 8241474: Build failing on Ubuntu 20.04 Message-ID: <4pHn9aYKegP55IpfIJk3kgzHDw8geOvfum-BVODhfYQ=.b7e9e021-7fd3-4ecc-8a96-f2541f7c567e@github.com> Small fix for building on ubuntu 20.04. ------------- Commit messages: - Fix build on 20.04 - Merge pull request #7 from openjdk/master - Merge pull request #6 from openjdk/master - Merge pull request #5 from openjdk/master - Merge pull request #4 from openjdk/master Changes: https://git.openjdk.java.net/jfx/pull/149/files Webrev: https://webrevs.openjdk.java.net/jfx/149/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241474 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/149.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/149/head:pull/149 PR: https://git.openjdk.java.net/jfx/pull/149 From tsayao at openjdk.java.net Tue Mar 24 01:41:17 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 24 Mar 2020 01:41:17 GMT Subject: RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) Message-ID: Simple fix to remove annoying warnings. ------------- Commit messages: - Remove build warning - Merge pull request #7 from openjdk/master - Merge pull request #6 from openjdk/master - Merge pull request #5 from openjdk/master - Merge pull request #4 from openjdk/master Changes: https://git.openjdk.java.net/jfx/pull/150/files Webrev: https://webrevs.openjdk.java.net/jfx/150/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241476 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/150.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/150/head:pull/150 PR: https://git.openjdk.java.net/jfx/pull/150 From nlisker at gmail.com Tue Mar 24 05:22:22 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 24 Mar 2020 07:22:22 +0200 Subject: Build instructions for Ubuntu 20.04 In-Reply-To: References: Message-ID: Updated On Tue, Mar 24, 2020 at 3:26 AM Thiago Milczarek Sayao < thiago.sayao at clamed.com.br> wrote: > Hi, > > Can someone update > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX for Ubuntu > 20.04? > > > 1) libavformat-ffmpeg57 -> libavformat58 > > 2) Need to add libxxf86vm-dev > > > Thanks > > From abhinay_agarwal at live.com Tue Mar 24 11:36:54 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Tue, 24 Mar 2020 11:36:54 +0000 Subject: ComboBox keypress discrepancy In-Reply-To: References: , <0F5B44EE-E337-48BE-BD23-E1DB4D7B43A2@gmail.com>, Message-ID: Hi All, I have traced out the root cause responsible for the discrepancy between the behavior of ComboBox in JavaFX 8 vs later version. It turns out the change is in ListViewBehavior and was made under JEP-253[1]. ListView is used as the PopupContent Node in ComboBox. In JDK 8, ListView doesn't have any event handler for TAB key press event [2]. In JDK 9, a default mapping was added to the ListViewBehavior [3][4] which added the key press event handlers for TAB and SHIFT + TAB. Unfortunately, I haven't been able to find the reasoning behind the change. Is there a JBS issue or mailing list discussion that can throw some light on it? This discrepancy can also be reproduced with latest releases JDK 8 and JavaFX 14. Best regards, Abhinay [1] https://bugs.openjdk.java.net/browse/JDK-8076423 [2] https://github.com/openjdk/jfx/blob/48086c72c27237552d8794ff72b2e152a9a7cea1/modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java#L65 [3] https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java#L81 [4] https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/FocusTraversalInputMap.java#L53 P.S. I sincerely hope everyone in this mailing list are healthy and safe! ________________________________ From: Abhinay Agarwal Sent: Sunday, March 8, 2020 1:51 PM To: Dirk Lemmermann Cc: openjfx-dev at openjdk.java.net Subject: Re: ComboBox keypress discrepancy Hi Dirk, Exactly. The TAB key press event not firing at all seems fishy. -- Abhinay ________________________________ From: Dirk Lemmermann Sent: Friday, March 6, 2020 2:55 PM To: Abhinay Agarwal Cc: openjfx-dev at openjdk.java.net Subject: Re: ComboBox keypress discrepancy Regarding expected behaviour: in native combo boxes / dropdowns on Mac the TAB key is doing nothing when the popup is open. If you want to select an item you need to use the arrow keys. So I guess that is what I would expect for navigating the element. But that does not mean that the key event can?t fire, right? Some subclass / custom control might have a need for it. Dirk Am 06.03.2020 um 05:59 schrieb Abhinay Agarwal >: Hi Dirk, Thanks for reaching out. As stated earlier, I want to know what exactly is causing this change in behaviour. I also want to know what is the expected behaviour in this case: should TAB key press trigger when the popupwindow is showing? -- Abhinay ________________________________ From: Dirk Lemmermann > Sent: Thursday, March 5, 2020 6:39 PM To: Abhinay Agarwal > Cc: openjfx-dev at openjdk.java.net > Subject: Re: ComboBox keypress discrepancy So what info do you need? What test do you want us to run? I ran it on MacOS X with Java 14ea and I DO NOT see the ?TAB? output. Dirk Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal >: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.ComboBox; import javafx.scene.input.KeyEvent; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class Main extends Application { @Override public void start(Stage primaryStage) { final ComboBox stringComboBox = new ComboBox<>(); stringComboBox.getItems().addAll("John", "Jacob", "Schmidt"); stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> System.out.println(kp.getCode())); final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 275); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } From kcr at openjdk.java.net Tue Mar 24 11:47:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 11:47:38 GMT Subject: RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: On Tue, 24 Mar 2020 01:36:29 GMT, Thiago Milczarek Sayao wrote: > Simple fix to remove annoying warnings. The problem is that gcc, for whatever reason, started issuing a (useless) warning if you pass the `-Werror=implicit-function-declaration` option to gcc for C++ files. I don't like the solution of removing that flag for C files. I think the better solution will be to have a set of options that are common to both C and C++ (all but this one currently), and then add `-Werror=implicit-function-declaration` only to the options for C. Until then, I think we live with this warning. It's better than losing the checking for C files. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/150 From kcr at openjdk.java.net Tue Mar 24 12:12:16 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 12:12:16 GMT Subject: RFR: 8241474: Build failing on Ubuntu 20.04 In-Reply-To: <4pHn9aYKegP55IpfIJk3kgzHDw8geOvfum-BVODhfYQ=.b7e9e021-7fd3-4ecc-8a96-f2541f7c567e@github.com> References: <4pHn9aYKegP55IpfIJk3kgzHDw8geOvfum-BVODhfYQ=.b7e9e021-7fd3-4ecc-8a96-f2541f7c567e@github.com> Message-ID: On Tue, 24 Mar 2020 01:28:04 GMT, Thiago Milczarek Sayao wrote: > Small fix for building on ubuntu 20.04. Looks good. Thanks for fixing. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/149 From kcr at openjdk.java.net Tue Mar 24 12:24:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 12:24:45 GMT Subject: RFR: 8241474: Build failing on Ubuntu 20.04 In-Reply-To: References: <4pHn9aYKegP55IpfIJk3kgzHDw8geOvfum-BVODhfYQ=.b7e9e021-7fd3-4ecc-8a96-f2541f7c567e@github.com> Message-ID: On Tue, 24 Mar 2020 12:10:03 GMT, Kevin Rushforth wrote: >> Small fix for building on ubuntu 20.04. > > Looks good. Thanks for fixing. @tsayao I will sponsor this for you. ------------- PR: https://git.openjdk.java.net/jfx/pull/149 From Rony.Flatscher at wu.ac.at Tue Mar 24 13:21:26 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 24 Mar 2020 14:21:26 +0100 Subject: [Rev 02] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: <_7uTovlrYnTZ-Gcj1brPO_UavNxYdthVioP3vrmTGew=.d84cc476-92d9-4cac-920f-e87411fdacd0@github.com> References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> <_7uTovlrYnTZ-Gcj1brPO_UavNxYdthVioP3vrmTGew=.d84cc476-92d9-4cac-920f-e87411fdacd0@github.com> Message-ID: <2d598423-89ae-2acc-5f32-80b5dfba88af@wu.ac.at> Kevin and Ajit, thank you very much for your reviews! Will apply the changes (including changing CRLF to LF) ASAP. ---rony On 23.03.2020 22:45, Kevin Rushforth wrote: > On Sat, 21 Mar 2020 19:19:18 GMT, Kevin Rushforth wrote: > >>> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >>> >>> corrected wrong test string >> The fix looks good. I left a few comments on the test. One of them is substantive, the rest are formatting. Once you >> make those changes, I'll approve it. > One more minor observation. I noticed the following have DOS line endings: > > tests/system/src/testscriptapp1/resources/mymod/META-INF/services/javax.script.ScriptEngineFactory: ASCII text, with > CRLF line terminators > tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_bottomscript.rpsl: ASCII text, with > CRLF line terminators > tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_middlescript.rpsl: ASCII text, with > CRLF line terminators > tests/system/src/testscriptapp1/resources/mymod/myapp1/demo_01_topscript.rpsl: ASCII text, with > CRLF line terminators > > Since they aren't source code files, `git jcheck` won't complain, but as long as you are fixing the other issues, would > you mind fixing these too? > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/122 From kcr at openjdk.java.net Tue Mar 24 13:28:16 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 13:28:16 GMT Subject: RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 23:40:39 GMT, Kevin Rushforth wrote: >> ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when >> the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves >> the issue. >> Please take a look. > > In general, there are two approaches to avoiding listener-related memory leaks. One is to use a WeakListener; the other > is to explicitly remove the listener when the object is removed or otherwise no longer needed. > Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up > after itself. I'm not suggesting that's the case here, but it is worth looking at. The one thing I would ask you to > take a look at is whether it would matter if the old skin didn't call `setDefaultButton(oldScene, false)` when removed > (and similarly `setCancelButton`). @aghaisas can you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From tsayao at openjdk.java.net Tue Mar 24 13:35:48 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 24 Mar 2020 13:35:48 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> Message-ID: <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> On Tue, 3 Mar 2020 11:10:07 GMT, Thiago Milczarek Sayao wrote: >> This is going to need further discussion on the mailing list as indicated above, so it is still premature to review it >> (i.e., it should still be considered effectively a "WIP" until that discussion happens). Additionally, this is a >> significant and risky change, so I'd like additional eyes on it when we do get to the point of reviewing it. > > I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 > and Scenebuilder. > Will have to do some tests on 16.04. Ubuntu 20.04 Test Results ![image](https://user-images.githubusercontent.com/30704286/77431021-e023ab00-6dba-11ea-9db0-72358a90501b.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Tue Mar 24 13:30:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 13:30:46 GMT Subject: RFR: 8089828: RTL Orientation, the flag of a mnemonic is not placed under the mnemonic letter. In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 22:42:54 GMT, Kevin Rushforth wrote: >> **Bug :** >> https://bugs.openjdk.java.net/browse/JDK-8089828 >> >> **Root Cause :** >> RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position calculation. >> >> **Fix :** >> Corrected code to consider RIGHT_TO_LEFT NodeOrientation while calculating mnemonic position. >> >> **Testing :** >> Existing manual test is modified to test RTL buttons as well. > > The fix looks good to me, although I'd like a second reviewer. > > I did note one issue with the format of the copyright year. @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/146 From kcr at openjdk.java.net Tue Mar 24 14:21:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Mar 2020 14:21:37 GMT Subject: [Rev 01] RFR: 8234471: Canvas in webview displayed with wrong scale on Windows In-Reply-To: References: Message-ID: On Tue, 25 Feb 2020 07:11:43 GMT, Arun Joseph wrote: >> This bug can be reproduced when the screen resolution is at 125%, 150% and 175% for Windows, which correpsonds to >> `pixelScale` values of 1.25, 1.5 and 1.75, respectively. >> Issue: The rectangle inside canvas is rendered on `pixelScale` while the borders are rendered on `Math.ceil(pixelScale)` >> >> Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform` > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Added CanvasTest The fix looks good to me. I left one comment on the test. tests/system/src/test/java/test/javafx/scene/web/CanvasTest.java line 125: > 124: assertEquals("Rect bottom-right corner", redColor, (int) webView.getEngine().executeScript( > 125: "document.getElementById('canvas').getContext('2d').getImageData(99, 99, 1, 1).data[0]")); > 126: webViewStateLatch.countDown(); An assertion failure here will not be propagated outside the listener. A failure will be reported as a timeout rather than an assertion failure. I recommend moving the above two assertion checks to a `Util.runAndWait` block at the end of this method -- after the await call for `webViewStateLatch`. ------------- PR: https://git.openjdk.java.net/jfx/pull/62 From tsayao at openjdk.java.net Wed Mar 25 00:42:00 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 25 Mar 2020 00:42:00 GMT Subject: [Rev 01] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: > Simple fix to remove annoying warnings. 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 five additional commits since the last revision: - Merge branch 'master' into jdk_8241476 - Another approach for removing c++ warnings - Merge pull request #8 from openjdk/master Merge upstream - Remove build warning - Merge pull request #7 from openjdk/master merge from jfx ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/150/files - new: https://git.openjdk.java.net/jfx/pull/150/files/6e185d8a..3164ab36 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/150/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/150/webrev.00-01 Stats: 1819 lines in 39 files changed: 1208 ins; 249 del; 362 mod Patch: https://git.openjdk.java.net/jfx/pull/150.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/150/head:pull/150 PR: https://git.openjdk.java.net/jfx/pull/150 From tsayao at openjdk.java.net Wed Mar 25 00:42:19 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 25 Mar 2020 00:42:19 GMT Subject: [Rev 01] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: On Tue, 24 Mar 2020 11:45:28 GMT, Kevin Rushforth wrote: >> 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 five additional commits >> since the last revision: >> - Merge branch 'master' into jdk_8241476 >> - Another approach for removing c++ warnings >> - Merge pull request #8 from openjdk/master >> >> Merge upstream >> - Remove build warning >> - Merge pull request #7 from openjdk/master >> >> merge from jfx > > The problem is that gcc, for whatever reason, started issuing a (useless) warning if you pass the > `-Werror=implicit-function-declaration` option to gcc for C++ files. I don't like the solution of removing that flag > for C files. I think the better solution will be to have a set of options that are common to both C and C++ (all but > this one currently), and then add `-Werror=implicit-function-declaration` only to the options for C. Until then, I > think we live with this warning. It's better than losing the checking for C files. Like this? I think all C builds are covered. Gstreamer seems to have a Makefile with the flags. Not sure about libxml and libxlst inside javafx.web. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From tsayao at openjdk.java.net Wed Mar 25 00:46:46 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 25 Mar 2020 00:46:46 GMT Subject: [Rev 31] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) 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 six additional commits since the last revision: - Merge branch 'master' into jdk_8236651 - Merge pull request #8 from openjdk/master Merge upstream - fix compilation on ubuntu 16.04 - Merge remote-tracking branch 'origin/jdk_8236651' into jdk_8236651 - Merge branch 'master' into jdk_8236651 - Merge pull request #7 from openjdk/master merge from jfx ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/086143ac..f8fe264c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.31 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.30-31 Stats: 1810 lines in 39 files changed: 1206 ins; 249 del; 355 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From fastegal at swingempire.de Wed Mar 25 10:13:24 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 25 Mar 2020 11:13:24 +0100 Subject: WeakXXListener - when not to use? Message-ID: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> Currently, there are two open pull requests (#147 and #148) for fixing memory leaks in controls/skin with the same comment from Kevin: "Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up after itself." Looks like I can't come up with a scenario where this might happen - as long as the owner (f.i. a control) of the instance that mananges the listener (f.i. a selectionModel) on a property of the owner keeps a strong reference to the manager. Questions: - what to watch out for to safely exlude any unwanted self-removal? - how to test? -- Jeanette From fastegal at swingempire.de Wed Mar 25 13:53:09 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 25 Mar 2020 14:53:09 +0100 Subject: Issue granularity? Message-ID: <20200325145309.Horde.lFrqKqIZDNsYmuRu3dRhsQ2@webmail.df.eu> While working on a memory leak for ChoiceBoxSelection (https://bugs.openjdk.java.net/browse/JDK-8241455) I wrote a test covering the same issue in other controls with selection- and focusModels (the latter if available). Turned out it fails for - TreeView selection- and focusModel - TreeTableView focusModel - TabPane selectionModel all register listeners (eventHandler in the case of TreeView) to properties of the control with strong references, the fix is similar: use weakListeners (if that's the outcome of fixing choiceBoxSelection) How to procede? Options seem to be - one issue/pull request per control - bulk issue/pull request for the all similar (keeping the current for ChoiceBox as is) - include all into the current issue/pull request for ChoiceBox - other? From kevin.rushforth at oracle.com Wed Mar 25 16:25:35 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Mar 2020 09:25:35 -0700 Subject: WeakXXListener - when not to use? In-Reply-To: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> Message-ID: <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> Here are my quick thoughts on the things to watch out for when converting a (strong) listener to a WeakListener, but I would love to hear from others. The main thing you need to do is make sure that the listener doesn't go out of scope, and thus become subject to garbage collection, too soon. At a minimum, it means that the object that creates the listener needs to hold a strong reference to the listener. In the case of the two PRs referred to above, that minimum bar was cleared (good). By way of example, blindly turning the following into a WeakReference would lead to a listener almost certainly being released too early: Before: ??? class SomeClass { ??????? ... ??????? void someMethod() { ??? ??? ??? someOtherObject.addListener((o, oldVal, newVal) -> doSomethingUseful(o, oldVal, newVal)); ??????? } ??? } After (wrong) : ??? class SomeClass { ??????? ... ??????? void someMethod() { ??? ??? ??? someOtherObject.addListener(new WeakChangeListener( (o, oldVal, newVal) -> doSomethingUseful(o, oldVal, newVal))); ??????? } ??? } So at a minimum, it would need to do this: After (better) : ??? class SomeClass { ??????? ... ??? ??? // hold listener in an instance variable ??????? private ChangeListener myListener = (o, oldVal, newVal) -> doSomethingUseful(o, oldVal, newVal); ??????? void someMethod() { ??? ??? ??? someOtherObject.addListener(new WeakChangeListener(myListener)); ??????? } ??? } As for whether the above is sufficient, it depends on what the listener does (what its purpose is).In this simple example, it seems unlikely that removing the listener when the instance of SomeClass goes out of scope will cause any problems. It's worth looking at what "doSomethingUseful" does to see if unregisters anything that ought to be unregistered (and now maybe won't be if the listener goes away early). Bringing this back to the two cases in question, I think they are both fine, although I pointed Ambarish at one thing to look at in the ButtonSkin case (I don't see anything similar for your ChoiceBox leak fix that ought to be looked at more carefully). -- Kevin On 3/25/2020 3:13 AM, Jeanette Winzenburg wrote: > > Currently, there are two open pull requests (#147 and #148) for fixing > memory leaks in controls/skin with the same comment from Kevin: > > "Using a WeakListener is certainly easier, but runs the risk of the > listener being removed too early and not cleaning up after itself." > > Looks like I can't come up with a scenario where this might happen - > as long as the owner (f.i. a control) of the instance that mananges > the listener (f.i. a selectionModel) on a property of the owner keeps > a strong reference to the manager. > > Questions: > > - what to watch out for to safely exlude any unwanted self-removal? > - how to test? > > -- Jeanette > From kevin.rushforth at oracle.com Wed Mar 25 16:34:55 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Mar 2020 09:34:55 -0700 Subject: WeakXXListener - when not to use? In-Reply-To: <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> Message-ID: <18e36670-9b17-0fee-527d-8881876d0b7e@oracle.com> I realized I didn't answer the "how to test" part of it. The only thing I can think of is running all of the existing tests, including the systemTests and any other manual tests that use the object in question, with a limited heap size to make GC more likely to happen. There might be additional GC flags that one could pass to make the GC more aggressive, but I haven't tried that. -- Kevin On 3/25/2020 9:25 AM, Kevin Rushforth wrote: > Here are my quick thoughts on the things to watch out for when > converting a (strong) listener to a WeakListener, but I would love to > hear from others. > > The main thing you need to do is make sure that the listener doesn't > go out of scope, and thus become subject to garbage collection, too soon. > > At a minimum, it means that the object that creates the listener needs > to hold a strong reference to the listener. In the case of the two PRs > referred to above, that minimum bar was cleared (good). By way of > example, blindly turning the following into a WeakReference would lead > to a listener almost certainly being released too early: > > Before: > ??? class SomeClass { > ??????? ... > ??????? void someMethod() { > ??? ??? ??? someOtherObject.addListener((o, oldVal, newVal) -> > doSomethingUseful(o, oldVal, newVal)); > ??????? } > ??? } > > After (wrong) : > ??? class SomeClass { > ??????? ... > ??????? void someMethod() { > ??? ??? ??? someOtherObject.addListener(new WeakChangeListener( > (o, oldVal, newVal) -> doSomethingUseful(o, oldVal, newVal))); > ??????? } > ??? } > > So at a minimum, it would need to do this: > > After (better) : > ??? class SomeClass { > ??????? ... > ??? ??? // hold listener in an instance variable > ??????? private ChangeListener myListener = (o, oldVal, newVal) -> > doSomethingUseful(o, oldVal, newVal); > > ??????? void someMethod() { > ??? ??? ??? someOtherObject.addListener(new > WeakChangeListener(myListener)); > ??????? } > ??? } > > As for whether the above is sufficient, it depends on what the > listener does (what its purpose is).In this simple example, it seems > unlikely that removing the listener when the instance of SomeClass > goes out of scope will cause any problems. It's worth looking at what > "doSomethingUseful" does to see if unregisters anything that ought to > be unregistered (and now maybe won't be if the listener goes away early). > > Bringing this back to the two cases in question, I think they are both > fine, although I pointed Ambarish at one thing to look at in the > ButtonSkin case (I don't see anything similar for your ChoiceBox leak > fix that ought to be looked at more carefully). > > -- Kevin > > > On 3/25/2020 3:13 AM, Jeanette Winzenburg wrote: >> >> Currently, there are two open pull requests (#147 and #148) for >> fixing memory leaks in controls/skin with the same comment from Kevin: >> >> "Using a WeakListener is certainly easier, but runs the risk of the >> listener being removed too early and not cleaning up after itself." >> >> Looks like I can't come up with a scenario where this might happen - >> as long as the owner (f.i. a control) of the instance that mananges >> the listener (f.i. a selectionModel) on a property of the owner keeps >> a strong reference to the manager. >> >> Questions: >> >> - what to watch out for to safely exlude any unwanted self-removal? >> - how to test? >> >> -- Jeanette >> > From tres.finocchiaro at gmail.com Wed Mar 25 17:27:18 2020 From: tres.finocchiaro at gmail.com (Tres Finocchiaro) Date: Wed, 25 Mar 2020 13:27:18 -0400 Subject: Monocle as a replacement In-Reply-To: References: Message-ID: With the help from a paid fx support channel, we're making headway with this. The main help was disabling the recommended software option. At time of writing this, I recommend this warning/detail is added to the wiki: https://wiki.openjdk.java.net/display/OpenJFX/Monocle Quoting: > *If you are running the desktop build of JavaFX or OpenJFX then your only > monocle option is Headless. Desktop JavaFX does not support the > javafx.platform system property, but you can select Monocle > with:-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw* In or case, removing "*-Dprism.order=sw"* was critical to prevent crashes on MacOS and Windows. We've yet to test on Linux. Last, since Monocle introduces a virtual desktop size (and we're using this desktop for screen captures), we'll be tweaking the "*-Dheadless.geometry=*" parameter depending on available heap size. These details are best tracked downstream for those interested https://github.com/qzind/tray/pull/586. Unless there are immediate questions, this will be the last update I provide to the mailing list, all further updates will be specific to the downstream implementation. As an aside, we may decide to sponsor the fixing of the underlying crashes as well (for example, d2d may not be available on Windows 2016 Core?) but at the time of writing this, we're adopting workarounds to make it viable on a standard Desktop. - Tres.Finocchiaro at gmail.com On Fri, Feb 21, 2020 at 5:13 PM Tres Finocchiaro wrote: > Danny, > > Thanks this information is very valuable. > > By using the provided patch, I too am able to re-use the Monocle framework > without suffering this bug. > > For those visiting this thread (e.g. through archive) at a later time, > it's being tracked downstream here: > https://github.com/qzind/tray/issues/576 > > So applying it I was able to discover I was running into two separate > issues... > > - The first was the unpredictable buffer behavior you've shared, which > seems to be resolved that problem. I used the recommended code, just in a > copy of the JavaFX 11 class instead. Thanks! > > - The second is a nuance of reusing the WebView and Stage using > Monocle, the stage/webview height calculation starts to grow out of control > (watching the DOM height -- we calculate the natural height and then use > that for snapshot). In my case it was growing 300, 900, 2900, 8600 > eventually crashing somewhere in buffer allocation. Hard-coding the sizing > didn't suffer the same fate because it bypasses our attempts to calculate > the height using JavaScript. Oddly, creating a fresh WebView each time > didn't correct the issue either. I believe the underlying issue stems > somewhere from the stage height never resetting back, but attempts to do so > manually cause other issues, so I'll see if there's a viable workaround by > doing more renders using Monocle. > > We already have an open item with Gluon regarding WebView stage sizing, so > this may be a race condition rearing its ugly head through a different > symptom. We'll continue to work on it separately. > > Danny, thanks again for the link to the patch. We'll continue our testing. > > - Tres.Finocchiaro at gmail.com > > > On Wed, Feb 19, 2020 at 2:46 AM Danny Gonzalez < > danny.gonzalez at screamingfrog.co.uk> wrote: > >> Hi Tres, >> >> We also are suffering from this crash when running our TestFX unit tests, >> particularly on Java 11. >> It is due to a concurrency issue between the JavaFX thread and the >> QuantumRenderer thread and there is an OpenJDK bug here: >> https://bugs.openjdk.java.net/browse/JDK-8201567 >> >> Quoting from this bug report: >> ?The QuantumRenderer calls the getPixels() method while trying to find a >> buffer that's not in use, yet in doing so it can inadvertently modify a >> buffer that's in use." >> >> There is also a related TestFX Bug: >> https://github.com/TestFX/Monocle/issues/56 >> >> There is a fix for this issue In the first comment of the JDK-8201567, in >> a link to GitLab: https://gitlab.com/openjfxepd/jfxpatch/commit/ >> >> >> We have used this patch in our local OpenJFX build. >> >> This has never been made into a pull request however but I believe it >> should. >> >> Danny >> >> On 17 Feb 2020, at 19:12, Tres Finocchiaro >> wrote: >> >> Hi, >> >> I'm the developer of a printing plugin which leverages JavaFX for a few >> HTML functions. >> >> One of our functions would greatly benefit from being "headless (or more >> accurately, "silent") mode that Monocle offers and I'm evaluating the use >> of Monocle on (non-headless) Desktops for this. I'm currently testing a >> monocle build by the TestFX team for MacOS. >> >> Although first test was positive, when invoking multiple times, I'm >> getting >> some internal errors similar to this: >> https://stackoverflow.com/questions/49388497 and the framework grows >> slower >> and slower as it nears its final capture. (I'm using WebView.capture(...)) >> >> Is this the right place for such as discussion? Where's the best place to >> ask about issues with Monocle? >> >> >> - Tres.Finocchiaro at gmail.com >> >> >> From ajoseph at openjdk.java.net Wed Mar 25 18:12:41 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 25 Mar 2020 18:12:41 GMT Subject: [Rev 02] RFR: 8234471: Canvas in webview displayed with wrong scale on Windows In-Reply-To: References: Message-ID: > This bug can be reproduced when the screen resolution is at 125%, 150% and 175% for Windows, which correpsonds to > `pixelScale` values of 1.25, 1.5 and 1.75, respectively. > Issue: The rectangle inside canvas is rendered on `pixelScale` while the borders are rendered on `Math.ceil(pixelScale)` > > Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform` Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Updated test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/62/files - new: https://git.openjdk.java.net/jfx/pull/62/files/ea422a78..eadff865 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/62/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/62/webrev.01-02 Stats: 13 lines in 1 file changed: 8 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/62/head:pull/62 PR: https://git.openjdk.java.net/jfx/pull/62 From kcr at openjdk.java.net Wed Mar 25 18:29:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 Mar 2020 18:29:06 GMT Subject: [Rev 02] RFR: 8234471: Canvas in webview displayed with wrong scale on Windows In-Reply-To: References: Message-ID: On Wed, 25 Mar 2020 18:12:41 GMT, Arun Joseph wrote: >> This bug can be reproduced when the screen resolution is at 125%, 150% and 175% for Windows, which correpsonds to >> `pixelScale` values of 1.25, 1.5 and 1.75, respectively. >> Issue: The rectangle inside canvas is rendered on `pixelScale` while the borders are rendered on `Math.ceil(pixelScale)` >> >> Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform` > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Updated test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/62 From github.com+60214806+ronyfla at openjdk.java.net Wed Mar 25 18:52:38 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Wed, 25 Mar 2020 18:52:38 GMT Subject: [Rev 03] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: > ?9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: Applying the changes according to the review. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/122/files - new: https://git.openjdk.java.net/jfx/pull/122/files/a42fed5c..7d867ab8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/122/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/122/webrev.02-03 Stats: 18 lines in 7 files changed: 1 ins; 2 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/122/head:pull/122 PR: https://git.openjdk.java.net/jfx/pull/122 From github.com+60214806+ronyfla at openjdk.java.net Wed Mar 25 19:05:42 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Wed, 25 Mar 2020 19:05:42 GMT Subject: [Rev 04] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: > ?9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: Remove jcheck whitespace error. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/122/files - new: https://git.openjdk.java.net/jfx/pull/122/files/7d867ab8..58c8ce59 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/122/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/122/webrev.03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/122/head:pull/122 PR: https://git.openjdk.java.net/jfx/pull/122 From kcr at openjdk.java.net Wed Mar 25 19:32:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 Mar 2020 19:32:59 GMT Subject: [Rev 04] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: On Wed, 25 Mar 2020 19:05:42 GMT, Rony G. Flatscher wrote: >> ?9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > Remove jcheck whitespace error. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From kcr at openjdk.java.net Wed Mar 25 21:25:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 Mar 2020 21:25:59 GMT Subject: RFR: 8240539: Upgrade gradle to version 6.3 Message-ID: This upgrades the version of gradle used to build JavaFX to 6.3. The minimum version of gradle is not changed by the proposed fix, and remains at 5.3. I have run done a full build and test with gradle 6.3 on all three platforms. There are no new failures. This will enable building JavaFX using JDK 14 as the boot JDK, although upgrading the boot JDK for our builds will be done in a separate pull request. ------------- Commit messages: - 8240539: Upgrade gradle to version 6.3 Changes: https://git.openjdk.java.net/jfx/pull/151/files Webrev: https://webrevs.openjdk.java.net/jfx/151/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240539 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/151/head:pull/151 PR: https://git.openjdk.java.net/jfx/pull/151 From kcr at openjdk.java.net Wed Mar 25 21:25:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 Mar 2020 21:25:59 GMT Subject: RFR: 8240539: Upgrade gradle to version 6.3 In-Reply-To: References: Message-ID: On Wed, 25 Mar 2020 21:20:37 GMT, Kevin Rushforth wrote: > This upgrades the version of gradle used to build JavaFX to 6.3. The minimum version of gradle is not changed by the > proposed fix, and remains at 5.3. > I have run done a full build and test with gradle 6.3 on all three platforms. There are no new failures. > > This will enable building JavaFX using JDK 14 as the boot JDK, although upgrading the boot JDK for our builds will be > done in a separate pull request. @arapte can you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/151 From pedro.duquevieira at gmail.com Wed Mar 25 22:21:00 2020 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 25 Mar 2020 22:21:00 +0000 Subject: WeakXXListener - when not to use? Message-ID: Hi guys, Sorry to barge in on the conversation but I think I have some comments that might add to the conversation. Sometime ago someone reported this bug in the JMetro issue tracker: https://github.com/JFXtras/jfxtras-styles/issues/144 (it's a hobby project, a JavaFX theme, I've been working on, on my spare time) To summarize: they want to allow the user to be able to change themes while the JavaFX app is running which will end up changing control skins on the process. I think it's a valid scenario. What I've found that is that the JavaFX Skins of some controls don't release the listeners, in this case TextFieldSkin when the skin of the corresponding control gets switched. Same for ProgressBarSkin it seems. I think in the dispose method of both skins the listeners that were added in the skins should be removed? So the old skin listeners end up being called, when they shouldn't because the skin of the Control is now another object. This ends up in an Exception being thrown in those listeners. I think the reporter of the issue ended up registering an issue with this in the JavaFX issue tracker. Thanks. Which this adds something to the conversation. Best regards, -- Pedro Duque Vieira - https://www.pixelduke.com From kevin.rushforth at oracle.com Wed Mar 25 22:45:01 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Mar 2020 15:45:01 -0700 Subject: Issue granularity? In-Reply-To: <20200325145309.Horde.lFrqKqIZDNsYmuRu3dRhsQ2@webmail.df.eu> References: <20200325145309.Horde.lFrqKqIZDNsYmuRu3dRhsQ2@webmail.df.eu> Message-ID: <5b69d029-d67d-b5df-0ed5-d411bee9511f@oracle.com> It depends on how many there are and how similar they are. If there isn't much similarity, then one issue per control is probably fine (and may be best). If there is a lot of similar patterns then some grouping will help cut down on the number of reviews (and the associated testing). Ambarish was looking into a few of these, too, so maybe he has some thoughts on this. -- Kevin On 3/25/2020 6:53 AM, Jeanette Winzenburg wrote: > > While working on a memory leak for ChoiceBoxSelection > (https://bugs.openjdk.java.net/browse/JDK-8241455) I wrote a test > covering the same issue in other controls with selection- and > focusModels (the latter if available). Turned out it fails for > > - TreeView selection- and focusModel > - TreeTableView focusModel > - TabPane selectionModel > > all register listeners (eventHandler in the case of TreeView) to > properties of the control with strong references, the fix is similar: > use weakListeners (if that's the outcome of fixing choiceBoxSelection) > > How to procede? Options seem to be > > - one issue/pull request per control > - bulk issue/pull request for the all similar (keeping the current for > ChoiceBox as is) > - include all into the current issue/pull request for ChoiceBox > - other? > > > > From aghaisas at openjdk.java.net Thu Mar 26 06:25:55 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 26 Mar 2020 06:25:55 GMT Subject: [Rev 01] RFR: 8089828: RTL Orientation, the flag of a mnemonic is not placed under the mnemonic letter. In-Reply-To: References: Message-ID: <4tHlHIh6GKPwga4fon7fmrnUz6aqRtBmZ0gU6wG9N7k=.5842bc3a-bf84-4034-8d34-554fdebc0aea@github.com> > **Bug :** > https://bugs.openjdk.java.net/browse/JDK-8089828 > > **Root Cause :** > RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position calculation. > > **Fix :** > Corrected code to consider RIGHT_TO_LEFT NodeOrientation while calculating mnemonic position. > > **Testing :** > Existing manual test is modified to test RTL buttons as well. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: fix file header comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/146/files - new: https://git.openjdk.java.net/jfx/pull/146/files/a88ed536..6dd5602a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/146/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/146/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/146.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/146/head:pull/146 PR: https://git.openjdk.java.net/jfx/pull/146 From jvos at openjdk.java.net Thu Mar 26 08:27:27 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 26 Mar 2020 08:27:27 GMT Subject: RFR: 8240262: iOS refresh rate is capped to 30 Hz In-Reply-To: References: Message-ID: On Sun, 1 Mar 2020 18:15:07 GMT, Jose Pereda wrote: > There is a hardcoded limit to refresh the glass view on iOS at a half rate of the native refresh rate. > > This PR removes that limit. > > Since the default value for `frameInterval ` is 1 (which implies refreshing at the same rate as allowed by the device), > doing `setFrameInterval:1` is not necessary. What's more, this method is > [deprecated](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1621231-frameinterval?language=objc). The only thing that worries me is that I don't see a reason why this limitation was added originally. I don't see a reason to keep it, so +1 on removing it. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/130 From jvos at openjdk.java.net Thu Mar 26 08:25:51 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 26 Mar 2020 08:25:51 GMT Subject: RFR: 8240539: Upgrade gradle to version 6.3 In-Reply-To: References: Message-ID: On Wed, 25 Mar 2020 21:20:37 GMT, Kevin Rushforth wrote: > This upgrades the version of gradle used to build JavaFX to 6.3. The minimum version of gradle is not changed by the > proposed fix, and remains at 5.3. > I have run done a full build and test with gradle 6.3 on all three platforms. There are no new failures. > > This will enable building JavaFX using JDK 14 as the boot JDK, although upgrading the boot JDK for our builds will be > done in a separate pull request. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/151 From jvos at openjdk.java.net Thu Mar 26 08:35:37 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 26 Mar 2020 08:35:37 GMT Subject: [Rev 01] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: On Wed, 25 Mar 2020 00:40:01 GMT, Thiago Milczarek Sayao wrote: >> The problem is that gcc, for whatever reason, started issuing a (useless) warning if you pass the >> `-Werror=implicit-function-declaration` option to gcc for C++ files. I don't like the solution of removing that flag >> for C files. I think the better solution will be to have a set of options that are common to both C and C++ (all but >> this one currently), and then add `-Werror=implicit-function-declaration` only to the options for C. Until then, I >> think we live with this warning. It's better than losing the checking for C files. > > Like this? > > I think all C builds are covered. Gstreamer seems to have a Makefile with the flags. Not sure about libxml and libxlst > inside javafx.web. I think it's better to split the flags between CFLAGS and CPPFLAGS (as is done in OpenJDK). The `-Werror=implicit-function-declaration` is extremely useful for C files, and we don't want to risk that this somehow got lost. If we use CFLAGS and CPPFLAGS, we can pass the latter as CXXFLAGS to cmake, so that should be fairly easy. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From ghb at openjdk.java.net Thu Mar 26 09:42:38 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 26 Mar 2020 09:42:38 GMT Subject: [Rev 02] RFR: 8234471: Canvas in webview displayed with wrong scale on Windows In-Reply-To: References: Message-ID: On Wed, 25 Mar 2020 18:12:41 GMT, Arun Joseph wrote: >> This bug can be reproduced when the screen resolution is at 125%, 150% and 175% for Windows, which correpsonds to >> `pixelScale` values of 1.25, 1.5 and 1.75, respectively. >> Issue: The rectangle inside canvas is rendered on `pixelScale` while the borders are rendered on `Math.ceil(pixelScale)` >> >> Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform` > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Updated test Marked as reviewed by ghb (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/62 From kcr at openjdk.java.net Thu Mar 26 11:23:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Mar 2020 11:23:20 GMT Subject: [Rev 01] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 08:33:29 GMT, Johan Vos wrote: >> Like this? >> >> I think all C builds are covered. Gstreamer seems to have a Makefile with the flags. Not sure about libxml and libxlst >> inside javafx.web. > > I think it's better to split the flags between CFLAGS and CPPFLAGS (as is done in OpenJDK). The > `-Werror=implicit-function-declaration` is extremely useful for C files, and we don't want to risk that this somehow > got lost. If we use CFLAGS and CPPFLAGS, we can pass the latter as CXXFLAGS to cmake, so that should be fairly easy. I took a look yesterday and came to the same conclusion that what we really want are separate C and C++ flags. For now, the only difference would be the presence or absence of `-Werror=implicit-function-declaration`, but it would allow for other differences in the future if needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From kcr at openjdk.java.net Thu Mar 26 11:30:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Mar 2020 11:30:12 GMT Subject: [Rev 01] RFR: 8089828: RTL Orientation, the flag of a mnemonic is not placed under the mnemonic letter. In-Reply-To: <4tHlHIh6GKPwga4fon7fmrnUz6aqRtBmZ0gU6wG9N7k=.5842bc3a-bf84-4034-8d34-554fdebc0aea@github.com> References: <4tHlHIh6GKPwga4fon7fmrnUz6aqRtBmZ0gU6wG9N7k=.5842bc3a-bf84-4034-8d34-554fdebc0aea@github.com> Message-ID: On Thu, 26 Mar 2020 06:25:55 GMT, Ajit Ghaisas wrote: >> **Bug :** >> https://bugs.openjdk.java.net/browse/JDK-8089828 >> >> **Root Cause :** >> RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position calculation. >> >> **Fix :** >> Corrected code to consider RIGHT_TO_LEFT NodeOrientation while calculating mnemonic position. >> >> **Testing :** >> Existing manual test is modified to test RTL buttons as well. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > fix file header comment Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/146 From debayansutradhar3 at gmail.com Thu Mar 26 11:33:51 2020 From: debayansutradhar3 at gmail.com (Debayan Sutradhar) Date: Thu, 26 Mar 2020 17:03:51 +0530 Subject: OpenJFX >11 exclusive RuntimeException on Embedded Message-ID: <5e7c9326.1c69fb81.d68fb.5d9f@mx.google.com> From fastegal at openjdk.java.net Thu Mar 26 11:39:22 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 26 Mar 2020 11:39:22 GMT Subject: RFR: 8241455: ChoiceBox - memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 23:45:55 GMT, Kevin Rushforth wrote: >> I have basically the same comment / question as I asked in #147 >> >> In general, there are two approaches to avoiding listener-related memory leaks. One is to use a WeakListener; the other >> is to explicitly remove the listener when the object is removed or otherwise no longer needed. >> Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up >> after itself. I'm not suggesting that's the case here, but it is worth looking at. > > @arapte @aghaisas - Can you both review this? I would like to widen the issue (and change this pull request accordingly) to include memory leaks of introduced selection- and focusModels in other controls that are caused by the basically same reason, that is strong references via listeners to controls' properties. The fix would be the same as well, that is wrap the listeners into weakXXListeners and register these. The models suggested to include here: - TreeView: selection- and focusModel - TreeTableView: focusModel - TabPane: selectionModel Not included would be memory leaks introduced by whacky listening of ChoiceBoxSkin and TabPaneSkin to properties of the selectionModel. The former will (most probably) be fixed as a side-effect of https://bugs.openjdk.java.net/browse/JDK-8087555 (which I intend to take, if Ajit agrees :), will open a separate issue for the latter. The extended fix here will have tests for replacing selection/focusModels with/out a skin registered for all controls having the respective models. Not entirely certain about the formal procedure (locally fix and tests are - nearly, pending some cleanup - ready). Simply change titles, rebase and push again? ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From kevin.rushforth at oracle.com Thu Mar 26 11:44:52 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Mar 2020 04:44:52 -0700 Subject: CFV: New OpenJFX Committer: Arun Joseph Message-ID: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> I hereby nominate Arun Joseph [1] to OpenJFX Committer. Arun is a member of JavaFX team at Oracle, who has contributed 13 commits [2][3] to OpenJFX. Votes are due by April 9, 2020. Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] http://openjdk.java.net/census#ajoseph [2] https://github.com/openjdk/jfx/commits?author=arun-Joseph [3] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 [4] http://openjdk.java.net/census#openjfx [5] http://openjdk.java.net/bylaws#lazy-consensus [6] http://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Thu Mar 26 11:45:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Mar 2020 04:45:51 -0700 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: Vote: YES On 3/26/2020 4:44 AM, Kevin Rushforth wrote: > I hereby nominate Arun Joseph [1] to OpenJFX Committer. From ambarish.rapte at oracle.com Thu Mar 26 11:52:23 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 26 Mar 2020 04:52:23 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: Vote: YES -----Original Message----- From: Kevin Rushforth Sent: Thursday, March 26, 2020 5:16 PM To: openjfx-dev at openjdk.java.net Subject: Re: CFV: New OpenJFX Committer: Arun Joseph Vote: YES On 3/26/2020 4:44 AM, Kevin Rushforth wrote: > I hereby nominate Arun Joseph [1] to OpenJFX Committer. From nlisker at gmail.com Thu Mar 26 11:51:58 2020 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 26 Mar 2020 13:51:58 +0200 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: Vote: YES On Thu, Mar 26, 2020 at 1:46 PM Kevin Rushforth wrote: > Vote: YES > > On 3/26/2020 4:44 AM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Committer. > > From fastegal at swingempire.de Thu Mar 26 11:52:32 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 26 Mar 2020 12:52:32 +0100 Subject: WeakXXListener - when not to use? In-Reply-To: <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> Message-ID: <20200326125232.Horde.maFt83PDf6RYO43UMwAVhA7@webmail.df.eu> Zitat von Kevin Rushforth : Thanks for your input! Glad we didn't miss the "minimum bar" height - with the java doc being really clear on that :) What I still don't quite get is the concern about "too early" and "not cleaning up" - maybe I misunderstand the point entirely > > As for whether the above is sufficient, it depends on what the > listener does (what its purpose is).In this simple example, it seems > unlikely that removing the listener when the instance of SomeClass > goes out of scope will cause any problems. It's worth looking at > what "doSomethingUseful" does to see if unregisters anything that > ought to be unregistered (and now maybe won't be if the listener > goes away early). > if not doing that "doSomethingUseful" would cause a - more - terrible misbehavior than a memory leak, would that mean that the listening/update implementation in that specific case would have to be re-thought? F.i. in the case of the ButtonSkin listening to control's scene is changing global state which might be broken if it's not reverted to not having a default/cancel registered? (what a horrible sentence, sry ;) Hmm .. From nlisker at gmail.com Thu Mar 26 11:58:18 2020 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 26 Mar 2020 13:58:18 +0200 Subject: WeakXXListener - when not to use? In-Reply-To: <20200326125232.Horde.maFt83PDf6RYO43UMwAVhA7@webmail.df.eu> References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> <20200326125232.Horde.maFt83PDf6RYO43UMwAVhA7@webmail.df.eu> Message-ID: BTW, Tomas Mikula wrote about this on http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html . There is a comment at the end that is worth a read too. On Thu, Mar 26, 2020 at 1:53 PM Jeanette Winzenburg wrote: > > Zitat von Kevin Rushforth : > > Thanks for your input! > > Glad we didn't miss the "minimum bar" height - with the java doc being > really clear on that :) > > What I still don't quite get is the concern about "too early" and "not > cleaning up" - maybe I misunderstand the point entirely > > > > > As for whether the above is sufficient, it depends on what the > > listener does (what its purpose is).In this simple example, it seems > > unlikely that removing the listener when the instance of SomeClass > > goes out of scope will cause any problems. It's worth looking at > > what "doSomethingUseful" does to see if unregisters anything that > > ought to be unregistered (and now maybe won't be if the listener > > goes away early). > > > > if not doing that "doSomethingUseful" would cause a - more - terrible > misbehavior than a memory leak, would that mean that the > listening/update implementation in that specific case would have to be > re-thought? F.i. in the case of the ButtonSkin listening to control's > scene is changing global state which might be broken if it's not > reverted to not having a default/cancel registered? (what a horrible > sentence, sry ;) > > Hmm .. > > > > From arapte at openjdk.java.net Thu Mar 26 12:01:31 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 26 Mar 2020 12:01:31 GMT Subject: RFR: 8240539: Upgrade gradle to version 6.3 In-Reply-To: References: Message-ID: On Wed, 25 Mar 2020 21:20:37 GMT, Kevin Rushforth wrote: > This upgrades the version of gradle used to build JavaFX to 6.3. The minimum version of gradle is not changed by the > proposed fix, and remains at 5.3. > I have run done a full build and test with gradle 6.3 on all three platforms. There are no new failures. > > This will enable building JavaFX using JDK 14 as the boot JDK, although upgrading the boot JDK for our builds will be > done in a separate pull request. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/151 From kevin.rushforth at oracle.com Thu Mar 26 12:08:28 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Mar 2020 12:08:28 +0000 (UTC) Subject: WeakXXListener - when not to use? In-Reply-To: References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> <20200326125232.Horde.maFt83PDf6RYO43UMwAVhA7@webmail.df.eu> Message-ID: Yes, that's another good point about weak listeners, although in practice it might not be much of a problem unless the listener is doing something that is no longer valid (or computationally expensive, but that is less likely). Another problem is that using weak listeners can let you avoid thinking about the life cycle of the object and the listener. In cases where there is a good point to explicitly free the listener, it is often better to do so. In most of the cases of skins, it's probably OK to remove the listener as long as there is no functional problem with the listener disappearing some unknowable amount of time after the object in question goes away. > if not doing that "doSomethingUseful" would cause a - more - terrible > misbehavior than a memory leak, would that mean that the > listening/update implementation in that specific case would have to be > re-thought? F.i. in the case of the ButtonSkin listening to control's > scene is changing global state which might be broken if it's not > reverted to not having a default/cancel registered? (what a horrible > sentence, sry ;) Yes, something like that is what I meant. And the rethinking might lead to a need for an explicit removal of the listener at the "right time", or adding additional cleanup logic when the skin goes away. -- Kevin On 3/26/2020 4:58 AM, Nir Lisker wrote: > BTW, Tomas Mikula wrote about this on > http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html > . > There is a comment at the end that is worth a read too. > > > On Thu, Mar 26, 2020 at 1:53 PM Jeanette Winzenburg > wrote: > >> Zitat von Kevin Rushforth : >> >> Thanks for your input! >> >> Glad we didn't miss the "minimum bar" height - with the java doc being >> really clear on that :) >> >> What I still don't quite get is the concern about "too early" and "not >> cleaning up" - maybe I misunderstand the point entirely >> >>> As for whether the above is sufficient, it depends on what the >>> listener does (what its purpose is).In this simple example, it seems >>> unlikely that removing the listener when the instance of SomeClass >>> goes out of scope will cause any problems. It's worth looking at >>> what "doSomethingUseful" does to see if unregisters anything that >>> ought to be unregistered (and now maybe won't be if the listener >>> goes away early). >>> >> if not doing that "doSomethingUseful" would cause a - more - terrible >> misbehavior than a memory leak, would that mean that the >> listening/update implementation in that specific case would have to be >> re-thought? F.i. in the case of the ButtonSkin listening to control's >> scene is changing global state which might be broken if it's not >> reverted to not having a default/cancel registered? (what a horrible >> sentence, sry ;) >> >> Hmm .. >> >> >> >> From kcr at openjdk.java.net Thu Mar 26 12:27:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Mar 2020 12:27:29 GMT Subject: RFR: 8241455: ChoiceBox - memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 11:37:06 GMT, Jeanette Winzenburg wrote: >> @arapte @aghaisas - Can you both review this? > > I would like to widen the issue (and change this pull request accordingly) to include memory leaks of introduced > selection- and focusModels in other controls that are caused by the basically same reason, that is strong references > via listeners to controls' properties. The fix would be the same as well, that is wrap the listeners into > weakXXListeners and register these. The models suggested to include here: > - TreeView: selection- and focusModel > - TreeTableView: focusModel > - TabPane: selectionModel > > Not included would be memory leaks introduced by whacky listening of ChoiceBoxSkin and TabPaneSkin to properties of the > selectionModel. The former will (most probably) be fixed as a side-effect of > https://bugs.openjdk.java.net/browse/JDK-8087555 (which I intend to take, if Ajit agrees :), will open a separate issue > for the latter. The extended fix here will have tests for replacing selection/focusModels with/out a skin registered > for all controls having the respective models. Not entirely certain about the formal procedure (locally fix and tests > are - nearly, pending some cleanup - ready). Simply change titles, rebase and push again? If Ambarish and Ajit are OK with this, then the procedure would be as you guessed: change the title of both the JBS bug and then this PR and push your new fix (with or without rebasing would be fine). ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Thu Mar 26 12:35:58 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 26 Mar 2020 12:35:58 GMT Subject: RFR: 8241455: ChoiceBox - memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 12:25:14 GMT, Kevin Rushforth wrote: >> I would like to widen the issue (and change this pull request accordingly) to include memory leaks of introduced >> selection- and focusModels in other controls that are caused by the basically same reason, that is strong references >> via listeners to controls' properties. The fix would be the same as well, that is wrap the listeners into >> weakXXListeners and register these. The models suggested to include here: >> - TreeView: selection- and focusModel >> - TreeTableView: focusModel >> - TabPane: selectionModel >> >> Not included would be memory leaks introduced by whacky listening of ChoiceBoxSkin and TabPaneSkin to properties of the >> selectionModel. The former will (most probably) be fixed as a side-effect of >> https://bugs.openjdk.java.net/browse/JDK-8087555 (which I intend to take, if Ajit agrees :), will open a separate issue >> for the latter. The extended fix here will have tests for replacing selection/focusModels with/out a skin registered >> for all controls having the respective models. Not entirely certain about the formal procedure (locally fix and tests >> are - nearly, pending some cleanup - ready). Simply change titles, rebase and push again? > > If Ambarish and Ajit are OK with this, then the procedure would be as you guessed: change the title of both the JBS bug > and then this PR and push your new fix (with or without rebasing would be fine). That is good idea to combine all similarly affected selection models. I think rebase won't be required just updating the PR with more commits should be good enough. ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From kcr at openjdk.java.net Thu Mar 26 12:53:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Mar 2020 12:53:07 GMT Subject: RFR: 8240262: iOS refresh rate is capped to 30 Hz In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 08:25:11 GMT, Johan Vos wrote: >> There is a hardcoded limit to refresh the glass view on iOS at a half rate of the native refresh rate. >> >> This PR removes that limit. >> >> Since the default value for `frameInterval ` is 1 (which implies refreshing at the same rate as allowed by the device), >> doing `setFrameInterval:1` is not necessary. What's more, this method is >> [deprecated](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1621231-frameinterval?language=objc). > > The only thing that worries me is that I don't see a reason why this limitation was added originally. > I don't see a reason to keep it, so +1 on removing it. Btw, the jcheck failure is because JBS is down. This revealed a bug in the Skara jcheck bot where it doesn't handle it gracefully (so considers it a failure). As soon as JBS is back up or the Skara bot is fixed, this will proceed. ------------- PR: https://git.openjdk.java.net/jfx/pull/130 From ebresie at gmail.com Thu Mar 26 13:01:11 2020 From: ebresie at gmail.com (Eric Bresie) Date: Thu, 26 Mar 2020 08:01:11 -0500 Subject: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: BN8PR21MB12813A47F499CBF86A0274CD9BFF0@BN8PR21MB1281.namprd21.prod.outlook.com References: E56C7B59-4735-4D13-B0B9-F4A56B182DCF@screamingfrog.co.uk BN8PR21MB12811B12B089749381AB2D1C9BE40@BN8PR21MB1281.namprd21.prod.outlook.com 03DF5DCD-BE78-43E1-9F79-2828B847BE4D@screamingfrog.co.uk BN8PR21MB1281BDAEAEDC896BA9DF82A29BE30@BN8PR21MB1281.namprd21.prod.outlook.com BN8PR21MB1281BDAEAEDC896BA9DF82A29BE30@BN8PR21MB1281.namprd21.prod.outlook.com Message-ID: Not sure if this is the cause of some of this but... I see some similar flags like needsRecreateCells and needsRebuildCells. In one context (around line 1025) I see a recreateOrRebuild flag based on the two. Is it possible something similar is needed around here to only do something once if either is set? Maybe it?s doing the reset twice as part of recreate and rebuild. Eric Bresie Ebresie at gmail.com > On March 10, 2020 at 11:48:27 AM CDT, David Grieve wrote: > The flickering is happening because of the way VirtualFlow reuses cells. The selected state gets cleared and reset, which is the flicker. > This change fixed the flickering for me. I'm not sure why the index of a cell was being set to -1, but the effect of doing so is that when the > cell is pulled out of the pile, it looks like a new cell that has to have its index set, selected state set, etc, etc. By commenting out the > updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected state, etc turns into noops (more or less). > > Again, there may have been a good reason for setting index to -1 in this condition. More investigation needs to be done. > > diff --git a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > index 728e7c5513..a58859bd05 100644 > --- a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > +++ b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > @@ -991,9 +991,9 @@ public class VirtualFlow extends Region { > lastWidth = -1; > lastHeight = -1; > releaseCell(accumCell); > - for (int i = 0, max = cells.size(); i < max; i++) { > - cells.get(i).updateIndex(-1); > - } > +// for (int i = 0, max = cells.size(); i < max; i++) { > +// cells.get(i).updateIndex(-1); > +// } > addAllToPile(); > releaseAllPrivateCells(); > } else if (needsReconfigureCells) { > > > -----Original Message----- > > From: openjfx-dev On Behalf Of > > David Grieve > > Sent: Friday, March 6, 2020 9:29 AM > > To: Danny Gonzalez > > Cc: openjfx-dev at openjdk.java.net > > Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to > > TableView > > > > This might fix the issue, but I?d like to understand better what the root of the > > problem is. My concern is that this fix might cause a performance regression. > > I?m using the code in JDK-8177945. I want to look at what TableView does > > when it adds a cell. Is there something about the selected state that > > changes? Or is this just the CSS implementation recalculating styles and un- > > necessarily clearing old values? Some debugging is in order. > > > > From: Danny Gonzalez > > Sent: Wednesday, March 4, 2020 4:34 AM > > To: David Grieve > > Cc: openjfx-dev at openjdk.java.net > > Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when > > adding data to TableView > > > > Hi David, > > > > Just wanted to add some more information. > > > > The cell selection flashing issue goes away If I put back the following code in > > the layout function in Parent.java: > > > > // > > // One idiom employed by developers is to, during the layout pass, > > // add or remove nodes from the scene. For example, a ScrollPane > > // might add scroll bars to itself if it determines during layout > > // that it needs them, or a ListView might add cells to itself if > > // it determines that it needs to. In such situations we must > > // apply the CSS immediately and not add it to the scene's queue > > // for deferred action. > > // > > // Note that we only call processCSS if the flag is update. If the > > // flag is DIRTY_BRANCH, then the whatever children need UPDATE > > // will be visited during this layout anyway. On the next pulse, > > // doCSSPass will clean up the DIRTY_BRANCH nodes. > > // > > if (cssFlag == CssFlags.UPDATE) { > > processCSS(); > > } > > > > This code was originally added in in the following commit: > > > > commit e76b5755d4d2752037cc95eb75cb2615a740cc30 > > Author: David Grieve > > > > > Date: Thu Apr 10 15:40:34 2014 -0400 (tel:34%202014%20-0400) > > > > RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply > > css to child nodes if nothing has changed. 2 - on applyCss, only look for > > ancestor node with css state = UPDATE. 3 - only recalculate checksum of css > > file if the file has been removed from a scene or parent > > > > > > It was reverted out in this commit: > > > > commit 05afad6b528e871d607b76aea2642cf788b417fe > > Author: David Grieve > > > > > Date: Tue Apr 15 11:51:38 2014 -0400 (tel:38%202014%20-0400) > > > > RT-36672: move code to process css during layout back to impl_reapplyCSS, > > which is where it was priort to RT-36559 > > > > > > > > > > This was the point at which the cell selection flashing appeared. > > > > > > Thanks > > > > > > Danny > > > > > > > > On 3 Mar 2020, at 16:50, David Grieve > > > > > wrote: > > > > The importance of 05afad6 Is there in the commit itself: > > > > + // > > + // One idiom employed by developers is to, during the layout pass, > > + // add or remove nodes from the scene. For example, a ScrollPane > > + // might add scroll bars to itself if it determines during layout > > + // that it needs them, or a ListView might add cells to itself if > > + // it determines that it needs to. In such situations we must > > + // apply the CSS immediately and not add it to the scene's queue > > + // for deferred action. > > + > > > > If you revert 05afad6, you'll break this. > > > > This is the first time I've become aware of this flickering issue. I'll have to look > > at it. > > I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK- > > 8193445 > F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK- > > 8193445&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C9148c860ff5 > > 24a32ac3208d7c01f2523%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > > 7C637189112753556661&sdata=mZrjldSw%2Fjbd0ita58XMU%2BaKM2GlvObq > > 3aaQmQb5Poc%3D&reserved=0> has any impact on this. > > > > > > -----Original Message----- > > From: openjfx-dev > bounces at openjdk.java.net > bounces at openjdk.java.net>> On Behalf Of Danny Gonzalez > > Sent: Tuesday, March 3, 2020 11:14 AM > > To: openjfx-dev at openjdk.java.net > > Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding > > data to TableView > > > > > > There is currently an open bug to do with the issue of selection flickering > > when using single cell selection and when adding data to a TableView. > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > > .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da > > ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 > > d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 > > 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb > > 8AwcRXVrfLo%3D&reserved=0 > > > > This bug seems to be low priority because it hasn?t been looked at since I > > submitted it at the start of 2017. > > > > This is quite a major issue for us so I have narrowed down when the issue > > was first introduced. > > > > Here is the changeset: > > > > commit 05afad6b528e871d607b76aea2642cf788b417fe > > Author: David Grieve > > > jdk.org%3cmailto:dgrieve at openjdk.org>>> > > Date: Tue Apr 15 11:51:38 2014 -0400 (tel:38%202014%20-0400) > > > > RT-36672: move code to process css during layout back to impl_reapplyCSS, > > which is where it was priort to RT-36559 > > > > > > I can?t search the bug database for this bug ID as I believe it was submitted > > when a previous bug tracking system was in use. > > > > Does anyone have any knowledge as to why this fix was needed and what > > the repercussions would be if I reverted it out for our local OpenJFX build. > > > > Alternatively I would be glad to receive any suggestions of how to fix the > > flickering issue if this changeset is important to leave in. > > > > Thanks > > > > Danny > From debayansutradhar3 at gmail.com Thu Mar 26 11:33:51 2020 From: debayansutradhar3 at gmail.com (Debayan Sutradhar) Date: Thu, 26 Mar 2020 17:03:51 +0530 Subject: OpenJFX >11 exclusive RuntimeException on Embedded Message-ID: <5e7cb0d8.1c69fb81.d542d.6869@mx.google.com> From fastegal at swingempire.de Thu Mar 26 13:58:09 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 26 Mar 2020 14:58:09 +0100 Subject: WeakXXListener - when not to use? In-Reply-To: References: Message-ID: <20200326145809.Horde._Fi2m4TJKt5Z1F434u0hZw1@webmail.df.eu> switching skins definitely is a valid use-case, and not that rare :) There's an umbrella issue to look into all skins that might (or not) leave a memory leak around after dispose: https://bugs.openjdk.java.net/browse/JDK-8241364 -- Jeanette Zitat von Pedro Duque Vieira : > Hi guys, > > Sorry to barge in on the conversation but I think I have some comments that > might add to the conversation. > > Sometime ago someone reported this bug in the JMetro issue tracker: > https://github.com/JFXtras/jfxtras-styles/issues/144 (it's a hobby project, > a JavaFX theme, I've been working on, on my spare time) > > To summarize: they want to allow the user to be able to change themes while > the JavaFX app is running which will end up changing control skins on the > process. I think it's a valid scenario. > > What I've found that is that the JavaFX Skins of some controls don't > release the listeners, in this case TextFieldSkin when the skin of the > corresponding control gets switched. Same for ProgressBarSkin it seems. I > think in the dispose method of both skins the listeners that were added in > the skins should be removed? > So the old skin listeners end up being called, when they shouldn't because > the skin of the Control is now another object. This ends up in an Exception > being thrown in those listeners. > > I think the reporter of the issue ended up registering an issue with this > in the JavaFX issue tracker. > > Thanks. Which this adds something to the conversation. > > Best regards, > > -- > Pedro Duque Vieira - https://www.pixelduke.com From fastegal at swingempire.de Thu Mar 26 13:59:02 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 26 Mar 2020 14:59:02 +0100 Subject: WeakXXListener - when not to use? In-Reply-To: References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> <20200326125232.Horde.maFt83PDf6RYO43UMwAVhA7@webmail.df.eu> Message-ID: <20200326145902.Horde.XU7AFlvZPn88v95g7N_z2Q1@webmail.df.eu> Zitat von Nir Lisker : > BTW, Tomas Mikula wrote about this on > http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html > . > There is a comment at the end that is worth a read too. > > thanks for the reference, thought I had seen something like that but couldn't find it :) > On Thu, Mar 26, 2020 at 1:53 PM Jeanette Winzenburg > wrote: > >> >> Zitat von Kevin Rushforth : >> >> Thanks for your input! >> >> Glad we didn't miss the "minimum bar" height - with the java doc being >> really clear on that :) >> >> What I still don't quite get is the concern about "too early" and "not >> cleaning up" - maybe I misunderstand the point entirely >> >> > >> > As for whether the above is sufficient, it depends on what the >> > listener does (what its purpose is).In this simple example, it seems >> > unlikely that removing the listener when the instance of SomeClass >> > goes out of scope will cause any problems. It's worth looking at >> > what "doSomethingUseful" does to see if unregisters anything that >> > ought to be unregistered (and now maybe won't be if the listener >> > goes away early). >> > >> >> if not doing that "doSomethingUseful" would cause a - more - terrible >> misbehavior than a memory leak, would that mean that the >> listening/update implementation in that specific case would have to be >> re-thought? F.i. in the case of the ButtonSkin listening to control's >> scene is changing global state which might be broken if it's not >> reverted to not having a default/cancel registered? (what a horrible >> sentence, sry ;) >> >> Hmm .. >> >> >> >> From fastegal at swingempire.de Thu Mar 26 14:07:58 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 26 Mar 2020 15:07:58 +0100 Subject: WeakXXListener - when not to use? In-Reply-To: References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> <20200326125232.Horde.maFt83PDf6RYO43UMwAVhA7@webmail.df.eu> Message-ID: <20200326150758.Horde.iMypg0ddAZSzS8zZKRnCjw1@webmail.df.eu> good points, going into thinking :) Maybe we can come up with a pattern (and its anti-pattern) about how to use them correctly, now that we are looking more closely (and are in the process of learning - me at least :) If we could collect the does and donts somewhere, it would be easier for contributors to do the-right-thing and watch out for the-wrong-thing. Thanks! Zitat von Kevin Rushforth : > Yes, that's another good point about weak listeners, although in > practice it might not be much of a problem unless the listener is > doing something that is no longer valid (or computationally > expensive, but that is less likely). > > Another problem is that using weak listeners can let you avoid > thinking about the life cycle of the object and the listener. In > cases where there is a good point to explicitly free the listener, > it is often better to do so. > > In most of the cases of skins, it's probably OK to remove the > listener as long as there is no functional problem with the listener > disappearing some unknowable amount of time after the object in > question goes away. > >> if not doing that "doSomethingUseful" would cause a - more - terrible >> misbehavior than a memory leak, would that mean that the >> listening/update implementation in that specific case would have to be >> re-thought? F.i. in the case of the ButtonSkin listening to control's >> scene is changing global state which might be broken if it's not >> reverted to not having a default/cancel registered? (what a horrible >> sentence, sry ;) > > Yes, something like that is what I meant. And the rethinking might > lead to a need for an explicit removal of the listener at the "right > time", or adding additional cleanup logic when the skin goes away. > > -- Kevin > > > On 3/26/2020 4:58 AM, Nir Lisker wrote: >> BTW, Tomas Mikula wrote about this on >> http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html >> . >> There is a comment at the end that is worth a read too. >> >> >> On Thu, Mar 26, 2020 at 1:53 PM Jeanette Winzenburg >> >> wrote: >> >>> Zitat von Kevin Rushforth : >>> >>> Thanks for your input! >>> >>> Glad we didn't miss the "minimum bar" height - with the java doc being >>> really clear on that :) >>> >>> What I still don't quite get is the concern about "too early" and "not >>> cleaning up" - maybe I misunderstand the point entirely >>> >>>> As for whether the above is sufficient, it depends on what the >>>> listener does (what its purpose is).In this simple example, it seems >>>> unlikely that removing the listener when the instance of SomeClass >>>> goes out of scope will cause any problems. It's worth looking at >>>> what "doSomethingUseful" does to see if unregisters anything that >>>> ought to be unregistered (and now maybe won't be if the listener >>>> goes away early). >>>> >>> if not doing that "doSomethingUseful" would cause a - more - terrible >>> misbehavior than a memory leak, would that mean that the >>> listening/update implementation in that specific case would have to be >>> re-thought? F.i. in the case of the ButtonSkin listening to control's >>> scene is changing global state which might be broken if it's not >>> reverted to not having a default/cancel registered? (what a horrible >>> sentence, sry ;) >>> >>> Hmm .. >>> >>> >>> >>> From arapte at openjdk.java.net Thu Mar 26 18:11:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 26 Mar 2020 18:11:48 GMT Subject: [Rev 01] RFR: 8089828: RTL Orientation, the flag of a mnemonic is not placed under the mnemonic letter. In-Reply-To: <4tHlHIh6GKPwga4fon7fmrnUz6aqRtBmZ0gU6wG9N7k=.5842bc3a-bf84-4034-8d34-554fdebc0aea@github.com> References: <4tHlHIh6GKPwga4fon7fmrnUz6aqRtBmZ0gU6wG9N7k=.5842bc3a-bf84-4034-8d34-554fdebc0aea@github.com> Message-ID: On Thu, 26 Mar 2020 06:25:55 GMT, Ajit Ghaisas wrote: >> **Bug :** >> https://bugs.openjdk.java.net/browse/JDK-8089828 >> >> **Root Cause :** >> RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position calculation. >> >> **Fix :** >> Corrected code to consider RIGHT_TO_LEFT NodeOrientation while calculating mnemonic position. >> >> **Testing :** >> Existing manual test is modified to test RTL buttons as well. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > fix file header comment Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/146 From kcr at openjdk.java.net Thu Mar 26 18:53:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Mar 2020 18:53:18 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK Message-ID: Now that we have switched to using gradle 6.3 we can switch to using JDK 14 as the boot JDK for JavaFX 15 builds. This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to generate class files using `-source 11 -target 11`. ------------- Commit messages: - 8240542: Switch FX build to use JDK 14 as boot JDK Changes: https://git.openjdk.java.net/jfx/pull/152/files Webrev: https://webrevs.openjdk.java.net/jfx/152/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240542 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/152.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/152/head:pull/152 PR: https://git.openjdk.java.net/jfx/pull/152 From kcr at openjdk.java.net Thu Mar 26 18:53:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Mar 2020 18:53:18 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 18:46:15 GMT, Kevin Rushforth wrote: > Now that we have switched to using gradle 6.3 we can switch to using JDK 14 as the boot JDK for JavaFX 15 builds. > > This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to > generate class files using `-source 11 -target 11`. @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/152 From kcr at openjdk.java.net Thu Mar 26 19:52:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Mar 2020 19:52:17 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK In-Reply-To: References: Message-ID: <1qbX8_J1bsV47C_Mnyqn8_pWLPFNMtgoJ2PtMG3IVkY=.31d858ae-ba99-48f7-be91-808b93258dba@github.com> On Thu, 26 Mar 2020 18:47:58 GMT, Kevin Rushforth wrote: >> Now that we have switched to using gradle 6.3 we can switch to using JDK 14 as the boot JDK for JavaFX 15 builds. >> >> This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to >> generate class files using `-source 11 -target 11`. > > @arapte can you also review this? @tiainen can you also take a look? ------------- PR: https://git.openjdk.java.net/jfx/pull/152 From David.Grieve at microsoft.com Thu Mar 26 22:07:31 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Thu, 26 Mar 2020 22:07:31 +0000 Subject: [EXTERNAL] Re: RE: JDK-8177945 : Single cell selection flickers when adding data to TableView In-Reply-To: References: E56C7B59-4735-4D13-B0B9-F4A56B182DCF@screamingfrog.co.uk BN8PR21MB12811B12B089749381AB2D1C9BE40@BN8PR21MB1281.namprd21.prod.outlook.com 03DF5DCD-BE78-43E1-9F79-2828B847BE4D@screamingfrog.co.uk BN8PR21MB1281BDAEAEDC896BA9DF82A29BE30@BN8PR21MB1281.namprd21.prod.outlook.com BN8PR21MB1281BDAEAEDC896BA9DF82A29BE30@BN8PR21MB1281.namprd21.prod.outlook.com Message-ID: That?s possible. I think that?s in the ballpark, at least. If we could somehow set the cell state before it gets added back into the scenegraph, then the cell would be rendered correctly from the start, rather than having its state updated halfway through the layout. I haven?t had time to circle back on this, but I was looking at and around javafx.scene.control.Cell#updateItem and javafx.scene.control.Cell#updateSelected From: Eric Bresie Sent: Thursday, March 26, 2020 9:01 AM To: David Grieve Cc: Danny Gonzalez ; openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Re: RE: JDK-8177945 : Single cell selection flickers when adding data to TableView Not sure if this is the cause of some of this but... I see some similar flags like needsRecreateCells and needsRebuildCells. In one context (around line 1025) I see a recreateOrRebuild flag based on the two. Is it possible something similar is needed around here to only do something once if either is set? Maybe it?s doing the reset twice as part of recreate and rebuild. Eric Bresie Ebresie at gmail.com On March 10, 2020 at 11:48:27 AM CDT, David Grieve > wrote: The flickering is happening because of the way VirtualFlow reuses cells. The selected state gets cleared and reset, which is the flicker. This change fixed the flickering for me. I'm not sure why the index of a cell was being set to -1, but the effect of doing so is that when the cell is pulled out of the pile, it looks like a new cell that has to have its index set, selected state set, etc, etc. By commenting out the updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected state, etc turns into noops (more or less). Again, there may have been a good reason for setting index to -1 in this condition. More investigation needs to be done. diff --git a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java index 728e7c5513..a58859bd05 100644 --- a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java +++ b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java @@ -991,9 +991,9 @@ public class VirtualFlow extends Region { lastWidth = -1; lastHeight = -1; releaseCell(accumCell); - for (int i = 0, max = cells.size(); i < max; i++) { - cells.get(i).updateIndex(-1); - } +// for (int i = 0, max = cells.size(); i < max; i++) { +// cells.get(i).updateIndex(-1); +// } addAllToPile(); releaseAllPrivateCells(); } else if (needsReconfigureCells) { -----Original Message----- From: openjfx-dev > On Behalf Of David Grieve Sent: Friday, March 6, 2020 9:29 AM To: Danny Gonzalez > Cc: openjfx-dev at openjdk.java.net Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to TableView This might fix the issue, but I?d like to understand better what the root of the problem is. My concern is that this fix might cause a performance regression. I?m using the code in JDK-8177945. I want to look at what TableView does when it adds a cell. Is there something about the selected state that changes? Or is this just the CSS implementation recalculating styles and un- necessarily clearing old values? Some debugging is in order. From: Danny Gonzalez > Sent: Wednesday, March 4, 2020 4:34 AM To: David Grieve > Cc: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when adding data to TableView Hi David, Just wanted to add some more information. The cell selection flashing issue goes away If I put back the following code in the layout function in Parent.java: // // One idiom employed by developers is to, during the layout pass, // add or remove nodes from the scene. For example, a ScrollPane // might add scroll bars to itself if it determines during layout // that it needs them, or a ListView might add cells to itself if // it determines that it needs to. In such situations we must // apply the CSS immediately and not add it to the scene's queue // for deferred action. // // Note that we only call processCSS if the flag is update. If the // flag is DIRTY_BRANCH, then the whatever children need UPDATE // will be visited during this layout anyway. On the next pulse, // doCSSPass will clean up the DIRTY_BRANCH nodes. // if (cssFlag == CssFlags.UPDATE) { processCSS(); } This code was originally added in in the following commit: commit e76b5755d4d2752037cc95eb75cb2615a740cc30 Author: David Grieve >> Date: Thu Apr 10 15:40:34 2014 -0400 RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply css to child nodes if nothing has changed. 2 - on applyCss, only look for ancestor node with css state = UPDATE. 3 - only recalculate checksum of css file if the file has been removed from a scene or parent It was reverted out in this commit: commit 05afad6b528e871d607b76aea2642cf788b417fe Author: David Grieve >> Date: Tue Apr 15 11:51:38 2014 -0400 RT-36672: move code to process css during layout back to impl_reapplyCSS, which is where it was priort to RT-36559 This was the point at which the cell selection flashing appeared. Thanks Danny On 3 Mar 2020, at 16:50, David Grieve >> wrote: The importance of 05afad6 Is there in the commit itself: + // + // One idiom employed by developers is to, during the layout pass, + // add or remove nodes from the scene. For example, a ScrollPane + // might add scroll bars to itself if it determines during layout + // that it needs them, or a ListView might add cells to itself if + // it determines that it needs to. In such situations we must + // apply the CSS immediately and not add it to the scene's queue + // for deferred action. + If you revert 05afad6, you'll break this. This is the first time I've become aware of this flickering issue. I'll have to look at it. I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK- 8193445> has any impact on this. -----Original Message----- From: openjfx-dev bounces at openjdk.java.net>> On Behalf Of Danny Gonzalez Sent: Tuesday, March 3, 2020 11:14 AM To: openjfx-dev at openjdk.java.net> Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding data to TableView There is currently an open bug to do with the issue of selection flickering when using single cell selection and when adding data to a TableView. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945&da ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008 d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848 9816399816&sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb 8AwcRXVrfLo%3D&reserved=0 This bug seems to be low priority because it hasn?t been looked at since I submitted it at the start of 2017. This is quite a major issue for us so I have narrowed down when the issue was first introduced. Here is the changeset: commit 05afad6b528e871d607b76aea2642cf788b417fe Author: David Grieve >>> Date: Tue Apr 15 11:51:38 2014 -0400 RT-36672: move code to process css during layout back to impl_reapplyCSS, which is where it was priort to RT-36559 I can?t search the bug database for this bug ID as I believe it was submitted when a previous bug tracking system was in use. Does anyone have any knowledge as to why this fix was needed and what the repercussions would be if I reverted it out for our local OpenJFX build. Alternatively I would be glad to receive any suggestions of how to fix the flickering issue if this changeset is important to leave in. Thanks Danny From github.com+4688201+tiainen at openjdk.java.net Thu Mar 26 22:12:28 2020 From: github.com+4688201+tiainen at openjdk.java.net (Joeri Sykora) Date: Thu, 26 Mar 2020 22:12:28 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK In-Reply-To: <1qbX8_J1bsV47C_Mnyqn8_pWLPFNMtgoJ2PtMG3IVkY=.31d858ae-ba99-48f7-be91-808b93258dba@github.com> References: <1qbX8_J1bsV47C_Mnyqn8_pWLPFNMtgoJ2PtMG3IVkY=.31d858ae-ba99-48f7-be91-808b93258dba@github.com> Message-ID: On Thu, 26 Mar 2020 19:50:05 GMT, Kevin Rushforth wrote: >> @arapte can you also review this? > > @tiainen can you also take a look? Looks ok to me. All our jenkins jobs ran successfully using JDK 14. ------------- PR: https://git.openjdk.java.net/jfx/pull/152 From aghaisas at openjdk.java.net Fri Mar 27 05:02:58 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 27 Mar 2020 05:02:58 GMT Subject: RFR: 8241455: ChoiceBox - memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 11:37:06 GMT, Jeanette Winzenburg wrote: > > Not included would be memory leaks introduced by whacky listening of ChoiceBoxSkin and TabPaneSkin to properties of the > selectionModel. The former will (most probably) be fixed as a side-effect of > https://bugs.openjdk.java.net/browse/JDK-8087555 (which I intend to take, if Ajit agrees :), will open a separate issue > for the latter. Please go ahead and take it up. Thanks! Regarding combining other issue. I am OK with the idea. Bug Title, Bug Description and PR Title should be updated accordingly. ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From fastegal at openjdk.java.net Fri Mar 27 11:46:30 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 27 Mar 2020 11:46:30 GMT Subject: [Rev 01] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: > ChoiceBox leaves a memory leak when replacing the selectionModel. Culprit is ChoiceBoxSelectionModel which registers > listener with strong references. Fix is to change these to weak references. > Added test that fails before and passes after the test. > > for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: widened issue/fix/test for all controls with selection/focus models ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/148/files - new: https://git.openjdk.java.net/jfx/pull/148/files/56d16954..d2918fb5 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/148/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/148/webrev.00-01 Stats: 358 lines in 5 files changed: 312 ins; 34 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/148.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/148/head:pull/148 PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Fri Mar 27 12:15:10 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 27 Mar 2020 12:15:10 GMT Subject: RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Mon, 23 Mar 2020 23:40:39 GMT, Kevin Rushforth wrote: > > > Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up > after itself. I'm not suggesting that's the case here, but it is worth looking at. The listener does not get early GCed here. I did verify this by creating large number of `ButtonSkin`s. The latest `ButtonSkin` set on the `Button` is never GCed > > >The one thing I would ask you to take a look at is whether it would matter if the old skin didn't call >`setDefaultButton(oldScene, false)` when removed (and similarly `setCancelButton`). This seems to be a bigger issue. If we create multiple `ButtonSkin`s for a given `Button`, then all the `ButtonSkin` register listeners with the properties of that `Button`. And it results in various listeners being added to same property of the `Button`. and this should be a common issue across all skins. ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From fastegal at swingempire.de Fri Mar 27 15:03:39 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 27 Mar 2020 16:03:39 +0100 Subject: WeakXXListener - when not to use? In-Reply-To: References: <20200325111324.Horde.0jyO5LK5Oyx2TYTPQRcpXw1@webmail.df.eu> <251e5576-d698-2705-db11-caaa2f0be99d@oracle.com> <20200326125232.Horde.maFt83PDf6RYO43UMwAVhA7@webmail.df.eu> Message-ID: <20200327160339.Horde.p-BCB8UvZNS-vKImc_XXBQ1@webmail.df.eu> Zitat von Nir Lisker : > BTW, Tomas Mikula wrote about this on > http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html > . > There is a comment at the end that is worth a read too. also interesting is the old (closed as wontfix) bug https://bugs.openjdk.java.net/browse/JDK-8095375 - it's about a very long lived observable (f.i. one holding the current Locale, which hardly ever changes but might) to which all nodes are listening with WeakListeners. Those listeners hang around until the value actually changes - at which time it might be too late to really do any cleanup (either directly throwing a overflow or make the ui unresponsive). Always thought that the weakListeners are removed from two ends (provided their weakRef is reclaimed): 1. from the listener itself when being notified: it removes itself from the observable if ref is null 2. from the observable itself via its ExpressionHelper which has a trim method that's called on addListener: it seems to throw away all garbage collected weak listeners 1 is ineffective without change notification, and 2 seems to rarely be effective: it's only ever called when the current size of the listeners is exactly its capacity .. which in the example of the bug is after it's too late. Just musing (didn't test anything) - maybe this is part of the very bad performance of table scrolling (see https://github.com/openjdk/jfx/pull/108) and maybe it is worth improving, after all :) From jvos at openjdk.java.net Fri Mar 27 17:12:19 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 27 Mar 2020 17:12:19 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK In-Reply-To: References: Message-ID: <9wi_4if_KGXVM0HbWRTX3FZHNanytzpDl7IX02LUw2Q=.c946377c-fe53-4597-b4ce-a66365b74f63@github.com> On Thu, 26 Mar 2020 18:46:15 GMT, Kevin Rushforth wrote: > Now that we have switched to using gradle 6.3 we can switch to using JDK 14 as the boot JDK for JavaFX 15 builds. > > This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to > generate class files using `-source 11 -target 11`. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/152 From nlisker at openjdk.java.net Fri Mar 27 21:19:20 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 27 Mar 2020 21:19:20 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK In-Reply-To: <9wi_4if_KGXVM0HbWRTX3FZHNanytzpDl7IX02LUw2Q=.c946377c-fe53-4597-b4ce-a66365b74f63@github.com> References: <9wi_4if_KGXVM0HbWRTX3FZHNanytzpDl7IX02LUw2Q=.c946377c-fe53-4597-b4ce-a66365b74f63@github.com> Message-ID: On Fri, 27 Mar 2020 17:10:09 GMT, Johan Vos wrote: >> Now that we have switched to using gradle 6.3 we can switch to using JDK 14 as the boot JDK for JavaFX 15 builds. >> >> This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to >> generate class files using `-source 11 -target 11`. > > Marked as reviewed by jvos (Reviewer). > We will continue to generate class files using `-source 11 -target 11` Isn't `-release 11` the preferred way? ------------- PR: https://git.openjdk.java.net/jfx/pull/152 From kcr at openjdk.java.net Fri Mar 27 21:36:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 Mar 2020 21:36:29 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK In-Reply-To: References: <9wi_4if_KGXVM0HbWRTX3FZHNanytzpDl7IX02LUw2Q=.c946377c-fe53-4597-b4ce-a66365b74f63@github.com> Message-ID: <7qXXDOUQlWFxobDWj6y-X8ikPGEAmGr_70MaYvzLsLY=.edc8f3c6-9600-4b8e-97eb-a26b1af9217b@github.com> On Fri, 27 Mar 2020 21:17:04 GMT, Nir Lisker wrote: >> Marked as reviewed by jvos (Reviewer). > >> We will continue to generate class files using `-source 11 -target 11` > > Isn't `-release 11` the preferred way? gradle's java plugin translates `sourceCompatibility NN` into `-source NN -target NN`. I haven't looked into whether gradle has a way to use `-release`. In practice, what it means is that we need to be careful not to use newer API from a newer JDK. We could look into changing it if gradle provides that support, but that would be a separate issue, independent from upgrading the boot JDK from 13 to 14. ------------- PR: https://git.openjdk.java.net/jfx/pull/152 From arapte at openjdk.java.net Sat Mar 28 06:42:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 28 Mar 2020 06:42:06 GMT Subject: [Rev 01] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: <7LDkD9pey1uNcKAj6ajx-TbzKdhP6zzrfZUfy_5hwFM=.e7fb5c79-d981-45e1-b440-293057c38259@github.com> > ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when > the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves > the issue. > Please take a look. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Changes for Kevin's review comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/147/files - new: https://git.openjdk.java.net/jfx/pull/147/files/d393e81d..43624547 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/147/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/147/webrev.00-01 Stats: 56 lines in 2 files changed: 52 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/147.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/147/head:pull/147 PR: https://git.openjdk.java.net/jfx/pull/147 From arapte at openjdk.java.net Sat Mar 28 06:42:25 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 28 Mar 2020 06:42:25 GMT Subject: RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Fri, 27 Mar 2020 12:12:30 GMT, Ambarish Rapte wrote: >> In general, there are two approaches to avoiding listener-related memory leaks. One is to use a WeakListener; the other >> is to explicitly remove the listener when the object is removed or otherwise no longer needed. >> Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up >> after itself. I'm not suggesting that's the case here, but it is worth looking at. The one thing I would ask you to >> take a look at is whether it would matter if the old skin didn't call `setDefaultButton(oldScene, false)` when removed >> (and similarly `setCancelButton`). > >> >> >> Using a WeakListener is certainly easier, but runs the risk of the listener being removed too early and not cleaning up >> after itself. I'm not suggesting that's the case here, but it is worth looking at. > > > The listener does not get early GCed here. I did verify this by creating large number of `ButtonSkin`s. The latest > `ButtonSkin` set on the `Button` is never GCed >> >> >>The one thing I would ask you to take a look at is whether it would matter if the old skin didn't call >>`setDefaultButton(oldScene, false)` when removed (and similarly `setCancelButton`). > > > This seems to be a bigger issue. > If we create multiple `ButtonSkin`s for a given `Button`, then all the `ButtonSkin` register listeners with the > properties of that `Button`. And it results in various listeners being added to same property of the `Button`. and this > should be a common issue across all skins. Hi Kevin, Please take a look at the updated changes. Added tests as we discussed and an explicit call to remove the listener. ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From fastegal at openjdk.java.net Sat Mar 28 10:44:01 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 28 Mar 2020 10:44:01 GMT Subject: [Rev 01] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: <7LDkD9pey1uNcKAj6ajx-TbzKdhP6zzrfZUfy_5hwFM=.e7fb5c79-d981-45e1-b440-293057c38259@github.com> References: <7LDkD9pey1uNcKAj6ajx-TbzKdhP6zzrfZUfy_5hwFM=.e7fb5c79-d981-45e1-b440-293057c38259@github.com> Message-ID: On Sat, 28 Mar 2020 06:42:06 GMT, Ambarish Rapte wrote: >> ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when >> the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves >> the issue. >> Please take a look. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Changes for Kevin's review comment Changes requested by fastegal (Author). modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java line 101: > 100: }; > 101: WeakChangeListener weakChangeListener = new WeakChangeListener<>(sceneChangeListener); > 102: a loose naming convention for weak listeners seems to be to prepend _weak_ to the name of the strong listener, which would be WeakChangeListener weakSceneChangeListener = new WeakChangeListener<>(sceneChangeListener); modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java line 178: > 177: @Override public void dispose() { > 178: getSkinnable().sceneProperty().removeListener(weakChangeListener); > 179: super.dispose(); +1! Actually, looks like that manual remove is really needed - otherwise we get an NPE when removing the default button from its parent after the skin has been switched: @Test public void testDefaultButtonSwitchSkinAndRemove() { Button button = new Button(); button.setDefaultButton(true); Group root = new Group(button); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); stage.show(); button.setSkin(new ButtonSkin1(button)); root.getChildren().remove(button); } Note: to see this NPE as failing test (vs. its printout on sysout), we need to re-wire the uncaughtExceptionHandler, see ComboBoxTest setup/cleanup for an example. ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From tsayao at openjdk.java.net Sun Mar 29 00:38:20 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 29 Mar 2020 00:38:20 GMT Subject: [Rev 02] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: > Simple fix to remove annoying warnings. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Sep cppFlags and cFlags ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/150/files - new: https://git.openjdk.java.net/jfx/pull/150/files/3164ab36..67adeaee Webrevs: - full: https://webrevs.openjdk.java.net/jfx/150/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/150/webrev.01-02 Stats: 22 lines in 1 file changed: 3 ins; 2 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/150.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/150/head:pull/150 PR: https://git.openjdk.java.net/jfx/pull/150 From arapte at openjdk.java.net Mon Mar 30 07:21:32 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 30 Mar 2020 07:21:32 GMT Subject: [Rev 02] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: > ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when > the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves > the issue. > Please take a look. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Fix review comment, add test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/147/files - new: https://git.openjdk.java.net/jfx/pull/147/files/43624547..e81f175a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/147/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/147/webrev.01-02 Stats: 27 lines in 2 files changed: 24 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/147.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/147/head:pull/147 PR: https://git.openjdk.java.net/jfx/pull/147 From arapte at openjdk.java.net Mon Mar 30 07:24:35 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 30 Mar 2020 07:24:35 GMT Subject: [Rev 01] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: <7LDkD9pey1uNcKAj6ajx-TbzKdhP6zzrfZUfy_5hwFM=.e7fb5c79-d981-45e1-b440-293057c38259@github.com> Message-ID: On Sat, 28 Mar 2020 10:29:39 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes for Kevin's review comment > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java line 101: > >> 100: }; >> 101: WeakChangeListener weakChangeListener = new WeakChangeListener<>(sceneChangeListener); >> 102: > > a loose naming convention for weak listeners seems to be to prepend _weak_ to the name of the strong listener, which > would be > > WeakChangeListener weakSceneChangeListener = new WeakChangeListener<>(sceneChangeListener); Corrected in the next commit... > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java line 178: > >> 177: @Override public void dispose() { >> 178: getSkinnable().sceneProperty().removeListener(weakChangeListener); >> 179: super.dispose(); > > +1! Actually, looks like that manual remove is really needed - otherwise we get an NPE when removing the default button > from its parent after the skin has been switched: > @Test > public void testDefaultButtonSwitchSkinAndRemove() { > Button button = new Button(); > button.setDefaultButton(true); > Group root = new Group(button); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > stage.show(); > > button.setSkin(new ButtonSkin1(button)); > root.getChildren().remove(button); > } > > Note: to see this NPE as failing test (vs. its printout on sysout), we need to re-wire the uncaughtExceptionHandler, > see ComboBoxTest setup/cleanup for an example. Thanks for the test case, I did minor changes to it and included in the next commit. The NPE can occur even without `button.setDefaultButton(true);`. Please take a look ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From fastegal at openjdk.java.net Mon Mar 30 10:38:23 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 30 Mar 2020 10:38:23 GMT Subject: [Rev 01] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: <7LDkD9pey1uNcKAj6ajx-TbzKdhP6zzrfZUfy_5hwFM=.e7fb5c79-d981-45e1-b440-293057c38259@github.com> Message-ID: On Mon, 30 Mar 2020 07:21:38 GMT, Ambarish Rapte wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonSkin.java line 178: >> >>> 177: @Override public void dispose() { >>> 178: getSkinnable().sceneProperty().removeListener(weakChangeListener); >>> 179: super.dispose(); >> >> +1! Actually, looks like that manual remove is really needed - otherwise we get an NPE when removing the default button >> from its parent after the skin has been switched: >> @Test >> public void testDefaultButtonSwitchSkinAndRemove() { >> Button button = new Button(); >> button.setDefaultButton(true); >> Group root = new Group(button); >> Scene scene = new Scene(root); >> Stage stage = new Stage(); >> stage.setScene(scene); >> stage.show(); >> >> button.setSkin(new ButtonSkin1(button)); >> root.getChildren().remove(button); >> } >> >> Note: to see this NPE as failing test (vs. its printout on sysout), we need to re-wire the uncaughtExceptionHandler, >> see ComboBoxTest setup/cleanup for an example. > > Thanks for the test case, I did minor changes to it and included in the next commit. > The NPE can occur even without `button.setDefaultButton(true);`. > Please take a look good catch! You are right, without explicit removal of the listener, the NPE happens always. Actually, I had been sloppy and got distracted by the NPE from my actual goal which was to dig into Kevin's "not cleaning up after itself" and .. finally found a (concededly extreme corner-case :) where that's happening: when setting the skin to null. Two failing tests: @Test public void testDefaultButtonNullSkinReleased() { Button button = new Button(); button.setDefaultButton(true); Group root = new Group(button); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); stage.show(); WeakReference defSkinRef = new WeakReference<>((ButtonSkin)button.getSkin()); button.setSkin(null); attemptGC(defSkinRef); assertNull("skin must be gc'ed", defSkinRef.get()); } @Test public void testDefaultButtonNullSkinAcceleratorRemoved() { Button button = new Button(); button.setDefaultButton(true); Group root = new Group(button); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); stage.show(); KeyCodeCombination key = new KeyCodeCombination(KeyCode.ENTER); assertNotNull(scene.getAccelerators().get(key)); button.setSkin(null); assertNull(scene.getAccelerators().get(key)); } An explicitly cleanup in dispose makes them pass: @Override public void dispose() { setDefaultButton(false); setCancelButton(false); getSkinnable().sceneProperty().removeListener(weakChangeListener); ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From florian.kirmaier at gmail.com Mon Mar 30 13:41:19 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Mon, 30 Mar 2020 15:41:19 +0200 Subject: RFR: JDK-8241840: Memoryleak: Closed focused Stages are not collected with Monocle Message-ID: Hi everyone, Here is my PR for the memory-leak I've reported some minutes ago. PR: https://github.com/openjdk/jfx/pull/153 ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Greetings Florian Kirmaier From fkirmaier at openjdk.java.net Mon Mar 30 13:47:12 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 30 Mar 2020 13:47:12 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. Message-ID: Closed focused Stages are not collected with Monocle This commit adds a unit-test and a fix for collecting focused closed stages. ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 ------------- Commit messages: - fixing accidentally commited test - cleanup - JDK-8241840 Changes: https://git.openjdk.java.net/jfx/pull/153/files Webrev: https://webrevs.openjdk.java.net/jfx/153/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241840 Stats: 147 lines in 3 files changed: 145 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Mon Mar 30 14:04:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 30 Mar 2020 14:04:42 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Mon, 30 Mar 2020 13:37:51 GMT, Florian Kirmaier wrote: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 @arapte can you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From eduard.filipas at telemach.net Mon Mar 30 17:30:41 2020 From: eduard.filipas at telemach.net (Eduard Filipas) Date: Mon, 30 Mar 2020 19:30:41 +0200 Subject: java fx 11 Message-ID: <4821d4a3-ab95-30bc-aa04-bb2510c08eaa@telemach.net> hi i have a possible problem. i wrote project in openJDK 11 and java FX 11 i used intelij idea latest version and on both win10 or win7 when i execute project with batch file including javaw command then cmd is activated? it shouldnt show cmd. if i start project as proces within my pascal program then cmd is not shown. also i would like to ask how to catch system.out.println messages if cmd is not activated .. thank you regards From tsayao at openjdk.java.net Tue Mar 31 04:02:14 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 31 Mar 2020 04:02:14 GMT Subject: [Rev 32] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: <90qzjmHxufUQfRD9i_KmoqPP50AzGbN6JQeYGmn9-N0=.33731bce-ce7e-4ca1-a0a0-750891e86eda@github.com> > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: calculate less if _NET_FRAME_EXTENTS is available ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/f8fe264c..70878fb4 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.32 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.31-32 Stats: 55 lines in 2 files changed: 7 ins; 40 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From arapte at openjdk.java.net Tue Mar 31 04:18:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 31 Mar 2020 04:18:45 GMT Subject: RFR: 8240542: Switch FX build to use JDK 14 as boot JDK In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 18:46:15 GMT, Kevin Rushforth wrote: > Now that we have switched to using gradle 6.3 we can switch to using JDK 14 as the boot JDK for JavaFX 15 builds. > > This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to > generate class files using `-source 11 -target 11`. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/152 From arapte at openjdk.java.net Tue Mar 31 05:38:58 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 31 Mar 2020 05:38:58 GMT Subject: RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 Message-ID: This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. Call to jpeg_read_header() may fail when the partial image data has incomplete header information. In the given case the jpeg_read_header() call fails and code execution flow enters the 'if (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test passes with fix and causes a native crash without the fix. ------------- Commit messages: - 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 Changes: https://git.openjdk.java.net/jfx/pull/154/files Webrev: https://webrevs.openjdk.java.net/jfx/154/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241370 Stats: 127 lines in 3 files changed: 125 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/154.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/154/head:pull/154 PR: https://git.openjdk.java.net/jfx/pull/154 From aghaisas at openjdk.java.net Tue Mar 31 11:54:32 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 31 Mar 2020 11:54:32 GMT Subject: [Rev 04] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: On Wed, 25 Mar 2020 19:05:42 GMT, Rony G. Flatscher wrote: >> ?9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > Remove jcheck whitespace error. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From github.com+60214806+ronyfla at openjdk.java.net Tue Mar 31 12:09:23 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Tue, 31 Mar 2020 12:09:23 GMT Subject: [Rev 04] RFR: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV In-Reply-To: References: <3ceu1Fz2dqHnjYFcv_up4wXCMGriXiivfrqloUKqII8=.889f4780-c14e-4b74-aad9-07c4209183f0@github.com> Message-ID: On Tue, 31 Mar 2020 11:52:19 GMT, Ajit Ghaisas wrote: >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove jcheck whitespace error. > > Marked as reviewed by aghaisas (Reviewer). Kevin, Ajit, could you please /sponsor this PR? TIA, ---rony ------------- PR: https://git.openjdk.java.net/jfx/pull/122 From Rony.Flatscher at wu.ac.at Tue Mar 31 15:06:35 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 31 Mar 2020 17:06:35 +0200 Subject: Seeking help with latest master ... Message-ID: After merging the master into a local branch, gradle fails with two exceptions. After updating to 6.3 it still fails, here the output: rony at rony-linux:~/dev/github/openjdk/jfx$ gradle --stop Stopping Daemon(s) 1 Daemon stopped rony at rony-linux:~/dev/github/openjdk/jfx$ gradle Starting a Gradle Daemon, 1 stopped Daemon could not be reused, use --status for details > Configure project : gradle.gradleVersion: 6.3 OS_NAME: linux OS_ARCH: amd64 JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 java version: 11.0.6 java build number: 10 jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 jdk version: 11.0.6 jdk build number: 10 minimum jdk version: 11 minimum jdk build number: 28 GCC version: gcc8.3.0-OL6.4+1.0 cmake version: 3.13.3 ninja version: 1.8.2 ant version: 1.10.5 HAS_JAVAFX_MODULES: false STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64 CONF: Debug NUM_COMPILE_THREADS: 8 COMPILE_TARGETS: linux COMPILE_FLAGS_FILES: buildSrc/linux.gradle HUDSON_JOB_NAME: not_hudson HUDSON_BUILD_NUMBER: 0000 PROMOTED_BUILD_NUMBER: 0 PRODUCT_NAME: OpenJFX RELEASE_VERSION: 15 RELEASE_SUFFIX: -internal RELEASE_VERSION_SHORT: 15-internal RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-165101 RELEASE_VERSION_PADDED: 15.0.0.0 MAVEN_VERSION: 15-internal+0-2020-03-31-165101 UPDATE_STUB_CACHE: false Building Webkit configuration /Release/ into /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux module: project ':apps' (buildModule=NO) module: project ':base' (buildModule=YES) module: project ':controls' (buildModule=YES) module: project ':fxml' (buildModule=YES) module: project ':graphics' (buildModule=YES) module: project ':media' (buildModule=YES) module: project ':swing' (buildModule=YES) module: project ':swt' (buildModule=NO) module: project ':systemTests' (buildModule=NO) module: project ':web' (buildModule=YES) FAILURE: Build completed with 2 failures. 1: Task failed with an exception. ----------- * Where: Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176 * What went wrong: A problem occurred evaluating root project 'jfx'. > Could not resolve all dependencies for configuration ':apps:lucene'. ?? > Multiple build operations failed. ???????? java.lang.ExceptionInInitializerError ???????? java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ???????? java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ????? > java.lang.ExceptionInInitializerError ????? > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ????? > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ============================================================================== 2: Task failed with an exception. ----------- * Where: Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589 * What went wrong: A problem occurred configuring root project 'jfx'. > Failed to notify project evaluation listener. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ============================================================================== * Get more help at https://help.gradle.org Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings BUILD FAILED in 4s rony at rony-linux:~/dev/github/openjdk/jfx$ Any hint/help highly appreciated (did not find anything on the Internet that would give me options to try out)! ---rony From kevin.rushforth at oracle.com Tue Mar 31 16:20:22 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 31 Mar 2020 09:20:22 -0700 Subject: Seeking help with latest master ... In-Reply-To: References: Message-ID: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> Check your JDK version and gradle version: $ java -version $ gradle -version If they look OK, you might try: $ rm -rf build $ gradle clean and then do a build. -- Kevin On 3/31/2020 8:06 AM, Rony G. Flatscher wrote: > After merging the master into a local branch, gradle fails with two exceptions. After updating to > 6.3 it still fails, here the output: > > rony at rony-linux:~/dev/github/openjdk/jfx$ gradle --stop > Stopping Daemon(s) > 1 Daemon stopped > > rony at rony-linux:~/dev/github/openjdk/jfx$ gradle > Starting a Gradle Daemon, 1 stopped Daemon could not be reused, use --status for details > > > Configure project : > gradle.gradleVersion: 6.3 > OS_NAME: linux > OS_ARCH: amd64 > JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 > JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 > java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 > java version: 11.0.6 > java build number: 10 > jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 > jdk version: 11.0.6 > jdk build number: 10 > minimum jdk version: 11 > minimum jdk build number: 28 > GCC version: gcc8.3.0-OL6.4+1.0 > cmake version: 3.13.3 > ninja version: 1.8.2 > ant version: 1.10.5 > HAS_JAVAFX_MODULES: false > STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64 > CONF: Debug > NUM_COMPILE_THREADS: 8 > COMPILE_TARGETS: linux > COMPILE_FLAGS_FILES: buildSrc/linux.gradle > HUDSON_JOB_NAME: not_hudson > HUDSON_BUILD_NUMBER: 0000 > PROMOTED_BUILD_NUMBER: 0 > PRODUCT_NAME: OpenJFX > RELEASE_VERSION: 15 > RELEASE_SUFFIX: -internal > RELEASE_VERSION_SHORT: 15-internal > RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-165101 > RELEASE_VERSION_PADDED: 15.0.0.0 > MAVEN_VERSION: 15-internal+0-2020-03-31-165101 > UPDATE_STUB_CACHE: false > Building Webkit configuration /Release/ into > /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux > module: project ':apps' (buildModule=NO) > module: project ':base' (buildModule=YES) > module: project ':controls' (buildModule=YES) > module: project ':fxml' (buildModule=YES) > module: project ':graphics' (buildModule=YES) > module: project ':media' (buildModule=YES) > module: project ':swing' (buildModule=YES) > module: project ':swt' (buildModule=NO) > module: project ':systemTests' (buildModule=NO) > module: project ':web' (buildModule=YES) > > FAILURE: Build completed with 2 failures. > > 1: Task failed with an exception. > ----------- > * Where: > Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176 > > * What went wrong: > A problem occurred evaluating root project 'jfx'. > > Could not resolve all dependencies for configuration ':apps:lucene'. > ?? > Multiple build operations failed. > ???????? java.lang.ExceptionInInitializerError > ???????? java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > ???????? java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > ????? > java.lang.ExceptionInInitializerError > ????? > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > ????? > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get > more log output. Run with --scan to get full insights. > ============================================================================== > > 2: Task failed with an exception. > ----------- > * Where: > Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589 > > * What went wrong: > A problem occurred configuring root project 'jfx'. > > Failed to notify project evaluation listener. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get > more log output. Run with --scan to get full insights. > ============================================================================== > > * Get more help at https://help.gradle.org > > Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. > Use '--warning-mode all' to show the individual deprecation warnings. > See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings > > BUILD FAILED in 4s > rony at rony-linux:~/dev/github/openjdk/jfx$ > > Any hint/help highly appreciated (did not find anything on the Internet that would give me options > to try out)! > > ---rony > > > From Rony.Flatscher at wu.ac.at Tue Mar 31 16:51:40 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 31 Mar 2020 18:51:40 +0200 Subject: Seeking help with latest master ... In-Reply-To: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> Message-ID: <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> On 31.03.2020 18:20, Kevin Rushforth wrote: > Check your JDK version and gradle version: > > $ java -version > $ gradle -version > > If they look OK, you might try: > > $ rm -rf build > $ gradle clean > > and then do a build. Thank you, Kevin, unfortunately, it does not work out (it fails at "gradle clean"), using adoptOpenjdk 11.0.6 release 10 and gradle 6.3. Do I need a JDK > 11 to build ? Here the log of the commands as suggested: rony at rony-linux:~/dev/github/openjdk/jfx$ java -version openjdk version "11.0.6" 2020-01-14 OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1) OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1, mixed mode, sharing) rony at rony-linux:~/dev/github/openjdk/jfx$ javac -version javac 11.0.6 rony at rony-linux:~/dev/github/openjdk/jfx$ rm -rf build rony at rony-linux:~/dev/github/openjdk/jfx$ gradle --stop Stopping Daemon(s) 1 Daemon stopped rony at rony-linux:~/dev/github/openjdk/jfx$ gradle clean Starting a Gradle Daemon, 2 stopped Daemons could not be reused, use --status for details > Configure project : gradle.gradleVersion: 6.3 OS_NAME: linux OS_ARCH: amd64 JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 java version: 11.0.6 java build number: 10 jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 jdk version: 11.0.6 jdk build number: 10 minimum jdk version: 11 minimum jdk build number: 28 GCC version: gcc8.3.0-OL6.4+1.0 cmake version: 3.13.3 ninja version: 1.8.2 ant version: 1.10.5 HAS_JAVAFX_MODULES: false STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64 CONF: Debug NUM_COMPILE_THREADS: 8 COMPILE_TARGETS: linux COMPILE_FLAGS_FILES: buildSrc/linux.gradle HUDSON_JOB_NAME: not_hudson HUDSON_BUILD_NUMBER: 0000 PROMOTED_BUILD_NUMBER: 0 PRODUCT_NAME: OpenJFX RELEASE_VERSION: 15 RELEASE_SUFFIX: -internal RELEASE_VERSION_SHORT: 15-internal RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-184608 RELEASE_VERSION_PADDED: 15.0.0.0 MAVEN_VERSION: 15-internal+0-2020-03-31-184608 UPDATE_STUB_CACHE: false Building Webkit configuration /Release/ into /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux module: project ':apps' (buildModule=NO) module: project ':base' (buildModule=YES) module: project ':controls' (buildModule=YES) module: project ':fxml' (buildModule=YES) module: project ':graphics' (buildModule=YES) module: project ':media' (buildModule=YES) module: project ':swing' (buildModule=YES) module: project ':swt' (buildModule=NO) module: project ':systemTests' (buildModule=NO) module: project ':web' (buildModule=YES) FAILURE: Build completed with 2 failures. 1: Task failed with an exception. ----------- * Where: Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176 * What went wrong: A problem occurred evaluating root project 'jfx'. > Could not resolve all dependencies for configuration ':apps:lucene'. ?? > Multiple build operations failed. ???????? java.lang.ExceptionInInitializerError ???????? java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ???????? java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ????? > java.lang.ExceptionInInitializerError ????? > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ????? > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ============================================================================== 2: Task failed with an exception. ----------- * Where: Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589 * What went wrong: A problem occurred configuring root project 'jfx'. > Failed to notify project evaluation listener. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ============================================================================== * Get more help at https://help.gradle.org Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings BUILD FAILED in 4s rony at rony-linux:~/dev/github/openjdk/jfx$ ---rony From Rony.Flatscher at wu.ac.at Tue Mar 31 17:00:16 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 31 Mar 2020 19:00:16 +0200 Subject: Seeking help with latest master ... In-Reply-To: <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> Message-ID: Hmm, noticed a JDK? "minimum jdk build number: 28" minimum build number. Currently using the latest AdoptOpenJDK 11 LTS. If that is the problem which JDK would you suggest to use instead? ---rony On 31.03.2020 18:51, Rony G. Flatscher wrote: > On 31.03.2020 18:20, Kevin Rushforth wrote: >> Check your JDK version and gradle version: >> >> $ java -version >> $ gradle -version >> >> If they look OK, you might try: >> >> $ rm -rf build >> $ gradle clean >> >> and then do a build. > Thank you, Kevin, unfortunately, it does not work out (it fails at "gradle clean"), using > adoptOpenjdk 11.0.6 release 10 and gradle 6.3. > > Do I need a JDK > 11 to build ? > > Here the log of the commands as suggested: > > rony at rony-linux:~/dev/github/openjdk/jfx$ java -version > openjdk version "11.0.6" 2020-01-14 > OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1) > OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1, mixed mode, sharing) > rony at rony-linux:~/dev/github/openjdk/jfx$ javac -version > javac 11.0.6 > rony at rony-linux:~/dev/github/openjdk/jfx$ rm -rf build > rony at rony-linux:~/dev/github/openjdk/jfx$ gradle --stop > Stopping Daemon(s) > 1 Daemon stopped > rony at rony-linux:~/dev/github/openjdk/jfx$ gradle clean > Starting a Gradle Daemon, 2 stopped Daemons could not be reused, use --status for details > > > Configure project : > gradle.gradleVersion: 6.3 > OS_NAME: linux > OS_ARCH: amd64 > JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 > JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 > java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 > java version: 11.0.6 > java build number: 10 > jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 > jdk version: 11.0.6 > jdk build number: 10 > minimum jdk version: 11 > minimum jdk build number: 28 > GCC version: gcc8.3.0-OL6.4+1.0 > cmake version: 3.13.3 > ninja version: 1.8.2 > ant version: 1.10.5 > HAS_JAVAFX_MODULES: false > STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64 > CONF: Debug > NUM_COMPILE_THREADS: 8 > COMPILE_TARGETS: linux > COMPILE_FLAGS_FILES: buildSrc/linux.gradle > HUDSON_JOB_NAME: not_hudson > HUDSON_BUILD_NUMBER: 0000 > PROMOTED_BUILD_NUMBER: 0 > PRODUCT_NAME: OpenJFX > RELEASE_VERSION: 15 > RELEASE_SUFFIX: -internal > RELEASE_VERSION_SHORT: 15-internal > RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-184608 > RELEASE_VERSION_PADDED: 15.0.0.0 > MAVEN_VERSION: 15-internal+0-2020-03-31-184608 > UPDATE_STUB_CACHE: false > Building Webkit configuration /Release/ into > /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux > module: project ':apps' (buildModule=NO) > module: project ':base' (buildModule=YES) > module: project ':controls' (buildModule=YES) > module: project ':fxml' (buildModule=YES) > module: project ':graphics' (buildModule=YES) > module: project ':media' (buildModule=YES) > module: project ':swing' (buildModule=YES) > module: project ':swt' (buildModule=NO) > module: project ':systemTests' (buildModule=NO) > module: project ':web' (buildModule=YES) > > FAILURE: Build completed with 2 failures. > > 1: Task failed with an exception. > ----------- > * Where: > Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176 > > * What went wrong: > A problem occurred evaluating root project 'jfx'. > > Could not resolve all dependencies for configuration ':apps:lucene'. > ?? > Multiple build operations failed. > ???????? java.lang.ExceptionInInitializerError > ???????? java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > ???????? java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > ????? > java.lang.ExceptionInInitializerError > ????? > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > ????? > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get > more log output. Run with --scan to get full insights. > ============================================================================== > > 2: Task failed with an exception. > ----------- > * Where: > Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589 > > * What went wrong: > A problem occurred configuring root project 'jfx'. > > Failed to notify project evaluation listener. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get > more log output. Run with --scan to get full insights. > ============================================================================== > > * Get more help at https://help.gradle.org > > Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. > Use '--warning-mode all' to show the individual deprecation warnings. > See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings > > BUILD FAILED in 4s > rony at rony-linux:~/dev/github/openjdk/jfx$ > > ---rony > From kevin.rushforth at oracle.com Tue Mar 31 17:10:08 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 31 Mar 2020 10:10:08 -0700 Subject: Seeking help with latest master ... In-Reply-To: References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> Message-ID: <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> That's not the problem. The minimum build number only applies if at the exact minimum JDK version in question. You are using 11.0.6 which is > 11 so no problem there. One last thing to try: $ rm -rf .gradle buildSrc/.gradle buildSrc/build In case something is cached there that the newer gradle trips over. -- Kevin On 3/31/2020 10:00 AM, Rony G. Flatscher wrote: > Hmm, noticed a JDK? "minimum jdk build number: 28" minimum build number. Currently using the latest > AdoptOpenJDK 11 LTS. > > If that is the problem which JDK would you suggest to use instead? > > ---rony > > > On 31.03.2020 18:51, Rony G. Flatscher wrote: >> On 31.03.2020 18:20, Kevin Rushforth wrote: >>> Check your JDK version and gradle version: >>> >>> $ java -version >>> $ gradle -version >>> >>> If they look OK, you might try: >>> >>> $ rm -rf build >>> $ gradle clean >>> >>> and then do a build. >> Thank you, Kevin, unfortunately, it does not work out (it fails at "gradle clean"), using >> adoptOpenjdk 11.0.6 release 10 and gradle 6.3. >> >> Do I need a JDK > 11 to build ? >> >> Here the log of the commands as suggested: >> >> rony at rony-linux:~/dev/github/openjdk/jfx$ java -version >> openjdk version "11.0.6" 2020-01-14 >> OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1) >> OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1, mixed mode, sharing) >> rony at rony-linux:~/dev/github/openjdk/jfx$ javac -version >> javac 11.0.6 >> rony at rony-linux:~/dev/github/openjdk/jfx$ rm -rf build >> rony at rony-linux:~/dev/github/openjdk/jfx$ gradle --stop >> Stopping Daemon(s) >> 1 Daemon stopped >> rony at rony-linux:~/dev/github/openjdk/jfx$ gradle clean >> Starting a Gradle Daemon, 2 stopped Daemons could not be reused, use --status for details >> >> > Configure project : >> gradle.gradleVersion: 6.3 >> OS_NAME: linux >> OS_ARCH: amd64 >> JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 >> JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 >> java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 >> java version: 11.0.6 >> java build number: 10 >> jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 >> jdk version: 11.0.6 >> jdk build number: 10 >> minimum jdk version: 11 >> minimum jdk build number: 28 >> GCC version: gcc8.3.0-OL6.4+1.0 >> cmake version: 3.13.3 >> ninja version: 1.8.2 >> ant version: 1.10.5 >> HAS_JAVAFX_MODULES: false >> STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64 >> CONF: Debug >> NUM_COMPILE_THREADS: 8 >> COMPILE_TARGETS: linux >> COMPILE_FLAGS_FILES: buildSrc/linux.gradle >> HUDSON_JOB_NAME: not_hudson >> HUDSON_BUILD_NUMBER: 0000 >> PROMOTED_BUILD_NUMBER: 0 >> PRODUCT_NAME: OpenJFX >> RELEASE_VERSION: 15 >> RELEASE_SUFFIX: -internal >> RELEASE_VERSION_SHORT: 15-internal >> RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-184608 >> RELEASE_VERSION_PADDED: 15.0.0.0 >> MAVEN_VERSION: 15-internal+0-2020-03-31-184608 >> UPDATE_STUB_CACHE: false >> Building Webkit configuration /Release/ into >> /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux >> module: project ':apps' (buildModule=NO) >> module: project ':base' (buildModule=YES) >> module: project ':controls' (buildModule=YES) >> module: project ':fxml' (buildModule=YES) >> module: project ':graphics' (buildModule=YES) >> module: project ':media' (buildModule=YES) >> module: project ':swing' (buildModule=YES) >> module: project ':swt' (buildModule=NO) >> module: project ':systemTests' (buildModule=NO) >> module: project ':web' (buildModule=YES) >> >> FAILURE: Build completed with 2 failures. >> >> 1: Task failed with an exception. >> ----------- >> * Where: >> Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176 >> >> * What went wrong: >> A problem occurred evaluating root project 'jfx'. >> > Could not resolve all dependencies for configuration ':apps:lucene'. >> ?? > Multiple build operations failed. >> ???????? java.lang.ExceptionInInitializerError >> ???????? java.lang.NoClassDefFoundError: Could not initialize class >> sun.security.ssl.SSLContextImpl$TLSContext >> ???????? java.lang.NoClassDefFoundError: Could not initialize class >> sun.security.ssl.SSLContextImpl$TLSContext >> ????? > java.lang.ExceptionInInitializerError >> ????? > java.lang.NoClassDefFoundError: Could not initialize class >> sun.security.ssl.SSLContextImpl$TLSContext >> ????? > java.lang.NoClassDefFoundError: Could not initialize class >> sun.security.ssl.SSLContextImpl$TLSContext >> >> * Try: >> Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get >> more log output. Run with --scan to get full insights. >> ============================================================================== >> >> 2: Task failed with an exception. >> ----------- >> * Where: >> Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589 >> >> * What went wrong: >> A problem occurred configuring root project 'jfx'. >> > Failed to notify project evaluation listener. >> ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type >> org.gradle.api.internal.tasks.DefaultTaskContainer. >> ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type >> org.gradle.api.internal.tasks.DefaultTaskContainer. >> ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type >> org.gradle.api.internal.tasks.DefaultTaskContainer. >> ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type >> org.gradle.api.internal.tasks.DefaultTaskContainer. >> ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type >> org.gradle.api.internal.tasks.DefaultTaskContainer. >> ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type >> org.gradle.api.internal.tasks.DefaultTaskContainer. >> ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type >> org.gradle.api.internal.tasks.DefaultTaskContainer. >> >> * Try: >> Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get >> more log output. Run with --scan to get full insights. >> ============================================================================== >> >> * Get more help at https://help.gradle.org >> >> Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. >> Use '--warning-mode all' to show the individual deprecation warnings. >> See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings >> >> BUILD FAILED in 4s >> rony at rony-linux:~/dev/github/openjdk/jfx$ >> >> ---rony >> From Rony.Flatscher at wu.ac.at Tue Mar 31 17:21:16 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 31 Mar 2020 19:21:16 +0200 Subject: Seeking help with latest master ... In-Reply-To: <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> Message-ID: <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> On 31.03.2020 19:10, Kevin Rushforth wrote: > That's not the problem. The minimum build number only applies if at the exact minimum JDK version > in question. You are using 11.0.6 which is > 11 so no problem there. > > One last thing to try: > > $ rm -rf .gradle buildSrc/.gradle buildSrc/build > > In case something is cached there that the newer gradle trips over. Unfortunately did not resolve the failure: rony at rony-linux:~/dev/github/openjdk/jfx$ rm -rf build .gradle buildSrc/.gradle buildSrc/build rony at rony-linux:~/dev/github/openjdk/jfx$ gradle --stop No Gradle daemons are running. rony at rony-linux:~/dev/github/openjdk/jfx$ gradle clean Starting a Gradle Daemon, 5 stopped Daemons could not be reused, use --status for details > Configure project : gradle.gradleVersion: 6.3 OS_NAME: linux OS_ARCH: amd64 JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 java version: 11.0.6 java build number: 10 jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 jdk version: 11.0.6 jdk build number: 10 minimum jdk version: 11 minimum jdk build number: 28 GCC version: gcc8.3.0-OL6.4+1.0 cmake version: 3.13.3 ninja version: 1.8.2 ant version: 1.10.5 HAS_JAVAFX_MODULES: false STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64 CONF: Debug NUM_COMPILE_THREADS: 8 COMPILE_TARGETS: linux COMPILE_FLAGS_FILES: buildSrc/linux.gradle HUDSON_JOB_NAME: not_hudson HUDSON_BUILD_NUMBER: 0000 PROMOTED_BUILD_NUMBER: 0 PRODUCT_NAME: OpenJFX RELEASE_VERSION: 15 RELEASE_SUFFIX: -internal RELEASE_VERSION_SHORT: 15-internal RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-191843 RELEASE_VERSION_PADDED: 15.0.0.0 MAVEN_VERSION: 15-internal+0-2020-03-31-191843 UPDATE_STUB_CACHE: false Building Webkit configuration /Release/ into /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux module: project ':apps' (buildModule=NO) module: project ':base' (buildModule=YES) module: project ':controls' (buildModule=YES) module: project ':fxml' (buildModule=YES) module: project ':graphics' (buildModule=YES) module: project ':media' (buildModule=YES) module: project ':swing' (buildModule=YES) module: project ':swt' (buildModule=NO) module: project ':systemTests' (buildModule=NO) module: project ':web' (buildModule=YES) FAILURE: Build completed with 2 failures. 1: Task failed with an exception. ----------- * Where: Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176 * What went wrong: A problem occurred evaluating root project 'jfx'. > Could not resolve all dependencies for configuration ':apps:lucene'. ?? > Multiple build operations failed. ???????? java.lang.ExceptionInInitializerError ???????? java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ???????? java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ????? > java.lang.ExceptionInInitializerError ????? > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext ????? > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ============================================================================== 2: Task failed with an exception. ----------- * Where: Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589 * What went wrong: A problem occurred configuring root project 'jfx'. > Failed to notify project evaluation listener. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. ?? > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. ============================================================================== * Get more help at https://help.gradle.org Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings BUILD FAILED in 5s rony at rony-linux:~/dev/github/openjdk/jfx$ ---rony From swpalmer at gmail.com Tue Mar 31 18:21:32 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 31 Mar 2020 14:21:32 -0400 Subject: Seeking help with latest master ... In-Reply-To: <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> Message-ID: > Could not resolve all dependencies for configuration ':apps:lucene'. > Multiple build operations failed. java.lang.ExceptionInInitializerError java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext > java.lang.ExceptionInInitializerError > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext > java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext This to me looks like it may be failing to make an https connection to a repository when attempting to download dependencies. There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running gradle builds, see: https://github.com/gradle/gradle/issues/7842 Claims to be fixed, but maybe not? If it is related to Gradle changing java.home while compiling, I wonder if using --no-parallel might work around it? Of course try with --debug as well to see if it offers more clues. Regards, Scott > On Mar 31, 2020, at 1:21 PM, Rony G. Flatscher wrote: > > On 31.03.2020 19:10, Kevin Rushforth wrote: >> That's not the problem. The minimum build number only applies if at the exact minimum JDK version >> in question. You are using 11.0.6 which is > 11 so no problem there. >> >> One last thing to try: >> >> $ rm -rf .gradle buildSrc/.gradle buildSrc/build >> >> In case something is cached there that the newer gradle trips over. > > Unfortunately did not resolve the failure: > > rony at rony-linux:~/dev/github/openjdk/jfx$ rm -rf build .gradle buildSrc/.gradle buildSrc/build > rony at rony-linux:~/dev/github/openjdk/jfx$ gradle --stop > No Gradle daemons are running. > rony at rony-linux:~/dev/github/openjdk/jfx$ gradle clean > Starting a Gradle Daemon, 5 stopped Daemons could not be reused, use --status for details > >> Configure project : > gradle.gradleVersion: 6.3 > OS_NAME: linux > OS_ARCH: amd64 > JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64 > JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64 > java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 > java version: 11.0.6 > java build number: 10 > jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1 > jdk version: 11.0.6 > jdk build number: 10 > minimum jdk version: 11 > minimum jdk build number: 28 > GCC version: gcc8.3.0-OL6.4+1.0 > cmake version: 3.13.3 > ninja version: 1.8.2 > ant version: 1.10.5 > HAS_JAVAFX_MODULES: false > STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64 > CONF: Debug > NUM_COMPILE_THREADS: 8 > COMPILE_TARGETS: linux > COMPILE_FLAGS_FILES: buildSrc/linux.gradle > HUDSON_JOB_NAME: not_hudson > HUDSON_BUILD_NUMBER: 0000 > PROMOTED_BUILD_NUMBER: 0 > PRODUCT_NAME: OpenJFX > RELEASE_VERSION: 15 > RELEASE_SUFFIX: -internal > RELEASE_VERSION_SHORT: 15-internal > RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-191843 > RELEASE_VERSION_PADDED: 15.0.0.0 > MAVEN_VERSION: 15-internal+0-2020-03-31-191843 > UPDATE_STUB_CACHE: false > Building Webkit configuration /Release/ into > /home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux > module: project ':apps' (buildModule=NO) > module: project ':base' (buildModule=YES) > module: project ':controls' (buildModule=YES) > module: project ':fxml' (buildModule=YES) > module: project ':graphics' (buildModule=YES) > module: project ':media' (buildModule=YES) > module: project ':swing' (buildModule=YES) > module: project ':swt' (buildModule=NO) > module: project ':systemTests' (buildModule=NO) > module: project ':web' (buildModule=YES) > > FAILURE: Build completed with 2 failures. > > 1: Task failed with an exception. > ----------- > * Where: > Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176 > > * What went wrong: > A problem occurred evaluating root project 'jfx'. >> Could not resolve all dependencies for configuration ':apps:lucene'. > > Multiple build operations failed. > java.lang.ExceptionInInitializerError > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > > java.lang.ExceptionInInitializerError > > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$TLSContext > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get > more log output. Run with --scan to get full insights. > ============================================================================== > > 2: Task failed with an exception. > ----------- > * Where: > Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 1589 > > * What went wrong: > A problem occurred configuring root project 'jfx'. >> Failed to notify project evaluation listener. > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type > org.gradle.api.internal.tasks.DefaultTaskContainer. > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get > more log output. Run with --scan to get full insights. > ============================================================================== > > * Get more help at https://help.gradle.org > > Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. > Use '--warning-mode all' to show the individual deprecation warnings. > See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings > > BUILD FAILED in 5s > rony at rony-linux:~/dev/github/openjdk/jfx$ > > ---rony > From Rony.Flatscher at wu.ac.at Tue Mar 31 18:36:25 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 31 Mar 2020 20:36:25 +0200 Subject: Seeking help with latest master ... In-Reply-To: References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> Message-ID: On 31.03.2020 20:21, Scott Palmer wrote: >> Could not resolve all dependencies for configuration ':apps:lucene'. > ????? > Multiple build operations failed. > ??????????? java.lang.ExceptionInInitializerError > ??????????? java.lang.NoClassDefFoundError: Could not initialize class > ???sun.security.ssl.SSLContextImpl$TLSContext > ??????????? java.lang.NoClassDefFoundError: Could not initialize class > ???sun.security.ssl.SSLContextImpl$TLSContext > ???????? > java.lang.ExceptionInInitializerError > ???????? > java.lang.NoClassDefFoundError: Could not initialize class > ???sun.security.ssl.SSLContextImpl$TLSContext > ???????? > java.lang.NoClassDefFoundError: Could not initialize class > ???sun.security.ssl.SSLContextImpl$TLSContext > > > This to me looks like it may be failing to make an https connection to a repository when > attempting to download?dependencies. > > There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running gradle builds, see:? > https://github.com/gradle/gradle/issues/7842 > > Claims to be fixed, but maybe not? > > If it is related to Gradle?changing java.home while compiling, I wonder if using?--no-parallel > might work around it? ?Of course try with --debug as well to see if it offers more clues. Scott, thank you! Not having any knowledge about gradle I am unfortunately lost in this case. However, I used? "gradle --no-parallel --debug" which did not succeed but created a 1.2 MB text file which I keep temporarily in my DrobBox at: . Will have to leave in a few minutes for today so can only try other things tomorrow. ---rony From tsayao at openjdk.java.net Tue Mar 31 20:47:55 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 31 Mar 2020 20:47:55 GMT Subject: [Rev 02] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: On Thu, 26 Mar 2020 11:21:06 GMT, Kevin Rushforth wrote: >> I think it's better to split the flags between CFLAGS and CPPFLAGS (as is done in OpenJDK). The >> `-Werror=implicit-function-declaration` is extremely useful for C files, and we don't want to risk that this somehow >> got lost. If we use CFLAGS and CPPFLAGS, we can pass the latter as CXXFLAGS to cmake, so that should be fairly easy. > > I took a look yesterday and came to the same conclusion that what we really want are separate C and C++ flags. For now, > the only difference would be the presence or absence of `-Werror=implicit-function-declaration`, but it would allow for > other differences in the future if needed. Please, let me know if this is the desired way to do it. If not, I will rework it. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From tsayao at openjdk.java.net Tue Mar 31 23:17:52 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 31 Mar 2020 23:17:52 GMT Subject: [Rev 33] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: <6siHPi5hbGSMMplT56Yg9UtRbyjLGQCgA8Sr-Cth-4Q=.caf87c25-8805-481f-84de-e26996d457c1@github.com> > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fixes for WM that do not support frame extents ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/70878fb4..3855e16f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.33 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.32-33 Stats: 36 lines in 2 files changed: 7 ins; 9 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77