From bchoudhary at openjdk.java.net Tue Sep 1 06:29:17 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 1 Sep 2020 06:29:17 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling [v2] In-Reply-To: References: Message-ID: > ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of > actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue > is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due > to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Moved test from unit test to system test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/279/files - new: https://git.openjdk.java.net/jfx/pull/279/files/91e8bdf0..a99141df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=279&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=279&range=00-01 Stats: 211 lines in 3 files changed: 185 ins; 26 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/279.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/279/head:pull/279 PR: https://git.openjdk.java.net/jfx/pull/279 From hjohn at xs4all.nl Tue Sep 1 09:06:06 2020 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 1 Sep 2020 11:06:06 +0200 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> Message-ID: <2bca9ed5-a71f-37e1-575e-df4bff9d0d6d@xs4all.nl> The "dynamic update performance" performance issue we are seeing is a regression from JDK-8090322. In this change the Node treeShowing property was introduced. The JDK-8090322 warns in its description about: """ Considerations: * This is too expensive to calculate for all nodes by default. So the simplest way to provide it would be a special binding implementation or a util class. Where you create a instance and pass in the node you are interested in. It can then register listeners all the way up the tree and listen to what it needs. """ The above comment is warning against the fact that registering listeners for EACH Node on Window and Scene is going to be a performance issue. As nodes can number in the 1000's or 10.000's, that's a lot of listeners to store in a List data structure. PR 185 targets this issue and implements the feature in JDK-8090322 in the way that was suggested in the above comment, instead of how it currently is implemented (registering listeners for every Node, just in case someone needs the treeShowing property). It's scope is not as broad as it would seem (because of a change in Node). It effectively only makes a small change in two controls (PopupWindow and ProgressIndicatorSkin). --John On 31/08/2020 16:54, Jeanette Winzenburg wrote: > > Looking at the examples provided in 108/125: apart from both having many > columns (> 300 makes them really nasty) they differ in > > Table content: > 125 - static data > 108 - items are frequently modified (added) > > Perceived performance: > 125 - vertical scrolling: thumb/content lags behind mouse > 108 - with enough columns, all interaction is sluggish (mouse, keys, > ..), scrolling being just one of them > > Both have examples, running those against the suggested fixes (with 108a > for Jose's approach) > 125 - fixes its own example, does nothing for the other > 108, 108a, 185 - improves its own example, does nothing for other > > So we seem to have multiple issues that are (mostly) orthogonal: one > being the broken/missing horizontal virtualization (125), the other > related to dynamic update of table content (108, 108a, 185). We need to > solve both, the solution/s for one looks (mostly?) unrelated to the > solution to the other. > > 125 is the only one PR for its use-case, and it seems to do its job. > From those targeting the dynamic data update all except Jose's (not yet > formalized into a PR) approach feel too broad: table's reaction to items > modifications is .. suboptimal in more than one aspect. Changing overall > notification implementation to improve that, sounds like covering it up. > > -- Jeanette > > Zitat von Kevin Rushforth : > >> Sorry for the badly formatted html. Here it is again. >> >> I see some progress being made on the {Tree}TableView performance >> issue. To summarize where I think we are: >> >> There are currently 2 different approaches under review: >> >> 1. https://github.com/openjdk/jfx/pull/108 : optimization in >> javafx.base to make removing listeners faster >> 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView >> to reduce the number of add / removes >> >> In addition, the following is a WIP PR that the author thinks could be >> a 3rd approach: >> >> 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene >> graph to avoid install treeShowing listeners on Window and Scene for >> all nodes >> >> Jose has proposed a 4th approach as a comment to PR #108, and as I >> understand it, he will propose a PR shortly. >> >> 4. Don't clear the list of children in a VirtualFlow when the number >> of items changes. >> >> So the first thing that is needed is to evaluate the approaches and >> decide which one to pursue. >> >> Options 1 and 3 are more broad in their scope, option #2 is more >> targeted (to TableView), but within that area is a larger change. >> Option #3 would remove the (internal) treeShowing property as a >> generally available concept and only use it for controls like >> ProgressIndicator that really need it. Option #4 affects only controls >> that use VirtualFlow (ListView, TableVIew, TreeTableView), and seems >> not to be a large change (presuming we can verify that no leak is >> introduced). >> >> I note that these fixes are not mutually exclusive, but I do think we >> need to settle on a primary approach and use that to fix this issue. >> If there are still performance problems after that fix, we can >> consider one (or more) of the others. >> >> Comments? >> >> -- Kevin > > > From nlisker at openjdk.java.net Tue Sep 1 10:57:16 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 1 Sep 2020 10:57:16 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> On Fri, 7 Aug 2020 22:37:15 GMT, Kevin Rushforth wrote: >> Given that we don't have any automated tests for lighting (we have a couple that verify that we can take a snapshot and >> get the same result, but that isn't testing the lighting itself), probably the most we can expect is a simple test of a >> large quad with a light fairly close to the object, such that the difference with / without attenuation is noticeable. >> Then you could sample the center and near the corners of the object for both the attenuated and unattenuated cases. > > The performance tests need a standard GPLv2+classpath copyright header. I haven't tested them yet, but will do that > next week. I've written a simple draft for the automated test: PointLight light = new PointLight(Color.BLUE); light.setTranslateZ(-50); var box = new Box(100, 100, 1); var root = new Group(light, box); var scene = new Scene(root); var image = box.snapshot(null, null); var nonAttenColor = image.getPixelReader().getColor(1, 1); light.setLinearAttenuation(2); image = box.snapshot(null, null); var attenColor = image.getPixelReader().getColor(1, 1); assertTrue("Attenuation color should be less than non-attenuated", nonAttenColor.getBlue() > attenColor.getBlue()); However, I'm getting the error: java.lang.UnsupportedOperationException at javafx.graphics/test.com.sun.javafx.pgstub.StubToolkit.renderToImage(StubToolkit.java:719) at javafx.graphics/javafx.scene.Scene.doSnapshotTile(Scene.java:1383) at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1319) at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) Where is the test that takes the snapshot? I am missing something in my setup. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From bchoudhary at openjdk.java.net Tue Sep 1 11:37:04 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 1 Sep 2020 11:37:04 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v10] In-Reply-To: References: Message-ID: <_m4pp2yaaPCPxi8_Umb7FTnldSM7zXQVWVaeMsDC2GI=.134f813d-0910-4f71-ab2d-47356aa84073@github.com> > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Added fillRoundedRect and fillPath drawing with mask ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/41f64c0e..87f63074 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=08-09 Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From kcr at openjdk.java.net Tue Sep 1 11:44:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 1 Sep 2020 11:44:46 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Tue, 1 Sep 2020 10:54:50 GMT, Nir Lisker wrote: >> The performance tests need a standard GPLv2+classpath copyright header. I haven't tested them yet, but will do that >> next week. > > I've written a simple draft for the automated test: > > PointLight light = new PointLight(Color.BLUE); > light.setTranslateZ(-50); > var box = new Box(100, 100, 1); > var root = new Group(light, box); > var scene = new Scene(root); > var image = box.snapshot(null, null); > var nonAttenColor = image.getPixelReader().getColor(1, 1); > light.setLinearAttenuation(2); > image = box.snapshot(null, null); > var attenColor = image.getPixelReader().getColor(1, 1); > assertTrue("Attenuation color should be less than non-attenuated", nonAttenColor.getBlue() > attenColor.getBlue()); > > However, I'm getting the error: > > java.lang.UnsupportedOperationException > at javafx.graphics/test.com.sun.javafx.pgstub.StubToolkit.renderToImage(StubToolkit.java:719) > at javafx.graphics/javafx.scene.Scene.doSnapshotTile(Scene.java:1383) > at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1319) > at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) > at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) > Where is the test that takes the snapshot? I am missing something in my setup. I guess you are trying a unit test in the `javafx.graphics` project? That won't work. It needs to be a system test in `tests/system/...` ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Tue Sep 1 13:52:12 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 1 Sep 2020 13:52:12 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Tue, 1 Sep 2020 11:42:30 GMT, Kevin Rushforth wrote: >> I've written a simple draft for the automated test: >> >> PointLight light = new PointLight(Color.BLUE); >> light.setTranslateZ(-50); >> var box = new Box(100, 100, 1); >> var root = new Group(light, box); >> var scene = new Scene(root); >> var image = box.snapshot(null, null); >> var nonAttenColor = image.getPixelReader().getColor(1, 1); >> light.setLinearAttenuation(2); >> image = box.snapshot(null, null); >> var attenColor = image.getPixelReader().getColor(1, 1); >> assertTrue("Attenuation color should be less than non-attenuated", nonAttenColor.getBlue() > attenColor.getBlue()); >> >> However, I'm getting the error: >> >> java.lang.UnsupportedOperationException >> at javafx.graphics/test.com.sun.javafx.pgstub.StubToolkit.renderToImage(StubToolkit.java:719) >> at javafx.graphics/javafx.scene.Scene.doSnapshotTile(Scene.java:1383) >> at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1319) >> at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) >> at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) >> Where is the test that takes the snapshot? I am missing something in my setup. > > I guess you are trying a unit test in the `javafx.graphics` project? That won't work. It needs to be a system test in > `tests/system/...` I tried several approaches. When I put it under `tests/system` and run the tests task, I don't see it being run. I'm not familiar with the way tests under `tests` are run in general. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Tue Sep 1 14:01:32 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 1 Sep 2020 14:01:32 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v8] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: <549pqzBdvFAW4kVPON69UFObPHpsPLudT5HXj7qha74=.e8246f24-c175-412b-98a1-fe6de9903569@github.com> On Sat, 29 Aug 2020 10:40:35 GMT, Jeanette Winzenburg wrote: > What do you think? Suggestion looks promising, I shall try it and update. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Tue Sep 1 14:14:31 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 1 Sep 2020 14:14:31 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v3] In-Reply-To: <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> Message-ID: On Mon, 31 Aug 2020 19:16:31 GMT, yosbits wrote: > > > Since there was a problem that the cell was not updated when the window was maximized, I added a fix to > TreeTableViewSkin.java. that's just the added listener to hbar properties (same as in TableViewSkin), or anything else changed? > Added test code (BigTreeTableViewTest) for TreeTableView to the first post. > > @kleopatra > Does the test code I added (BigTreeTableViewTest.java) also have side effects? yeah, but why do you ask me - you could easily see for yourself :) And don't understand why you wrap the hierarchy setup in runlater (which smears a bit over the delay by filling the treeTable content at an unspecific time "later") ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From kcr at openjdk.java.net Tue Sep 1 17:02:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 1 Sep 2020 17:02:38 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Tue, 1 Sep 2020 13:49:48 GMT, Nir Lisker wrote: >> I guess you are trying a unit test in the `javafx.graphics` project? That won't work. It needs to be a system test in >> `tests/system/...` > > I tried several approaches. When I put it under `tests/system` and run the tests task, I don't see it being run. I'm > not familiar with the way tests under `tests` are run in general. You need to pass a flag to enable system tests (and a second one for Robot tests, but if you use snapshot it might not need to be). gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests MyTest ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Tue Sep 1 19:46:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 1 Sep 2020 19:46:19 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling [v2] In-Reply-To: References: Message-ID: <16DdO5HAURzOLWVNLv75wtTn-lm7p1QWkGjfLRnK4Q8=.80294469-4f38-49ed-b801-a46ecb05afcc@github.com> On Tue, 1 Sep 2020 06:29:17 GMT, Bhawesh Choudhary wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Moved test from unit test to system test Looks good. I verified that the system test still catches the bug (that is, it fails without the fix and passes with the fix). I ran it in a loop 100 times on both Mac and Windows without crashing. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/279 From github.com+7517141+yososs at openjdk.java.net Tue Sep 1 21:00:09 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 1 Sep 2020 21:00:09 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v3] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> Message-ID: On Tue, 1 Sep 2020 14:12:15 GMT, Jeanette Winzenburg wrote: >> Since there was a problem that the cell was not updated when the window was maximized, I added a fix to >> TreeTableViewSkin.java. >> Added test code (BigTreeTableViewTest) for TreeTableView to the first post. >> >> @kleopatra >> Does the test code I added (BigTreeTableViewTest.java) also have side effects? > >> >> >> Since there was a problem that the cell was not updated when the window was maximized, I added a fix to >> TreeTableViewSkin.java. > > that's just the added listener to hbar properties (same as in TableViewSkin), or anything else changed? > >> Added test code (BigTreeTableViewTest) for TreeTableView to the first post. >> >> @kleopatra >> Does the test code I added (BigTreeTableViewTest.java) also have side effects? > > yeah, but why do you ask me - you could easily see for yourself :) And don't understand why you wrap the hierarchy > setup in runlater (which smears a bit over the delay by filling the treeTable content at an unspecific time "later") When the startup time is measured by eye, the impression changes depending on the individual difference. The effect of runLater affects your experience. However, I succeeded in further improving performance by eliminating another bottleneck in TreeTableView. Of course, it also includes improvements in startup time. I plan to commit at a later date. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From nlisker at openjdk.java.net Tue Sep 1 22:48:59 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 1 Sep 2020 22:48:59 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Tue, 1 Sep 2020 17:00:10 GMT, Kevin Rushforth wrote: > gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests MyTest What format is `MyTest`? Is it some relative path? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Tue Sep 1 23:12:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 1 Sep 2020 23:12:10 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Tue, 1 Sep 2020 22:46:44 GMT, Nir Lisker wrote: >> You need to pass a flag to enable system tests (and a second one for Robot tests, but if you use snapshot it might not >> need to be). >> gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests MyTest > >> gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests MyTest > > What format is `MyTest`? Is it some relative path? It can either be a fully qualified class name (with `.` as separator) or the unqualified name of the test class. The class name must end with exactly `Test`. So for example, try it with `Snapshot1Test`. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From ajoseph at openjdk.java.net Wed Sep 2 03:16:45 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 2 Sep 2020 03:16:45 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling [v2] In-Reply-To: References: Message-ID: On Tue, 1 Sep 2020 06:29:17 GMT, Bhawesh Choudhary wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Moved test from unit test to system test tests/system/src/test/java/test/javafx/scene/web/CSSFilterTest.java line 44: > 43: import static javafx.concurrent.Worker.State.SUCCEEDED; > 44: import static org.junit.Assert.assertEquals; > 45: import static org.junit.Assert.assertNotNull; assertEquals is not used in this test and can be removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/279 From ajoseph at openjdk.java.net Wed Sep 2 03:30:49 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 2 Sep 2020 03:30:49 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling [v2] In-Reply-To: References: Message-ID: On Tue, 1 Sep 2020 06:29:17 GMT, Bhawesh Choudhary wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Moved test from unit test to system test tests/system/src/test/java/test/javafx/scene/web/CSSFilterTest.java line 93: > 92: double deltaOpacity = Math.abs(notExpected.getOpacity() - actual.getOpacity()); > 93: if (deltaRed < delta && deltaGreen < delta && deltaBlue < delta && deltaOpacity < delta) { > 94: fail(msg + " not expected:" + colorToString(notExpected) testColorEquals can be reused here. `if (testColorEquals(expected, actual, delta))` ------------- PR: https://git.openjdk.java.net/jfx/pull/279 From fastegal at openjdk.java.net Wed Sep 2 10:49:13 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 2 Sep 2020 10:49:13 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v3] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> Message-ID: On Tue, 1 Sep 2020 20:57:58 GMT, yosbits wrote: > > > When the startup time is measured by eye, the impression changes depending on the individual difference. my eye is a precision instrument :) Seriously, who would do such a thingy? Obviously, it must be measured, for zeroth approximation doing so crudely by comparing currentMillis before/after showing is good enough to "see" the tendency. > The effect of runLater affects your experience. that's why you shouldn't do it when trying to gain insight into timing issues ;) > > However, I succeeded in further improving performance by eliminating another bottleneck in TreeTableView. Of course, it > also includes improvements in startup time. cool :) ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From ajoseph at openjdk.java.net Wed Sep 2 11:26:58 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 2 Sep 2020 11:26:58 GMT Subject: RFR: 8252062: WebKit build fails with recent VS 2019 compiler Message-ID: The WebKit build fails with recent VS 2019 compiler. Bug: This MediaQueryEvaluator constructor takes a String parameter, but the conversion of char* to String is failing. Fix: Use the default constructor of MediaQueryEvaluator, which also returns true for "all". Test: Build webkit with the recent VS 2019 compiler with and without this fix. It should crash without the fix and build with the fix. ------------- Commit messages: - 8252062: WebKit build fails with recent VS 2019 compiler Changes: https://git.openjdk.java.net/jfx/pull/294/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=294&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252062 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/294/head:pull/294 PR: https://git.openjdk.java.net/jfx/pull/294 From fastegal at swingempire.de Wed Sep 2 12:24:19 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 02 Sep 2020 14:24:19 +0200 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <2bca9ed5-a71f-37e1-575e-df4bff9d0d6d@xs4all.nl> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> <2bca9ed5-a71f-37e1-575e-df4bff9d0d6d@xs4all.nl> Message-ID: <20200902142419.Horde.J6EIkd0uSUOP9oM5txT0gA3@webmail.df.eu> Hi John, thanks for the clarification :) Hmm .. but then it's not really a PR against JDK-8185886 (scrolling performance was always bad with many columns) but against - yet to be reported - side-effect of JDK-8090322 which happens to detoriate tableView performance even further (there might be other side-effects)? -- Jeanette Zitat von John Hendrikx : > The "dynamic update performance" performance issue we are seeing is > a regression from JDK-8090322. In this change the Node treeShowing > property was introduced. The JDK-8090322 warns in its description > about: > > """ Considerations: > * This is too expensive to calculate for all nodes by default. So > the simplest way to provide it would be a special binding > implementation or a util class. Where you create a instance and pass > in the node you are interested in. It can then register listeners > all the way up the tree and listen to what it needs. """ > > The above comment is warning against the fact that registering > listeners for EACH Node on Window and Scene is going to be a > performance issue. As nodes can number in the 1000's or 10.000's, > that's a lot of listeners to store in a List data structure. > > PR 185 targets this issue and implements the feature in JDK-8090322 in > the way that was suggested in the above comment, instead of how it > currently is implemented (registering listeners for every Node, just > in case someone needs the treeShowing property). > > It's scope is not as broad as it would seem (because of a change in > Node). It effectively only makes a small change in two controls > (PopupWindow and ProgressIndicatorSkin). > > --John > > > > On 31/08/2020 16:54, Jeanette Winzenburg wrote: >> >> Looking at the examples provided in 108/125: apart from both having many >> columns (> 300 makes them really nasty) they differ in >> >> Table content: >> 125 - static data >> 108 - items are frequently modified (added) >> >> Perceived performance: >> 125 - vertical scrolling: thumb/content lags behind mouse >> 108 - with enough columns, all interaction is sluggish (mouse, keys, >> ..), scrolling being just one of them >> >> Both have examples, running those against the suggested fixes (with 108a >> for Jose's approach) >> 125 - fixes its own example, does nothing for the other >> 108, 108a, 185 - improves its own example, does nothing for other >> >> So we seem to have multiple issues that are (mostly) orthogonal: one >> being the broken/missing horizontal virtualization (125), the other >> related to dynamic update of table content (108, 108a, 185). We need to >> solve both, the solution/s for one looks (mostly?) unrelated to the >> solution to the other. >> >> 125 is the only one PR for its use-case, and it seems to do its job. >> From those targeting the dynamic data update all except Jose's (not yet >> formalized into a PR) approach feel too broad: table's reaction to items >> modifications is .. suboptimal in more than one aspect. Changing overall >> notification implementation to improve that, sounds like covering it up. >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> Sorry for the badly formatted html. Here it is again. >>> >>> I see some progress being made on the {Tree}TableView performance >>> issue. To summarize where I think we are: >>> >>> There are currently 2 different approaches under review: >>> >>> 1. https://github.com/openjdk/jfx/pull/108 : optimization in >>> javafx.base to make removing listeners faster >>> 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView >>> to reduce the number of add / removes >>> >>> In addition, the following is a WIP PR that the author thinks could be >>> a 3rd approach: >>> >>> 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene >>> graph to avoid install treeShowing listeners on Window and Scene for >>> all nodes >>> >>> Jose has proposed a 4th approach as a comment to PR #108, and as I >>> understand it, he will propose a PR shortly. >>> >>> 4. Don't clear the list of children in a VirtualFlow when the number >>> of items changes. >>> >>> So the first thing that is needed is to evaluate the approaches and >>> decide which one to pursue. >>> >>> Options 1 and 3 are more broad in their scope, option #2 is more >>> targeted (to TableView), but within that area is a larger change. >>> Option #3 would remove the (internal) treeShowing property as a >>> generally available concept and only use it for controls like >>> ProgressIndicator that really need it. Option #4 affects only controls >>> that use VirtualFlow (ListView, TableVIew, TreeTableView), and seems >>> not to be a large change (presuming we can verify that no leak is >>> introduced). >>> >>> I note that these fixes are not mutually exclusive, but I do think we >>> need to settle on a primary approach and use that to fix this issue. >>> If there are still performance problems after that fix, we can >>> consider one (or more) of the others. >>> >>> Comments? >>> >>> -- Kevin >> >> >> From kcr at openjdk.java.net Wed Sep 2 15:35:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Sep 2020 15:35:32 GMT Subject: RFR: 8252062: WebKit build fails with recent VS 2019 compiler In-Reply-To: References: Message-ID: On Wed, 2 Sep 2020 11:22:45 GMT, Arun Joseph wrote: > The WebKit build fails with recent VS 2019 compiler. > > Bug: This MediaQueryEvaluator constructor takes a String parameter, but the conversion of char* to String is failing. > > Fix: Use the default constructor of MediaQueryEvaluator, which also returns true for "all". > > Test: Build webkit with the recent VS 2019 compiler with and without this fix. It should fail without the fix and build > with the fix. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/294 From kcr at openjdk.java.net Wed Sep 2 15:48:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Sep 2020 15:48:28 GMT Subject: RFR: 8252062: WebKit build fails with recent VS 2019 compiler In-Reply-To: References: Message-ID: On Wed, 2 Sep 2020 15:33:23 GMT, Kevin Rushforth wrote: >> The WebKit build fails with recent VS 2019 compiler. >> >> Bug: This MediaQueryEvaluator constructor takes a String parameter, but the conversion of char* to String is failing. >> >> Fix: Use the default constructor of MediaQueryEvaluator, which also returns true for "all". >> >> Test: Build webkit with the recent VS 2019 compiler with and without this fix. It should fail without the fix and build >> with the fix. > > Marked as reviewed by kcr (Lead). This is simple enough that a single reviewer will suffice. ------------- PR: https://git.openjdk.java.net/jfx/pull/294 From ajoseph at openjdk.java.net Wed Sep 2 15:48:29 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 2 Sep 2020 15:48:29 GMT Subject: Integrated: 8252062: WebKit build fails with recent VS 2019 compiler In-Reply-To: References: Message-ID: On Wed, 2 Sep 2020 11:22:45 GMT, Arun Joseph wrote: > The WebKit build fails with recent VS 2019 compiler. > > Bug: This MediaQueryEvaluator constructor takes a String parameter, but the conversion of char* to String is failing. > > Fix: Use the default constructor of MediaQueryEvaluator, which also returns true for "all". > > Test: Build webkit with the recent VS 2019 compiler with and without this fix. It should fail without the fix and build > with the fix. This pull request has now been integrated. Changeset: 8e3616cf Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/8e3616cf Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8252062: WebKit build fails with recent VS 2019 compiler Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/294 From nlisker at openjdk.java.net Wed Sep 2 16:59:44 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 2 Sep 2020 16:59:44 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Tue, 1 Sep 2020 23:09:39 GMT, Kevin Rushforth wrote: >>> gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests MyTest >> >> What format is `MyTest`? Is it some relative path? > > It can either be a fully qualified class name (with `.` as separator) or the unqualified name of the test class. The > class name must end with exactly `Test`. So for example, try it with `Snapshot1Test`. I wrote the following test: import static org.junit.Assert.assertTrue; import static org.junit.Assert.fail; import java.util.concurrent.CountDownLatch; import java.util.concurrent.TimeUnit; import org.junit.AfterClass; import org.junit.BeforeClass; import org.junit.Test; import javafx.application.Application; import javafx.application.Platform; import javafx.scene.Group; import javafx.scene.PointLight; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.shape.Box; import javafx.stage.Stage; import javafx.stage.WindowEvent; public class PointLightAttenuationTest { private static CountDownLatch startupLatch; private static Stage stage; private static PointLight light = new PointLight(Color.BLUE); private static Box box = new Box(100, 100, 1); @BeforeClass public static void initFX() throws Exception { startupLatch = new CountDownLatch(1); new Thread(() -> Application.launch(TestApp.class, (String[])null)).start(); assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); } public class TestApp extends Application { @Override public void start(Stage mainStage) { stage = mainStage; light.setTranslateZ(-50); var root = new Group(light, box); var scene = new Scene(root); stage.setScene(scene); stage.setFullScreen(true); stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e -> Platform.runLater(startupLatch::countDown)); stage.show(); } } @Test public void testAttenuation() { var image = box.snapshot(null, null); var nonAttenColor = image.getPixelReader().getColor(1, 1); light.setLinearAttenuation(2); image = box.snapshot(null, null); var attenColor = image.getPixelReader().getColor(1, 1); System.out.println(nonAttenColor); System.out.println(attenColor); if (nonAttenColor.getBlue() > attenColor.getBlue()) { throw new AssertionError("Attenuation color should be less than non-attenuated"); } } @AfterClass public static void teardown() { Platform.runLater(() -> { stage.hide(); Platform.exit(); }); } } But when executing it with ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests PointLightAttenuationTest I get the error test.javafx.scene.lighting3D.PointLightAttenuationTest > classMethod FAILED java.lang.AssertionError: Timeout waiting for FX runtime to start at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.javafx.scene.lighting3D.PointLightAttenuationTest.initFX(PointLightAttenuationTest.java:59) So for some reason the Application doesn't start, it seems. I ran `ShapeViewOrderLeakTest` and `RestoreSceneSizeTest` which look the same, and those work. Any idea? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Wed Sep 2 17:18:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Sep 2020 17:18:14 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Wed, 2 Sep 2020 16:57:25 GMT, Nir Lisker wrote: >> It can either be a fully qualified class name (with `.` as separator) or the unqualified name of the test class. The >> class name must end with exactly `Test`. So for example, try it with `Snapshot1Test`. > > I wrote the following test: > > import static org.junit.Assert.assertTrue; > import static org.junit.Assert.fail; > > import java.util.concurrent.CountDownLatch; > import java.util.concurrent.TimeUnit; > > import org.junit.AfterClass; > import org.junit.BeforeClass; > import org.junit.Test; > > import javafx.application.Application; > import javafx.application.Platform; > import javafx.scene.Group; > import javafx.scene.PointLight; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.shape.Box; > import javafx.stage.Stage; > import javafx.stage.WindowEvent; > > public class PointLightAttenuationTest { > > private static CountDownLatch startupLatch; > private static Stage stage; > private static PointLight light = new PointLight(Color.BLUE); > private static Box box = new Box(100, 100, 1); > > @BeforeClass > public static void initFX() throws Exception { > startupLatch = new CountDownLatch(1); > new Thread(() -> Application.launch(TestApp.class, (String[])null)).start(); > assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); > } > > public class TestApp extends Application { > > @Override > public void start(Stage mainStage) { > stage = mainStage; > light.setTranslateZ(-50); > var root = new Group(light, box); > var scene = new Scene(root); > stage.setScene(scene); > stage.setFullScreen(true); > stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e -> Platform.runLater(startupLatch::countDown)); > stage.show(); > } > } > > @Test > public void testAttenuation() { > var image = box.snapshot(null, null); > var nonAttenColor = image.getPixelReader().getColor(1, 1); > > light.setLinearAttenuation(2); > image = box.snapshot(null, null); > var attenColor = image.getPixelReader().getColor(1, 1); > > System.out.println(nonAttenColor); > System.out.println(attenColor); > if (nonAttenColor.getBlue() > attenColor.getBlue()) { > throw new AssertionError("Attenuation color should be less than non-attenuated"); > } > } > > @AfterClass > public static void teardown() { > Platform.runLater(() -> { > stage.hide(); > Platform.exit(); > }); > } > } > But when executing it with > > ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests PointLightAttenuationTest > > I get the error > > test.javafx.scene.lighting3D.PointLightAttenuationTest > classMethod FAILED > java.lang.AssertionError: Timeout waiting for FX runtime to start > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at test.javafx.scene.lighting3D.PointLightAttenuationTest.initFX(PointLightAttenuationTest.java:59) > > So for some reason the Application doesn't start, it seems. I ran `ShapeViewOrderLeakTest` and `RestoreSceneSizeTest` > which look the same, and those work. Any idea? If you run it with `--info` you will see something like this: test.javafx.scene.shape.PointLightAttenuationTest STANDARD_ERROR Exception in Application constructor Exception in thread "Thread-4" java.lang.RuntimeException: Unable to construct Application instance: class test.javafx.scene.shape.PointLightAttenuationTest$TestApp at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:890) at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) at java.base/java.lang.Thread.run(Thread.java:832) Caused by: java.lang.NoSuchMethodException: test.javafx.scene.shape.PointLightAttenuationTest$TestApp.() at java.base/java.lang.Class.getConstructor0(Class.java:3427) at java.base/java.lang.Class.getConstructor(Class.java:2165) at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:801) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:455) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) ... 1 more The nested `TestApp` class should be declared as `static`. Btw, I don't recommend using `setFullScreen` for a test such as this. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From hjohn at xs4all.nl Wed Sep 2 19:31:04 2020 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 2 Sep 2020 21:31:04 +0200 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <20200902142419.Horde.J6EIkd0uSUOP9oM5txT0gA3@webmail.df.eu> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> <2bca9ed5-a71f-37e1-575e-df4bff9d0d6d@xs4all.nl> <20200902142419.Horde.J6EIkd0uSUOP9oM5txT0gA3@webmail.df.eu> Message-ID: <722ac9f2-858c-cf62-6700-e2d0d10156d4@xs4all.nl> Hi Jeanette, Thanks for taking a look. The PR was sort of inspired by JDK-8185886 (PR 108) because changes were made there to make performance with long listener lists better (by using a Map structure). I wanted to know the root cause of the long lists, and found out that the long lists are on properties carried by Window and Scene. This then was traced to the treeShowing property in Node which registers listeners on Window and Scene. I think Kevin then mentioned the JDK-8090322 issue which gave me further background on why the treeShowing solution was introduced. The change I proposed to fix this regression was also tested by the author of PR 108 (Danny Gonzalez) and addressed the issue as well, see this comment: https://github.com/openjdk/jfx/pull/108#issuecomment-615125904 I'm not aware of any other side effects of the change introduces with JDK-8090322, but anything with lots of nodes in a single scene (in the thousands) may see some performance degradation when adding/removing nodes -- complex Tables or TreeTables are the primary culprit. It might also affect the performance of hiding/showing a Window (when there are many nodes), but that's not an action that is usually done a lot. I did not include a JDK number -- I can include JDK-8185886 as it was supposed to address that issue, or file a new issue referring both that issue and JDK-8090322. I donot think it will fix the performance issue with having many columns in a table, although it may reduce its impact a bit. The issue there is more that columns are not virtualized, so a table rotated 90 degrees would exhibit the same problems as an unvirtualized table would because of the sheer number of nodes involved. --John On 02/09/2020 14:24, Jeanette Winzenburg wrote: > > Hi John, > > thanks for the clarification :) > > Hmm .. but then it's not really a PR against JDK-8185886 (scrolling > performance was always bad with many columns) but against - yet to be > reported - side-effect of JDK-8090322 which happens to detoriate > tableView performance even further (there might be other side-effects)? > > -- Jeanette > > Zitat von John Hendrikx : > >> The "dynamic update performance" performance issue we are seeing is a >> regression from JDK-8090322. In this change the Node treeShowing >> property was introduced. The JDK-8090322 warns in its description about: >> >> """ Considerations: >> * This is too expensive to calculate for all nodes by default. So the >> simplest way to provide it would be a special binding implementation >> or a util class. Where you create a instance and pass in the node you >> are interested in. It can then register listeners all the way up the >> tree and listen to what it needs. """ >> >> The above comment is warning against the fact that registering >> listeners for EACH Node on Window and Scene is going to be a >> performance issue. As nodes can number in the 1000's or 10.000's, >> that's a lot of listeners to store in a List data structure. >> >> PR 185 targets this issue and implements the feature in JDK-8090322 in >> the way that was suggested in the above comment, instead of how it >> currently is implemented (registering listeners for every Node, just >> in case someone needs the treeShowing property). >> >> It's scope is not as broad as it would seem (because of a change in >> Node). It effectively only makes a small change in two controls >> (PopupWindow and ProgressIndicatorSkin). >> >> --John >> >> >> >> On 31/08/2020 16:54, Jeanette Winzenburg wrote: >>> >>> Looking at the examples provided in 108/125: apart from both having many >>> columns (> 300 makes them really nasty) they differ in >>> >>> Table content: >>> 125 - static data >>> 108 - items are frequently modified (added) >>> >>> Perceived performance: >>> 125 - vertical scrolling: thumb/content lags behind mouse >>> 108 - with enough columns, all interaction is sluggish (mouse, keys, >>> ..), scrolling being just one of them >>> >>> Both have examples, running those against the suggested fixes (with 108a >>> for Jose's approach) >>> 125 - fixes its own example, does nothing for the other >>> 108, 108a, 185 - improves its own example, does nothing for other >>> >>> So we seem to have multiple issues that are (mostly) orthogonal: one >>> being the broken/missing horizontal virtualization (125), the other >>> related to dynamic update of table content (108, 108a, 185). We need to >>> solve both, the solution/s for one looks (mostly?) unrelated to the >>> solution to the other. >>> >>> 125 is the only one PR for its use-case, and it seems to do its job. >>> From those targeting the dynamic data update all except Jose's (not yet >>> formalized into a PR) approach feel too broad: table's reaction to items >>> modifications is .. suboptimal in more than one aspect. Changing overall >>> notification implementation to improve that, sounds like covering it up. >>> >>> -- Jeanette >>> >>> Zitat von Kevin Rushforth : >>> >>>> Sorry for the badly formatted html. Here it is again. >>>> >>>> I see some progress being made on the {Tree}TableView performance >>>> issue. To summarize where I think we are: >>>> >>>> There are currently 2 different approaches under review: >>>> >>>> 1. https://github.com/openjdk/jfx/pull/108 : optimization in >>>> javafx.base to make removing listeners faster >>>> 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView >>>> to reduce the number of add / removes >>>> >>>> In addition, the following is a WIP PR that the author thinks could be >>>> a 3rd approach: >>>> >>>> 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene >>>> graph to avoid install treeShowing listeners on Window and Scene for >>>> all nodes >>>> >>>> Jose has proposed a 4th approach as a comment to PR #108, and as I >>>> understand it, he will propose a PR shortly. >>>> >>>> 4. Don't clear the list of children in a VirtualFlow when the number >>>> of items changes. >>>> >>>> So the first thing that is needed is to evaluate the approaches and >>>> decide which one to pursue. >>>> >>>> Options 1 and 3 are more broad in their scope, option #2 is more >>>> targeted (to TableView), but within that area is a larger change. >>>> Option #3 would remove the (internal) treeShowing property as a >>>> generally available concept and only use it for controls like >>>> ProgressIndicator that really need it. Option #4 affects only controls >>>> that use VirtualFlow (ListView, TableVIew, TreeTableView), and seems >>>> not to be a large change (presuming we can verify that no leak is >>>> introduced). >>>> >>>> I note that these fixes are not mutually exclusive, but I do think we >>>> need to settle on a primary approach and use that to fix this issue. >>>> If there are still performance problems after that fix, we can >>>> consider one (or more) of the others. >>>> >>>> Comments? >>>> >>>> -- Kevin >>> >>> >>> > > > From kcr at openjdk.java.net Wed Sep 2 20:32:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Sep 2020 20:32:15 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: References: Message-ID: <5vDqwTCb8tygwB-6S-A1JBGuszF3crdZxjx_fwGYVts=.be332dd9-9334-4508-a828-ba71e6eca605@github.com> On Sat, 29 Aug 2020 14:53:37 GMT, Kevin Rushforth wrote: >> @kevinrushforth Why is the Skara bot saying this PR can be integrated if the CSR is not approved yet? >> >> Also, in the main post under Reviewers, the links to the users lead to a 404. >> >> Should I submit bugs for these? > >> Why is the Skara bot saying this PR can be integrated if the CSR is not approved yet? > > Looks like we both noticed this at the same time. > >> Also, in the main post under Reviewers, the links to the users lead to a 404. > > I hadn't noticed this before. > >> Should I submit bugs for these? > > Yes, please. @bhaweshkc the CSR is approved. Go ahead and `/integrate` when ready. ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From bchoudhary at openjdk.java.net Thu Sep 3 06:07:10 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Thu, 3 Sep 2020 06:07:10 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling [v3] In-Reply-To: References: Message-ID: > ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of > actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue > is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due > to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Updated test as per review comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/279/files - new: https://git.openjdk.java.net/jfx/pull/279/files/a99141df..62dc4592 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=279&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=279&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/279.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/279/head:pull/279 PR: https://git.openjdk.java.net/jfx/pull/279 From ajoseph at openjdk.java.net Thu Sep 3 06:25:43 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 3 Sep 2020 06:25:43 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling [v3] In-Reply-To: References: Message-ID: On Thu, 3 Sep 2020 06:07:10 GMT, Bhawesh Choudhary wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updated test as per review comment The fix and test looks good. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/279 From github.com+7517141+yososs at openjdk.java.net Thu Sep 3 07:13:35 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 3 Sep 2020 07:13:35 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v4] In-Reply-To: References: Message-ID: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import java.util.Arrays; > import java.util.Collections; > > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > private static final boolean USE_WIDTH_FIXED_SIZE = false; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=30; > // private static final int COL_COUNT=300; > // private static final int COL_COUNT=600; > private static final int COL_COUNT = 1000; > private static final int ROW_COUNT = 1000; > > @Override > public void start(final Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > // tableView.setTableMenuButtonVisible(true); //too heavy > if (USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > final ObservableList> columns = tableView.getColumns(); > for (int i = 0; i < COL_COUNT; i++) { > final TableColumn column = new TableColumn<>("Col" + i); > final int colIndex = i; > column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if (USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > final Button load = new Button("load"); > load.setOnAction(e -> { > final ObservableList items = tableView.getItems(); > items.clear(); > for (int i = 0; i < ROW_COUNT; i++) { > final String[] rec = new String[COL_COUNT]; > for (int j = 0; j < rec.length; j++) { > rec[j] = i + ":" + j; > } > items.add(rec); > } > }); > > final Button reverse = new Button("reverse columns"); > reverse.setOnAction(e -> { > final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); > Collections.reverse(Arrays.asList(itemsArray)); > tableView.getColumns().clear(); > tableView.getColumns().addAll(Arrays.asList(itemsArray)); > }); > > final Button hide = new Button("hide % 10"); > hide.setOnAction(e -> { > for (int i = 0, n = columns.size(); i < n; i++) { > if (i % 10 == 0) { > columns.get(i).setVisible(false); > } > } > }); > > final BorderPane root = new BorderPane(tableView); > root.setTop(new HBox(8, load, reverse, hide)); > > final Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > this.prepareTimeline(scene); > } > > public static void main(final String[] args) { > Application.launch(args); > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > } > > Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.application.Platform; > import javafx.beans.property.ReadOnlyStringWrapper; > import javafx.scene.Scene; > import javafx.scene.control.TreeItem; > import javafx.scene.control.TreeTableColumn; > import javafx.scene.control.TreeTableColumn.CellDataFeatures; > import javafx.scene.control.TreeTableView; > import javafx.stage.Stage; > > public class BigTreeTableViewTest extends Application { > > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT = 900; > private static final int COL_COUNT = 800; > // private static final int COL_COUNT = 600; > // private static final int COL_COUNT = 500; > // private static final int COL_COUNT = 400; > // private static final int COL_COUNT = 300; > // private static final int COL_COUNT = 200; > // private static final int COL_COUNT = 100; > > public static void main(final String[] args) { > Application.launch(args); > } > > @Override > public void start(final Stage stage) { > final TreeItem root = new TreeItem<>("Root"); > final TreeTableView treeTableView = new TreeTableView<>(root); > if (USE_HEIGHT_FIXED_SIZE) { > treeTableView.setFixedCellSize(24); > } > treeTableView.setPrefWidth(800); > treeTableView.setPrefHeight(500); > stage.setWidth(800); > stage.setHeight(500); > > Platform.runLater(() -> { > for (int i = 0; i < 100; i++) { > TreeItem child = this.addNodes(root); > child = this.addNodes(child); > child = this.addNodes(child); > child = this.addNodes(child); > } > }); > > final TreeTableColumn[] cols = new TreeTableColumn[COL_COUNT + 1]; > final TreeTableColumn column = new TreeTableColumn<>("Column"); > column.setPrefWidth(150); > column.setCellValueFactory( > (final CellDataFeatures p) -> new ReadOnlyStringWrapper(p.getValue().getValue())); > cols[0] = column; > > for (int i = 0; i < COL_COUNT; i++) { > final TreeTableColumn col = new TreeTableColumn<>(Integer.toString(i)); > col.setPrefWidth(60); > col.setCellValueFactory(val -> new > ReadOnlyStringWrapper(val.getValue().getValue()+":"+val.getTreeTableColumn().getText())); cols[i + 1] = col; > } > treeTableView.getColumns().addAll(cols); > > final Scene scene = new Scene(treeTableView, 800, 500); > stage.setScene(scene); > stage.show(); > this.prepareTimeline(scene); > } > > private TreeItem addNodes(final TreeItem parent) { > > final TreeItem[] childNodes = new TreeItem[20]; > for (int i = 0; i < childNodes.length; i++) { > childNodes[i] = new TreeItem<>("N" + i); > } > final TreeItem root = new TreeItem<>("dir"); > root.setExpanded(true); > root.getChildren().addAll(childNodes); > parent.setExpanded(true); > parent.getChildren().add(root); > return root; > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > > } yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8185886: Fix scroll performance of TableView with many columns ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/125/files - new: https://git.openjdk.java.net/jfx/pull/125/files/dcbbfdcd..c81dd2e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=125&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=125&range=02-03 Stats: 55 lines in 5 files changed: 28 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jfx/pull/125.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/125/head:pull/125 PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+7517141+yososs at openjdk.java.net Thu Sep 3 07:47:17 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 3 Sep 2020 07:47:17 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v4] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> Message-ID: On Wed, 2 Sep 2020 10:46:48 GMT, Jeanette Winzenburg wrote: >> When the startup time is measured by eye, the impression changes depending on the individual difference. >> The effect of runLater affects your experience. >> >> However, I succeeded in further improving performance by eliminating another bottleneck in TreeTableView. Of course, it >> also includes improvements in startup time. >> I plan to commit at a later date. > >> >> >> When the startup time is measured by eye, the impression changes depending on the individual difference. > > my eye is a precision instrument :) Seriously, who would do such a thingy? Obviously, it must be measured, for zeroth > approximation doing so crudely by comparing currentMillis before/after showing is good enough to "see" the tendency. >> The effect of runLater affects your experience. > > that's why you shouldn't do it when trying to gain insight into timing issues ;) > >> >> However, I succeeded in further improving performance by eliminating another bottleneck in TreeTableView. Of course, it >> also includes improvements in startup time. > > cool :) Column virtualization causes shortness of breath when scrolling a large stroke horizontally. This does not happen when stroking on the scrollbar. Looks like a potential problem with VirtualFlow. If you are worried about shortness of breath, the following code will help reduce the problem. Java ?private static final int OVERLAP_MARGIN = 500; private static boolean isOverlap(double start, double end, double start2, double end2){ start = Math.max(start-OVERLAP_MARGIN, start2); end = Math.min(end+OVERLAP_MARGIN, end2); return (start<=end2 && end >= start2); } ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From bchoudhary at openjdk.java.net Thu Sep 3 10:04:40 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Thu, 3 Sep 2020 10:04:40 GMT Subject: Integrated: 8252387: Deprecate for removal css Selector and ShapeConverter constructors In-Reply-To: References: Message-ID: On Fri, 28 Aug 2020 14:55:55 GMT, Bhawesh Choudhary wrote: > Deprecate the public constructor of javafx.css.Selector as it should not be public due to only being extended by > classes in same package. Deprecate the public constructor of javafx.css.converter.ShapeConverter as its a singleton > class. This pull request has now been integrated. Changeset: a5ecfb68 Author: Bhawesh Choudhary Committer: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/a5ecfb68 Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod 8252387: Deprecate for removal css Selector and ShapeConverter constructors Reviewed-by: nlisker, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From kcr at openjdk.java.net Thu Sep 3 15:23:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Sep 2020 15:23:21 GMT Subject: RFR: 8252446: Screen.getScreens() is empty sometimes Message-ID: As noted in the bug report, we get a pair of change events every time the list of screens changes. First, a change is sent with an empty list of screens and then a change is sent with the new list of screens. This happens whenever a monitor is plugged in or unplugged. It also happens on Mac at application startup. As noted in the bug the reason for this is because the `updateConfiguration` method makes two separate calls on the list of screens, `clear` and `addAll`, rather than calling `setAll`. The latter ensures that only a single change event is delivered. I verified that before this fix, the example program attached to the bug works correctly after the fix. I wrote a unit test. It ends up being skipped on Windows and Linux since we don't get an initial change event. On Mac the test fails without the fix and passes with the fix. ------------- Commit messages: - 8252446: Screen.getScreens() is empty sometimes Changes: https://git.openjdk.java.net/jfx/pull/295/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=295&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252446 Stats: 107 lines in 2 files changed: 103 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/295.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/295/head:pull/295 PR: https://git.openjdk.java.net/jfx/pull/295 From kcr at openjdk.java.net Thu Sep 3 17:41:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Sep 2020 17:41:30 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling [v3] In-Reply-To: References: Message-ID: <6H4nJ0dy5cVQYamWgZ2qUef9UyCdwAmxITFrnylIGrY=.db08bbda-287a-44b5-91aa-3edda21b1e0a@github.com> On Thu, 3 Sep 2020 06:07:10 GMT, Bhawesh Choudhary wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updated test as per review comment Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/279 From bchoudhary at openjdk.java.net Thu Sep 3 19:13:35 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Thu, 3 Sep 2020 19:13:35 GMT Subject: Integrated: 8202990: javafx webview css filter property with display scaling In-Reply-To: References: Message-ID: On Tue, 11 Aug 2020 16:18:37 GMT, Bhawesh Choudhary wrote: > ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of > actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue > is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due > to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. This pull request has now been integrated. Changeset: 3cb3ca84 Author: Bhawesh Choudhary Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/3cb3ca84 Stats: 200 lines in 4 files changed: 0 ins; 199 del; 1 mod 8202990: javafx webview css filter property with display scaling Reviewed-by: kcr, ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/279 From kevin.rushforth at oracle.com Thu Sep 3 23:46:24 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 Sep 2020 16:46:24 -0700 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <20200902142419.Horde.J6EIkd0uSUOP9oM5txT0gA3@webmail.df.eu> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> <2bca9ed5-a71f-37e1-575e-df4bff9d0d6d@xs4all.nl> <20200902142419.Horde.J6EIkd0uSUOP9oM5txT0gA3@webmail.df.eu> Message-ID: <2d57f205-239b-2ec7-fe05-ceb8c368378a@oracle.com> It seems clear now that we will need 3 different JBS issues for these proposed performance enhancements. It's a holiday weekend coming up in the US, so I can file the other two issues unless someone else gets to it first. Unless there is a good reason to do otherwise, I propose: The JBS Issue associated with PR #108 should be filed against javafx/base The JBS Issue associated with PR #125 should be filed against javafx/controls (or we can reuse JDK-8185886) The JBS Issue associated with PR #185 should be filed against javafx/scenegraph Jose: Is you approach an alternative to one of the above or could it be considered a 4th approach? If the latter, can you file a new JBS Issue for that? -- Kevin On 9/2/2020 5:24 AM, Jeanette Winzenburg wrote: > > Hi John, > > thanks for the clarification :) > > Hmm .. but then it's not really a PR against JDK-8185886 (scrolling > performance was always bad with many columns) but against - yet to be > reported - side-effect of JDK-8090322 which happens to detoriate > tableView performance even further (there might be other side-effects)? > > -- Jeanette > > Zitat von John Hendrikx : > >> The "dynamic update performance" performance issue we are seeing is a >> regression from JDK-8090322.? In this change the Node treeShowing >> property was introduced.? The JDK-8090322 warns in its description >> about: >> >> """??? Considerations: >> * This is too expensive to calculate for all nodes by default. So the >> simplest way to provide it would be a special binding implementation >> or a util class. Where you create a instance and pass in the node you >> are interested in. It can then register listeners all the way up the >> tree and listen to what it needs. """ >> >> The above comment is warning against the fact that registering >> listeners for EACH Node on Window and Scene is going to be a >> performance issue. As nodes can number in the 1000's or 10.000's, >> that's a lot of listeners to store in a List data structure. >> >> PR 185 targets this issue and implements the feature in JDK-8090322 in >> the way that was suggested in the above comment, instead of how it >> currently is implemented (registering listeners for every Node, just >> in case someone needs the treeShowing property). >> >> It's scope is not as broad as it would seem (because of a change in >> Node).? It effectively only makes a small change in two controls >> (PopupWindow and ProgressIndicatorSkin). >> >> --John >> >> >> >> On 31/08/2020 16:54, Jeanette Winzenburg wrote: >>> >>> Looking at the examples provided in 108/125: apart from both having >>> many >>> columns (> 300 makes them really nasty) they differ in >>> >>> Table content: >>> 125 - static data >>> 108 - items are frequently modified (added) >>> >>> Perceived performance: >>> 125 - vertical scrolling: thumb/content lags behind mouse >>> 108 - with enough columns, all interaction is sluggish (mouse, keys, >>> ..), scrolling being just one of them >>> >>> Both have examples, running those against the suggested fixes (with >>> 108a >>> for Jose's approach) >>> 125 - fixes its own example, does nothing for the other >>> 108, 108a, 185 - improves its own example, does nothing for other >>> >>> So we seem to have multiple issues that are (mostly) orthogonal: one >>> being the broken/missing horizontal virtualization (125), the other >>> related to dynamic update of table content (108, 108a, 185). We need to >>> solve both, the solution/s for one looks (mostly?) unrelated to the >>> solution to the other. >>> >>> 125 is the only one PR for its use-case, and it seems to do its job. >>> From those targeting the dynamic data update all except Jose's (not yet >>> formalized into a PR) approach feel too broad: table's reaction to >>> items >>> modifications is .. suboptimal in more than one aspect. Changing >>> overall >>> notification implementation to improve that, sounds like covering it >>> up. >>> >>> -- Jeanette >>> >>> Zitat von Kevin Rushforth : >>> >>>> Sorry for the badly formatted html. Here it is again. >>>> >>>> I see some progress being made on the {Tree}TableView performance >>>> issue. To summarize where I think we are: >>>> >>>> There are currently 2 different approaches under review: >>>> >>>> 1. https://github.com/openjdk/jfx/pull/108 : optimization in >>>> javafx.base to make removing listeners faster >>>> 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView >>>> to reduce the number of add / removes >>>> >>>> In addition, the following is a WIP PR that the author thinks could be >>>> a 3rd approach: >>>> >>>> 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene >>>> graph to avoid install treeShowing listeners on Window and Scene for >>>> all nodes >>>> >>>> Jose has proposed a 4th approach as a comment to PR #108, and as I >>>> understand it, he will propose a PR shortly. >>>> >>>> 4. Don't clear the list of children in a VirtualFlow when the number >>>> of items changes. >>>> >>>> So the first thing that is needed is to evaluate the approaches and >>>> decide which one to pursue. >>>> >>>> Options 1 and 3 are more broad in their scope, option #2 is more >>>> targeted (to TableView), but within that area is a larger change. >>>> Option #3 would remove the (internal) treeShowing property as a >>>> generally available concept and only use it for controls like >>>> ProgressIndicator that really need it. Option #4 affects only controls >>>> that use VirtualFlow (ListView, TableVIew, TreeTableView), and seems >>>> not to be a large change (presuming we can verify that no leak is >>>> introduced). >>>> >>>> I note that these fixes are not mutually exclusive, but I do think we >>>> need to settle on a primary approach and use that to fix this issue. >>>> If there are still performance problems after that fix, we can >>>> consider one (or more) of the others. >>>> >>>> Comments? >>>> >>>> -- Kevin >>> >>> >>> > > > From jvos at openjdk.java.net Fri Sep 4 09:28:56 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 4 Sep 2020 09:28:56 GMT Subject: [jfx15] RFR: 8252784: Create release notes for JavaFX 15 Message-ID: Fix for JDK-8252784 ------------- Commit messages: - add links - Add release notes for JavaFX 15 Changes: https://git.openjdk.java.net/jfx/pull/296/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=296&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252784 Stats: 125 lines in 1 file changed: 125 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/296/head:pull/296 PR: https://git.openjdk.java.net/jfx/pull/296 From kcr at openjdk.java.net Fri Sep 4 11:54:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Sep 2020 11:54:25 GMT Subject: [jfx15] RFR: 8252784: Create release notes for JavaFX 15 In-Reply-To: References: Message-ID: On Fri, 4 Sep 2020 09:23:52 GMT, Johan Vos wrote: > Fix for JDK-8252784 Looks fine. Did you want to add a note about the additional Javascript bridge restrictions, similar to [this note](https://github.com/openjdk/jfx/blob/331a39be016a284e5495c73726e7b58e7769a75e/doc-files/release-notes-14.0.1.md#list-of-security-fixes) that was done for 14.0.1? Either way is fine with me. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/296 From nlisker at openjdk.java.net Fri Sep 4 14:37:04 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 4 Sep 2020 14:37:04 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Wed, 2 Sep 2020 17:16:00 GMT, Kevin Rushforth wrote: >> I wrote the following test: >> >> import static org.junit.Assert.assertTrue; >> import static org.junit.Assert.fail; >> >> import java.util.concurrent.CountDownLatch; >> import java.util.concurrent.TimeUnit; >> >> import org.junit.AfterClass; >> import org.junit.BeforeClass; >> import org.junit.Test; >> >> import javafx.application.Application; >> import javafx.application.Platform; >> import javafx.scene.Group; >> import javafx.scene.PointLight; >> import javafx.scene.Scene; >> import javafx.scene.paint.Color; >> import javafx.scene.shape.Box; >> import javafx.stage.Stage; >> import javafx.stage.WindowEvent; >> >> public class PointLightAttenuationTest { >> >> private static CountDownLatch startupLatch; >> private static Stage stage; >> private static PointLight light = new PointLight(Color.BLUE); >> private static Box box = new Box(100, 100, 1); >> >> @BeforeClass >> public static void initFX() throws Exception { >> startupLatch = new CountDownLatch(1); >> new Thread(() -> Application.launch(TestApp.class, (String[])null)).start(); >> assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); >> } >> >> public class TestApp extends Application { >> >> @Override >> public void start(Stage mainStage) { >> stage = mainStage; >> light.setTranslateZ(-50); >> var root = new Group(light, box); >> var scene = new Scene(root); >> stage.setScene(scene); >> stage.setFullScreen(true); >> stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e -> Platform.runLater(startupLatch::countDown)); >> stage.show(); >> } >> } >> >> @Test >> public void testAttenuation() { >> var image = box.snapshot(null, null); >> var nonAttenColor = image.getPixelReader().getColor(1, 1); >> >> light.setLinearAttenuation(2); >> image = box.snapshot(null, null); >> var attenColor = image.getPixelReader().getColor(1, 1); >> >> System.out.println(nonAttenColor); >> System.out.println(attenColor); >> if (nonAttenColor.getBlue() > attenColor.getBlue()) { >> throw new AssertionError("Attenuation color should be less than non-attenuated"); >> } >> } >> >> @AfterClass >> public static void teardown() { >> Platform.runLater(() -> { >> stage.hide(); >> Platform.exit(); >> }); >> } >> } >> But when executing it with >> >> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests PointLightAttenuationTest >> >> I get the error >> >> test.javafx.scene.lighting3D.PointLightAttenuationTest > classMethod FAILED >> java.lang.AssertionError: Timeout waiting for FX runtime to start >> at org.junit.Assert.fail(Assert.java:91) >> at org.junit.Assert.assertTrue(Assert.java:43) >> at test.javafx.scene.lighting3D.PointLightAttenuationTest.initFX(PointLightAttenuationTest.java:59) >> >> So for some reason the Application doesn't start, it seems. I ran `ShapeViewOrderLeakTest` and `RestoreSceneSizeTest` >> which look the same, and those work. Any idea? > > If you run it with `--info` you will see something like this: > > test.javafx.scene.shape.PointLightAttenuationTest STANDARD_ERROR > Exception in Application constructor > Exception in thread "Thread-4" java.lang.RuntimeException: Unable to construct Application instance: class > test.javafx.scene.shape.PointLightAttenuationTest$TestApp > at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:890) > at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) > at java.base/java.lang.Thread.run(Thread.java:832) > Caused by: java.lang.NoSuchMethodException: test.javafx.scene.shape.PointLightAttenuationTest$TestApp.() > at java.base/java.lang.Class.getConstructor0(Class.java:3427) > at java.base/java.lang.Class.getConstructor(Class.java:2165) > at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:801) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:455) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > ... 1 more > > The nested `TestApp` class should be declared as `static`. Btw, I don't recommend using `setFullScreen` for a test such > as this. Thanks, the test runs now, but I've run into an issue with `snapshot`. `Node#snapshot` uses its scene parameters (like lights) to render the image, but if the node is in a subscene then the image will be wrong since it takes the wrong data. Bounds transforms like `sceneToLocal` and `localToScene` do take care of this case. I think that this is a mistake in `snapshot`, and maybe it should use the subscene, or a `boolean subScene` parameter should be offered, or `SnapshotParameters` should allow to specify it. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From jose.pereda at gluonhq.com Fri Sep 4 16:04:10 2020 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Fri, 4 Sep 2020 18:04:10 +0200 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <2d57f205-239b-2ec7-fe05-ceb8c368378a@oracle.com> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> <2bca9ed5-a71f-37e1-575e-df4bff9d0d6d@xs4all.nl> <20200902142419.Horde.J6EIkd0uSUOP9oM5txT0gA3@webmail.df.eu> <2d57f205-239b-2ec7-fe05-ceb8c368378a@oracle.com> Message-ID: I've filed https://bugs.openjdk.java.net/browse/JDK-8252811 (under javafx/controls). I believe this is not an alternative to any of the other three issues, but obviously a less invasive one, as it only implies changes in VirtualFlow. Once tackled, it should directly increase performance and reduce CPU usage of TableView/TreeTableView/ListView controls when their items change frequently. But it will also benefit from the improvements of the other three approaches. Jose On Fri, Sep 4, 2020 at 1:46 AM Kevin Rushforth wrote: > It seems clear now that we will need 3 different JBS issues for these > proposed performance enhancements. It's a holiday weekend coming up in > the US, so I can file the other two issues unless someone else gets to > it first. Unless there is a good reason to do otherwise, I propose: > > The JBS Issue associated with PR #108 should be filed against javafx/base > The JBS Issue associated with PR #125 should be filed against > javafx/controls (or we can reuse JDK-8185886) > The JBS Issue associated with PR #185 should be filed against > javafx/scenegraph > > Jose: Is you approach an alternative to one of the above or could it be > considered a 4th approach? If the latter, can you file a new JBS Issue > for that? > > -- Kevin > > > On 9/2/2020 5:24 AM, Jeanette Winzenburg wrote: > > > > Hi John, > > > > thanks for the clarification :) > > > > Hmm .. but then it's not really a PR against JDK-8185886 (scrolling > > performance was always bad with many columns) but against - yet to be > > reported - side-effect of JDK-8090322 which happens to detoriate > > tableView performance even further (there might be other side-effects)? > > > > -- Jeanette > > > > Zitat von John Hendrikx : > > > >> The "dynamic update performance" performance issue we are seeing is a > >> regression from JDK-8090322. In this change the Node treeShowing > >> property was introduced. The JDK-8090322 warns in its description > >> about: > >> > >> """ Considerations: > >> * This is too expensive to calculate for all nodes by default. So the > >> simplest way to provide it would be a special binding implementation > >> or a util class. Where you create a instance and pass in the node you > >> are interested in. It can then register listeners all the way up the > >> tree and listen to what it needs. """ > >> > >> The above comment is warning against the fact that registering > >> listeners for EACH Node on Window and Scene is going to be a > >> performance issue. As nodes can number in the 1000's or 10.000's, > >> that's a lot of listeners to store in a List data structure. > >> > >> PR 185 targets this issue and implements the feature in JDK-8090322 in > >> the way that was suggested in the above comment, instead of how it > >> currently is implemented (registering listeners for every Node, just > >> in case someone needs the treeShowing property). > >> > >> It's scope is not as broad as it would seem (because of a change in > >> Node). It effectively only makes a small change in two controls > >> (PopupWindow and ProgressIndicatorSkin). > >> > >> --John > >> > >> > >> > >> On 31/08/2020 16:54, Jeanette Winzenburg wrote: > >>> > >>> Looking at the examples provided in 108/125: apart from both having > >>> many > >>> columns (> 300 makes them really nasty) they differ in > >>> > >>> Table content: > >>> 125 - static data > >>> 108 - items are frequently modified (added) > >>> > >>> Perceived performance: > >>> 125 - vertical scrolling: thumb/content lags behind mouse > >>> 108 - with enough columns, all interaction is sluggish (mouse, keys, > >>> ..), scrolling being just one of them > >>> > >>> Both have examples, running those against the suggested fixes (with > >>> 108a > >>> for Jose's approach) > >>> 125 - fixes its own example, does nothing for the other > >>> 108, 108a, 185 - improves its own example, does nothing for other > >>> > >>> So we seem to have multiple issues that are (mostly) orthogonal: one > >>> being the broken/missing horizontal virtualization (125), the other > >>> related to dynamic update of table content (108, 108a, 185). We need to > >>> solve both, the solution/s for one looks (mostly?) unrelated to the > >>> solution to the other. > >>> > >>> 125 is the only one PR for its use-case, and it seems to do its job. > >>> From those targeting the dynamic data update all except Jose's (not yet > >>> formalized into a PR) approach feel too broad: table's reaction to > >>> items > >>> modifications is .. suboptimal in more than one aspect. Changing > >>> overall > >>> notification implementation to improve that, sounds like covering it > >>> up. > >>> > >>> -- Jeanette > >>> > >>> Zitat von Kevin Rushforth : > >>> > >>>> Sorry for the badly formatted html. Here it is again. > >>>> > >>>> I see some progress being made on the {Tree}TableView performance > >>>> issue. To summarize where I think we are: > >>>> > >>>> There are currently 2 different approaches under review: > >>>> > >>>> 1. https://github.com/openjdk/jfx/pull/108 : optimization in > >>>> javafx.base to make removing listeners faster > >>>> 2. https://github.com/openjdk/jfx/pull/125 : optimization in > TableView > >>>> to reduce the number of add / removes > >>>> > >>>> In addition, the following is a WIP PR that the author thinks could be > >>>> a 3rd approach: > >>>> > >>>> 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene > >>>> graph to avoid install treeShowing listeners on Window and Scene for > >>>> all nodes > >>>> > >>>> Jose has proposed a 4th approach as a comment to PR #108, and as I > >>>> understand it, he will propose a PR shortly. > >>>> > >>>> 4. Don't clear the list of children in a VirtualFlow when the number > >>>> of items changes. > >>>> > >>>> So the first thing that is needed is to evaluate the approaches and > >>>> decide which one to pursue. > >>>> > >>>> Options 1 and 3 are more broad in their scope, option #2 is more > >>>> targeted (to TableView), but within that area is a larger change. > >>>> Option #3 would remove the (internal) treeShowing property as a > >>>> generally available concept and only use it for controls like > >>>> ProgressIndicator that really need it. Option #4 affects only controls > >>>> that use VirtualFlow (ListView, TableVIew, TreeTableView), and seems > >>>> not to be a large change (presuming we can verify that no leak is > >>>> introduced). > >>>> > >>>> I note that these fixes are not mutually exclusive, but I do think we > >>>> need to settle on a primary approach and use that to fix this issue. > >>>> If there are still performance problems after that fix, we can > >>>> consider one (or more) of the others. > >>>> > >>>> Comments? > >>>> > >>>> -- Kevin > >>> > >>> > >>> > > > > > > > > -- From github.com+4029915+TheMrMilchmann at openjdk.java.net Fri Sep 4 16:48:15 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Fri, 4 Sep 2020 16:48:15 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification Message-ID: Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling `#clear()`), or if 2. it was modified as result of the `#addAll()` call. If you want any test coverage for this please let me know. I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission is still pending anyway.) ------------- Commit messages: - 8251946: Simplify ModifiableObservableListBase#setAll and only special-case two empty lists - 8251946: Correctly compute if the list was modified in ModifiableObservableListBase#setAll Changes: https://git.openjdk.java.net/jfx/pull/284/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=284&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251946 Stats: 23 lines in 3 files changed: 20 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/284/head:pull/284 PR: https://git.openjdk.java.net/jfx/pull/284 From kcr at openjdk.java.net Fri Sep 4 16:48:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Sep 2020 16:48:15 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Tue, 18 Aug 2020 19:50:55 GMT, Leon Linhart wrote: > Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was > actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling > `#clear()`), or if 2. it was modified as result of the `#addAll()` call. > > If you want any test coverage for this please let me know. > > I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see > that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle > JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or > that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission > is still pending anyway.) @TheMrMilchmann I am not actively working on that bug, so you can proceed with this PR. I will review it when it is ready. Once you have submitted the OCA, please add a comment to this PR with the `/signed` command (and nothing else in the comment). After your OCA is approved and recorded, the Skara bot will mark it as ready for review. Please do add a unit test for this. You can find existing collections tests [here](https://github.com/openjdk/jfx/tree/master/modules/javafx.base/src/test/java/test/javafx/collections). ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+4029915+TheMrMilchmann at openjdk.java.net Fri Sep 4 16:48:18 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Fri, 4 Sep 2020 16:48:18 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Thu, 20 Aug 2020 12:54:27 GMT, Kevin Rushforth wrote: >> Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was >> actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling >> `#clear()`), or if 2. it was modified as result of the `#addAll()` call. >> >> If you want any test coverage for this please let me know. >> >> I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see >> that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle >> JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or >> that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission >> is still pending anyway.) > > @TheMrMilchmann I am not actively working on that bug, so you can proceed with this PR. I will review it when it is > ready. > Once you have submitted the OCA, please add a comment to this PR with the `/signed` command (and nothing else in the > comment). After your OCA is approved and recorded, the Skara bot will mark it as ready for review. > Please do add a unit test for this. You can find existing collections tests > [here](https://github.com/openjdk/jfx/tree/master/modules/javafx.base/src/test/java/test/javafx/collections). While adding unit tests, I noticed that I missed an important edge-case that has to be considered when computing if a list was modified. The initial implementation assumed that > the list was modified if >1. it was not empty (modified by calling `#clear()`), or if >2. it was modified as result of the `#addAll()` call. However, a non-empty list is not modified either if `setAll` is called with an equal list. The PR has been updated to take this into account and unit tests have been added. Note that the current implementation is rather complex and could be greatly simplified by making a copy of the list before modification. .i.e List prev = List.copyOf(this); clear(); addAll(col); return !equals(prev); Please let me know which solution you prefer. ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From kcr at openjdk.java.net Fri Sep 4 16:48:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Sep 2020 16:48:19 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Fri, 21 Aug 2020 14:27:15 GMT, Leon Linhart wrote: >> @TheMrMilchmann I am not actively working on that bug, so you can proceed with this PR. I will review it when it is >> ready. >> Once you have submitted the OCA, please add a comment to this PR with the `/signed` command (and nothing else in the >> comment). After your OCA is approved and recorded, the Skara bot will mark it as ready for review. >> Please do add a unit test for this. You can find existing collections tests >> [here](https://github.com/openjdk/jfx/tree/master/modules/javafx.base/src/test/java/test/javafx/collections). > > While adding unit tests, I noticed that I missed an important edge-case that has to be considered when computing if a > list was modified. The initial implementation assumed that >> the list was modified if >>1. it was not empty (modified by calling `#clear()`), or if >>2. it was modified as result of the `#addAll()` call. > > However, a non-empty list is not modified either if `setAll` is called with an equal list. The PR has been updated to > take this into account and unit tests have been added. Note that the current implementation is rather complex and could > be greatly simplified by making a copy of the list before modification. .i.e > List prev = List.copyOf(this); > clear(); > addAll(col); > return !equals(prev); > > Please let me know which solution you prefer. One overall comment while we are waiting for your OCA to be approved. I don't think the complexity of this proposed fix to `setAll` is warranted. I would prefer a simpler fix that returns `false` if both the current list and the new list are empty, and `true` otherwise. This method is essentially a convenience method that does: List::clear List::addAll(...) Given this, it seems reasonable for `setAll` to return true if either `clear` or `addAll` would modify the list. If there is a good justification for handling the corner case of calling `setAll` with the same list of elements in exactly the same order (and I am not sure that there is), then a better approach might be to do the check before actually modifying the list, returning early if the new list and the current list were identical. In that case, the list really would be unmodified and no listeners would be notified. ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From robilad at openjdk.java.net Fri Sep 4 16:48:19 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Fri, 4 Sep 2020 16:48:19 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Tue, 1 Sep 2020 00:23:38 GMT, Kevin Rushforth wrote: >> While adding unit tests, I noticed that I missed an important edge-case that has to be considered when computing if a >> list was modified. The initial implementation assumed that >>> the list was modified if >>>1. it was not empty (modified by calling `#clear()`), or if >>>2. it was modified as result of the `#addAll()` call. >> >> However, a non-empty list is not modified either if `setAll` is called with an equal list. The PR has been updated to >> take this into account and unit tests have been added. Note that the current implementation is rather complex and could >> be greatly simplified by making a copy of the list before modification. .i.e >> List prev = List.copyOf(this); >> clear(); >> addAll(col); >> return !equals(prev); >> >> Please let me know which solution you prefer. > > One overall comment while we are waiting for your OCA to be approved. > > I don't think the complexity of this proposed fix to `setAll` is warranted. I would prefer a simpler fix that returns > `false` if both the current list and the new list are empty, and `true` otherwise. This method is essentially a > convenience method that does: List::clear > List::addAll(...) > > Given this, it seems reasonable for `setAll` to return true if either `clear` or `addAll` would modify the list. > > If there is a good justification for handling the corner case of calling `setAll` with the same list of elements in > exactly the same order (and I am not sure that there is), then a better approach might be to do the check before > actually modifying the list, returning early if the new list and the current list were identical. In that case, the > list really would be unmodified and no listeners would be notified. Unfortunately, I don't see @TheMrMilchmann OCA in the approval queue. Could you please (re)send it to Oracle-ca_us at oracle.com? Thanks! ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+4029915+TheMrMilchmann at openjdk.java.net Fri Sep 4 16:48:19 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Fri, 4 Sep 2020 16:48:19 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Tue, 1 Sep 2020 00:23:38 GMT, Kevin Rushforth wrote: > I don't think the complexity of this proposed fix to `setAll` is warranted. I would prefer a simpler fix that returns > `false` if both the current list and the new list are empty, and `true` otherwise. @kevinrushforth Thanks for your feedback! I have just pushed a commit that greatly simplifies `setAll` by returning early if both lists are empty and continuing with `clear`, `addAll` otherwise. > If there is a good justification for handling the corner case of calling `setAll` with the same list of elements in > exactly the same order (and I am not sure that there is), then a better approach might be to do the check before > actually modifying the list, returning early if the new list and the current list were identical. Fair point. I'm afraid I don't have any justification other than that, in my opinion, this is a violation of the method's contract (which is debatable). I suppose it's best to leave it as-is for this case for now. --- > Unfortunately, I don't see @TheMrMilchmann OCA in the approval queue. Could you please (re)send it to > Oracle-ca_us at oracle.com? Thanks! @robilad That's strange. I have sent a mail on Aug 13 and received no indication that it didn't go through (though neither did I receive an automated confirmation that it arrived - if such a thing is set up). Anyway, I just resent it. ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From robilad at openjdk.java.net Fri Sep 4 16:48:20 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Fri, 4 Sep 2020 16:48:20 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Tue, 1 Sep 2020 15:17:18 GMT, Leon Linhart wrote: >> One overall comment while we are waiting for your OCA to be approved. >> >> I don't think the complexity of this proposed fix to `setAll` is warranted. I would prefer a simpler fix that returns >> `false` if both the current list and the new list are empty, and `true` otherwise. This method is essentially a >> convenience method that does: List::clear >> List::addAll(...) >> >> Given this, it seems reasonable for `setAll` to return true if either `clear` or `addAll` would modify the list. >> >> If there is a good justification for handling the corner case of calling `setAll` with the same list of elements in >> exactly the same order (and I am not sure that there is), then a better approach might be to do the check before >> actually modifying the list, returning early if the new list and the current list were identical. In that case, the >> list really would be unmodified and no listeners would be notified. > >> I don't think the complexity of this proposed fix to `setAll` is warranted. I would prefer a simpler fix that returns >> `false` if both the current list and the new list are empty, and `true` otherwise. > > @kevinrushforth Thanks for your feedback! I have just pushed a commit that greatly simplifies `setAll` by returning > early if both lists are empty and continuing with `clear`, `addAll` otherwise. >> If there is a good justification for handling the corner case of calling `setAll` with the same list of elements in >> exactly the same order (and I am not sure that there is), then a better approach might be to do the check before >> actually modifying the list, returning early if the new list and the current list were identical. > > Fair point. I'm afraid I don't have any justification other than that, in my opinion, this is a violation of the > method's contract (which is debatable). I suppose it's best to leave it as-is for this case for now. > --- > >> Unfortunately, I don't see @TheMrMilchmann OCA in the approval queue. Could you please (re)send it to >> Oracle-ca_us at oracle.com? Thanks! > > @robilad That's strange. I have sent a mail on Aug 13 and received no indication that it didn't go through (though > neither did I receive an automated confirmation that it arrived - if such a thing is set up). Anyway, I just resent it. Thanks @TheMrMilchmann and apologies for the delay! ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From nlisker at openjdk.java.net Fri Sep 4 23:23:03 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 4 Sep 2020 23:23:03 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Fri, 4 Sep 2020 14:34:40 GMT, Nir Lisker wrote: >> If you run it with `--info` you will see something like this: >> >> test.javafx.scene.shape.PointLightAttenuationTest STANDARD_ERROR >> Exception in Application constructor >> Exception in thread "Thread-4" java.lang.RuntimeException: Unable to construct Application instance: class >> test.javafx.scene.shape.PointLightAttenuationTest$TestApp >> at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:890) >> at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) >> at java.base/java.lang.Thread.run(Thread.java:832) >> Caused by: java.lang.NoSuchMethodException: test.javafx.scene.shape.PointLightAttenuationTest$TestApp.() >> at java.base/java.lang.Class.getConstructor0(Class.java:3427) >> at java.base/java.lang.Class.getConstructor(Class.java:2165) >> at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:801) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:455) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) >> at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) >> at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) >> ... 1 more >> >> The nested `TestApp` class should be declared as `static`. Btw, I don't recommend using `setFullScreen` for a test such >> as this. > > Thanks, the test runs now, but I've run into an issue with `snapshot`. > > `Node#snapshot` uses its scene parameters (like lights) to render the image, but if the node is in a subscene then the > image will be wrong since it takes the wrong data. Bounds transforms like `sceneToLocal` and `localToScene` do take > care of this case. I think that this is a mistake in `snapshot`, and maybe it should use the subscene, or a `boolean > subScene` parameter should be offered, or `SnapshotParameters` should allow to specify it. Looks like there's more to it. I've created the test code: import javafx.application.Application; import javafx.scene.Group; import javafx.scene.PerspectiveCamera; import javafx.scene.PointLight; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.Slider; import javafx.scene.image.ImageView; import javafx.scene.layout.BorderPane; import javafx.scene.paint.Color; import javafx.scene.shape.Box; import javafx.stage.Stage; public class PointLightAttenuationTest extends Application { public static void main(String[] args) throws Exception { launch(args); } @Override public void start(Stage stage) { var light = new PointLight(Color.BLUE); light.setTranslateZ(-10); Box box = new Box(100, 100, 1); var group = new Group(light, box); var scene = new Scene(group, 500, 500, true); var camera = new PerspectiveCamera(true); camera.setTranslateZ(-300); camera.setFarClip(1000); scene.setCamera(camera); stage.setScene(scene); stage.show(); var imageView = new ImageView(); var snapshotButton = new Button("Node Snaphot"); snapshotButton.setOnAction(e -> imageView.setImage(scene.snapshot(null))); var slider = new Slider(0, 0.2, 0); slider.setShowTickMarks(true); slider.setShowTickLabels(true); light.linearAttenuationProperty().bindBidirectional(slider.valueProperty()); var snapshotStage = new Stage(); snapshotStage.setScene(new Scene(new BorderPane(imageView, snapshotButton, null, slider, null))); snapshotStage.setWidth(600); snapshotStage.setHeight(600); snapshotStage.show(); } } If the line `snapshotButton.setOnAction(e -> imageView.setImage(scene.snapshot(null)));` is replaced to use `box.snapshot(null, null)` then the snapshot is wrong. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From jvos at openjdk.java.net Mon Sep 7 07:05:36 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 7 Sep 2020 07:05:36 GMT Subject: [jfx15] RFR: 8252784: Create release notes for JavaFX 15 In-Reply-To: References: Message-ID: <_A__k4ug-z3-y5z7xrgmXNcQiRNQZTN3Ahv4_4nkKWw=.6198043b-2692-460e-94ef-9c14da3a7e8b@github.com> On Fri, 4 Sep 2020 11:51:59 GMT, Kevin Rushforth wrote: > Looks fine. Did you want to add a note about the additional Javascript bridge restrictions, similar to [this > note](https://github.com/openjdk/jfx/blob/331a39be016a284e5495c73726e7b58e7769a75e/doc-files/release-notes-14.0.1.md#list-of-security-fixes) > that was done for 14.0.1? Either way is fine with me. My first thinking was *not* to add the note here as well, since it is in 14.0.1 and there are no fixes in 14.0.1 that are not in 15-GA, hence 15-GA implicitly assumes all release notes and docs from 14.0.1. But on the other hand, since we list the fix in the 15 release notes, it makes sense to add the restriction list here too. I'll add it.. ------------- PR: https://git.openjdk.java.net/jfx/pull/296 From jvos at openjdk.java.net Mon Sep 7 07:14:14 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 7 Sep 2020 07:14:14 GMT Subject: [jfx15] RFR: 8252784: Create release notes for JavaFX 15 [v2] In-Reply-To: References: Message-ID: > Fix for JDK-8252784 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: add list of javascript bridge restrictions ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/296/files - new: https://git.openjdk.java.net/jfx/pull/296/files/fee979b0..54939604 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=296&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=296&range=00-01 Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/296/head:pull/296 PR: https://git.openjdk.java.net/jfx/pull/296 From arapte at openjdk.java.net Mon Sep 7 13:27:39 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Sep 2020 13:27:39 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v10] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Change approach to use Interceptor ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/b948ef18..de91bed4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=172&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=172&range=08-09 Stats: 125 lines in 4 files changed: 29 ins; 71 del; 25 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Mon Sep 7 13:33:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Sep 2020 13:33:48 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v11] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: rename tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/de91bed4..0755797b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=172&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=172&range=09-10 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Mon Sep 7 13:38:21 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Sep 2020 13:38:21 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v8] In-Reply-To: <549pqzBdvFAW4kVPON69UFObPHpsPLudT5HXj7qha74=.e8246f24-c175-412b-98a1-fe6de9903569@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <549pqzBdvFAW4kVPON69UFObPHpsPLudT5HXj7qha74=.e8246f24-c175-412b-98a1-fe6de9903569@github.com> Message-ID: On Tue, 1 Sep 2020 13:59:06 GMT, Ambarish Rapte wrote: >> hmm .. this is getting unwieldy, isn't it ;) >> >> The pain points: >> - cascade of listeners (editable -> comboSkin -> properties -> behavior) >> - dynamic change (add/remove) of mappings >> - multiple key/value pairs for basically the same - though variant - state >> >> My suggestion would be to take a step back (in solution path): near the beginning was the evaluation of using different >> inputMaps for different state contexts. Which was not further evaluated because it looked like we could get away with >> simply configuring the mappings - based on certain condition - once at instantiation time. Which has the advantage of >> not touching too much code but unfortunely turned out to be not enough. Meanwhile, I'm convinced that in the long run >> there is no way around different inputMaps based on context: the differences in behavior (stand-alone vs. editable >> combo-popup vs. not-editable combo-popup) are many - f.i. focus-only navigation doesn't make sense in the popup (should >> be selection navigation always), left/right in a not-editable should trigger selection navigation .. and certainly >> more. So we not only have to enable/disable certain mappings, but also re-map the triggered behavior. That's too >> broad for this issue, but we could take a step into that direction: use the InputMap/Mapping API to help - it was >> designed for exactly such a differentiation :) The step would be to use interceptors (instead of dynamic modification >> of the mappings list), they are available on both inputMap and mapping level. As a first step, we could use the latter: >> keep the addition of mappings as-is (before the fix) and add interceptors to mappings for inclusion/exclusion based on >> context. No listeners, no dynamic modification, just one marker in the properties .. hopefully :) Raw code snippets: >> // let combo skin put a Supplier for editable as value >> getProperties().put("comboContext", (Supplier) () -> getSkinnable().isEditable()); >> >> // let listView behavior use the supplier to build interceptors >> Supplier comboEditable = (Supplier) control.getProperties().get("comboContext"); >> Predicate interceptIfInCombo = e -> comboEditable != null; >> Predicate interceptIfInEditableCombo = e -> comboEditable != null && comboEditable.get(); >> >> if (comboEditable == null) { >> // add focus traversal mappings if not in combo popup >> addDefaultMapping(listViewInputMap, FocusTraversalInputMap.getFocusTraversalMappings()); >> } >> // add mappings with appropriate interceptors >> addDefaultMapping(listViewInputMap, >> // missing api in KeyMapping: no constructor taking KeyCode and interceptor >> new KeyMapping(new KeyBinding(HOME), e -> selectFirstRow(), interceptIfInEditableCombo), >> new KeyMapping(new KeyBinding(END), e -> selectLastRow(), interceptIfInEditableCombo), >> new KeyMapping(new KeyBinding(HOME).shift(), e -> selectAllToFirstRow(), interceptIfInCombo), >> new KeyMapping(new KeyBinding(END).shift(), e -> selectAllToLastRow(), interceptIfInCombo), >> ... >> >> With this, the tests for key navigation are passing, the low-level mapping tests will have to be re-formulated to test >> for not/intercepted vs. existence. >> What do you think? > >> What do you think? > > Suggestion looks promising, I shall try it and update. @kleopatra @kevinrushforth Change looks pretty with interceptor. Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From kcr at openjdk.java.net Mon Sep 7 14:11:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Sep 2020 14:11:17 GMT Subject: [jfx15] RFR: 8252784: Create release notes for JavaFX 15 [v2] In-Reply-To: References: Message-ID: <3QyjqsR8yT_2Fo6iTHAiWy7_QaiJ3I5aIRr-26b3KnI=.ed192d56-d20f-46ea-8db9-2cde850e3e65@github.com> On Mon, 7 Sep 2020 07:14:14 GMT, Johan Vos wrote: >> Fix for JDK-8252784 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > add list of javascript bridge restrictions Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/296 From jvos at openjdk.java.net Mon Sep 7 14:33:16 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 7 Sep 2020 14:33:16 GMT Subject: [jfx15] Withdrawn: 8252784: Create release notes for JavaFX 15 In-Reply-To: References: Message-ID: On Fri, 4 Sep 2020 09:23:52 GMT, Johan Vos wrote: > Fix for JDK-8252784 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/296 From jpereda at openjdk.java.net Mon Sep 7 17:58:44 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 7 Sep 2020 17:58:44 GMT Subject: RFR: 8178297: TableView scrolls slightly when adding new elements Message-ID: <_ip0Z6pUqZ5_FA0f1bsX3HgO4zQBf2krfIiAEGJaIhc=.47d6d48e-94ef-4ae5-a909-626f5e72c804@github.com> This PR fixes an issue that happens when adding new items to a `TableView` or any other control that uses `VirtualFlow`, if the scroll position is not 0: the virtual flow is slightly shifted down. For instance, let's say that a cell has a layoutY of -10.0. After adding a new item to the table, during the layout pass the new value is initially modified to -9.999999999999996 (`VirtualFlow::adjustByPixelAmount`) , and then, after calling `VirtualFlow::positionCell` (that uses `snapSizeY(position)`) the layoutY is modified to -9.5, causing an undesired positive shift of 0.5 pixels. `Region` has different snap methods: `snapSizeX/Y` are used to snap node dimension values, like width or height, by ceiling to the nearest pixel (which explains the -9.5 value), while `snapSpaceX/Y` are used to snap position values like insets, by rounding to the nearest pixel (this will give the expected -10.0). Therefore, this PR modifies `VirtualFlow::positionCell` to use the `snapSpaceX/Y` methods, since these are being used to set the layout of the cell and not its size. Test: A unity test has been included. It simulates the case of adding new items to the virtual flow after an initial scroll. It currently fails after adding a few items, and it passes with the changes of this PR. ------------- Commit messages: - Add test to verify the cell position remains constant when new cells are added to the virtualFlow. - Use correct snap method to set cell layout Changes: https://git.openjdk.java.net/jfx/pull/297/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=297&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8178297 Stats: 25 lines in 2 files changed: 23 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/297.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/297/head:pull/297 PR: https://git.openjdk.java.net/jfx/pull/297 From github.com+2120116+baumeister at openjdk.java.net Mon Sep 7 18:33:02 2020 From: github.com+2120116+baumeister at openjdk.java.net (Timm) Date: Mon, 7 Sep 2020 18:33:02 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.88aea0b5-c8bd-459d-89a4-27be96af88b8@github.com> Message-ID: On Tue, 21 Apr 2020 12:50:50 GMT, Kevin Rushforth wrote: >> Hi, >> I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail >> at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. > > @aghaisas can you also review this? Any progress with having this merged? ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From bchoudhary at openjdk.java.net Tue Sep 8 07:43:54 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 8 Sep 2020 07:43:54 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v11] In-Reply-To: References: Message-ID: > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: rendering fix for paths and strokes + refactoring ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/87f63074..ec272623 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=09-10 Stats: 132 lines in 1 file changed: 54 ins; 70 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Tue Sep 8 09:56:06 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 8 Sep 2020 09:56:06 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v12] In-Reply-To: References: Message-ID: > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Added unit test for strokes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/ec272623..ed2dd092 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=10-11 Stats: 39 lines in 1 file changed: 37 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From jpereda at openjdk.java.net Tue Sep 8 12:01:21 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 8 Sep 2020 12:01:21 GMT Subject: RFR: 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes Message-ID: This PR removes an old fix (RT-13965/JDK-8113318), which was applied in 2011 to avoid a memory leak in `VirtualFlow::sheetChildren`, after new items were constantly added. With the current VirtualFlow implementation, there are in place the necessary methods that take care of cleaning or adding new cells to the sheetChildren list, and such memory leak doesn't exist, the size remains constant when new items are added or removed (see included unity test). The call to `sheetchildren.clear()`, on the contrary, has a big impact in performance and CPU usage, when new items are constantly added, as has been reported in JDK-8185886/#108. ------------- Commit messages: - Add test to verify the sheet children size remains constant when adding or removing new items - Remove old fix RT-13965 Changes: https://git.openjdk.java.net/jfx/pull/298/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=298&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252811 Stats: 38 lines in 2 files changed: 32 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/298.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/298/head:pull/298 PR: https://git.openjdk.java.net/jfx/pull/298 From jvos at openjdk.java.net Tue Sep 8 12:45:33 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 8 Sep 2020 12:45:33 GMT Subject: RFR: 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 11:56:51 GMT, Jose Pereda wrote: > This PR removes an old fix (RT-13965/JDK-8113318), which was applied in 2011 to avoid a memory leak in > `VirtualFlow::sheetChildren`, after new items were constantly added. > With the current VirtualFlow implementation, there are in place the necessary methods that take care of cleaning or > adding new cells to the sheetChildren list, and such memory leak doesn't exist, the size remains constant when new > items are added or removed (see included unity test). The call to `sheetchildren.clear()`, on the contrary, has a big > impact in performance and CPU usage, when new items are constantly added, as has been reported in JDK-8185886/#108. This looks ok to me. It would be ideal to have the test failing before JDK-8113318 was applied, as that would show the issue for which JDK-8113318 was created is now fixed. But I do understand it is very hard to apply this test to a code snapshot from 2011. ------------- PR: https://git.openjdk.java.net/jfx/pull/298 From kevin.rushforth at oracle.com Tue Sep 8 20:12:17 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 Sep 2020 13:12:17 -0700 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> <2bca9ed5-a71f-37e1-575e-df4bff9d0d6d@xs4all.nl> <20200902142419.Horde.J6EIkd0uSUOP9oM5txT0gA3@webmail.df.eu> <2d57f205-239b-2ec7-fe05-ceb8c368378a@oracle.com> Message-ID: <625eba60-2a32-274f-225e-5c06e6cb90b4@oracle.com> Thanks for filing it, Jose. I think it's better not to use JDK-8185886 for any of these PRs, since it's too generic a description, and was meant as an umbrella issue anyway, so I closed it as a duplicate of the 4 issues that are split out from it. I filed a new issue for each of PR #108 and PR #185. There is already an issue about the lack of virtualization in the horizontal direction, JDK-8185887, so we can use that for PR #125. Here is the list of the 4 PRs under review: PR #108 [1] : JDK-8252936 [2] : Optimize removal of listeners from ExpressionHelper.Generic PR #125 [3] : JDK-8185887 [4] : TableRowSkinBase fails to correctly virtualize cells in horizontal direction PR #185 [5] : JDK-8252935 [6] : Add treeShowing listener only when needed PR #298 [7] : JDK-8252811 [8] : The list of cells in a VirtualFlow is cleared every time the number of items changes For the first three PRs, I ask the author of the PR to update the title of their PR to match their associated JBS issue. We can proceed to discuss each fix in their respective PRs. -- Kevin [1] https://github.com/openjdk/jfx/pull/108 [2] https://bugs.openjdk.java.net/browse/JDK-8252936 [3] https://github.com/openjdk/jfx/pull/125 [4] https://bugs.openjdk.java.net/browse/JDK-8185887 [5] https://github.com/openjdk/jfx/pull/185 [6] https://bugs.openjdk.java.net/browse/JDK-8252935 [7] https://github.com/openjdk/jfx/pull/298 [8] https://bugs.openjdk.java.net/browse/JDK-8252811 On 9/4/2020 9:04 AM, Jos? Pereda wrote: > I've filed https://bugs.openjdk.java.net/browse/JDK-8252811 (under > javafx/controls). > > I believe this is not an alternative to any of the other three > issues,?but obviously?a less invasive?one,?as it only implies changes > in VirtualFlow. > > Once tackled, it should directly increase performance and reduce CPU > usage of TableView/TreeTableView/ListView controls when their?items > change frequently. > > But it will also benefit from the improvements of the other three > approaches. > > Jose > > On Fri, Sep 4, 2020 at 1:46 AM Kevin Rushforth > > wrote: > > It seems clear now that we will need 3 different JBS issues for these > proposed performance enhancements. It's a holiday weekend coming > up in > the US, so I can file the other two issues unless someone else > gets to > it first. Unless there is a good reason to do otherwise, I propose: > > The JBS Issue associated with PR #108 should be filed against > javafx/base > The JBS Issue associated with PR #125 should be filed against > javafx/controls (or we can reuse JDK-8185886) > The JBS Issue associated with PR #185 should be filed against > javafx/scenegraph > > Jose: Is you approach an alternative to one of the above or could > it be > considered a 4th approach? If the latter, can you file a new JBS > Issue > for that? > > -- Kevin > > > On 9/2/2020 5:24 AM, Jeanette Winzenburg wrote: > > > > Hi John, > > > > thanks for the clarification :) > > > > Hmm .. but then it's not really a PR against JDK-8185886 (scrolling > > performance was always bad with many columns) but against - yet > to be > > reported - side-effect of JDK-8090322 which happens to detoriate > > tableView performance even further (there might be other > side-effects)? > > > > -- Jeanette > > > > Zitat von John Hendrikx >: > > > >> The "dynamic update performance" performance issue we are > seeing is a > >> regression from JDK-8090322.? In this change the Node treeShowing > >> property was introduced.? The JDK-8090322 warns in its description > >> about: > >> > >> """??? Considerations: > >> * This is too expensive to calculate for all nodes by default. > So the > >> simplest way to provide it would be a special binding > implementation > >> or a util class. Where you create a instance and pass in the > node you > >> are interested in. It can then register listeners all the way > up the > >> tree and listen to what it needs. """ > >> > >> The above comment is warning against the fact that registering > >> listeners for EACH Node on Window and Scene is going to be a > >> performance issue. As nodes can number in the 1000's or 10.000's, > >> that's a lot of listeners to store in a List data structure. > >> > >> PR 185 targets this issue and implements the feature in > JDK-8090322 in > >> the way that was suggested in the above comment, instead of how it > >> currently is implemented (registering listeners for every Node, > just > >> in case someone needs the treeShowing property). > >> > >> It's scope is not as broad as it would seem (because of a > change in > >> Node).? It effectively only makes a small change in two controls > >> (PopupWindow and ProgressIndicatorSkin). > >> > >> --John > >> > >> > >> > >> On 31/08/2020 16:54, Jeanette Winzenburg wrote: > >>> > >>> Looking at the examples provided in 108/125: apart from both > having > >>> many > >>> columns (> 300 makes them really nasty) they differ in > >>> > >>> Table content: > >>> 125 - static data > >>> 108 - items are frequently modified (added) > >>> > >>> Perceived performance: > >>> 125 - vertical scrolling: thumb/content lags behind mouse > >>> 108 - with enough columns, all interaction is sluggish (mouse, > keys, > >>> ..), scrolling being just one of them > >>> > >>> Both have examples, running those against the suggested fixes > (with > >>> 108a > >>> for Jose's approach) > >>> 125 - fixes its own example, does nothing for the other > >>> 108, 108a, 185 - improves its own example, does nothing for other > >>> > >>> So we seem to have multiple issues that are (mostly) > orthogonal: one > >>> being the broken/missing horizontal virtualization (125), the > other > >>> related to dynamic update of table content (108, 108a, 185). > We need to > >>> solve both, the solution/s for one looks (mostly?) unrelated > to the > >>> solution to the other. > >>> > >>> 125 is the only one PR for its use-case, and it seems to do > its job. > >>> From those targeting the dynamic data update all except Jose's > (not yet > >>> formalized into a PR) approach feel too broad: table's > reaction to > >>> items > >>> modifications is .. suboptimal in more than one aspect. Changing > >>> overall > >>> notification implementation to improve that, sounds like > covering it > >>> up. > >>> > >>> -- Jeanette > >>> > >>> Zitat von Kevin Rushforth >: > >>> > >>>> Sorry for the badly formatted html. Here it is again. > >>>> > >>>> I see some progress being made on the {Tree}TableView performance > >>>> issue. To summarize where I think we are: > >>>> > >>>> There are currently 2 different approaches under review: > >>>> > >>>> 1. https://github.com/openjdk/jfx/pull/108 > > : optimization in > >>>> javafx.base to make removing listeners faster > >>>> 2. https://github.com/openjdk/jfx/pull/125 > > : optimization in TableView > >>>> to reduce the number of add / removes > >>>> > >>>> In addition, the following is a WIP PR that the author thinks > could be > >>>> a 3rd approach: > >>>> > >>>> 3. https://github.com/openjdk/jfx/pull/185 > > : optimization in scene > >>>> graph to avoid install treeShowing listeners on Window and > Scene for > >>>> all nodes > >>>> > >>>> Jose has proposed a 4th approach as a comment to PR #108, and > as I > >>>> understand it, he will propose a PR shortly. > >>>> > >>>> 4. Don't clear the list of children in a VirtualFlow when the > number > >>>> of items changes. > >>>> > >>>> So the first thing that is needed is to evaluate the > approaches and > >>>> decide which one to pursue. > >>>> > >>>> Options 1 and 3 are more broad in their scope, option #2 is more > >>>> targeted (to TableView), but within that area is a larger change. > >>>> Option #3 would remove the (internal) treeShowing property as a > >>>> generally available concept and only use it for controls like > >>>> ProgressIndicator that really need it. Option #4 affects only > controls > >>>> that use VirtualFlow (ListView, TableVIew, TreeTableView), > and seems > >>>> not to be a large change (presuming we can verify that no leak is > >>>> introduced). > >>>> > >>>> I note that these fixes are not mutually exclusive, but I do > think we > >>>> need to settle on a primary approach and use that to fix this > issue. > >>>> If there are still performance problems after that fix, we can > >>>> consider one (or more) of the others. > >>>> > >>>> Comments? > >>>> > >>>> -- Kevin > >>> > >>> > >>> > > > > > > > > > > -- > From kcr at openjdk.java.net Tue Sep 8 20:17:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Sep 2020 20:17:02 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> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Thu, 27 Aug 2020 00:07:21 GMT, Kevin Rushforth wrote: >> So far, there are two alternative fixes for the bad performance issue while scrolling TableView/TreeTableViews: >> >> - this one #108, that tries to improve the performance of excessive number of `removeListener` calls >> - the WIP #185 that avoids registering two listeners (on Scene and on Window) for each and every Node. >> >> For the case presented, where new items are constantly added to the TableView, the trace of calls that reach >> `com.sun.javafx.binding.ExpressionHelper.removeListener()` is something like this: >> ![TraceOpenJFX16ea1](https://user-images.githubusercontent.com/2043230/91322208-c2ba9900-e7bf-11ea-8918-cdbecd457cf2.png) >> >> As can be seen, all those calls are triggered by the change of the number of cells in >> [VirtualFlow::setCellCount](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L804). >> Whenever the cell count changes there is this >> [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L843): >> sheetChildren.clear(); >> >> This happens every time the number of items in the `TableView` changes, as the `VirtualFlow` keeps track of the number >> of virtual cells (`cellCount` is the total number of items) while the number of actual cells or number of visible nodes >> used is given by `sheetChildren.size()`. This means that all the actual cells (nodes) that are used by the >> `VirtualFlow` are disposed and recreated all over again every time the number of items changes, triggering all those >> calls to unregister those nodes from the scene that ultimately lead to remove the listeners with >> `ExpressionHelper.removeListener`. However, this seems unnecessary, as the number of actual cells/nodes doesn't change >> that much, and causes this very bad performance. On a quick test over the sample posted, just removing that line gives >> a noticeable improvement in performance.. >> There is a concern though due to the >> [comment](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L839): >> // Fix for RT-13965: Without this line of code, the number of items in >> // the sheet would constantly grow, leaking memory for the life of the >> // application. This was especially apparent when the total number of >> // cells changes - regardless of whether it became bigger or smaller. >> sheetChildren.clear(); >> >> There are some methods in VirtualFlow that already manage the lifecycle of this list of nodes (clear, remove cells, add >> cells, ...), so I don't think that is the case anymore for that comment: the number of items in the sheet doesn't >> constantly grow and there is no memory leak. Running the attached sample for a long time, and profiling with VisualVM, >> shows improved performance (considerable drop in CPU usage), and no issues regarding memory usage. >> So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but >> wouldn't have any impact in the rest of controls as the other two options (as `ExpressionHelper` or `Node` listeners >> wouldn't be modified). Thoughts and feedback are welcome. > >> So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but >> wouldn't have any impact in the rest of controls as the other two options (as ExpressionHelper or Node listeners >> wouldn't be modified). > > Given PR #185, which was mentioned above, (it isn't out for review yet, but I want to evaluate it), this would be a 4th > approach. > As long as this really doesn't introduce a leak, it seems promising. > > I note that these are not mutually exclusive. > > We should discuss this on the list and not just in one or more of of the 3 (soon to be 4) open pull requests. @dannygonzalez Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: 8252936: Optimize removal of listeners from ExpressionHelper.Generic ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Tue Sep 8 20:21:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Sep 2020 20:21:51 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v4] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> Message-ID: On Thu, 3 Sep 2020 07:44:55 GMT, yosbits wrote: >>> >>> >>> When the startup time is measured by eye, the impression changes depending on the individual difference. >> >> my eye is a precision instrument :) Seriously, who would do such a thingy? Obviously, it must be measured, for zeroth >> approximation doing so crudely by comparing currentMillis before/after showing is good enough to "see" the tendency. >>> The effect of runLater affects your experience. >> >> that's why you shouldn't do it when trying to gain insight into timing issues ;) >> >>> >>> However, I succeeded in further improving performance by eliminating another bottleneck in TreeTableView. Of course, it >>> also includes improvements in startup time. >> >> cool :) > > Column virtualization causes shortness of breath when scrolling a large stroke horizontally. > This does not happen when stroking on the scrollbar. Looks like a potential problem with VirtualFlow. > > If you are worried about shortness of breath, the following code will help reduce the problem. > > > Java > ?private static final int OVERLAP_MARGIN = 500; > > private static boolean isOverlap(double start, double end, double start2, double end2){ > start = Math.max(start-OVERLAP_MARGIN, start2); > end = Math.min(end+OVERLAP_MARGIN, end2); > return (start<=end2 && end >= start2); > } @yososs Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have closed [JDK-8185886](https://bugs.openjdk.java.net/browse/JDK-8185886) as a duplicate, and suggested another existing JBS issue for this PR to use. Please change the title to: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+7517141+yososs at openjdk.java.net Wed Sep 9 02:50:59 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Wed, 9 Sep 2020 02:50:59 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> Message-ID: On Tue, 8 Sep 2020 20:19:13 GMT, Kevin Rushforth wrote: >> Column virtualization causes shortness of breath when scrolling a large stroke horizontally. >> This does not happen when stroking on the scrollbar. Looks like a potential problem with VirtualFlow. >> >> If you are worried about shortness of breath, the following code will help reduce the problem. >> >> >> Java >> ?private static final int OVERLAP_MARGIN = 500; >> >> private static boolean isOverlap(double start, double end, double start2, double end2){ >> start = Math.max(start-OVERLAP_MARGIN, start2); >> end = Math.min(end+OVERLAP_MARGIN, end2); >> return (start<=end2 && end >= start2); >> } > > @yososs Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the > openjfx-dev mailing list, I have closed [JDK-8185886](https://bugs.openjdk.java.net/browse/JDK-8185886) as a duplicate, > and suggested another existing JBS issue for this PR to use. Please change the title to: 8185887: TableRowSkinBase > fails to correctly virtualize cells in horizontal direction Below are the answers to JBS's suggestions. > The patch below resolves the issue, but it is not likely the correct solution (we are trying to determine the table > width, but we are getting the width and padding on the underlying virtualflow (the width is fine, the padding should > really come from tableview directly): You probably mention this part, At least padding refers to Skinnable(TableView or TreeTableView). This is the same as before (L683). The width of VirtualFlow is determined by the header of Table. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java#L360-L365 Java final VirtualFlow virtualFlow = getVirtualFlow(); final double scrollX = virtualFlow == null ? 0.0 : virtualFlow.getHbar().getValue(); final Insets padding = getSkinnable().getPadding(); final double vfWidth = virtualFlow == null ? 0.0:virtualFlow.getWidth(); final double headerWidth = vfWidth - (padding.getLeft() + padding.getRight()); For example, can you assume a case that does not work properly? ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+6702882+dannygonzalez at openjdk.java.net Wed Sep 9 06:55:45 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Wed, 9 Sep 2020 06:55:45 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic 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> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2OiqSod2idVc=.88bd412a-9158-47bf-a1df-f7ac78b03ba6@github.com> On Tue, 8 Sep 2020 20:14:48 GMT, Kevin Rushforth wrote: >>> So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but >>> wouldn't have any impact in the rest of controls as the other two options (as ExpressionHelper or Node listeners >>> wouldn't be modified). >> >> Given PR #185, which was mentioned above, (it isn't out for review yet, but I want to evaluate it), this would be a 4th >> approach. >> As long as this really doesn't introduce a leak, it seems promising. >> >> I note that these are not mutually exclusive. >> >> We should discuss this on the list and not just in one or more of of the 3 (soon to be 4) open pull requests. > > @dannygonzalez Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on > the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: > 8252936: Optimize removal of listeners from ExpressionHelper.Generic Thanks @kevinrushforth, I've changed the title. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Wed Sep 9 12:26:12 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 9 Sep 2020 12:26:12 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v11] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Mon, 7 Sep 2020 13:33:48 GMT, Ambarish Rapte wrote: >> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. >> This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several >> `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. >> Fix: >> 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. >> 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to >> `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. >> Change unrelated to fix: >> `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup >> is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code >> from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed >> for the fix. But this seems to be dead code. Verification: >> Added new unit tests to verify the change. >> Also verified that the behavior ListView behaves same before and after this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > rename tests Fix looks fine and indeed pretty :) Verified tests failing before and after the fix. Left some minor comments inline. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 87: > 85: Predicate pIsInComboBox = e -> isListViewOfComboBox != null; > 86: Predicate pIsInEditableComboBox = > 87: e -> isListViewOfComboBox != null && isListViewOfComboBox.get(); nit-pick about naming: I think we don't use (crippled) hungarian notation, or do we? If we don't, the leading "p" should be removed, isIn/Editable/Combo is expressive enough (and no need to differentiate by type of functional interface, IMO) modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxListViewSkin.java line 509: > 507: getProperties().put("selectFirstRowByDefault", false); > 508: getProperties().put("editableComboBoxEditor", (Supplier) () -> > getSkinnable().isEditable()); 509: } nit-pick about naming: it's the editable state of the combo (vs. the editable state of the editor) that's in the center of interest, so maybe rename the key to express that? Like "editableComboBox"? Another thingy (which I think is a bit under-used in the fx code-base;) - how about a code comment to why this marker is added and which collaborator is using it? modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1347: > 1345: final ComboBox cb = new ComboBox<>(FXCollections.observableArrayList("a", "b", "c")); > 1346: cb.setEditable(true); > 1347: StageLoader sl = new StageLoader(cb); shouldn't there be an analogous functional test for not-editable combo? There are both functional and low-level for editable, but only low-level for not editable. modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1514: > 1512: return ((KeyMapping)mappings.get(i)).getInterceptor().test(null); > 1513: } > 1514: his throws an NPE without the fix - which makes the test using this method still fail (good!), but a bit unspecific for my taste. A slight re-organisation of the helpers might help: move the asserts down instead of returning a boolean. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2083: > 2081: private boolean testInterceptor(ObservableList mappings, KeyBinding binding) { > 2082: int i = mappings.indexOf(new KeyMapping(binding, null)); > 2083: return ((KeyMapping)mappings.get(i)).getInterceptor().test(null); same as for ComboBoxTest ------------- Changes requested by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/172 From jules at bookus-boulet.com Wed Sep 9 17:18:27 2020 From: jules at bookus-boulet.com (Jules Yasuna) Date: Wed, 9 Sep 2020 13:18:27 -0400 Subject: Cannot extend javafx.scene.transform.Transform Message-ID: <4B25E5ED-8DC4-47C9-8939-96F5D2A3E81C@bookus-boulet.com> I would like to extend from javafx.scene.transform.Transform Two methods are preventing this ? abstract void apply(Affine3D t); abstract BaseTransform derive(BaseTransform t); I accomplished this in jdk 8 by overriding these two methods ? public abstract void impl_apply(final Affine3D trans); public abstract BaseTransform impl_derive(final BaseTransform trans); Which of course I should not have done. Is there any change the apply and derive methods could open to permit derivation? From jhendrikx at openjdk.java.net Wed Sep 9 21:35:56 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 9 Sep 2020 21:35:56 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed Message-ID: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> This is a PoC for performance testing. It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. ------------- Commit messages: - WIP: Moved treeShowingProperty into its own class Changes: https://git.openjdk.java.net/jfx/pull/185/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252935 Stats: 275 lines in 6 files changed: 161 ins; 109 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/185/head:pull/185 PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Wed Sep 9 21:35:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Sep 2020 21:35:57 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Fri, 17 Apr 2020 08:06:23 GMT, John Hendrikx wrote: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the > aforementioned classes. The complete change should update these two classes to add their own listeners instead. These listeners exist for a good reason. Removing them will almost certainly cause regressions in behavior. See [JDK-8090322](https://bugs.openjdk.java.net/browse/JDK-8090322) as well as the follow-on fixes (since that was a rather involved fix in the first place). ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Wed Sep 9 21:35:57 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 9 Sep 2020 21:35:57 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Fri, 17 Apr 2020 16:59:29 GMT, Kevin Rushforth wrote: >> This is a PoC for performance testing. >> >> It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. >> >> This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the >> aforementioned classes. The complete change should update these two classes to add their own listeners instead. > > These listeners exist for a good reason. Removing them will almost certainly cause regressions in behavior. See > [JDK-8090322](https://bugs.openjdk.java.net/browse/JDK-8090322) as well as the follow-on fixes (since that was a rather > involved fix in the first place). @kevinrushforth I don't propose to remove them, only to move them to where they are needed. Currently they are part of Node, which means all nodes, whether they need to know the state of the Window or not are registering a listener. However, only PopupWindow and the ProgressIndicatorSkin are registering a listener on this property (other uses are limited to a simple "isTreeShowing" checks which can be determined directly). It is very wasteful to have all nodes register this listener, as there are potentially tens of thousands of nodes. All of these nodes are listening on the exact same two properties (when there is only one Scene and Window), causing huge listener lists there. The listener is not registered in a lazy fashion (ie, only registered if something else is listening to the property downstream, like reactfx would do). This also means that when a Scene change or Window showing change occurs, thousands of nodes will receive a change event, but only 2 types of nodes are actually interested. The other nodes are just doing a lot of house keeping to keep watching the correct property (as there is an indirection from Scene to Window). Therefore my proposal is to have the two cases involved register their own listener on Scene and Window. There will not be any regressions. The two tests that currently fail in this PR are expected to fail as I commented out the listener code in the classes involved, but that can easily be fixed by adding the correct listeners there. I'll update it so you can see all tests will pass. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Wed Sep 9 21:35:57 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 9 Sep 2020 21:35:57 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <2sdQMJamnqA2xRHM1NpXG2CqHLAKSHr5bqmG-rC4y28=.c1dc6bb3-b6d3-46df-ac77-c9d5053dcabd@github.com> On Fri, 17 Apr 2020 17:18:00 GMT, John Hendrikx wrote: >> These listeners exist for a good reason. Removing them will almost certainly cause regressions in behavior. See >> [JDK-8090322](https://bugs.openjdk.java.net/browse/JDK-8090322) as well as the follow-on fixes (since that was a rather >> involved fix in the first place). > > @kevinrushforth I don't propose to remove them, only to move them to where they are needed. > > Currently they are part of Node, which means all nodes, whether they need to know the state of the Window or not are > registering a listener. However, only PopupWindow and the ProgressIndicatorSkin are registering a listener on this > property (other uses are limited to a simple "isTreeShowing" checks which can be determined directly). It is very > wasteful to have all nodes register this listener, as there are potentially tens of thousands of nodes. All of these > nodes are listening on the exact same two properties (when there is only one Scene and Window), causing huge listener > lists there. The listener is not registered in a lazy fashion (ie, only registered if something else is listening to > the property downstream, like reactfx would do). This also means that when a Scene change or Window showing change > occurs, thousands of nodes will receive a change event, but only 2 types of nodes are actually interested. The other > nodes are just doing a lot of house keeping to keep watching the correct property (as there is an indirection from > Scene to Window). Therefore my proposal is to have the two cases involved register their own listener on Scene and > Window. There will not be any regressions. The two tests that currently fail in this PR are expected to fail as I > commented out the listener code in the classes involved, but that can easily be fixed by adding the correct listeners > there. I'll update it so you can see all tests will pass. @kevinrushforth I've updated this PR now with proper listeners added in again for PopupWindow and ProgressIndicatorSkin. In short, the functionality to support the `treeShowingProperty` has been extracted to a separate class `TreeShowingExpression` which is now used by the two classes mentioned. All tests pass, including the memory leak tests that failed before. The issue JDK-8090322 you mentioned actually cautioned for not adding such listeners for all nodes and seemed to propose the kind of solution I constructed here with a separate class for the `treeShowingProperty`: > This is too expensive to calculate for all nodes by default. So the simplest way to provide it would be a special > binding implementation or a util class. Where you create a instance and pass in the node you are interested in. It can > then register listeners all the way up the tree and listen to what it needs. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Wed Sep 9 21:35:58 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 9 Sep 2020 21:35:58 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: <2sdQMJamnqA2xRHM1NpXG2CqHLAKSHr5bqmG-rC4y28=.c1dc6bb3-b6d3-46df-ac77-c9d5053dcabd@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <2sdQMJamnqA2xRHM1NpXG2CqHLAKSHr5bqmG-rC4y28=.c1dc6bb3-b6d3-46df-ac77-c9d5053dcabd@github.com> Message-ID: On Fri, 17 Apr 2020 23:47:42 GMT, John Hendrikx wrote: >> @kevinrushforth I don't propose to remove them, only to move them to where they are needed. >> >> Currently they are part of Node, which means all nodes, whether they need to know the state of the Window or not are >> registering a listener. However, only PopupWindow and the ProgressIndicatorSkin are registering a listener on this >> property (other uses are limited to a simple "isTreeShowing" checks which can be determined directly). It is very >> wasteful to have all nodes register this listener, as there are potentially tens of thousands of nodes. All of these >> nodes are listening on the exact same two properties (when there is only one Scene and Window), causing huge listener >> lists there. The listener is not registered in a lazy fashion (ie, only registered if something else is listening to >> the property downstream, like reactfx would do). This also means that when a Scene change or Window showing change >> occurs, thousands of nodes will receive a change event, but only 2 types of nodes are actually interested. The other >> nodes are just doing a lot of house keeping to keep watching the correct property (as there is an indirection from >> Scene to Window). Therefore my proposal is to have the two cases involved register their own listener on Scene and >> Window. There will not be any regressions. The two tests that currently fail in this PR are expected to fail as I >> commented out the listener code in the classes involved, but that can easily be fixed by adding the correct listeners >> there. I'll update it so you can see all tests will pass. > > @kevinrushforth I've updated this PR now with proper listeners added in again for PopupWindow and > ProgressIndicatorSkin. In short, the functionality to support the `treeShowingProperty` has been extracted to a > separate class `TreeShowingExpression` which is now used by the two classes mentioned. All tests pass, including the > memory leak tests that failed before. > The issue JDK-8090322 you mentioned actually cautioned for not adding such listeners for all nodes and seemed to > propose the kind of solution I constructed here with a separate class for the `treeShowingProperty`: >> This is too expensive to calculate for all nodes by default. So the simplest way to provide it would be a special >> binding implementation or a util class. Where you create a instance and pass in the node you are interested in. It can >> then register listeners all the way up the tree and listen to what it needs. @kevinrushforth I have another working alternative, but won't make a PR for it until it is more clear which direction the TableView / TreeTableView performance fixes are going to take. The alternative would convert the `treeShowing` property in `Node` into a "lazy" property (something which JavaFX does not support directly at the moment). A lazy property only binds to its dependencies when it is observed itself (so in this specific case, only when PopupWindow or ProgressIndicatorSkin are making use of it). This means the property stays a part of `NodeHelper` but will only register its listeners on Window and Scene when it is observed itself. Such lazy properties could be of great use in JavaFX in general, not just in this case. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Wed Sep 9 21:35:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Sep 2020 21:35:59 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <2sdQMJamnqA2xRHM1NpXG2CqHLAKSHr5bqmG-rC4y28=.c1dc6bb3-b6d3-46df-ac77-c9d5053dcabd@github.com> Message-ID: On Tue, 21 Apr 2020 14:22:46 GMT, John Hendrikx wrote: >> @kevinrushforth I've updated this PR now with proper listeners added in again for PopupWindow and >> ProgressIndicatorSkin. In short, the functionality to support the `treeShowingProperty` has been extracted to a >> separate class `TreeShowingExpression` which is now used by the two classes mentioned. All tests pass, including the >> memory leak tests that failed before. >> The issue JDK-8090322 you mentioned actually cautioned for not adding such listeners for all nodes and seemed to >> propose the kind of solution I constructed here with a separate class for the `treeShowingProperty`: >>> This is too expensive to calculate for all nodes by default. So the simplest way to provide it would be a special >>> binding implementation or a util class. Where you create a instance and pass in the node you are interested in. It can >>> then register listeners all the way up the tree and listen to what it needs. > > @kevinrushforth > > I have another working alternative, but won't make a PR for it until it is more clear which direction the TableView / > TreeTableView performance fixes are going to take. > The alternative would convert the `treeShowing` property in `Node` into a "lazy" property (something which JavaFX does > not support directly at the moment). A lazy property only binds to its dependencies when it is observed itself (so in > this specific case, only when PopupWindow or ProgressIndicatorSkin are making use of it). This means the property > stays a part of `NodeHelper` but will only register its listeners on Window and Scene when it is observed itself. > Such lazy properties could be of great use in JavaFX in general, not just in this case. @hjohn Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: 8252935: Add treeShowing listener only when needed ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From github.com+7517141+yososs at openjdk.java.net Thu Sep 10 05:31:40 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 10 Sep 2020 05:31:40 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> Message-ID: On Wed, 9 Sep 2020 02:46:37 GMT, yosbits wrote: >> @yososs Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the >> openjfx-dev mailing list, I have closed [JDK-8185886](https://bugs.openjdk.java.net/browse/JDK-8185886) as a duplicate, >> and suggested another existing JBS issue for this PR to use. Please change the title to: 8185887: TableRowSkinBase >> fails to correctly virtualize cells in horizontal direction > > Below are the answers to JBS's suggestions. > >> The patch below resolves the issue, but it is not likely the correct solution (we are trying to determine the table >> width, but we are getting the width and padding on the underlying virtualflow (the width is fine, the padding should >> really come from tableview directly): > > You probably mention this part, > At least padding refers to Skinnable(TableRow or TreeTableRow). This is the same as before (L683). The width of > VirtualFlow is determined by the header of Table. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java#L360-L365 > Java > final VirtualFlow virtualFlow = getVirtualFlow(); > final double scrollX = virtualFlow == null ? 0.0 : virtualFlow.getHbar().getValue(); > final Insets padding = getSkinnable().getPadding(); > final double vfWidth = virtualFlow == null ? 0.0:virtualFlow.getWidth(); > final double headerWidth = vfWidth - (padding.getLeft() + padding.getRight()); > > For example, can you assume a case that does not work properly? This is the answer to JBS's comment. The BigTreeTableViewTest.java attached to this PR commentary is a modified version of the JDK-8166956 test code. The original test code is good for reproducing the problem, but I have decided that it cannot be used as a test code because the cell values are random and the cell values change randomly with the close / expand operation. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+7517141+yososs at openjdk.java.net Thu Sep 10 09:50:35 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 10 Sep 2020 09:50:35 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2OiqSod2idVc=.88bd412a-9158-47bf-a1df-f7ac78b03ba6@github.com> 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> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2OiqSod2idVc=.88bd412a-9158-47bf-a1df-f7ac78b03ba6@github.com> Message-ID: On Wed, 9 Sep 2020 06:53:11 GMT, dannygonzalez wrote: >> @dannygonzalez Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on >> the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: >> 8252936: Optimize removal of listeners from ExpressionHelper.Generic > > Thanks @kevinrushforth, I've changed the title. I have found that fixing this rudimentary problematic code alleviates your problem. **This fix improves CPU utilization by 1/3 without your changes.** **This fix improves performance in many widespread use cases.** However, I'm wondering how to report the problem. Should it be handled in this issue? Should I deal with a new issue for a rudimentary issue? @kevinrushforth What should i do? https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java#L170-L206 Rewritten so that BitSet is not used. Java @Override public boolean removeAll(Collection c) { if(this.isEmpty() || c.isEmpty()){ return false; } beginChange(); boolean removed = false; for (int i = size()-1; i>=0; i--) { if (c.contains(get(i))) { remove(i); removed = true; } } endChange(); return removed; } @Override public boolean retainAll(Collection c) { if(this.isEmpty() || c.isEmpty()){ return false; } beginChange(); boolean retained = false; for (int i = size()-1; i>=0; i--) { if (!c.contains(get(i))) { remove(i); retained = true; } } endChange(); return retained; } ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Thu Sep 10 12:09:20 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 10 Sep 2020 12:09:20 GMT Subject: RFR: 8252236: TabPane - initial select tab not working properly Message-ID: the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) - initially - after changing side - after resizing stage/tabPane Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its scroll might need an update. Added tests that fail before and pass after the fix. ------------- Commit messages: - 8252236: TabPane - initial select tab not working properly Changes: https://git.openjdk.java.net/jfx/pull/300/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=300&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252236 Stats: 361 lines in 3 files changed: 353 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/300.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/300/head:pull/300 PR: https://git.openjdk.java.net/jfx/pull/300 From fkirmaier at openjdk.java.net Thu Sep 10 13:08:17 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 10 Sep 2020 13:08:17 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: References: <02hKtV2O8WDJUuXZZ-5dtlawHafSm91QcElR_PvuddQ=.a5528377-2c8e-41df-9873-b052e9b564b6@github.com> Message-ID: On Thu, 23 Jul 2020 17:44:14 GMT, Kevin Rushforth wrote: >> Any news about this PR? > > Now that `jfx15` is pretty much done, we'll put this back on the queue to review. Any news? I will probably soon have some PR which would like to use it for the tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Thu Sep 10 13:43:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 13:43:18 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic 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> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2OiqSod2idVc=.88bd412a-9158-47bf-a1df-f7ac78b03ba6@github.com> Message-ID: On Thu, 10 Sep 2020 09:48:07 GMT, yosbits wrote: >> Thanks @kevinrushforth, I've changed the title. > > I have found that fixing this rudimentary problematic code alleviates your problem. > > **This fix will reduce CPU usage by about 1/3 without your changes.** > **This fix improves performance in many widespread use cases.** > > However, I'm wondering how to report the problem. Should it be handled in this issue? Should I deal with a new issue > for a rudimentary issue? > @kevinrushforth What should i do? > > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java#L170-L206 > > Rewritten so that BitSet is not used. > Java > @Override > public boolean removeAll(Collection c) { > if(this.isEmpty() || c.isEmpty()){ > return false; > } > beginChange(); > boolean removed = false; > for (int i = size()-1; i>=0; i--) { > if (c.contains(get(i))) { > remove(i); > removed = true; > } > } > endChange(); > return removed; > } > > @Override > public boolean retainAll(Collection c) { > if(this.isEmpty() || c.isEmpty()){ > return false; > } > beginChange(); > boolean retained = false; > for (int i = size()-1; i>=0; i--) { > if (!c.contains(get(i))) { > remove(i); > retained = true; > } > } > endChange(); > return retained; > } @yososs Please file a new JBS issue for this. You will need to prove that your proposed change is functionally equivalent (or that any perceived changes are incidental and still conform to the spec). You should also think about whether your proposed change needs additional tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Thu Sep 10 15:53:46 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 10 Sep 2020 15:53:46 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic 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> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2OiqSod2idVc=.88bd412a-9158-47bf-a1df-f7ac78b03ba6@github.com> Message-ID: On Thu, 10 Sep 2020 13:41:00 GMT, Kevin Rushforth wrote: >> I have found that fixing this rudimentary problematic code alleviates your problem. >> >> **This fix will reduce CPU usage by about 1/3 without your changes.** >> **This fix improves performance in many widespread use cases.** >> >> However, I'm wondering how to report the problem. Should it be handled in this issue? Should I deal with a new issue >> for a rudimentary issue? >> @kevinrushforth What should i do? >> >> https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java#L170-L206 >> >> Rewritten so that BitSet is not used. >> Java >> @Override >> public boolean removeAll(Collection c) { >> if(this.isEmpty() || c.isEmpty()){ >> return false; >> } >> beginChange(); >> boolean removed = false; >> for (int i = size()-1; i>=0; i--) { >> if (c.contains(get(i))) { >> remove(i); >> removed = true; >> } >> } >> endChange(); >> return removed; >> } >> >> @Override >> public boolean retainAll(Collection c) { >> if(this.isEmpty() || c.isEmpty()){ >> return false; >> } >> beginChange(); >> boolean retained = false; >> for (int i = size()-1; i>=0; i--) { >> if (!c.contains(get(i))) { >> remove(i); >> retained = true; >> } >> } >> endChange(); >> return retained; >> } > > @yososs Please file a new JBS issue for this. You will need to prove that your proposed change is functionally > equivalent (or that any perceived changes are incidental and still conform to the spec). You should also think about > whether your proposed change needs additional tests. Because it is such a small correction Problem from me I feel that it is not easy to register, but I will try to register. It has passed two existing tests for compatibility: * gradle base:test * gradle controls:test ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Thu Sep 10 17:37:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 17:37:25 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 12:25:04 GMT, Jeanette Winzenburg wrote: > ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the > listView and incorrect update of internal state (see bug report for details) > Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView > state when needed. > Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior > before/after. (catching up on some overdue reviews) The fix and tests look fine to me. I left one minor suggestion to add a comment in one of the tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 68: > 66: installDefaultSkin(cell); > 67: cell.updateListView(null); > 68: listView.setFixedCellSize(100); I presume this test is just checking that no exception is thrown? If so, can you add a comment to that effect? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/251 From kcr at openjdk.java.net Thu Sep 10 17:37:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 17:37:26 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: <-QQVL6M_vw_EzzwpQ5TSqK42kkv8senj1h5ONYwG5dc=.dcac7b4e-7b2e-457c-b0dc-12ba130a159f@github.com> On Tue, 16 Jun 2020 10:07:22 GMT, Jeanette Winzenburg wrote: >>> hmm, do you mean a list with height of one cell only? >> >> Yes, List with one cell height. >> In continuation to my previous comment, looks like 8 of the first 23 calls when window is displayed for the first time >> are NOT for the one visible cell. These 8 calls are for some intermediate cell. I added a single counter for all three >> `computeXXHeight` methods and verified with a list of height of one cell. When `fixedCellSize` is not set, total >> combined number of calls for a cell are, 1) 15, when Stage is displayed for the first time.(+8 for an intermediate >> cell, not sure why) 2) 5, when the list item is selected. >> 3) 5, when the Window is resized. > > something similar as I'm seeing - that's good :) Uploaded my [play > code](https://gist.github.com/kleopatra/37ac1bffa0e2ad7580cd55344237cdca) to gist: the idea is to do something (like > f.i. moving the selection), then press f1 to log the calls to each cell (the skin has a final instance counter and > counters for calling the compute methods). As much fun as this is (really like to dig until I'm dirty all over :) - > at the end of the day we'll need some measurements (doing these is not so much fun, still hoping something already > available) Normally we implement this sort of lazy evaluation (caching + invalidation) when there is a computation that is being saved, or when a micro-benchmark shows that something is called 1000s of times (e.g., in the inner loop of some common operation). I don't see either being the case here, but it's possible I missed something. The method in question, `getFixedCellSize()` just calls `ListView::getFixedCellSize` which just returns the value of a property. I suspect that any performance hit would be down in the noise. So I think the complexity of the existing mechanism isn't justified. Removing the listener as the PR proposes to do, which is possible since the listener isn't being used to trigger an operation, seems like a win as well. I am inclined to approve this fix even without performance measurements, since it seems unlikely they would show a problem. @arapte if you want to measure it further before you approve it, that would be fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From kcr at openjdk.java.net Fri Sep 11 00:29:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 00:29:52 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v12] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 09:56:06 GMT, Bhawesh Choudhary wrote: >> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking >> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() >> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in >> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface >> otherwise use usual way of rendering. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Added unit test for strokes modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 447: > 445: public void setClip(int cx, int cy, int cw, int ch, WCImage maskImage) { > 446: setClip(new Rectangle(cx, cy, cw, ch)); > 447: state.setClipMaskImage(maskImage); Should all of the other variants of setClip (the ones that don't take a maskImage) set the clipMaskImage to null? Otherwise it seems that it might not be reset to null in all cases. modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 520: > 518: state.apply(g1); > 519: g1.setPaint(paint); > 520: if(stroke != null) { Minor: there should be a space after the `if`. modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 524: > 522: } > 523: if (isFill) { > 524: g1.fill(shape); This will call the slower `fill(Shape)` method in all cases rather than the specialized `fillRect` or `fillRoundRect` method. Given all the other things that are done to draw a shape with a clip mask, I suspect that this is fine. One thing to consider is to pass in an enum instead of a boolean. The enum could say whether to use the specialized calls or the generic `fill` call. It's probably not worth the effort to make this change. modules/javafx.web/src/test/java/test/javafx/scene/web/SVGTest.java line 164: > 162: final WebPage webPage = WebEngineShim.getPage(getEngine()); > 163: assertNotNull(webPage); > 164: final BufferedImage img = WebPageShim.paint(webPage, 0, 0, 200, 200); This is added to the (preexisting) problem of calling `paint` on the wrong thread. In this case, it doesn't seem to cause any additional problems, and other tests in this same class do it, so we can fix this in the follow-on issue that is already filed, [JDK-8252596](https://bugs.openjdk.java.net/browse/JDK-8252596). ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From kcr at openjdk.java.net Fri Sep 11 00:32:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 00:32:13 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v7] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 14:54:14 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed RenderSVGResourceMasker changes and added fix for HIDPI mask rendering > > modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp line 235: > >> 233: } else { >> 234: if (m_state.fillGradient) { >> 235: setCTM(m_state.transform); > > Why is this needed here, but not in the other places `setGradient` is called? Won't there be a similar problem with > `strokeRect`, `fillPath`, etc? This question is still outstanding. It seems like the call to `setCTM` is either needed before all of the `setGradient` calls or none of them. Can you comment? ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Fri Sep 11 06:51:06 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 11 Sep 2020 06:51:06 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v7] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 00:29:53 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp line 235: >> >>> 233: } else { >>> 234: if (m_state.fillGradient) { >>> 235: setCTM(m_state.transform); >> >> Why is this needed here, but not in the other places `setGradient` is called? Won't there be a similar problem with >> `strokeRect`, `fillPath`, etc? > > This question is still outstanding. It seems like the call to `setCTM` is either needed before all of the `setGradient` > calls or none of them. Can you comment? i believe setCTM call is needed for none of them. it is a workaround i have added till i have more concrete fix. also please note that this workaround is needed only in cases where ui scaling is more than 1. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From arapte at openjdk.java.net Fri Sep 11 09:22:00 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Sep 2020 09:22:00 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v12] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Review: update ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/0755797b..697e4395 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=172&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=172&range=10-11 Stats: 111 lines in 4 files changed: 74 ins; 0 del; 37 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Fri Sep 11 09:40:22 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Sep 2020 09:40:22 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v11] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Wed, 9 Sep 2020 11:49:55 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> rename tests > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 87: > >> 85: Predicate pIsInComboBox = e -> isListViewOfComboBox != null; >> 86: Predicate pIsInEditableComboBox = >> 87: e -> isListViewOfComboBox != null && isListViewOfComboBox.get(); > > nit-pick about naming: I think we don't use (crippled) hungarian notation, or do we? If we don't, the leading "p" > should be removed, isIn/Editable/Combo is expressive enough (and no need to differentiate by type of functional > interface, IMO) Even I was bit skeptical about prefix p, before it those names sounded like a boolean. So I wanted to give it a different name. But as you said, isIn/Editable/Combo looks enough expressive. Changed names. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxListViewSkin.java line 509: > >> 507: getProperties().put("selectFirstRowByDefault", false); >> 508: getProperties().put("editableComboBoxEditor", (Supplier) () -> >> getSkinnable().isEditable()); 509: } > > nit-pick about naming: it's the editable state of the combo (vs. the editable state of the editor) that's in the center > of interest, so maybe rename the key to express that? Like "editableComboBox"? > Another thingy (which I think is a bit under-used in the fx code-base;) - how about a code comment to why this marker > is added and which collaborator is using it? Changed to `editableComboBox` and added a short two liner comment about it. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Fri Sep 11 09:44:22 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Sep 2020 09:44:22 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v11] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Wed, 9 Sep 2020 11:59:35 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> rename tests > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1347: > >> 1345: final ComboBox cb = new ComboBox<>(FXCollections.observableArrayList("a", "b", "c")); >> 1346: cb.setEditable(true); >> 1347: StageLoader sl = new StageLoader(cb); > > shouldn't there be an analogous functional test for not-editable combo? There are both functional and low-level for > editable, but only low-level for not editable. I did not understand what low-level test mean here. But have added test for navigation keys which verify using `SelectionModel.getSelectedIndex()`. Please point if it is sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Fri Sep 11 09:50:59 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Sep 2020 09:50:59 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v11] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Wed, 9 Sep 2020 12:23:32 GMT, Jeanette Winzenburg wrote: > Left some minor comments inline. Updated PR with corrections, please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Fri Sep 11 09:57:09 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 11 Sep 2020 09:57:09 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: > ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the > listView and incorrect update of internal state (see bug report for details) > Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView > state when needed. > Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior > before/after. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: added code comment as requested in review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/251/files - new: https://git.openjdk.java.net/jfx/pull/251/files/c21ed224..75c209a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=251&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=251&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/251.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/251/head:pull/251 PR: https://git.openjdk.java.net/jfx/pull/251 From fastegal at openjdk.java.net Fri Sep 11 09:57:09 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 11 Sep 2020 09:57:09 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 17:20:07 GMT, Kevin Rushforth wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> added code comment as requested in review > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 68: > >> 66: installDefaultSkin(cell); >> 67: cell.updateListView(null); >> 68: listView.setFixedCellSize(100); > > I presume this test is just checking that no exception is thrown? If so, can you add a comment to that effect? yeah, exactly :) Was NPE before fix (due to skin listening to property of previous listView and trying to access the current which is null). Added comment as requested ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From fastegal at openjdk.java.net Fri Sep 11 10:20:36 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 11 Sep 2020 10:20:36 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v12] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Fri, 11 Sep 2020 09:22:00 GMT, Ambarish Rapte wrote: >> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. >> This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several >> `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. >> Fix: >> 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. >> 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to >> `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. >> Change unrelated to fix: >> `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup >> is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code >> from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed >> for the fix. But this seems to be dead code. Verification: >> Added new unit tests to verify the change. >> Also verified that the behavior ListView behaves same before and after this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Review: update looks good to me now :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Fri Sep 11 10:20:39 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Sep 2020 10:20:39 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v11] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Wed, 9 Sep 2020 12:15:51 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> rename tests > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1514: > >> 1512: return ((KeyMapping)mappings.get(i)).getInterceptor().test(null); >> 1513: } >> 1514: > > his throws an NPE without the fix - which makes the test using this method still fail (good!), but a bit unspecific for > my taste. A slight re-organisation of the helpers might help: move the asserts down instead of returning a boolean. Change function as you suggested. Unlike ListViewTest, ComboBoxTest needs to verify if the interceptor correctly evaluates to either true or false, so it needed a minor tweak to use `assertEquals()` ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Fri Sep 11 10:20:41 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 11 Sep 2020 10:20:41 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v11] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Fri, 11 Sep 2020 09:41:46 GMT, Ambarish Rapte wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1347: >> >>> 1345: final ComboBox cb = new ComboBox<>(FXCollections.observableArrayList("a", "b", "c")); >>> 1346: cb.setEditable(true); >>> 1347: StageLoader sl = new StageLoader(cb); >> >> shouldn't there be an analogous functional test for not-editable combo? There are both functional and low-level for >> editable, but only low-level for not editable. > > I did not understand what low-level test mean here. But have added test for navigation keys which verify using > `SelectionModel.getSelectedIndex()`. Please point if it is sufficient. my apologies for having been unclear: low-level == implementation details in keyMappings whereas functional are those testing the effect on firing keys. But you guessed so much and added tests of key-firing on not-editable combo, so looks good now :) ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From kcr at openjdk.java.net Fri Sep 11 12:01:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 12:01:08 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:57:09 GMT, Jeanette Winzenburg wrote: >> ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the >> listView and incorrect update of internal state (see bug report for details) >> Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView >> state when needed. >> Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior >> before/after. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > added code comment as requested in review Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From arapte at openjdk.java.net Fri Sep 11 12:05:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Sep 2020 12:05:15 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:57:09 GMT, Jeanette Winzenburg wrote: >> ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the >> listView and incorrect update of internal state (see bug report for details) >> Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView >> state when needed. >> Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior >> before/after. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > added code comment as requested in review Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From arapte at openjdk.java.net Fri Sep 11 12:05:16 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Sep 2020 12:05:16 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin [v2] In-Reply-To: <-QQVL6M_vw_EzzwpQ5TSqK42kkv8senj1h5ONYwG5dc=.dcac7b4e-7b2e-457c-b0dc-12ba130a159f@github.com> References: <-QQVL6M_vw_EzzwpQ5TSqK42kkv8senj1h5ONYwG5dc=.dcac7b4e-7b2e-457c-b0dc-12ba130a159f@github.com> Message-ID: On Thu, 10 Sep 2020 17:10:41 GMT, Kevin Rushforth wrote: >> something similar as I'm seeing - that's good :) Uploaded my [play >> code](https://gist.github.com/kleopatra/37ac1bffa0e2ad7580cd55344237cdca) to gist: the idea is to do something (like >> f.i. moving the selection), then press f1 to log the calls to each cell (the skin has a final instance counter and >> counters for calling the compute methods). As much fun as this is (really like to dig until I'm dirty all over :) - >> at the end of the day we'll need some measurements (doing these is not so much fun, still hoping something already >> available) > > Normally we implement this sort of lazy evaluation (caching + invalidation) when there is a computation that is being > saved, or when a micro-benchmark shows that something is called 1000s of times (e.g., in the inner loop of some common > operation). I don't see either being the case here, but it's possible I missed something. The method in question, > `getFixedCellSize()` just calls `ListView::getFixedCellSize` which just returns the value of a property. I suspect that > any performance hit would be down in the noise. So I think the complexity of the existing mechanism isn't justified. > Removing the listener as the PR proposes to do, which is possible since the listener isn't being used to trigger an > operation, seems like a win as well. I am inclined to approve this fix even without performance measurements, since it > seems unlikely they would show a problem. > @arapte if you want to measure it further before you approve it, that would be fine. The few additional computation would not cause any harm to performance. It just increases few computations in the compute* methods. Just for sanity verified a program with ListView of 10000000. ListView gets scrolled just as smooth. Approving. ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From fastegal at openjdk.java.net Fri Sep 11 12:23:57 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 11 Sep 2020 12:23:57 GMT Subject: Integrated: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 12:25:04 GMT, Jeanette Winzenburg wrote: > ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the > listView and incorrect update of internal state (see bug report for details) > Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView > state when needed. > Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior > before/after. This pull request has now been integrated. Changeset: 0514116f Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/0514116f Stats: 98 lines in 4 files changed: 32 ins; 59 del; 7 mod 8246745: ListCell/Skin: misbehavior on switching skin Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From kcr at openjdk.java.net Fri Sep 11 13:29:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 13:29:04 GMT Subject: RFR: 8240499: Enforce whitespace checking for additional source files Message-ID: The `.jcheck/conf` file is configured to check the same set of files as the old HG jcheck, namely files with the following extensions: .java, .c, .h, .cpp, .hpp The Skara git jcheck allows us to evolve the rules for white space checking compatibly. This PR adds the following additional file extensions to the list of source files that need to be kept whitespace-clean: .cc, .css, .frag, .fxml, .g4, .gradle, .groovy, .hlsl, .jsl, .m, .metal, .mm, .stg, .vert For ease of review, I have done the initial push as 2 commits. The first modifies the `.jcheck/conf` file and `tools/scripts/checkWhiteSpace` script to add the additional extensions. The second fixes the whitespace errors in the (39) files among those with the newly added extensions. ------------- Commit messages: - 8240499: Enforce whitespace checking for additional source files - 8240499: Enforce whitespace checking for additional source files Changes: https://git.openjdk.java.net/jfx/pull/301/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240499 Stats: 148 lines in 41 files changed: 0 ins; 16 del; 132 mod Patch: https://git.openjdk.java.net/jfx/pull/301.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/301/head:pull/301 PR: https://git.openjdk.java.net/jfx/pull/301 From kcr at openjdk.java.net Fri Sep 11 18:22:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 18:22:27 GMT Subject: RFR: 8223375: Remove Netbeans specific files from the source code repository Message-ID: As discussed in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/027049.html) on openjfx-dev I propose to remove the old netbeans-specific files from the source repository. They were originally done for NetBeans 8 / FX 8,. They sort of worked (but not well) with FX 9 (still using NB 8), but no longer work at all. The gradle support in the latest Apache NetBeans 12 is already pretty good, with a couple bugs that they need to fix. There is no longer a reason to host these old netbeans project files in our repo. ------------- Commit messages: - 8223375: Remove Netbeans specific files from the source code repository Changes: https://git.openjdk.java.net/jfx/pull/302/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=302&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223375 Stats: 32535 lines in 155 files changed: 0 ins; 32535 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/302.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/302/head:pull/302 PR: https://git.openjdk.java.net/jfx/pull/302 From kcr at openjdk.java.net Fri Sep 11 18:22:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 18:22:27 GMT Subject: RFR: 8223375: Remove Netbeans specific files from the source code repository In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 18:17:30 GMT, Kevin Rushforth wrote: > As discussed in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/027049.html) on > openjfx-dev I propose to remove the old netbeans-specific files from the source repository. They were originally done > for NetBeans 8 / FX 8,. They sort of worked (but not well) with FX 9 (still using NB 8), but no longer work at all. The > gradle support in the latest Apache NetBeans 12 is already pretty good, with a couple bugs that they need to fix. There > is no longer a reason to host these old netbeans project files in our repo. I'll leave this for a few days even if someone approves it sooner, in case there are any concerns raised. ------------- PR: https://git.openjdk.java.net/jfx/pull/302 From kcr at openjdk.java.net Fri Sep 11 19:29:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 19:29:18 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec In-Reply-To: References: Message-ID: On Sun, 30 Aug 2020 16:09:14 GMT, Nir Lisker wrote: > Moving implementation details about lazy evaluation and equality checking to `@implSpec`. I left a couple suggestions below. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 42: > 40: * An implementation of {@code ObservableValue} may support lazy evaluation, > 41: * which means that the value is not immediately recomputed after changes, but > 42: * lazily the next time the value is requested (see note 1 in {@code implSpec}). The term "implSpec" doesn't show up in the generated documents, so maybe change it to something like: see note 1 in the "Implementation Requirements" modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 46: > 44: * An {@code ObservableValue} generates two types of events: change events and > 45: * invalidation events. A change event indicates that the value has changed > 46: * (see note 2 in {@code implSpec}). An invalidation event is generated if the current value is not valid anymore. Same comment as above. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 73: > 71: *
  • All bindings and properties in this library support lazy evaluation. > 72: *
  • Current implementing classes in JavaFX check for a change using reference > 73: * equality (and not object equality, {@code Object#equals(Object)}) of the value. Now that they are right next to each other, it would be good to unify the language of these two requirements, making it clear that both apply to all JavaFX classes that implement this interface. Perhaps something like: 1. All bindings and properties in the JavaFX library support lazy... 2. All implementing classes in the JavaFX library check for a change... ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Fri Sep 11 21:49:44 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 21:49:44 GMT Subject: RFR: 8252547: Correct transformations docs in Node In-Reply-To: References: Message-ID: On Mon, 31 Aug 2020 23:28:51 GMT, Nir Lisker wrote: > Correction to the order of transforms specified in the docs of `Node`. The updated text look good, although there is a javadoc error that causes the build to fail. I left a few comments below. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 335: > 333: * > 334: * The transforms are applied in the reverse order of the matrix multiplication outlined above: last element of > the transforms list 335: * to 0th element, scale, rotate, and layout and translate. By applying the transforms in this > order, the bound in the local "bounds" should be plural. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 328: > 326: * The matrices that represent the transforms are multiplied in this order: > 327: *
      > 328: *
    1. Layout ({@link #layoutXProperty layoutX}), {@link #layoutYProperty layoutY} and translate The closing paren should be after `layoutY`: *
    2. Layout ({@link #layoutXProperty layoutX}, {@link #layoutYProperty layoutY}) and ... Also, can you add `
    3. ` after each item? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 3423: > 3421: * > 3422: * @return the {@code boundsInParent} property for this {@code Node} > 3423: * @see {@linkplain Node Bounding Rectangles} section in the class docs This causes a javadoc error: > Task :javadoc modules\javafx.graphics\src\main\java\javafx\scene\Node.java:3423: error: unexpected content * @see {@linkplain Node Bounding Rectangles} section in the class docs ^ 1 error > Task :javadoc FAILED ------------- PR: https://git.openjdk.java.net/jfx/pull/293 From nlisker at openjdk.java.net Sat Sep 12 10:48:17 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 10:48:17 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v2] In-Reply-To: References: Message-ID: <_hGJ0qF-fcn73IxSSeaf2SywmSlbSwT8zF-LxxyA9KU=.f0010dbf-f652-4413-8028-3db739c3f751@github.com> > Moving implementation details about lazy evaluation and equality checking to `@implSpec`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/292/files - new: https://git.openjdk.java.net/jfx/pull/292/files/808ba3ce..2a0b1f3b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=292&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=292&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/292/head:pull/292 PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Sat Sep 12 12:58:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Sep 2020 12:58:17 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v2] In-Reply-To: <_hGJ0qF-fcn73IxSSeaf2SywmSlbSwT8zF-LxxyA9KU=.f0010dbf-f652-4413-8028-3db739c3f751@github.com> References: <_hGJ0qF-fcn73IxSSeaf2SywmSlbSwT8zF-LxxyA9KU=.f0010dbf-f652-4413-8028-3db739c3f751@github.com> Message-ID: On Sat, 12 Sep 2020 10:48:17 GMT, Nir Lisker wrote: >> Moving implementation details about lazy evaluation and equality checking to `@implSpec`. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Looks good with one minor comment. Go ahead and create the CSR once you make the requested update. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 46: > 44: * An {@code ObservableValue} generates two types of events: change events and > 45: * invalidation events. A change event indicates that the value has changed > 46: * (see note 2 in "Implementation Requirements"). An invalidation event is generated if the current value is not > valid anymore. Minor: either add `the` before `"Implementation Requirements"` here or remove `the` from the earlier line for consistency. Minor: as long as you are here, can you break this line between `An` and `invalidation`? In addition to wrapping a long line, it will reduce the diffs, which seems good given that there will be an associated CSR. ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From nlisker at openjdk.java.net Sat Sep 12 13:43:54 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 13:43:54 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v2] In-Reply-To: References: Message-ID: > Correction to the order of transforms specified in the docs of `Node`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/293/files - new: https://git.openjdk.java.net/jfx/pull/293/files/d56f8d02..e09d20f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=00-01 Stats: 16 lines in 1 file changed: 4 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/293/head:pull/293 PR: https://git.openjdk.java.net/jfx/pull/293 From nlisker at openjdk.java.net Sat Sep 12 13:46:38 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 13:46:38 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v3] In-Reply-To: References: Message-ID: > Correction to the order of transforms specified in the docs of `Node`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added tags ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/293/files - new: https://git.openjdk.java.net/jfx/pull/293/files/e09d20f7..0bf63c0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/293/head:pull/293 PR: https://git.openjdk.java.net/jfx/pull/293 From nlisker at openjdk.java.net Sat Sep 12 13:50:08 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 13:50:08 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v3] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 21:43:46 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Added tags > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 3423: > >> 3421: * >> 3422: * @return the {@code boundsInParent} property for this {@code Node} >> 3423: * @see {@linkplain Node Bounding Rectangles} section in the class docs > > This causes a javadoc error: > >> Task :javadoc > modules\javafx.graphics\src\main\java\javafx\scene\Node.java:3423: error: unexpected content > * @see {@linkplain Node Bounding Rectangles} section in the class docs > ^ > 1 error > >> Task :javadoc FAILED `@see` doesn't show for properties because of the special handling (same goes for `@return`). I opted to create HTML links to the headers instead. I did it to all for them even if they are not all used. ------------- PR: https://git.openjdk.java.net/jfx/pull/293 From nlisker at openjdk.java.net Sat Sep 12 13:53:49 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 13:53:49 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v4] In-Reply-To: References: Message-ID: > Correction to the order of transforms specified in the docs of `Node`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Replaced link ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/293/files - new: https://git.openjdk.java.net/jfx/pull/293/files/0bf63c0b..453435ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/293/head:pull/293 PR: https://git.openjdk.java.net/jfx/pull/293 From nlisker at openjdk.java.net Sat Sep 12 14:10:38 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 14:10:38 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: References: Message-ID: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> > Moving implementation details about lazy evaluation and equality checking to `@implSpec`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments and added ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/292/files - new: https://git.openjdk.java.net/jfx/pull/292/files/2a0b1f3b..6529dc4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=292&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=292&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/292/head:pull/292 PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Sat Sep 12 14:28:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Sep 2020 14:28:09 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> References: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> Message-ID: On Sat, 12 Sep 2020 14:10:38 GMT, Nir Lisker wrote: >> Moving implementation details about lazy evaluation and equality checking to `@implSpec`. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments and added Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Sat Sep 12 14:39:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Sep 2020 14:39:52 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: References: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> Message-ID: On Sat, 12 Sep 2020 14:25:53 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments and added > > Marked as reviewed by kcr (Lead). I see that [SKARA-548](https://bugs.openjdk.java.net/browse/SKARA-548) is still an issue, and that the PR was marked ready without the CSR being approved. ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From nlisker at openjdk.java.net Sat Sep 12 14:39:52 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 14:39:52 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: References: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> Message-ID: On Sat, 12 Sep 2020 14:35:49 GMT, Kevin Rushforth wrote: >> Marked as reviewed by kcr (Lead). > > I see that [SKARA-548](https://bugs.openjdk.java.net/browse/SKARA-548) is still an issue, and that the PR was marked > ready without the CSR being approved. Yeah I saw. The CSR has been submitted. I think that the bot isn't picking up on it even. ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Sat Sep 12 14:49:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Sep 2020 14:49:45 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v4] In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 13:53:49 GMT, Nir Lisker wrote: >> Correction to the order of transforms specified in the docs of `Node`. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Replaced link Changes look good to me. I asked one question about whether you wanted to add another hyperlink, but it's up to you. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 336: > 334: * The transforms are applied in the reverse order of the matrix multiplication outlined above: last element of > the transforms list 335: * to 0th element, scale, rotate, and layout and translate. By applying the transforms in this > order, the bounds in the local 336: * coordinates of the node are transformed to the bounds in the parent coordinate > of the node (see the Bounding Rectangles Maybe hyperlink to the Bounding Rectangles section? (although as it is right below, it isn't as important). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/293 From nlisker at openjdk.java.net Sat Sep 12 15:21:35 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 15:21:35 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v5] In-Reply-To: References: Message-ID: > Correction to the order of transforms specified in the docs of `Node`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Replaced a link ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/293/files - new: https://git.openjdk.java.net/jfx/pull/293/files/453435ef..45f9d8aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/293/head:pull/293 PR: https://git.openjdk.java.net/jfx/pull/293 From nlisker at openjdk.java.net Sat Sep 12 15:21:37 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 12 Sep 2020 15:21:37 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v4] In-Reply-To: References: Message-ID: <8BV6zuUE-jqyJ4UmldHbnXbYo2Vvv-EFkW9ketdurOw=.13acff7b-c9c3-4978-8920-858dc5189c2c@github.com> On Sat, 12 Sep 2020 14:41:01 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Replaced link > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 336: > >> 334: * The transforms are applied in the reverse order of the matrix multiplication outlined above: last element of >> the transforms list 335: * to 0th element, scale, rotate, and layout and translate. By applying the transforms in this >> order, the bounds in the local 336: * coordinates of the node are transformed to the bounds in the parent coordinate >> of the node (see the Bounding Rectangles > > Maybe hyperlink to the Bounding Rectangles section? (although as it is right below, it isn't as important). Originally I had "see the next section" but didn't want to depend on the order. I put the link anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/293 From kcr at openjdk.java.net Sat Sep 12 16:01:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Sep 2020 16:01:00 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v5] In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 15:21:35 GMT, Nir Lisker wrote: >> Correction to the order of transforms specified in the docs of `Node`. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Replaced a link Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/293 From arapte at openjdk.java.net Mon Sep 14 07:11:46 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 14 Sep 2020 07:11:46 GMT Subject: RFR: 8252236: TabPane - initial select tab not working properly In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:03:34 GMT, Jeanette Winzenburg wrote: > the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) > > - initially > - after changing side > - after resizing stage/tabPane > > Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its > scroll might need an update. > Added tests that fail before and pass after the fix. In a bid to find more scenarios like you did mention description, I observed two more scenarios when selected tab does not stay in view. 1. Inserting tabs before or removing tabs after selected tab or moving the selected tab, causes the selected tab to go out of view. 2. Rotating TabPane can also take the selected tab out of view. I am little doubtful if it a legitimate issue. The rotations I tried clipped TabPane and TabPane header. I think rotation issue can be kept out of scope of this issue, can be filed as a follow on. I leave to it to you to take a call. About 1, I did quickly verify that it gets fixed by adding `invalidateScrollOffset();` call in `TabHeaderArea.removeTab()`, `TabHeaderArea.addTab()` and `TabHeaderArea.moveTab()`. Also If we fix it here, then bug summary might need a change. It currently reflects only initial tab. ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From arapte at openjdk.java.net Mon Sep 14 07:33:16 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 14 Sep 2020 07:33:16 GMT Subject: RFR: 8252547: Correct transformations docs in Node [v5] In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 15:21:35 GMT, Nir Lisker wrote: >> Correction to the order of transforms specified in the docs of `Node`. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Replaced a link change looks good to me, javadoc built with no problem. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/293 From jvos at openjdk.java.net Mon Sep 14 08:04:04 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 14 Sep 2020 08:04:04 GMT Subject: RFR: 8240499: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: <6B_ffj4sem07Y2Y1C6fAj9Bl68YypSP9at7g9ZH0dfA=.e1cb124b-bc23-4a7f-b233-e837d210884b@github.com> On Fri, 11 Sep 2020 13:21:29 GMT, Kevin Rushforth wrote: > The `.jcheck/conf` file is configured to check the same set of files as the old HG jcheck, namely files with the > following extensions: > .java, .c, .h, .cpp, .hpp > > The Skara git jcheck allows us to evolve the rules for white space checking compatibly. > > This PR adds the following additional file extensions to the list of source files that need to be kept whitespace-clean: > > .cc, .css, .frag, .fxml, .g4, .gradle, .groovy, .hlsl, .jsl, .m, .metal, .mm, .stg, .vert > > For ease of review, I have done the initial push as 2 commits. The first modifies the `.jcheck/conf` file and > `tools/scripts/checkWhiteSpace` script to add the additional extensions. The second fixes the whitespace errors in the > (39) files among those with the newly added extensions. Tested this with before/after tests, and it works as expected. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/301 From fastegal at openjdk.java.net Mon Sep 14 09:14:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 14 Sep 2020 09:14:33 GMT Subject: RFR: 8252236: TabPane - initial select tab not working properly In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 07:09:01 GMT, Ambarish Rapte wrote: >> the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) >> >> - initially >> - after changing side >> - after resizing stage/tabPane >> >> Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its >> scroll might need an update. >> Added tests that fail before and pass after the fix. > > In a bid to find more scenarios like you did mention description, I observed two more scenarios when selected tab does > not stay in view. 1. Inserting tabs before or removing tabs after selected tab or moving the selected tab, causes the > selected tab to go out of view. 2. Rotating TabPane can also take the selected tab out of view. I am little doubtful if > it a legitimate issue. The rotations I tried clipped TabPane and TabPane header. I think rotation issue can be kept > out of scope of this issue, can be filed as a follow on. I leave to it to you to take a call. > About 1, I did quickly verify that it gets fixed by adding `invalidateScrollOffset();` call in > `TabHeaderArea.removeTab()`, `TabHeaderArea.addTab()` and `TabHeaderArea.moveTab()`. Also If we fix it here, then bug > summary might need a change. It currently reflects only initial tab. good catch and many thanks for the evaluation - now all I'll have to do is to write tests to catch them :) Will also update the bug summary as you suggest. Agree, that the second can be regarded as off scope, as it seems to effect both header and content - will not do anything in this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From nlisker at openjdk.java.net Mon Sep 14 09:52:07 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 14 Sep 2020 09:52:07 GMT Subject: Integrated: 8252547: Correct transformations docs in Node In-Reply-To: References: Message-ID: On Mon, 31 Aug 2020 23:28:51 GMT, Nir Lisker wrote: > Correction to the order of transforms specified in the docs of `Node`. This pull request has now been integrated. Changeset: d6dee348 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/d6dee348 Stats: 45 lines in 1 file changed: 12 ins; 15 del; 18 mod 8252547: Correct transformations docs in Node Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/293 From github.com+7517141+yososs at openjdk.java.net Mon Sep 14 10:03:30 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 14 Sep 2020 10:03:30 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper Message-ID: https://bugs.openjdk.java.net/browse/JDK-8253086 ObservableListWrapper.java * public boolean removeAll(Collection c) * public boolean retainAll(Collection c) These two methods use BitSet, but it doesn't make sense. By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range of use cases. The test is done with the following command. * gradle base: test * gradle controls: test ------------- Commit messages: - 8253086: Optimization of removeAll and retainAll of ObservableListWrapper Changes: https://git.openjdk.java.net/jfx/pull/305/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253086 Stats: 26 lines in 1 file changed: 6 ins; 10 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/305/head:pull/305 PR: https://git.openjdk.java.net/jfx/pull/305 From aghaisas at openjdk.java.net Mon Sep 14 10:06:56 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 14 Sep 2020 10:06:56 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.88aea0b5-c8bd-459d-89a4-27be96af88b8@github.com> Message-ID: <1pAtd4WAcBklWUnlXeR3ezHWQxE0elZ5omkLCsCUYEM=.1212bcac-25ca-40d9-999a-b7018af4c51f@github.com> On Mon, 7 Sep 2020 18:14:03 GMT, Timm wrote: >> @aghaisas can you also review this? > > Any progress with having this merged? This is a very good attempt to improve selection performance. I have few review comments. I ran the manual test that you have provided. It does show the improvement. Can you please provide an automated test along with your fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From aghaisas at openjdk.java.net Mon Sep 14 10:06:57 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 14 Sep 2020 10:06:57 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of > TreeUtil.getTreeItem (). > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), > tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 899: > 897: for (;;) { > 898: index = bitset.nextSetBit(index + 1); > 899: if (index < 0) { As we are checking for nextSetBit, shouldn't we be checking for overflow rather than underflow? Refer - [javadoc](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/BitSet.html#nextSetBit(int)) modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 861: > 859: } > 860: > 861: /** Returns number of true bits in BitSet */ Method description and work done by it is no more matching. Can you please update the comment? modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 890: > 888: > 889: // is right most bit > 890: if( index == bitset.length()-1 ){ Spacing correction needed. Correct spacing is : "if (index == bitset.length()-1) {" Please correct at other places in this PR. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 885: > 883: } > 884: // is left most bit > 885: if(index==0) { Spacing correction needed. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 881: > 879: Number n = (Number) obj; > 880: int index = n.intValue(); > 881: if(!bitset.get(index)) { Spacing correction needed. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 895: > 893: > 894: // count right bit > 895: if( index > bitset.length()/2 ) { Spacing correction needed. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 912: > 910: for(;;){ > 911: index = bitset.previousSetBit(index-1); > 912: if(index<0){ Spacing correction needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From bchoudhary at openjdk.java.net Mon Sep 14 13:47:28 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 14 Sep 2020 13:47:28 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v13] In-Reply-To: References: Message-ID: > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Updates as per review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/ed2dd092..f26f03df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=11-12 Stats: 336 lines in 6 files changed: 173 ins; 152 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Mon Sep 14 14:15:30 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 14 Sep 2020 14:15:30 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v7] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 06:48:35 GMT, Bhawesh Choudhary wrote: >> This question is still outstanding. It seems like the call to `setCTM` is either needed before all of the `setGradient` >> calls or none of them. Can you comment? > > i believe setCTM call is needed for none of them. it is a workaround i have added till i have more concrete fix. also > please note that this workaround is needed only in cases where ui scaling is more than 1. Removed the workaround and added right fix. `setCTM` call is not needed in any of the case. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Mon Sep 14 14:15:31 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 14 Sep 2020 14:15:31 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v12] In-Reply-To: References: Message-ID: <5d54UOf5T_PEMrOTXSMcPW0t4XyqrdjpT9bJlN51cr4=.7c19bc62-2af3-40b3-9965-92310c58d341@github.com> On Fri, 11 Sep 2020 00:10:29 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Added unit test for strokes > > modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 447: > >> 445: public void setClip(int cx, int cy, int cw, int ch, WCImage maskImage) { >> 446: setClip(new Rectangle(cx, cy, cw, ch)); >> 447: state.setClipMaskImage(maskImage); > > Should all of the other variants of setClip (the ones that don't take a maskImage) set the clipMaskImage to null? > Otherwise it seems that it might not be reset to null in all cases. added setting of null to maskImage for all the overloads of setClip where mask image is not present. > modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 520: > >> 518: state.apply(g1); >> 519: g1.setPaint(paint); >> 520: if(stroke != null) { > > Minor: there should be a space after the `if`. Fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Mon Sep 14 14:28:12 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 14 Sep 2020 14:28:12 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v12] In-Reply-To: References: Message-ID: <8BBggmV3-Yl_N1nme3-4o1Fk4arzJz4HppVGzwqIeqc=.a4ddafdd-82b5-4283-91d7-1a160ba54783@github.com> On Fri, 11 Sep 2020 00:13:48 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Added unit test for strokes > > modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 524: > >> 522: } >> 523: if (isFill) { >> 524: g1.fill(shape); > > This will call the slower `fill(Shape)` method in all cases rather than the specialized `fillRect` or `fillRoundRect` > method. Given all the other things that are done to draw a shape with a clip mask, I suspect that this is fine. One > thing to consider is to pass in an enum instead of a boolean. The enum could say whether to use the specialized calls > or the generic `fill` call. It's probably not worth the effort to make this change. other than paths only RoundRectangle2D is passed to this function. Shape can be checked if it is an instance of RoundRectangle2D and faster draw api can be called. added the same along with enum private to this class. > modules/javafx.web/src/test/java/test/javafx/scene/web/SVGTest.java line 164: > >> 162: final WebPage webPage = WebEngineShim.getPage(getEngine()); >> 163: assertNotNull(webPage); >> 164: final BufferedImage img = WebPageShim.paint(webPage, 0, 0, 200, 200); > > This is added to the (preexisting) problem of calling `paint` on the wrong thread. In this case, it doesn't seem to > cause any additional problems, and other tests in this same class do it, so we can fix this in the follow-on issue that > is already filed, [JDK-8252596](https://bugs.openjdk.java.net/browse/JDK-8252596). moved tests to system test. also consolidated all tests into one. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From github.com+7517141+yososs at openjdk.java.net Mon Sep 14 17:25:45 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 14 Sep 2020 17:25:45 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <1pAtd4WAcBklWUnlXeR3ezHWQxE0elZ5omkLCsCUYEM=.1212bcac-25ca-40d9-999a-b7018af4c51f@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.88aea0b5-c8bd-459d-89a4-27be96af88b8@github.com> <1pAtd4WAcBklWUnlXeR3ezHWQxE0elZ5omkLCsCUYEM=.1212bcac-25ca-40d9-999a-b7018af4c51f@github.com> Message-ID: On Mon, 14 Sep 2020 10:03:59 GMT, Ajit Ghaisas wrote: >> Any progress with having this merged? > > This is a very good attempt to improve selection performance. I have few review comments. > I ran the manual test that you have provided. It does show the improvement. > Can you please provide an automated test along with your fix? The reviewer didn't point out that the There's a little bit of wastage left in the toArray(), so I'm going to push a modified version. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From omniprof at gmail.com Mon Sep 14 20:02:52 2020 From: omniprof at gmail.com (omniprof at gmail.com) Date: Mon, 14 Sep 2020 16:02:52 -0400 Subject: Media Player Failure When Speakers Not Present Message-ID: <011401d68ad2$07b891b0$1729b510$@gmail.com> While I am still looking for where I can file this problem I thought I'd bring it to the list. A program I use in my course plays a short video. Have used it for a few years and it works fine. EXCEPT, if there is not a connected audio out device such as speakers or headphones. The video does not play and there is no stack trace or any other indication of a problem. Stage opens fine but the media control does nothing and the scene appears empty. Discovered when I used a machine that did not have speakers plugged into it. Expected behaviour was just to see the video without sound. It is possible that this bug has been around since the introduction of the Media / Media Player control. I assume the code works like "Hi M. PCaudio, what are you connected to?" "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll just wait forever or just give up and do nothing". Or, it can just be a crazy Xeon based Windows machine that is giving grief to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. Ken Fogel PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will submit a bug report. From nlisker at gmail.com Mon Sep 14 20:18:58 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 14 Sep 2020 23:18:58 +0300 Subject: Media Player Failure When Speakers Not Present In-Reply-To: <011401d68ad2$07b891b0$1729b510$@gmail.com> References: <011401d68ad2$07b891b0$1729b510$@gmail.com> Message-ID: > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > bugreport.java.com On Mon, Sep 14, 2020 at 11:03 PM wrote: > While I am still looking for where I can file this problem I thought I'd > bring it to the list. A program I use in my course plays a short video. > Have > used it for a few years and it works fine. EXCEPT, if there is not a > connected audio out device such as speakers or headphones. The video does > not play and there is no stack trace or any other indication of a problem. > Stage opens fine but the media control does nothing and the scene appears > empty. Discovered when I used a machine that did not have speakers plugged > into it. Expected behaviour was just to see the video without sound. It is > possible that this bug has been around since the introduction of the Media > / > Media Player control. > > > > I assume the code works like "Hi M. PCaudio, what are you connected to?" > "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, > I'll > just wait forever or just give up and do nothing". > > > > Or, it can just be a crazy Xeon based Windows machine that is giving grief > to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. > > > > Ken Fogel > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > > From omniprof at gmail.com Mon Sep 14 20:27:37 2020 From: omniprof at gmail.com (omniprof at gmail.com) Date: Mon, 14 Sep 2020 16:27:37 -0400 Subject: Media Player Failure When Speakers Not Present In-Reply-To: References: <011401d68ad2$07b891b0$1729b510$@gmail.com> Message-ID: <012501d68ad5$7d20d860$77628920$@gmail.com> I am a little confused. The url you sent appears to be for Java SE bug reporting and I thought that JavaFX as OpenJFX is not part of the Java SE distribution. If so then this may not be where I report my issue. Ken From: Nir Lisker Sent: September 14, 2020 4:19 PM To: omniprof at gmail.com Cc: openjfx-dev at openjdk.java.net Mailing Subject: Re: Media Player Failure When Speakers Not Present PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will submit a bug report. bugreport.java.com On Mon, Sep 14, 2020 at 11:03 PM > wrote: While I am still looking for where I can file this problem I thought I'd bring it to the list. A program I use in my course plays a short video. Have used it for a few years and it works fine. EXCEPT, if there is not a connected audio out device such as speakers or headphones. The video does not play and there is no stack trace or any other indication of a problem. Stage opens fine but the media control does nothing and the scene appears empty. Discovered when I used a machine that did not have speakers plugged into it. Expected behaviour was just to see the video without sound. It is possible that this bug has been around since the introduction of the Media / Media Player control. I assume the code works like "Hi M. PCaudio, what are you connected to?" "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll just wait forever or just give up and do nothing". Or, it can just be a crazy Xeon based Windows machine that is giving grief to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. Ken Fogel PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will submit a bug report. From mp at jugs.org Mon Sep 14 20:36:39 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 14 Sep 2020 22:36:39 +0200 Subject: Media Player Failure When Speakers Not Present In-Reply-To: <012501d68ad5$7d20d860$77628920$@gmail.com> References: <011401d68ad2$07b891b0$1729b510$@gmail.com> <012501d68ad5$7d20d860$77628920$@gmail.com> Message-ID: <731f8a45-35e0-0eaa-e528-1071eaea735e@jugs.org> The URL is correct. JavaFX is still tracked by the normal JDK bug tracking system. Am 14.09.20 um 22:27 schrieb omniprof at gmail.com: > I am a little confused. The url you sent appears to be for Java SE bug reporting and I thought that JavaFX as OpenJFX is not part of the Java SE distribution. If so then this may not be where I report my issue. > > > > Ken > > > > > > From: Nir Lisker > Sent: September 14, 2020 4:19 PM > To: omniprof at gmail.com > Cc: openjfx-dev at openjdk.java.net Mailing > Subject: Re: Media Player Failure When Speakers Not Present > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > > bugreport.java.com > > > > On Mon, Sep 14, 2020 at 11:03 PM > wrote: > > While I am still looking for where I can file this problem I thought I'd > bring it to the list. A program I use in my course plays a short video. Have > used it for a few years and it works fine. EXCEPT, if there is not a > connected audio out device such as speakers or headphones. The video does > not play and there is no stack trace or any other indication of a problem. > Stage opens fine but the media control does nothing and the scene appears > empty. Discovered when I used a machine that did not have speakers plugged > into it. Expected behaviour was just to see the video without sound. It is > possible that this bug has been around since the introduction of the Media / > Media Player control. > > > > I assume the code works like "Hi M. PCaudio, what are you connected to?" > "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll > just wait forever or just give up and do nothing". > > > > Or, it can just be a crazy Xeon based Windows machine that is giving grief > to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. > > > > Ken Fogel > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > > From nlisker at gmail.com Mon Sep 14 20:37:26 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 14 Sep 2020 23:37:26 +0300 Subject: Media Player Failure When Speakers Not Present In-Reply-To: <012501d68ad5$7d20d860$77628920$@gmail.com> References: <011401d68ad2$07b891b0$1729b510$@gmail.com> <012501d68ad5$7d20d860$77628920$@gmail.com> Message-ID: The issues database is the same for all OpenJDK projects, including JDK and OpenJFX. When you submit the issue, it is triaged internally and transferred to the public JBS at https://bugs.openjdk.java.net. On Mon, Sep 14, 2020 at 11:27 PM wrote: > I am a little confused. The url you sent appears to be for Java SE bug > reporting and I thought that JavaFX as OpenJFX is not part of the Java SE > distribution. If so then this may not be where I report my issue. > > > > Ken > > > > > > *From:* Nir Lisker > *Sent:* September 14, 2020 4:19 PM > *To:* omniprof at gmail.com > *Cc:* openjfx-dev at openjdk.java.net Mailing > *Subject:* Re: Media Player Failure When Speakers Not Present > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > > bugreport.java.com > > > > On Mon, Sep 14, 2020 at 11:03 PM wrote: > > While I am still looking for where I can file this problem I thought I'd > bring it to the list. A program I use in my course plays a short video. > Have > used it for a few years and it works fine. EXCEPT, if there is not a > connected audio out device such as speakers or headphones. The video does > not play and there is no stack trace or any other indication of a problem. > Stage opens fine but the media control does nothing and the scene appears > empty. Discovered when I used a machine that did not have speakers plugged > into it. Expected behaviour was just to see the video without sound. It is > possible that this bug has been around since the introduction of the Media > / > Media Player control. > > > > I assume the code works like "Hi M. PCaudio, what are you connected to?" > "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, > I'll > just wait forever or just give up and do nothing". > > > > Or, it can just be a crazy Xeon based Windows machine that is giving grief > to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. > > > > Ken Fogel > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > From nlisker at openjdk.java.net Mon Sep 14 21:16:39 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 14 Sep 2020 21:16:39 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 17:16:38 GMT, Kevin Rushforth wrote: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing > list as the first step. 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this > when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Additional comments: 1. "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not". 2. "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere. 3. "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively. 4. `./gradlew all test` will cause failure on webkit tests if it was not built. CONTRIBUTING.md line 18: > 16: ---------------- > 17: > 18: All new feature requests, including any API changes, need prior discussion on the > [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing list, even if there is already an open I think that the mailing list link shouldn't be to a `mailto` protocol as these aren't always configured in the browser, and in any case, since the intention is to have a discussion, the user should be advised to register to the list and not send a one-time mail. So I suggest to redirect to https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev. CONTRIBUTING.md line 19: > 17: > 18: All new feature requests, including any API changes, need prior discussion on the > [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing list, even if there is already an open 19: [JBS > issue](https://bugs.openjdk.java.net). See the [New features / API additions](#new-features--api-additions) section at > the end of this guide for more information. Also for the link under "Bug reports". I think that the issue list link should direct to a JavaFX search like `https://bugs.openjdk.java.net/issues/?jql=component %3D javafx order by updated DESC` to make it easier to search. CONTRIBUTING.md line 24: > 22: ------------------------------------------- > 23: > 24: If you have a bug fix or new feature that you would like to contribute to OpenJFX, please find or open an issue > about it first. Talk about what you would like to do on the [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing > list. It may be that somebody is already working on it, or that there are particular issues that you should know about > before implementing the change. Feature requests, in particular, must be discussed ahead of time and will require > significant effort on your part. "please find or open an issue about it first" Shouldn't a discussion happen before a feature is submitted in JBS? Or do we close as "won't fix" if the feature is rejected? CONTRIBUTING.md line 24: > 22: ------------------------------------------- > 23: > 24: If you have a bug fix or new feature that you would like to contribute to OpenJFX, please find or open an issue > about it first. Talk about what you would like to do on the [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing > list. It may be that somebody is already working on it, or that there are particular issues that you should know about > before implementing the change. Feature requests, in particular, must be discussed ahead of time and will require > significant effort on your part. Same comment on the "openjfx-dev" link. CONTRIBUTING.md line 88: > 86: of the PR title and check for whitespace errors. Once that passes, > 87: it will automatically send a Request For Review (RFR) email to the > 88: [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing list. Same comment on the "openjfx-dev" link. CONTRIBUTING.md line 96: > 94: TIP: prefix the pull request title with `WIP:` if you aren't yet > 95: ready for it to be reviewed. The Skara bot will not send an RFR > 96: email unless the title starts with a 7-digit bug ID. I'm pretty sure it doesn't send RFR mails on draft issues regardless of the title. I create all my PRs as draft to make sure everything is correct, and only then transition. I've never seen a premature RFR mail, though it could be a natural delay of he bot. CONTRIBUTING.md line 100: > 98: Please adhere to the general guideline that you should never force push > 99: to a publicly shared branch. Once you have opened your pull request, you > 100: should consider your branch publicly shared. Instead of force pushing Minor: this whole paragraph is filled with git terminology like squash, rebase, force push... Maybe a link to the git docs could help. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Mon Sep 14 21:16:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Sep 2020 21:16:37 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes Message-ID: This PR updates the `CONTRIBUTING.md` guide to address the following: 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. 2. Add a link to the mailing list in the section regarding contributing bug fixes. 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate 6. Update the note regarding which JDK(s) to use. ------------- Commit messages: - Address review comments - Address review comments + additional fixes - 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes Changes: https://git.openjdk.java.net/jfx/pull/303/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231601 Stats: 100 lines in 1 file changed: 50 ins; 25 del; 25 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Mon Sep 14 21:16:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Sep 2020 21:16:40 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 10:18:05 GMT, Nir Lisker wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing >> list as the first step. 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this >> when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > CONTRIBUTING.md line 18: > >> 16: ---------------- >> 17: >> 18: All new feature requests, including any API changes, need prior discussion on the >> [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing list, even if there is already an open > > I think that the mailing list link shouldn't be to a `mailto` protocol as these aren't always configured in the > browser, and in any case, since the intention is to have a discussion, the user should be advised to register to the > list and not send a one-time mail. So I suggest to redirect to > https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev. Fixed. > CONTRIBUTING.md line 19: > >> 17: >> 18: All new feature requests, including any API changes, need prior discussion on the >> [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing list, even if there is already an open 19: [JBS >> issue](https://bugs.openjdk.java.net). See the [New features / API additions](#new-features--api-additions) section at >> the end of this guide for more information. > > Also for the link under "Bug reports". I think that the issue list link should direct to a JavaFX search like > `https://bugs.openjdk.java.net/issues/?jql=component %3D javafx order by updated DESC` to make it easier to search. Fixed (I included a link to a filter the first time, where it suggests to search for already-reported issues). > CONTRIBUTING.md line 24: > >> 22: ------------------------------------------- >> 23: >> 24: If you have a bug fix or new feature that you would like to contribute to OpenJFX, please find or open an issue >> about it first. Talk about what you would like to do on the [openjfx-dev](mailto:openjfx-dev at openjdk.java.net) mailing >> list. It may be that somebody is already working on it, or that there are particular issues that you should know about >> before implementing the change. Feature requests, in particular, must be discussed ahead of time and will require >> significant effort on your part. > > "please find or open an issue about it first" > Shouldn't a discussion happen before a feature is submitted in JBS? Or do we close as "won't fix" if the feature is > rejected? I think I'll remove the comment about "please find or open an issue about it first" and just say: If you have a bug fix or new feature that you would like to contribute to OpenJFX, please talk about what you would like to do... > CONTRIBUTING.md line 100: > >> 98: Please adhere to the general guideline that you should never force push >> 99: to a publicly shared branch. Once you have opened your pull request, you >> 100: should consider your branch publicly shared. Instead of force pushing > > Minor: this whole paragraph is filled with git terminology like squash, rebase, force push... Maybe a link to the git > docs could help. I added a pointer to the GitHub help page here. > CONTRIBUTING.md line 96: > >> 94: TIP: prefix the pull request title with `WIP:` if you aren't yet >> 95: ready for it to be reviewed. The Skara bot will not send an RFR >> 96: email unless the title starts with a 7-digit bug ID. > > I'm pretty sure it doesn't send RFR mails on draft issues regardless of the title. I create all my PRs as draft to make > sure everything is correct, and only then transition. I've never seen a premature RFR mail, though it could be a > natural delay of he bot. I updated the doc to mention Draft PRs ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kevin.rushforth at oracle.com Mon Sep 14 21:17:52 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Sep 2020 14:17:52 -0700 Subject: Media Player Failure When Speakers Not Present In-Reply-To: <012501d68ad5$7d20d860$77628920$@gmail.com> References: <011401d68ad2$07b891b0$1729b510$@gmail.com> <012501d68ad5$7d20d860$77628920$@gmail.com> Message-ID: <14240d6f-b0d5-b0f7-8549-429cb447f950@oracle.com> That's still the right place to report bugs. You can find this in the project README [1] on GItHub. -- Kevin [1] https://github.com/openjdk/jfx#issue-tracking On 9/14/2020 1:27 PM, omniprof at gmail.com wrote: > I am a little confused. The url you sent appears to be for Java SE bug reporting and I thought that JavaFX as OpenJFX is not part of the Java SE distribution. If so then this may not be where I report my issue. > > > > Ken > > > > > > From: Nir Lisker > Sent: September 14, 2020 4:19 PM > To: omniprof at gmail.com > Cc: openjfx-dev at openjdk.java.net Mailing > Subject: Re: Media Player Failure When Speakers Not Present > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > > bugreport.java.com > > > > On Mon, Sep 14, 2020 at 11:03 PM > wrote: > > While I am still looking for where I can file this problem I thought I'd > bring it to the list. A program I use in my course plays a short video. Have > used it for a few years and it works fine. EXCEPT, if there is not a > connected audio out device such as speakers or headphones. The video does > not play and there is no stack trace or any other indication of a problem. > Stage opens fine but the media control does nothing and the scene appears > empty. Discovered when I used a machine that did not have speakers plugged > into it. Expected behaviour was just to see the video without sound. It is > possible that this bug has been around since the introduction of the Media / > Media Player control. > > > > I assume the code works like "Hi M. PCaudio, what are you connected to?" > "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll > just wait forever or just give up and do nothing". > > > > Or, it can just be a crazy Xeon based Windows machine that is giving grief > to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. > > > > Ken Fogel > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > > From kcr at openjdk.java.net Mon Sep 14 21:39:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Sep 2020 21:39:47 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v2] In-Reply-To: References: Message-ID: <9_YLaRrpMSZ62XLc-sRzM-QsgU0dXt3b3-JuwC3708U=.6dc8ad2e-6734-4c12-b1b0-18b5f5ea73b9@github.com> > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing > list as the first step. 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this > when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fixed URL to WEBKIT-MEDIA-STUBS.md ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/9840ffea..becd269f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Mon Sep 14 21:42:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Sep 2020 21:42:58 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v2] In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 11:22:42 GMT, Nir Lisker wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed URL to WEBKIT-MEDIA-STUBS.md > > Additional comments: > > 1. "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not". > 2. "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere. > 3. "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively. > 4. `./gradlew all test` will cause failure on webkit tests if it was not built. Regarding your additional comments: > * "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not". Fixed. > * "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere. You're probably remembering an old version, but it's been 120 for a while now. > * "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively. Fixed to add an exception for wildcard static imports in tests. > * `./gradlew all test` will cause failure on webkit tests if it was not built. Added a note about this and a pointer to the [Web Testing](WEBKIT-MEDIA-STUBS.md) doc. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From bchoudhary at openjdk.java.net Tue Sep 15 06:43:47 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 15 Sep 2020 06:43:47 GMT Subject: RFR: 8169501: GIF animation is too fast In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 17:42:57 GMT, Kevin Rushforth wrote: >> issue is caused by the threshold value for frame duration used by javaFx before it gets normalized. JavaFx is using >> threshold value 10 while other browser (Safari, Firefox) is using 50 due to which, value between 10 and 50 don't get >> normalized and animation runs at faster speed. To fix the issue change frame duration normalization value to <= 50. >> Safari : https://bugs.webkit.org/show_bug.cgi?id=14413 Firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=386269 > > This is pending response to comments above. 10ms![10ms](https://user-images.githubusercontent.com/4208131/93172831-3c9fcb80-f749-11ea-93ee-46b58ecff4c3.gif)                   11ms![11ms](https://user-images.githubusercontent.com/4208131/93172833-3dd0f880-f749-11ea-8fa7-5cf2f3cfdcdc.gif)                  12ms![12ms](https://user-images.githubusercontent.com/4208131/93172834-3e698f00-f749-11ea-92ae-24b3087758d2.gif)                  15ms![15ms](https://user-images.githubusercontent.com/4208131/93172836-3e698f00-f749-11ea-9b9b-15c5f21dd5af.gif) ______________ 19ms![19ms](https://user-images.githubusercontent.com/4208131/93172837-3f022580-f749-11ea-84be-7adc712bf230.gif)                  20ms![20ms](https://user-images.githubusercontent.com/4208131/93172839-3f9abc00-f749-11ea-8d5d-98b4ae131546.gif)                  21ms![21ms](https://user-images.githubusercontent.com/4208131/93172841-3f9abc00-f749-11ea-9b50-0cb5aa56b525.gif)                  40ms![40ms](https://user-images.githubusercontent.com/4208131/93172843-40335280-f749-11ea-8572-5bcfae11e28f.gif)                   ______________ 75ms![75ms](https://user-images.githubusercontent.com/4208131/93172846-40cbe900-f749-11ea-8cc2-e20d2ce74947.gif)                  Original![gif](https://user-images.githubusercontent.com/4208131/93172848-41647f80-f749-11ea-88a9-429fa956e428.gif) Without the fix, gif animation speed matches for all interval gifs with all other browser (Which includes firefox, safari, chrome). Only animation speed for gif file which is attached in issue doesn't match. javafx webkit plays it faster. Imageview plays everything at its original speed. No clamping happens here. ------------- PR: https://git.openjdk.java.net/jfx/pull/221 From arapte at openjdk.java.net Tue Sep 15 10:37:41 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Sep 2020 10:37:41 GMT Subject: RFR: 8252446: Screen.getScreens() is empty sometimes In-Reply-To: References: Message-ID: <92JTGEBp6qygQjd24y5vg9J_hFNEHppZ5LcyWyaT5sw=.57a9ce91-b234-42ad-99d7-6450f21377e0@github.com> On Thu, 3 Sep 2020 15:18:06 GMT, Kevin Rushforth wrote: > As noted in the bug report, we get a pair of change events every time the list of screens changes. First, a change is > sent with an empty list of screens and then a change is sent with the new list of screens. This happens whenever a > monitor is plugged in or unplugged. It also happens on Mac at application startup. As noted in the bug the reason for > this is because the `updateConfiguration` method makes two separate calls on the list of screens, `clear` and `addAll`, > rather than calling `setAll`. The latter ensures that only a single change event is delivered. I verified that before > this fix, the example program attached to the bug works correctly after the fix. > I wrote a unit test. It ends up being skipped on Windows and Linux since we don't get an initial change event. On Mac > the test fails without the fix and passes with the fix. Looks good to me. As you mentioned in the comments, On my Mac the test does not fail without this change. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/295 From arapte at openjdk.java.net Tue Sep 15 14:12:03 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Sep 2020 14:12:03 GMT Subject: RFR: 8240499: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: <7IQ49gs_KSU5FG24P_iUxPproB71N_1mU4ZEXLsHLi0=.c65ab12f-9767-41f8-a737-bbb38f859e23@github.com> On Fri, 11 Sep 2020 13:21:29 GMT, Kevin Rushforth wrote: > The `.jcheck/conf` file is configured to check the same set of files as the old HG jcheck, namely files with the > following extensions: > .java, .c, .h, .cpp, .hpp > > The Skara git jcheck allows us to evolve the rules for white space checking compatibly. > > This PR adds the following additional file extensions to the list of source files that need to be kept whitespace-clean: > > .cc, .css, .frag, .fxml, .g4, .gradle, .groovy, .hlsl, .jsl, .m, .metal, .mm, .stg, .vert > > For ease of review, I have done the initial push as 2 commits. The first modifies the `.jcheck/conf` file and > `tools/scripts/checkWhiteSpace` script to add the additional extensions. The second fixes the whitespace errors in the > (39) files among those with the newly added extensions. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/301 From nlisker at openjdk.java.net Tue Sep 15 14:13:47 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 15 Sep 2020 14:13:47 GMT Subject: RFR: 8169501: GIF animation is too fast In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 06:41:29 GMT, Bhawesh Choudhary wrote: >> This is pending response to comments above. > > 10ms![10ms](https://user-images.githubusercontent.com/4208131/93172831-3c9fcb80-f749-11ea-93ee-46b58ecff4c3.gif) >                   > 11ms![11ms](https://user-images.githubusercontent.com/4208131/93172833-3dd0f880-f749-11ea-8fa7-5cf2f3cfdcdc.gif) >                  12ms![12ms](https://user-images.githubusercontent.com/4208131/93172834-3e698f00-f749-11ea-92ae-24b3087758d2.gif) >                  15ms![15ms](https://user-images.githubusercontent.com/4208131/93172836-3e698f00-f749-11ea-9b9b-15c5f21dd5af.gif) > ______________ > 19ms![19ms](https://user-images.githubusercontent.com/4208131/93172837-3f022580-f749-11ea-84be-7adc712bf230.gif) >                  20ms![20ms](https://user-images.githubusercontent.com/4208131/93172839-3f9abc00-f749-11ea-8d5d-98b4ae131546.gif) >                  21ms![21ms](https://user-images.githubusercontent.com/4208131/93172841-3f9abc00-f749-11ea-9b50-0cb5aa56b525.gif) >                  40ms![40ms](https://user-images.githubusercontent.com/4208131/93172843-40335280-f749-11ea-8572-5bcfae11e28f.gif) >                   ______________ > 75ms![75ms](https://user-images.githubusercontent.com/4208131/93172846-40cbe900-f749-11ea-8cc2-e20d2ce74947.gif) >                  > Original![gif](https://user-images.githubusercontent.com/4208131/93172848-41647f80-f749-11ea-88a9-429fa956e428.gif) > Without the fix, gif animation speed matches for all interval gifs with all other browser (Which includes firefox, > safari, chrome). Only animation speed for gif file which is attached in issue doesn't match. javafx webkit plays it > faster. Imageview plays everything at its original speed. No clamping happens here. Is this related to https://bugs.openjdk.java.net/browse/JDK-8209560? ------------- PR: https://git.openjdk.java.net/jfx/pull/221 From arapte at openjdk.java.net Tue Sep 15 15:59:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Sep 2020 15:59:13 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> References: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> Message-ID: On Sat, 12 Sep 2020 14:10:38 GMT, Nir Lisker wrote: >> Moving implementation details about lazy evaluation and equality checking to `@implSpec`. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments and added Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Tue Sep 15 16:09:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Sep 2020 16:09:53 GMT Subject: RFR: 8253123: Switch FX build to use JDK 15 as boot JDK Message-ID: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> Updates the boot JDK used to build JavaFX 16 to JDK 15. The minimum remains at JDK 11. Note to reviewers: the build number for JDK 15 GA is the same as JDK 14 GA, so that property is intentionally unchanged (I didn't forget to update it). ------------- Commit messages: - 8253123: Switch FX build to use JDK 15 as boot JDK Changes: https://git.openjdk.java.net/jfx/pull/306/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=306&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253123 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/306/head:pull/306 PR: https://git.openjdk.java.net/jfx/pull/306 From nlisker at openjdk.java.net Tue Sep 15 16:23:40 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 15 Sep 2020 16:23:40 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: References: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> Message-ID: On Tue, 15 Sep 2020 15:57:00 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments and added > > Marked as reviewed by arapte (Reviewer). It's not really ready to be integrated, right? It's not finding the CSR I think. ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Tue Sep 15 16:33:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Sep 2020 16:33:05 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: References: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> Message-ID: <7bDMtxGub09gPauAkm3oVchjeWCucxI0Ykq_XcN9gKo=.aa4ca1e2-10f1-4be2-b09a-487f5eff7cc6@github.com> On Tue, 15 Sep 2020 16:21:06 GMT, Nir Lisker wrote: >> Marked as reviewed by arapte (Reviewer). > > It's not really ready to be integrated, right? It's not finding the CSR I think. Correct. It is not yet ready. [SKARA-548](https://bugs.openjdk.java.net/browse/SKARA-548) is not yet resolved, so shows as ready even though it isn't. ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From kcr at openjdk.java.net Tue Sep 15 16:54:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Sep 2020 16:54:54 GMT Subject: Integrated: 8240499: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 13:21:29 GMT, Kevin Rushforth wrote: > The `.jcheck/conf` file is configured to check the same set of files as the old HG jcheck, namely files with the > following extensions: > .java, .c, .h, .cpp, .hpp > > The Skara git jcheck allows us to evolve the rules for white space checking compatibly. > > This PR adds the following additional file extensions to the list of source files that need to be kept whitespace-clean: > > .cc, .css, .frag, .fxml, .g4, .gradle, .groovy, .hlsl, .jsl, .m, .metal, .mm, .stg, .vert > > For ease of review, I have done the initial push as 2 commits. The first modifies the `.jcheck/conf` file and > `tools/scripts/checkWhiteSpace` script to add the additional extensions. The second fixes the whitespace errors in the > (39) files among those with the newly added extensions. This pull request has now been integrated. Changeset: 976a7638 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/976a7638 Stats: 148 lines in 41 files changed: 16 ins; 0 del; 132 mod 8240499: Enforce whitespace checking for additional source files Reviewed-by: jvos, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/301 From nlisker at openjdk.java.net Wed Sep 16 08:29:05 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 16 Sep 2020 08:29:05 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec [v3] In-Reply-To: <7bDMtxGub09gPauAkm3oVchjeWCucxI0Ykq_XcN9gKo=.aa4ca1e2-10f1-4be2-b09a-487f5eff7cc6@github.com> References: <6FY_YLn0wVE_kbf1-7aU8oD2Eeoo_SarkEuJadyAiYA=.9d0b3cc6-45f1-4571-a45e-ec5563c3740f@github.com> <7bDMtxGub09gPauAkm3oVchjeWCucxI0Ykq_XcN9gKo=.aa4ca1e2-10f1-4be2-b09a-487f5eff7cc6@github.com> Message-ID: <7PHcbUexkpvpVk__QK12DV7yMTbtLazpBWeHd0P9aW8=.742e3e99-0b2d-4854-ac83-b84ffaf6af20@github.com> On Tue, 15 Sep 2020 16:29:58 GMT, Kevin Rushforth wrote: >> It's not really ready to be integrated, right? It's not finding the CSR I think. > > Correct. It is not yet ready. [SKARA-548](https://bugs.openjdk.java.net/browse/SKARA-548) is not yet resolved, so shows > as ready even though it isn't. The CSR has been approved, I'll go ahead and integrate. ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From nlisker at openjdk.java.net Wed Sep 16 08:29:05 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 16 Sep 2020 08:29:05 GMT Subject: Integrated: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec In-Reply-To: References: Message-ID: On Sun, 30 Aug 2020 16:09:14 GMT, Nir Lisker wrote: > Moving implementation details about lazy evaluation and equality checking to `@implSpec`. This pull request has now been integrated. Changeset: b2e2000c Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/b2e2000c Stats: 11 lines in 1 file changed: 2 ins; 6 del; 3 mod 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From nlisker at openjdk.java.net Wed Sep 16 08:57:51 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 16 Sep 2020 08:57:51 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 09:57:26 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8253086 > > ObservableListWrapper.java > * public boolean removeAll(Collection c) > * public boolean retainAll(Collection c) > > These two methods use BitSet, but it doesn't make sense. > By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range > of use cases. > The test is done with the following command. > > * gradle base: test > * gradle controls: test I will review this. @kevinrushforth I am not able to self-request a review. Is it on purpose? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From bchoudhary at openjdk.java.net Wed Sep 16 10:51:09 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 16 Sep 2020 10:51:09 GMT Subject: RFR: 8169501: GIF animation is too fast In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 14:11:23 GMT, Nir Lisker wrote: > > > Is this related to https://bugs.openjdk.java.net/browse/JDK-8209560? it seems not. ------------- PR: https://git.openjdk.java.net/jfx/pull/221 From nlisker at openjdk.java.net Wed Sep 16 11:06:33 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 16 Sep 2020 11:06:33 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v2] In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 21:40:39 GMT, Kevin Rushforth wrote: >> Additional comments: >> >> 1. "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not". >> 2. "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere. >> 3. "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively. >> 4. `./gradlew all test` will cause failure on webkit tests if it was not built. > > Regarding your additional comments: > >> * "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not". > > Fixed. > >> * "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere. > > You're probably remembering an old version, but it's been 120 for a while now. > >> * "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively. > > Fixed to add an exception for wildcard static imports in tests. > >> * `./gradlew all test` will cause failure on webkit tests if it was not built. > > Added a note about this and a pointer to the [Web Testing](WEBKIT-MEDIA-STUBS.md) doc. The "New features / API additions" repeats some things already stated. Is it to make each section independent? ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Wed Sep 16 12:04:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Sep 2020 12:04:08 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 08:41:58 GMT, Nir Lisker wrote: >> https://bugs.openjdk.java.net/browse/JDK-8253086 >> >> ObservableListWrapper.java >> * public boolean removeAll(Collection c) >> * public boolean retainAll(Collection c) >> >> These two methods use BitSet, but it doesn't make sense. >> By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range >> of use cases. >> The test is done with the following command. >> >> * gradle base: test >> * gradle controls: test > > I will review this. > @kevinrushforth I am not able to self-request a review. Is it on purpose? I think it's some sort of GitHub permission issue. I was hoping that once people were added to the OpenJDK org anyone in that org could self-request a review (or even request a review of someone else in the org), but that doesn't seem to be the case. :( ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Wed Sep 16 12:56:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Sep 2020 12:56:39 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v2] In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 11:03:55 GMT, Nir Lisker wrote: >> Regarding your additional comments: >> >>> * "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not". >> >> Fixed. >> >>> * "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere. >> >> You're probably remembering an old version, but it's been 120 for a while now. >> >>> * "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively. >> >> Fixed to add an exception for wildcard static imports in tests. >> >>> * `./gradlew all test` will cause failure on webkit tests if it was not built. >> >> Added a note about this and a pointer to the [Web Testing](WEBKIT-MEDIA-STUBS.md) doc. > > The "New features / API additions" repeats some things already stated. Is it to make each section independent? I wanted the "New features / API additions" section to stand on its own. Once thing that might be redundant now is the following sentence in the "Contributing code and documentation changes" section: "Feature requests, in particular, must be discussed ahead of time and will require significant effort on your part." I think that could be removed or incorporated in "New features / API additions". ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kevin.rushforth at oracle.com Wed Sep 16 13:00:28 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Sep 2020 06:00:28 -0700 Subject: Cannot extend javafx.scene.transform.Transform In-Reply-To: <4B25E5ED-8DC4-47C9-8939-96F5D2A3E81C@bookus-boulet.com> References: <4B25E5ED-8DC4-47C9-8939-96F5D2A3E81C@bookus-boulet.com> Message-ID: <0ba50849-4804-edc0-4c2f-8c7607d8395c@oracle.com> Sorry for the delay in responding to this. No, these classes are not meant to be extensible and we do not plan to change this. BaseTransform and Affine3D are an internal non-exported package (i.e., it is an implementation detail), so are not public API. -- Kevin On 9/9/2020 10:18 AM, Jules Yasuna wrote: > I would like to extend from javafx.scene.transform.Transform > > Two methods are preventing this ? > abstract void apply(Affine3D t); > abstract BaseTransform derive(BaseTransform t); > > I accomplished this in jdk 8 by overriding these two methods ? > public abstract void impl_apply(final Affine3D trans); > public abstract BaseTransform impl_derive(final BaseTransform trans); > > Which of course I should not have done. > > > Is there any change the apply and derive methods could open to permit derivation? > > From nlisker at openjdk.java.net Wed Sep 16 15:47:48 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 16 Sep 2020 15:47:48 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 12:01:54 GMT, Kevin Rushforth wrote: >> I will review this. >> @kevinrushforth I am not able to self-request a review. Is it on purpose? > > I think it's some sort of GitHub permission issue. I was hoping that once people were added to the OpenJDK org anyone > in that org could self-request a review (or even request a review of someone else in the org), but that doesn't seem to > be the case. :( Maybe this can be set somewhere by the owners or maybe the Skara team can have a look? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From pbansal at openjdk.java.net Wed Sep 16 18:34:35 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 16 Sep 2020 18:34:35 GMT Subject: RFR: 8252446: Screen.getScreens() is empty sometimes In-Reply-To: References: Message-ID: On Thu, 3 Sep 2020 15:18:06 GMT, Kevin Rushforth wrote: > As noted in the bug report, we get a pair of change events every time the list of screens changes. First, a change is > sent with an empty list of screens and then a change is sent with the new list of screens. This happens whenever a > monitor is plugged in or unplugged. It also happens on Mac at application startup. As noted in the bug the reason for > this is because the `updateConfiguration` method makes two separate calls on the list of screens, `clear` and `addAll`, > rather than calling `setAll`. The latter ensures that only a single change event is delivered. I verified that before > this fix, the example program attached to the bug works correctly after the fix. > I wrote a unit test. It ends up being skipped on Windows and Linux since we don't get an initial change event. On Mac > the test fails without the fix and passes with the fix. I tried this on Mac and Ubuntu 20.04. I could not reproduce the issue without the fix and test passes with/without the fix. But the changes make sense, so approving the changes. ------------- Marked as reviewed by pbansal (no project role). PR: https://git.openjdk.java.net/jfx/pull/295 From kcr at openjdk.java.net Wed Sep 16 18:59:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Sep 2020 18:59:39 GMT Subject: RFR: 8252446: Screen.getScreens() is empty sometimes In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 18:31:51 GMT, Pankaj Bansal wrote: >> As noted in the bug report, we get a pair of change events every time the list of screens changes. First, a change is >> sent with an empty list of screens and then a change is sent with the new list of screens. This happens whenever a >> monitor is plugged in or unplugged. It also happens on Mac at application startup. As noted in the bug the reason for >> this is because the `updateConfiguration` method makes two separate calls on the list of screens, `clear` and `addAll`, >> rather than calling `setAll`. The latter ensures that only a single change event is delivered. I verified that before >> this fix, the example program attached to the bug works correctly after the fix. >> I wrote a unit test. It ends up being skipped on Windows and Linux since we don't get an initial change event. On Mac >> the test fails without the fix and passes with the fix. > > I tried this on Mac and Ubuntu 20.04. I could not reproduce the issue without the fix and test passes with/without the > fix. But the changes make sense, so approving the changes. > Reviewers: > ... > Pankaj Bansal (@pankaj-bansal - no project role) This is a case where the Skara `jcheck` bot is more restrictive than `hg jcheck` was. What it means is that even though Pankaj is a "R"eviewer in another project, and has several commits in the `jfx` project, the Skara tooling doesn't consider him as an Author in the `openjfx` project, so doesn't count that review towards the required 2. Given that Pankaj has several `jfx` commits, I will reflect the intent of that by lowering the requirement to 1 reviewer + 1 contributor to satisfy the tooling. ------------- PR: https://git.openjdk.java.net/jfx/pull/295 From kcr at openjdk.java.net Wed Sep 16 19:03:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Sep 2020 19:03:20 GMT Subject: Integrated: 8252446: Screen.getScreens() is empty sometimes In-Reply-To: References: Message-ID: On Thu, 3 Sep 2020 15:18:06 GMT, Kevin Rushforth wrote: > As noted in the bug report, we get a pair of change events every time the list of screens changes. First, a change is > sent with an empty list of screens and then a change is sent with the new list of screens. This happens whenever a > monitor is plugged in or unplugged. It also happens on Mac at application startup. As noted in the bug the reason for > this is because the `updateConfiguration` method makes two separate calls on the list of screens, `clear` and `addAll`, > rather than calling `setAll`. The latter ensures that only a single change event is delivered. I verified that before > this fix, the example program attached to the bug works correctly after the fix. > I wrote a unit test. It ends up being skipped on Windows and Linux since we don't get an initial change event. On Mac > the test fails without the fix and passes with the fix. This pull request has now been integrated. Changeset: 13ab2cbd Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/13ab2cbd Stats: 107 lines in 2 files changed: 2 ins; 103 del; 2 mod 8252446: Screen.getScreens() is empty sometimes Reviewed-by: arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/295 From omniprof at gmail.com Wed Sep 16 19:17:43 2020 From: omniprof at gmail.com (omniprof at gmail.com) Date: Wed, 16 Sep 2020 15:17:43 -0400 Subject: Media Player Failure When Speakers Not Present In-Reply-To: References: <011401d68ad2$07b891b0$1729b510$@gmail.com> <012501d68ad5$7d20d860$77628920$@gmail.com> Message-ID: <001701d68c5e$0e3dbd70$2ab93850$@gmail.com> Bug report filed. Ken From: Nir Lisker Sent: September 14, 2020 4:37 PM To: omniprof at gmail.com Cc: openjfx-dev at openjdk.java.net Mailing Subject: Re: Media Player Failure When Speakers Not Present The issues database is the same for all OpenJDK projects, including JDK and OpenJFX. When you submit the issue, it is triaged internally and transferred to the public JBS at https://bugs.openjdk.java.net. On Mon, Sep 14, 2020 at 11:27 PM > wrote: I am a little confused. The url you sent appears to be for Java SE bug reporting and I thought that JavaFX as OpenJFX is not part of the Java SE distribution. If so then this may not be where I report my issue. Ken From: Nir Lisker > Sent: September 14, 2020 4:19 PM To: omniprof at gmail.com Cc: openjfx-dev at openjdk.java.net Mailing > Subject: Re: Media Player Failure When Speakers Not Present PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will submit a bug report. bugreport.java.com On Mon, Sep 14, 2020 at 11:03 PM > wrote: While I am still looking for where I can file this problem I thought I'd bring it to the list. A program I use in my course plays a short video. Have used it for a few years and it works fine. EXCEPT, if there is not a connected audio out device such as speakers or headphones. The video does not play and there is no stack trace or any other indication of a problem. Stage opens fine but the media control does nothing and the scene appears empty. Discovered when I used a machine that did not have speakers plugged into it. Expected behaviour was just to see the video without sound. It is possible that this bug has been around since the introduction of the Media / Media Player control. I assume the code works like "Hi M. PCaudio, what are you connected to?" "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll just wait forever or just give up and do nothing". Or, it can just be a crazy Xeon based Windows machine that is giving grief to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. Ken Fogel PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will submit a bug report. From kevin.rushforth at oracle.com Wed Sep 16 20:19:04 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Sep 2020 13:19:04 -0700 Subject: Media Player Failure When Speakers Not Present In-Reply-To: <001701d68c5e$0e3dbd70$2ab93850$@gmail.com> References: <011401d68ad2$07b891b0$1729b510$@gmail.com> <012501d68ad5$7d20d860$77628920$@gmail.com> <001701d68c5e$0e3dbd70$2ab93850$@gmail.com> Message-ID: I see it in the system, with an internal ID of 9066884. Once it is transferred to the JDK project it will be publicly visible and you should receive email notification. FWIW, I think I've seen this problem in the past. I don't know how easy it will be to fix, but at least it will be tracked and we can take a look at it. You should should be able to detect this as an error condition in your program by listening for a media error. See MediaPlayer::onError -- Kevin On 9/16/2020 12:17 PM, omniprof at gmail.com wrote: > Bug report filed. > > > > Ken > > > > > > From: Nir Lisker > Sent: September 14, 2020 4:37 PM > To: omniprof at gmail.com > Cc: openjfx-dev at openjdk.java.net Mailing > Subject: Re: Media Player Failure When Speakers Not Present > > > > The issues database is the same for all OpenJDK projects, including JDK and OpenJFX. When you submit the issue, it is triaged internally and transferred to the public JBS at https://bugs.openjdk.java.net. > > > > On Mon, Sep 14, 2020 at 11:27 PM > wrote: > > I am a little confused. The url you sent appears to be for Java SE bug reporting and I thought that JavaFX as OpenJFX is not part of the Java SE distribution. If so then this may not be where I report my issue. > > > > Ken > > > > > > From: Nir Lisker > > Sent: September 14, 2020 4:19 PM > To: omniprof at gmail.com > Cc: openjfx-dev at openjdk.java.net Mailing > > Subject: Re: Media Player Failure When Speakers Not Present > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > > bugreport.java.com > > > > On Mon, Sep 14, 2020 at 11:03 PM > wrote: > > While I am still looking for where I can file this problem I thought I'd > bring it to the list. A program I use in my course plays a short video. Have > used it for a few years and it works fine. EXCEPT, if there is not a > connected audio out device such as speakers or headphones. The video does > not play and there is no stack trace or any other indication of a problem. > Stage opens fine but the media control does nothing and the scene appears > empty. Discovered when I used a machine that did not have speakers plugged > into it. Expected behaviour was just to see the video without sound. It is > possible that this bug has been around since the introduction of the Media / > Media Player control. > > > > I assume the code works like "Hi M. PCaudio, what are you connected to?" > "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll > just wait forever or just give up and do nothing". > > > > Or, it can just be a crazy Xeon based Windows machine that is giving grief > to OpenJFX. Using Java 14 and OpenJFX 16-ea+1. > > > > Ken Fogel > > > > PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will > submit a bug report. > > > From arapte at openjdk.java.net Thu Sep 17 05:43:33 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 17 Sep 2020 05:43:33 GMT Subject: RFR: 8253123: Switch FX build to use JDK 15 as boot JDK In-Reply-To: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> References: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> Message-ID: On Tue, 15 Sep 2020 16:04:29 GMT, Kevin Rushforth wrote: > Updates the boot JDK used to build JavaFX 16 to JDK 15. The minimum remains at JDK 11. > > Note to reviewers: the build number for JDK 15 GA is the same as JDK 14 GA, so that property is intentionally unchanged > (I didn't forget to update it). Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/306 From ajoseph at openjdk.java.net Thu Sep 17 06:31:47 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 17 Sep 2020 06:31:47 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v13] In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 13:47:28 GMT, Bhawesh Choudhary wrote: >> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking >> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() >> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in >> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface >> otherwise use usual way of rendering. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updates as per review comments The fix works when the shape is displayed initially on the screen, but fails when we scroll the image off-screen and then, back. To see the issue, you need to either rotate the gradient transform (by 90 degrees) or use a circle (any shape other than a rectangle) as the mask shape, as this bug can't be seen using a mask rectangle. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From ajoseph at openjdk.java.net Thu Sep 17 06:37:30 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 17 Sep 2020 06:37:30 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v13] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 06:29:36 GMT, Arun Joseph wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates as per review comments > > The fix works when the shape is displayed initially on the screen, but fails when we scroll the image off-screen and > then, back. To see the issue, you need to either rotate the gradient transform (by 90 degrees) or use a circle (any > shape other than a rectangle) as the mask shape, as this bug can't be seen using a mask rectangle. To reproduce the above issue, you can either you `` or ` ` in `svgMask.html` and resize the window for scrolling. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From stevenyi at gmail.com Thu Sep 17 11:01:39 2020 From: stevenyi at gmail.com (Steven Yi) Date: Thu, 17 Sep 2020 07:01:39 -0400 Subject: Question about deadlock issue Message-ID: Hi All, I had reported a deadlock issue that requires app restart whenever a context menu is shown in JFX embedded within Swing (i.e., JFXPanel) on macOS: https://bugs.openjdk.java.net/browse/JDK-8251038 I had not seen any updates on the issue in a month and I'm wondering what to do. This is a serious bug for me and I'd like to have as informed an opinion at this point on my decision on whether to continue using JavaFX. Any advice here would be appreciated. A few things: * I wanted to add information to the ticket but I'm a 3rd party bug reporter and I do not see how one can do this. I found that this situation is reproducible if I use "built-in" context menus, such as right clicking a text field. I thought I might be able to replace my own JFX code to use Swing popups and windows where necessary, but going and patching the built-in controls felt like too much. * I tested using the recently released JavaFX 15 and found the deadlock to still be reproducible. (Using AdoptOpenJDK 11.0.8+10) * I don't really understand the JBS in regards to priority (i.e, what P3 means). I understand that using JavaFX within a Swing application may not be a priority for anyone else but myself. However, I am trying to understand if this is being looked at and if there's any way for me to figure out a timeline so I can make a decision whether to remove JavaFX from my application or not. There is a lot of code in my application that I'd have to port back to Swing, but realizing that any macOS user of my app is pretty much going to run into this at some point, I have to seriously consider this option. Thanks, Steven From kevin.rushforth at oracle.com Thu Sep 17 12:26:27 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Sep 2020 05:26:27 -0700 Subject: Question about deadlock issue In-Reply-To: References: Message-ID: <524a3ca4-cfb3-8916-5375-912fbea432af@oracle.com> If you have additional information that is relevant to reproducing the bug or helpful in identifying a possible fix, you can send it to this alias and either I or another OpenJFX Author, Committer, or Reviewer can add it to the bug report. I have updated the bug report with your note about where you found the situation reproducible. Since the bug is easily reproducible with no known workaround, I set the target fix version to JavaFX 16, but there are no guarantees. If you or another developer want to take a stab at contributing a fix, that would make it more likely to be fixed sooner. -- Kevin On 9/17/2020 4:01 AM, Steven Yi wrote: > Hi All, > > I had reported a deadlock issue that requires app restart whenever a > context menu is shown in JFX embedded within Swing (i.e., JFXPanel) on > macOS: > > https://bugs.openjdk.java.net/browse/JDK-8251038 > > I had not seen any updates on the issue in a month and I'm wondering > what to do. This is a serious bug for me and I'd like to have as > informed an opinion at this point on my decision on whether to > continue using JavaFX. Any advice here would be appreciated. > > A few things: > > * I wanted to add information to the ticket but I'm a 3rd party bug > reporter and I do not see how one can do this. I found that this > situation is reproducible if I use "built-in" context menus, such as > right clicking a text field. I thought I might be able to replace my > own JFX code to use Swing popups and windows where necessary, but > going and patching the built-in controls felt like too much. > > * I tested using the recently released JavaFX 15 and found the > deadlock to still be reproducible. (Using AdoptOpenJDK 11.0.8+10) > > * I don't really understand the JBS in regards to priority (i.e, what > P3 means). I understand that using JavaFX within a Swing application > may not be a priority for anyone else but myself. However, I am trying > to understand if this is being looked at and if there's any way for me > to figure out a timeline so I can make a decision whether to remove > JavaFX from my application or not. There is a lot of code in my > application that I'd have to port back to Swing, but realizing that > any macOS user of my app is pretty much going to run into this at some > point, I have to seriously consider this option. > > Thanks, > Steven From kevin.rushforth at oracle.com Thu Sep 17 12:56:25 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Sep 2020 05:56:25 -0700 Subject: Question about deadlock issue In-Reply-To: <524a3ca4-cfb3-8916-5375-912fbea432af@oracle.com> References: <524a3ca4-cfb3-8916-5375-912fbea432af@oracle.com> Message-ID: Update: I cannot reproduce this even using your updated instructions. How often does it reproduce for you? Have you tried with a more recent JDK (in case it is a JDK bug)? I recommend trying it with the just-released JDK 15 [1]. -- Kevin [1] https://jdk.java.net/15/ On 9/17/2020 5:26 AM, Kevin Rushforth wrote: > If you have additional information that is relevant to reproducing the > bug or helpful in identifying a possible fix, you can send it to this > alias and either I or another OpenJFX Author, Committer, or Reviewer > can add it to the bug report. I have updated the bug report with your > note about where you found the situation reproducible. > > Since the bug is easily reproducible with no known workaround, I set > the target fix version to JavaFX 16, but there are no guarantees. If > you or another developer want to take a stab at contributing a fix, > that would make it more likely to be fixed sooner. > > -- Kevin > > > On 9/17/2020 4:01 AM, Steven Yi wrote: >> Hi All, >> >> I had reported a deadlock issue that requires app restart whenever a >> context menu is shown in JFX embedded within Swing (i.e., JFXPanel) on >> macOS: >> >> https://bugs.openjdk.java.net/browse/JDK-8251038 >> >> I had not seen any updates on the issue in a month and I'm wondering >> what to do. This is a serious bug for me and I'd like to have as >> informed an opinion at this point on my decision on whether to >> continue using JavaFX. Any advice here would be appreciated. >> >> A few things: >> >> * I wanted to add information to the ticket but I'm a 3rd party bug >> reporter and I do not see how one can do this. I found that this >> situation is reproducible if I use "built-in" context menus, such as >> right clicking a text field. I thought I might be able to replace my >> own JFX code to use Swing popups and windows where necessary, but >> going and patching the built-in controls felt like too much. >> >> * I tested using the recently released JavaFX 15 and found the >> deadlock to still be reproducible. (Using AdoptOpenJDK 11.0.8+10) >> >> * I don't really understand the JBS in regards to priority (i.e, what >> P3 means).? I understand that using JavaFX within a Swing application >> may not be a priority for anyone else but myself. However, I am trying >> to understand if this is being looked at and if there's any way for me >> to figure out a timeline so I can make a decision whether to remove >> JavaFX from my application or not. There is a lot of code in my >> application that I'd have to port back to Swing, but realizing that >> any macOS user of my app is pretty much going to run into this at some >> point, I have to seriously consider this option. >> >> Thanks, >> Steven > From stevenyi at gmail.com Thu Sep 17 14:06:34 2020 From: stevenyi at gmail.com (Steven Yi) Date: Thu, 17 Sep 2020 10:06:34 -0400 Subject: Question about deadlock issue In-Reply-To: References: <524a3ca4-cfb3-8916-5375-912fbea432af@oracle.com> Message-ID: Hi Kevin, Thanks for the quick response, very much appreciated. I installed and tested again with AdoptOpenJDK 15. In my app I found the popup from the text field did not trigger the deadlock now, but my context menu did. It seemed to take longer before the deadlock occurred though. It used to happen almost immediately after switching apps and returning. With the simple test case I submitted, it is also taking longer to trigger. I can hit the "Show Context Menu" a few times, switch apps and come back, hit the button a few times, and if I repeat the process it would inevitably deadlock again and I had to force quit the app. I recorded a quick screencast to show the issue: https://youtu.be/l6ThrwxnxMk Netbeans shows that adoptopenjdk-15 was used for JAVA_HOME. I use JNI a bit and program in C a fair amount, but I haven't had much bandwidth to sit down to learn JavaFX and Swing's native implementation on macOS to debug unfortunately. I was hoping the information about the hang in sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl might spark an idea for someone here. Thanks, Steven On Thu, Sep 17, 2020 at 8:56 AM Kevin Rushforth wrote: > > Update: I cannot reproduce this even using your updated instructions. > How often does it reproduce for you? Have you tried with a more recent > JDK (in case it is a JDK bug)? I recommend trying it with the > just-released JDK 15 [1]. > > -- Kevin > > [1] https://jdk.java.net/15/ > > > On 9/17/2020 5:26 AM, Kevin Rushforth wrote: > > If you have additional information that is relevant to reproducing the > > bug or helpful in identifying a possible fix, you can send it to this > > alias and either I or another OpenJFX Author, Committer, or Reviewer > > can add it to the bug report. I have updated the bug report with your > > note about where you found the situation reproducible. > > > > Since the bug is easily reproducible with no known workaround, I set > > the target fix version to JavaFX 16, but there are no guarantees. If > > you or another developer want to take a stab at contributing a fix, > > that would make it more likely to be fixed sooner. > > > > -- Kevin > > > > > > On 9/17/2020 4:01 AM, Steven Yi wrote: > >> Hi All, > >> > >> I had reported a deadlock issue that requires app restart whenever a > >> context menu is shown in JFX embedded within Swing (i.e., JFXPanel) on > >> macOS: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8251038 > >> > >> I had not seen any updates on the issue in a month and I'm wondering > >> what to do. This is a serious bug for me and I'd like to have as > >> informed an opinion at this point on my decision on whether to > >> continue using JavaFX. Any advice here would be appreciated. > >> > >> A few things: > >> > >> * I wanted to add information to the ticket but I'm a 3rd party bug > >> reporter and I do not see how one can do this. I found that this > >> situation is reproducible if I use "built-in" context menus, such as > >> right clicking a text field. I thought I might be able to replace my > >> own JFX code to use Swing popups and windows where necessary, but > >> going and patching the built-in controls felt like too much. > >> > >> * I tested using the recently released JavaFX 15 and found the > >> deadlock to still be reproducible. (Using AdoptOpenJDK 11.0.8+10) > >> > >> * I don't really understand the JBS in regards to priority (i.e, what > >> P3 means). I understand that using JavaFX within a Swing application > >> may not be a priority for anyone else but myself. However, I am trying > >> to understand if this is being looked at and if there's any way for me > >> to figure out a timeline so I can make a decision whether to remove > >> JavaFX from my application or not. There is a lot of code in my > >> application that I'd have to port back to Swing, but realizing that > >> any macOS user of my app is pretty much going to run into this at some > >> point, I have to seriously consider this option. > >> > >> Thanks, > >> Steven > > > From rob.nikander at gmail.com Thu Sep 17 17:11:00 2020 From: rob.nikander at gmail.com (Rob Nikander) Date: Thu, 17 Sep 2020 13:11:00 -0400 Subject: How to set app name in macOS, gradle? Message-ID: <13307A28-8F6B-4561-9F63-0F736A410300@gmail.com> Hi, I?m trying to set the text shown in the macOS menubar. The advice I see online says to use -Xdock:name, but when I try that, I still see ?java? in the menubar. Is there a way to make it use ?MyAppName?? Some of my build.gradle.kts file is shown below. Rob plugins { application kotlin("jvm") version "1.4.10" id("org.openjfx.javafxplugin") version "0.0.9" } application { mainClass.set(?myapp.MainKt") applicationName = "MyAppName" applicationDefaultJvmArgs = listOf( "-Xdock:name=MyAppName" ) } javafx { version = "15" modules = listOf("javafx.controls?) } From mp at jugs.org Thu Sep 17 17:20:20 2020 From: mp at jugs.org (Michael Paus) Date: Thu, 17 Sep 2020 19:20:20 +0200 Subject: How to set app name in macOS, gradle? In-Reply-To: <13307A28-8F6B-4561-9F63-0F736A410300@gmail.com> References: <13307A28-8F6B-4561-9F63-0F736A410300@gmail.com> Message-ID: <341d9fe4-0441-b31a-ada5-cfba44af382d@jugs.org> You can achieve this when you bundle your application with jpackage. For proper macOS menubar handling you should also consider to use the library NSMenuFX (https://github.com/codecentric/NSMenuFX) because JavaFX itself still cannot do that. Michael Am 17.09.20 um 19:11 schrieb Rob Nikander: > Hi, > > I?m trying to set the text shown in the macOS menubar. The advice I see online says to use -Xdock:name, but when I try that, I still see ?java? in the menubar. Is there a way to make it use ?MyAppName?? Some of my build.gradle.kts file is shown below. > > Rob > > > plugins { > application > kotlin("jvm") version "1.4.10" > id("org.openjfx.javafxplugin") version "0.0.9" > } > > application { > mainClass.set(?myapp.MainKt") > applicationName = "MyAppName" > applicationDefaultJvmArgs = listOf( > "-Xdock:name=MyAppName" > ) > } > > javafx { > version = "15" > modules = listOf("javafx.controls?) > } > > From rob.nikander at gmail.com Thu Sep 17 17:28:03 2020 From: rob.nikander at gmail.com (Rob Nikander) Date: Thu, 17 Sep 2020 13:28:03 -0400 Subject: How to set app name in macOS, gradle? In-Reply-To: <341d9fe4-0441-b31a-ada5-cfba44af382d@jugs.org> References: <13307A28-8F6B-4561-9F63-0F736A410300@gmail.com> <341d9fe4-0441-b31a-ada5-cfba44af382d@jugs.org> Message-ID: Okay, thank you. > On Sep 17, 2020, at 1:20 PM, Michael Paus wrote: > > You can achieve this when you bundle your application with jpackage. > For proper macOS menubar handling you should also consider to use > the library NSMenuFX (https://github.com/codecentric/NSMenuFX) because > JavaFX itself still cannot do that. > Michael From sykora at openjdk.java.net Thu Sep 17 19:35:36 2020 From: sykora at openjdk.java.net (Joeri Sykora) Date: Thu, 17 Sep 2020 19:35:36 GMT Subject: RFR: 8253123: Switch FX build to use JDK 15 as boot JDK In-Reply-To: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> References: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> Message-ID: <3ReOeFl819-ioEvf5eEWaEWcJBY1Wpp4yhXr8fR_3FM=.d6cce048-e3aa-412e-a2c6-5998572dc96f@github.com> On Tue, 15 Sep 2020 16:04:29 GMT, Kevin Rushforth wrote: > Updates the boot JDK used to build JavaFX 16 to JDK 15. The minimum remains at JDK 11. > > Note to reviewers: the build number for JDK 15 GA is the same as JDK 14 GA, so that property is intentionally unchanged > (I didn't forget to update it). I've successfully built on all platforms with JDK 15. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/306 From jvos at openjdk.java.net Thu Sep 17 19:40:46 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 17 Sep 2020 19:40:46 GMT Subject: RFR: 8253123: Switch FX build to use JDK 15 as boot JDK In-Reply-To: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> References: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> Message-ID: On Tue, 15 Sep 2020 16:04:29 GMT, Kevin Rushforth wrote: > Updates the boot JDK used to build JavaFX 16 to JDK 15. The minimum remains at JDK 11. > > Note to reviewers: the build number for JDK 15 GA is the same as JDK 14 GA, so that property is intentionally unchanged > (I didn't forget to update it). Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/306 From kcr at openjdk.java.net Thu Sep 17 19:45:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Sep 2020 19:45:12 GMT Subject: Integrated: 8253123: Switch FX build to use JDK 15 as boot JDK In-Reply-To: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> References: <4ax31B-an4NCFSxCBkSLcVHgULtmQdt9ah9V6XmIoRM=.4ae5899a-0751-44c8-82be-4cd016df11da@github.com> Message-ID: On Tue, 15 Sep 2020 16:04:29 GMT, Kevin Rushforth wrote: > Updates the boot JDK used to build JavaFX 16 to JDK 15. The minimum remains at JDK 11. > > Note to reviewers: the build number for JDK 15 GA is the same as JDK 14 GA, so that property is intentionally unchanged > (I didn't forget to update it). This pull request has now been integrated. Changeset: 47e67b40 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/47e67b40 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253123: Switch FX build to use JDK 15 as boot JDK Reviewed-by: arapte, sykora, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/306 From mik3hall at gmail.com Thu Sep 17 19:55:14 2020 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 17 Sep 2020 14:55:14 -0500 Subject: How to set app name in macOS, gradle? In-Reply-To: <341d9fe4-0441-b31a-ada5-cfba44af382d@jugs.org> References: <13307A28-8F6B-4561-9F63-0F736A410300@gmail.com> <341d9fe4-0441-b31a-ada5-cfba44af382d@jugs.org> Message-ID: > On Sep 17, 2020, at 12:20 PM, Michael Paus wrote: > > You can achieve this when you bundle your application with jpackage. With jpackage including these? -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe My application name showed correctly on the top menu bar and in the dock. Whether it was from these or just jpackage --name -n Name of the application and/or package I don?t know. What wasn?t showing correctly was the application names within the application menu. Like ?About LoaderLaunchStub? These looked like they were parsed from the main class name. app.mainclass=us.hall.hp.common.LoaderLaunchStub After seeing this thread I found this? -Dapple.awt.application.name=HalfPipe Which seems to correct that. NSMenuFX may give you additional functionality you want but with just the above for jpackage should get you correct looking application names about everywhere. From mp at jugs.org Thu Sep 17 20:00:59 2020 From: mp at jugs.org (Michael Paus) Date: Thu, 17 Sep 2020 22:00:59 +0200 Subject: How to set app name in macOS, gradle? In-Reply-To: References: <13307A28-8F6B-4561-9F63-0F736A410300@gmail.com> <341d9fe4-0441-b31a-ada5-cfba44af382d@jugs.org> Message-ID: <45b3a354-570c-07d2-d3ec-c3311312e579@jugs.org> NSMenuFX will fix, e.g., the "About" issue and will allow consistent internationalization of these predefined menu items. Am 17.09.20 um 21:55 schrieb Michael Hall: > > >> On Sep 17, 2020, at 12:20 PM, Michael Paus > > wrote: >> >> You can achieve this when you bundle your application with jpackage. > > With jpackage including these? > -Dapple.laf.useScreenMenuBar=true > -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe > > My application name showed correctly on the top menu bar and in the dock. > Whether it was from these or just jpackage > > --name -n > ? ? ? ? ??Name of the application and/or package > > I don?t know. What wasn?t showing correctly was the application names > within the application menu. Like ?About LoaderLaunchStub? > These looked like they were parsed from the main class name. > > app.mainclass=us.hall.hp.common.LoaderLaunchStub > > After seeing this thread I found this? > > -Dapple.awt.application.name=HalfPipe > > Which seems to correct that. > > NSMenuFX may give you additional functionality you want but with just > the above for jpackage should get you correct looking application > names about everywhere. > > > > > From mik3hall at gmail.com Thu Sep 17 20:06:50 2020 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 17 Sep 2020 15:06:50 -0500 Subject: How to set app name in macOS, gradle? In-Reply-To: <45b3a354-570c-07d2-d3ec-c3311312e579@jugs.org> References: <13307A28-8F6B-4561-9F63-0F736A410300@gmail.com> <341d9fe4-0441-b31a-ada5-cfba44af382d@jugs.org> <45b3a354-570c-07d2-d3ec-c3311312e579@jugs.org> Message-ID: > On Sep 17, 2020, at 3:00 PM, Michael Paus wrote: > > NSMenuFX will fix, e.g., the "About" issue and will allow consistent internationalization > of these predefined menu items. > I saw the above were supposed to support some localization. It wasn?t a current concern for me. It?s sort of an obscure probably old Apple property but -Dapple.awt.application.name also works. Except I just noticed maybe not in Activity Monitor, still LoaderLaunchStub. From fastegal at openjdk.java.net Fri Sep 18 10:30:05 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 18 Sep 2020 10:30:05 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v2] In-Reply-To: References: Message-ID: > the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) > > - initially > - after changing side > - after resizing stage/tabPane > - after modifying the list of tabs > > Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its > scroll might need an update. > Added tests that fail before and pass after the fix. > > Note that there still are issues while/after dragging, which are not in the scope of this fix. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: widened scope of fix to address review comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/300/files - new: https://git.openjdk.java.net/jfx/pull/300/files/d4c33714..c3583829 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=300&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=300&range=00-01 Stats: 161 lines in 3 files changed: 159 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/300.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/300/head:pull/300 PR: https://git.openjdk.java.net/jfx/pull/300 From aghaisas at openjdk.java.net Fri Sep 18 11:09:58 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 18 Sep 2020 11:09:58 GMT Subject: RFR: 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 11:56:51 GMT, Jose Pereda wrote: > This PR removes an old fix (RT-13965/JDK-8113318), which was applied in 2011 to avoid a memory leak in > `VirtualFlow::sheetChildren`, after new items were constantly added. > With the current VirtualFlow implementation, there are in place the necessary methods that take care of cleaning or > adding new cells to the sheetChildren list, and such memory leak doesn't exist, the size remains constant when new > items are added or removed (see included unity test). The call to `sheetchildren.clear()`, on the contrary, has a big > impact in performance and CPU usage, when new items are constantly added, as has been reported in JDK-8185886/#108. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/298 From aghaisas at openjdk.java.net Fri Sep 18 11:09:59 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 18 Sep 2020 11:09:59 GMT Subject: RFR: 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 12:43:19 GMT, Johan Vos wrote: >> This PR removes an old fix (RT-13965/JDK-8113318), which was applied in 2011 to avoid a memory leak in >> `VirtualFlow::sheetChildren`, after new items were constantly added. >> With the current VirtualFlow implementation, there are in place the necessary methods that take care of cleaning or >> adding new cells to the sheetChildren list, and such memory leak doesn't exist, the size remains constant when new >> items are added or removed (see included unity test). The call to `sheetchildren.clear()`, on the contrary, has a big >> impact in performance and CPU usage, when new items are constantly added, as has been reported in JDK-8185886/#108. > > This looks ok to me. It would be ideal to have the test failing before JDK-8113318 was applied, as that would show the > issue for which JDK-8113318 was created is now fixed. But I do understand it is very hard to apply this test to a code > snapshot from 2011. As there is no automated test to make sure we are not re-introducing the leak, I have verified by running Ensemble8 KeyEvent sample mentioned in JDK-8113318 and typing more than 800 keys. There is no performance degradation observed. The change and test looks OK. ------------- PR: https://git.openjdk.java.net/jfx/pull/298 From fastegal at openjdk.java.net Fri Sep 18 11:18:57 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 18 Sep 2020 11:18:57 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 09:12:12 GMT, Jeanette Winzenburg wrote: >> In a bid to find more scenarios like you did mention description, I observed two more scenarios when selected tab does >> not stay in view. 1. Inserting tabs before or removing tabs after selected tab or moving the selected tab, causes the >> selected tab to go out of view. 2. Rotating TabPane can also take the selected tab out of view. I am little doubtful if >> it a legitimate issue. The rotations I tried clipped TabPane and TabPane header. I think rotation issue can be kept >> out of scope of this issue, can be filed as a follow on. I leave to it to you to take a call. >> About 1, I did quickly verify that it gets fixed by adding `invalidateScrollOffset();` call in >> `TabHeaderArea.removeTab()`, `TabHeaderArea.addTab()` and `TabHeaderArea.moveTab()`. Also If we fix it here, then bug >> summary might need a change. It currently reflects only initial tab. > > good catch and many thanks for the evaluation - now all I'll have to do is to write tests to catch them :) Will also > update the bug summary as you suggest. > Agree, that the second can be regarded as off scope, as it seems to effect both header and content - will not do > anything in this fix. Widened scope of the issue to include problems after modifying the list of tabs: added fix and tests. Separated dragging issues into a new bug (there's an unrelated isssue when dragging over the leading edge, fixing that might have effects on the trailing edge, so didn't do much to fix the issue/s on the latter except ensuring the visibility after drop). ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From fastegal at openjdk.java.net Fri Sep 18 11:46:34 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 18 Sep 2020 11:46:34 GMT Subject: RFR: 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 11:07:36 GMT, Ajit Ghaisas wrote: >> This PR removes an old fix (RT-13965/JDK-8113318), which was applied in 2011 to avoid a memory leak in >> `VirtualFlow::sheetChildren`, after new items were constantly added. >> With the current VirtualFlow implementation, there are in place the necessary methods that take care of cleaning or >> adding new cells to the sheetChildren list, and such memory leak doesn't exist, the size remains constant when new >> items are added or removed (see included unity test). The call to `sheetchildren.clear()`, on the contrary, has a big >> impact in performance and CPU usage, when new items are constantly added, as has been reported in JDK-8185886/#108. > > Marked as reviewed by aghaisas (Reviewer). Just a note: fixing this makes [JDK-8244826](https://bugs.openjdk.java.net/browse/JDK-8244826) disappear - not entirely certain, if it's really a fix for that one or only smearing over it. ------------- PR: https://git.openjdk.java.net/jfx/pull/298 From kcr at openjdk.java.net Fri Sep 18 18:57:16 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Sep 2020 18:57:16 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v3] In-Reply-To: References: Message-ID: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing > list as the first step. 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this > when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review coments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/becd269f..9ee77cf7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From nlisker at openjdk.java.net Fri Sep 18 23:48:00 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 18 Sep 2020 23:48:00 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v3] In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 12:54:19 GMT, Kevin Rushforth wrote: >> The "New features / API additions" repeats some things already stated. Is it to make each section independent? > > I wanted the "New features / API additions" section to stand on its own. Once thing that might be redundant now is the > following sentence in the "Contributing code and documentation changes" section: > "Feature requests, in particular, must be discussed ahead of time and will require significant effort on your part." > > I think that could be removed or incorporated in "New features / API additions". I think that "Contributing to the OpenJFX codebase" should be renamed to something related to a style guide. Then split the testing part to its own subsection. Also, I still find it confusing that "New features / API additions" is not under the code contribution section. There seems to be 2 main sections: reporting bugs / requesting features - these don't involve code, just talk; then there is contributing code, which covers the process for setup, submissions of bugs fixes, submission of features/API, style, and testing (in some order). Wouldn't this be a better flow? ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From nlisker at openjdk.java.net Sat Sep 19 01:12:34 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 19 Sep 2020 01:12:34 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 09:57:26 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8253086 > > ObservableListWrapper.java > * public boolean removeAll(Collection c) > * public boolean retainAll(Collection c) > > These two methods use BitSet, but it doesn't make sense. > By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range > of use cases. > The test is done with the following command. > > * gradle base: test > * gradle controls: test Remove the unused `BitSet` import. modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 177: > 175: beginChange(); > 176: boolean removed = false; > 177: for (int i = size()-1; i>=0; i--) { 1. Use spaces between operators. 2. Why reverse the iteration order? Implementation discussion: * We can use `boolean removed = removeIf(c::contains);` instead of the loop. However, this method uses the iterator and not random access, which *could* be less performant. The class implements `RandomAccess`, suggesting that this is the case, however, I don't see why. It seems that the implementation can be any list, such as `LinkedList`, which is not `RandomAccess`. * Why do we need to override the inherited behavior? The super implementation, which is the one from `ModifiableObservableListBase`, does ``` beginChange(); try { boolean res = super.removeAll(c); return res; } finally { endChange(); } ``` (except that it does not check for empty collections at the start - should it?) The `super` here is `AbstractCollection`, which does `Iterator`-based removal. Same goes for the other method. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Sat Sep 19 05:20:34 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Sat, 19 Sep 2020 05:20:34 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Sat, 19 Sep 2020 01:09:10 GMT, Nir Lisker wrote: >> https://bugs.openjdk.java.net/browse/JDK-8253086 >> >> ObservableListWrapper.java >> * public boolean removeAll(Collection c) >> * public boolean retainAll(Collection c) >> >> These two methods use BitSet, but it doesn't make sense. >> By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range >> of use cases. >> The test is done with the following command. >> >> * gradle base: test >> * gradle controls: test > > modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 177: > >> 175: beginChange(); >> 176: boolean removed = false; >> 177: for (int i = size()-1; i>=0; i--) { > > 1. Use spaces between operators. > 2. Why reverse the iteration order? > > Implementation discussion: > * We can use `boolean removed = removeIf(c::contains);` instead of the loop. However, this method uses the iterator and > not random access, which *could* be less performant. The class implements `RandomAccess`, suggesting that this is the > case, however, I don't see why. It seems that the implementation can be any list, such as `LinkedList`, which is not > `RandomAccess`. > * Why do we need to override the inherited behavior? The super implementation, which is the one from > `ModifiableObservableListBase`, does > ``` > beginChange(); > try { > boolean res = super.removeAll(c); > return res; > } finally { > endChange(); > } > ``` > (except that it does not check for empty collections at the start - should it?) The `super` here is > `AbstractCollection`, which does `Iterator`-based removal. > > Same goes for the other method. Rewriting backingList.removeIf It is not used here because it requires doRemove processing. This is the same as the original code. The iteration order is reversed because index movement does not occur during deletion. This is the same as the original code. Reviewers don't seem to be familiar with this code. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From kcr at openjdk.java.net Sat Sep 19 15:36:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 19 Sep 2020 15:36:08 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <7aqDXDWKUsTmYLL-BzAXI5nggcy54mU2aAWhe0YVZY8=.d907ce81-3a63-42ea-a68c-3d199dc28fee@github.com> Message-ID: On Fri, 4 Sep 2020 23:20:43 GMT, Nir Lisker wrote: >> Thanks, the test runs now, but I've run into an issue with `snapshot`. >> >> `Node#snapshot` uses its scene parameters (like lights) to render the image, but if the node is in a subscene then the >> image will be wrong since it takes the wrong data. Bounds transforms like `sceneToLocal` and `localToScene` do take >> care of this case. I think that this is a mistake in `snapshot`, and maybe it should use the subscene, or a `boolean >> subScene` parameter should be offered, or `SnapshotParameters` should allow to specify it. > > Looks like there's more to it. I've created the test code: > > import javafx.application.Application; > import javafx.scene.Group; > import javafx.scene.PerspectiveCamera; > import javafx.scene.PointLight; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.Slider; > import javafx.scene.image.ImageView; > import javafx.scene.layout.BorderPane; > import javafx.scene.paint.Color; > import javafx.scene.shape.Box; > import javafx.stage.Stage; > > public class PointLightAttenuationTest extends Application { > > public static void main(String[] args) throws Exception { > launch(args); > } > > @Override > public void start(Stage stage) { > var light = new PointLight(Color.BLUE); > light.setTranslateZ(-10); > Box box = new Box(100, 100, 1); > var group = new Group(light, box); > > var scene = new Scene(group, 500, 500, true); > var camera = new PerspectiveCamera(true); > camera.setTranslateZ(-300); > camera.setFarClip(1000); > scene.setCamera(camera); > stage.setScene(scene); > stage.show(); > > var imageView = new ImageView(); > var snapshotButton = new Button("Node Snaphot"); > snapshotButton.setOnAction(e -> imageView.setImage(scene.snapshot(null))); > > var slider = new Slider(0, 0.2, 0); > slider.setShowTickMarks(true); > slider.setShowTickLabels(true); > light.linearAttenuationProperty().bindBidirectional(slider.valueProperty()); > > var snapshotStage = new Stage(); > snapshotStage.setScene(new Scene(new BorderPane(imageView, snapshotButton, null, slider, null))); > snapshotStage.setWidth(600); > snapshotStage.setHeight(600); > snapshotStage.show(); > } > } > If the line `snapshotButton.setOnAction(e -> imageView.setImage(scene.snapshot(null)));` is replaced to use > `box.snapshot(null, null)` then the snapshot is wrong. @nlisker Since there is a possible bug in snapshot, you might consider using Robot screen capture instead? Also, I don't know if you noticed, but there are now whitespace errors after the fix for [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Sat Sep 19 15:41:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 19 Sep 2020 15:41:21 GMT Subject: RFR: 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 11:56:51 GMT, Jose Pereda wrote: > This PR removes an old fix (RT-13965/JDK-8113318), which was applied in 2011 to avoid a memory leak in > `VirtualFlow::sheetChildren`, after new items were constantly added. > With the current VirtualFlow implementation, there are in place the necessary methods that take care of cleaning or > adding new cells to the sheetChildren list, and such memory leak doesn't exist, the size remains constant when new > items are added or removed (see included unity test). The call to `sheetchildren.clear()`, on the contrary, has a big > impact in performance and CPU usage, when new items are constantly added, as has been reported in JDK-8185886/#108. Looks good to me. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/298 From kcr at openjdk.java.net Sat Sep 19 15:57:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 19 Sep 2020 15:57:21 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 23:45:30 GMT, Nir Lisker wrote: >> I wanted the "New features / API additions" section to stand on its own. Once thing that might be redundant now is the >> following sentence in the "Contributing code and documentation changes" section: >> "Feature requests, in particular, must be discussed ahead of time and will require significant effort on your part." >> >> I think that could be removed or incorporated in "New features / API additions". > > I think that "Contributing to the OpenJFX codebase" should be renamed to something related to a style guide. Then split > the testing part to its own subsection. > Also, I still find it confusing that "New features / API additions" is not under the code contribution section. There > seems to be 2 main sections: reporting bugs / requesting features - these don't involve code, just talk; then there is > contributing code, which covers the process for setup, submissions of bugs fixes, submission of features/API, style, > and testing (in some order). Wouldn't this be a better flow? Yes, I do think the flow could be better. I'll need to put this on hold for a while, but when I get back to it, I'll look at your suggestions and see if I can come up with something that will improve the flow. Btw, the thinking behind putting the "New features / API additions" sections at the end (sort of like an appendix) is that I didn't want it to get in the way of the "here's how you sumbit and review a PR" for bug fixes, which is the more common case. I don't think it achieves that in its current form. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Sat Sep 19 17:04:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 19 Sep 2020 17:04:54 GMT Subject: RFR: 8169501: GIF animation is too fast In-Reply-To: References: Message-ID: <1SYEtVlOUYtRfxjBOUMRCptchjizzMF93Fh7h-iSOqI=.663c8e72-d60c-4eef-b69c-74c77c84ba0b@github.com> On Wed, 16 Sep 2020 10:48:43 GMT, Bhawesh Choudhary wrote: >> Is this related to https://bugs.openjdk.java.net/browse/JDK-8209560? > >> >> >> Is this related to https://bugs.openjdk.java.net/browse/JDK-8209560? > > it seems not. Using the images you posted above, it appears that the browsers (Firefox and Edge on Windows, Firefox and Safari on Mac) have a threshold of 20ms, not 51 ms. Looks like the formula should be delay < 20 : set to 100 delay >= 20 : use the value as is Your fix does make the 19 ms image match the browsers (whereas existing WebView is too fast), but the 20ms, 21ms, and 40ms images no longer do (they are fine in the existing WebVIew and too slow with your patch). So I recommend changing the value to 20 and then re-testing. ------------- PR: https://git.openjdk.java.net/jfx/pull/221 From jpereda at openjdk.java.net Sat Sep 19 19:44:24 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sat, 19 Sep 2020 19:44:24 GMT Subject: Integrated: 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 11:56:51 GMT, Jose Pereda wrote: > This PR removes an old fix (RT-13965/JDK-8113318), which was applied in 2011 to avoid a memory leak in > `VirtualFlow::sheetChildren`, after new items were constantly added. > With the current VirtualFlow implementation, there are in place the necessary methods that take care of cleaning or > adding new cells to the sheetChildren list, and such memory leak doesn't exist, the size remains constant when new > items are added or removed (see included unity test). The call to `sheetchildren.clear()`, on the contrary, has a big > impact in performance and CPU usage, when new items are constantly added, as has been reported in JDK-8185886/#108. This pull request has now been integrated. Changeset: d10f948e Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/d10f948e Stats: 38 lines in 2 files changed: 6 ins; 32 del; 0 mod 8252811: The list of cells in a VirtualFlow is cleared every time the number of items changes Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/298 From nlisker at openjdk.java.net Sun Sep 20 01:56:57 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 20 Sep 2020 01:56:57 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v12] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/2c9af767..d3dd5064 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Mon Sep 21 04:29:47 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 21 Sep 2020 04:29:47 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v13] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: - Fixed whitespaces - Added an automated test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/d3dd5064..af0b1794 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=11-12 Stats: 116 lines in 1 file changed: 116 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From fastegal at openjdk.java.net Mon Sep 21 10:43:49 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 21 Sep 2020 10:43:49 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 09:57:26 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8253086 > > ObservableListWrapper.java > * public boolean removeAll(Collection c) > * public boolean retainAll(Collection c) > > These two methods use BitSet, but it doesn't make sense. > By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range > of use cases. > The test is done with the following command. > > * gradle base: test > * gradle controls: test modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 191: > 189: if (this.isEmpty() || c.isEmpty()) { > 190: return false; > 191: } logic seems wrong: if c is empty this must be cleared The error shows up in a failing test (but only when running all base.collections tests in Eclipse, not with gradle on the commandline) the test failure is in ObservableListWithExtractor.testUpdate_retainAll() which - besides exposing the error above - tells us two issues with the tests a) the normal (that is no extractor) test is incomplete (in not testing retainAll with empty array/collection) b) the test is not run with gradle because it doesn't adhere to naming conventions ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fastegal at openjdk.java.net Mon Sep 21 10:48:50 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 21 Sep 2020 10:48:50 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Sat, 19 Sep 2020 05:18:11 GMT, yosbits wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 177: >> >>> 175: beginChange(); >>> 176: boolean removed = false; >>> 177: for (int i = size()-1; i>=0; i--) { >> >> 1. Use spaces between operators. >> 2. Why reverse the iteration order? >> >> Implementation discussion: >> * We can use `boolean removed = removeIf(c::contains);` instead of the loop. However, this method uses the iterator and >> not random access, which *could* be less performant. The class implements `RandomAccess`, suggesting that this is the >> case, however, I don't see why. It seems that the implementation can be any list, such as `LinkedList`, which is not >> `RandomAccess`. >> * Why do we need to override the inherited behavior? The super implementation, which is the one from >> `ModifiableObservableListBase`, does >> ``` >> beginChange(); >> try { >> boolean res = super.removeAll(c); >> return res; >> } finally { >> endChange(); >> } >> ``` >> (except that it does not check for empty collections at the start - should it?) The `super` here is >> `AbstractCollection`, which does `Iterator`-based removal. >> >> Same goes for the other method. > > Since the purpose of this issue is performance tuning, > Rewriting with removeIf has a different purpose. > This is the same as the original code. > > The iteration order is reversed because index movement does not occur during deletion. This is the same as the original > code. wondering why the implementation with the BitSet was choosen at all? Certainly feels like a detour, so what are the corner cases that I'm too blind to see? ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Mon Sep 21 11:22:11 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 21 Sep 2020 11:22:11 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 10:40:37 GMT, Jeanette Winzenburg wrote: >> https://bugs.openjdk.java.net/browse/JDK-8253086 >> >> ObservableListWrapper.java >> * public boolean removeAll(Collection c) >> * public boolean retainAll(Collection c) >> >> These two methods use BitSet, but it doesn't make sense. >> By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range >> of use cases. >> The test is done with the following command. >> >> * gradle base: test >> * gradle controls: test > > modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 191: > >> 189: if (this.isEmpty() || c.isEmpty()) { >> 190: return false; >> 191: } > > logic seems wrong: if c is empty this must be cleared > > The error shows up in a failing test (but only when running all base.collections tests in Eclipse, not with gradle on > the commandline) > the test failure is in ObservableListWithExtractor.testUpdate_retainAll() which - besides exposing the error above - > tells us two issues with the tests > a) the normal (that is no extractor) test is incomplete (in not testing retainAll with empty array/collection) > b) the test is not run with gradle because it doesn't adhere to naming conventions ;) I realized I was wrong. Thank you. I would probably need to add a test for this case. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Mon Sep 21 11:34:33 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 21 Sep 2020 11:34:33 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 10:45:49 GMT, Jeanette Winzenburg wrote: >> Since the purpose of this issue is performance tuning, >> Rewriting with removeIf has a different purpose. >> This is the same as the original code. >> >> The iteration order is reversed because index movement does not occur during deletion. This is the same as the original >> code. > > wondering why the implementation with the BitSet was choosen at all? Certainly feels like a detour, so what are the > corner cases that I'm too blind to see? I can't answer(, but my intuition is a pattern of lack of skill). Officially, I don't know because the history is interrupted. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From fastegal at openjdk.java.net Mon Sep 21 12:02:53 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 21 Sep 2020 12:02:53 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 11:31:33 GMT, yosbits wrote: >> wondering why the implementation with the BitSet was choosen at all? Certainly feels like a detour, so what are the >> corner cases that I'm too blind to see? > > I can't answer(, but my intuition is a pattern of lack of skill). > Officially, I don't know because the history is interrupted. digging a bit: the BitSet was introduced with https://bugs.openjdk.java.net/browse/JDK-8093144 to solve some problem with selectionModels - don't know whether those still hold (there had been extensive changes to selection since then). ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+1413266+jgneff at openjdk.java.net Mon Sep 21 18:37:25 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 21 Sep 2020 18:37:25 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened In-Reply-To: <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> Message-ID: On Mon, 29 Jun 2020 18:49:33 GMT, John Neffenger wrote: > Nonetheless, it would be reassuring if someone could try [this change](https://github.com/openjdk/jfx/pull/258/files) > just once on a mainstream device, such as the Raspberry Pi with a touchscreen LCD panel. I just placed an order for a Raspberry Pi 2 Model B -- the older model with the 32-bit ARMv7-A architecture. It's the oldest, slowest, and coolest-running Raspberry Pi supported by Ubuntu, and it's also the closest match to the processors found in devices with e-paper displays. The Raspberry Pi should finally let me test changes like this to the Linux Monocle platform on which the EPD platform is based. I may eventually add a touchscreen, but I'm hoping to get by with just the mouse for now. ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From tsayao at openjdk.java.net Mon Sep 21 23:26:00 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 21 Sep 2020 23:26:00 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend [v61] In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test 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 42 additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk_8236651' into jdk_8236651 - Fix mouse click event - Revert to all events mask - Small Adjustments - Fix compilation on 18.04 - Merge branch 'master' into jdk_8236651 - Limit GTK on 3.8 - Limit GTK on 3.18 (Ubuntu 16.04) - Forgot a g_print - Fix build with merged linux.gradle - ... and 32 more: https://git.openjdk.java.net/jfx/compare/2b740505...a8e1e18b ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/ffe3c36e..a8e1e18b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=77&range=60 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=77&range=59-60 Stats: 392034 lines in 5774 files changed: 194548 ins; 135448 del; 62038 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 tsayao at openjdk.java.net Mon Sep 21 23:44:49 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 21 Sep 2020 23:44:49 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend [v62] In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: parent c95598e8df7d303e8f2540c1845ebdcc2200ab2f author Thiago Sayao 1578267129 -0300 committer Thiago M Sayao 1600731362 -0300 parent c95598e8df7d303e8f2540c1845ebdcc2200ab2f author Thiago Sayao 1578267129 -0300 committer Thiago M Sayao 1600731289 -0300 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 Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment Fix Tab Prefer content size over window size. Fixes for ubuntu 16.04 (which delays frame extents) Just comment fixing More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Only work-around Unity bug if Unity is the Window Manager (Ubuntu 16.04). Separate the new gtk glass impl Make gtk3 compile without deprecations Make gtk3 compile without deprecations Make gtk3 compile without deprecations Smooth scrolling only possible with impl on java side Restore deleted idea file Restore comment position Rename flag to javafx.gtk.experimental Rename flag to javafx.gtk.experimental Fix window position bug Fix build with merged linux.gradle Forgot a g_print Limit GTK on 3.18 (Ubuntu 16.04) Limit GTK on 3.8 Fix compilation on 18.04 Small Adjustments Revert to all events mask Fix mouse click event 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 Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment Fix Tab Prefer content size over window size. Fixes for ubuntu 16.04 (which delays frame extents) Just comment fixing More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Only work-around Unity bug if Unity is the Window Manager (Ubuntu 16.04). Separate the new gtk glass impl Make gtk3 compile without deprecations Make gtk3 compile without deprecations Make gtk3 compile without deprecations Smooth scrolling only possible with impl on java side Restore deleted idea file Restore comment position Rename flag to javafx.gtk.experimental Fix build with merged linux.gradle Fix compilation on 18.04 Revert to all events mask Fix mouse click event ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/a8e1e18b..97c67419 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=77&range=61 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=77&range=60-61 Stats: 2 lines in 1 file changed: 0 ins; 2 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 tsayao at openjdk.java.net Mon Sep 21 23:44:50 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 21 Sep 2020 23:44:50 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> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.b4b2b8ca-3f26-4e74-8c61-024b82a9d1f5@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.f0d13854-5f71-4d32-98a1-d8d4add15c1c@github.com> Message-ID: On Thu, 27 Aug 2020 21:21:39 GMT, Tor (torbuntu) wrote: >> I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the >> "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). > >> I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the >> "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). > > Would it be safe you think to branch from your PR to have the updated gtk backend? It would be much easier to work with. Rebased onto "master" and squashed commits. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Tue Sep 22 01:15:21 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 22 Sep 2020 01:15:21 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> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.b4b2b8ca-3f26-4e74-8c61-024b82a9d1f5@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.f0d13854-5f71-4d32-98a1-d8d4add15c1c@github.com> Message-ID: On Mon, 21 Sep 2020 23:40:50 GMT, Thiago Milczarek Sayao wrote: >>> I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the >>> "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). >> >> Would it be safe you think to branch from your PR to have the updated gtk backend? It would be much easier to work with. > > Rebased onto "master" and squashed commits. Tested on Ubuntu 20.04 756 tests completed, 6 failed, 110 skipped Failed: test.robot.javafx.scene.ColorPickerTest > testColorPickerSceneChange FAILED java.lang.AssertionError: Timeout: Failed to receive onAction callback. at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.robot.javafx.scene.ColorPickerTest.waitForLatch(ColorPickerTest.java:203) at test.robot.javafx.scene.ColorPickerTest.clickColorPickerPalette(ColorPickerTest.java:88) at test.robot.javafx.scene.ColorPickerTest.testColorPickerSceneChange(ColorPickerTest.java:119) test.robot.javafx.scene.RobotTest > testKeyPress FAILED org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> at org.junit.Assert.assertEquals(Assert.java:123) at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest > resizeColumnToFitContentTest FAILED java.lang.AssertionError: resizeColumnToFitContent failed at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest.resizeColumnToFitContentTest(TableViewResizeColumnToFitContentTest.java:96) test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(62,62,62,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) For some reason the html report is not being generated. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 02:01:59 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 02:01:59 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 11:59:55 GMT, Jeanette Winzenburg wrote: >> I can't answer(, but my intuition is a pattern of lack of skill). >> Officially, I don't know because the history is interrupted. > > digging a bit: the BitSet was introduced with https://bugs.openjdk.java.net/browse/JDK-8093144 to solve some problem > with selectionModels - don't know whether those still hold (there had been extensive changes to selection since then). Thank you for searching for the origin of this strange code. However, as far as I read the comments, my intuition seems to be correct. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 02:19:09 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 02:19:09 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 11:19:30 GMT, yosbits wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 191: >> >>> 189: if (this.isEmpty() || c.isEmpty()) { >>> 190: return false; >>> 191: } >> >> logic seems wrong: if c is empty this must be cleared >> >> The error shows up in a failing test (but only when running all base.collections tests in Eclipse, not with gradle on >> the commandline) >> the test failure is in ObservableListWithExtractor.testUpdate_retainAll() which - besides exposing the error above - >> tells us two issues with the tests >> a) the normal (that is no extractor) test is incomplete (in not testing retainAll with empty array/collection) >> b) the test is not run with gradle because it doesn't adhere to naming conventions ;) > > I realized I was wrong. Thank you. I would probably need to add a test for this case. > I plan to push new changes around tomorrow. I found that I needed to add at least a retainAll test, but I also found that there was no test class to directly test ObservableListWrapper. Should I add a test for this non-public API class? When I add it, I'm not going to write test code for methods other than removeAll and retainAll. ------------- PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 07:11:10 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 07:11:10 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8253086 > > ObservableListWrapper.java > * public boolean removeAll(Collection c) > * public boolean retainAll(Collection c) > > These two methods use BitSet, but it doesn't make sense. > By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range > of use cases. > The test is done with the following command. > > * gradle base: test > * gradle controls: test yosbits has updated the pull request incrementally with one additional commit since the last revision: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/305/files - new: https://git.openjdk.java.net/jfx/pull/305/files/8e7bcc9e..6ba02baa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=00-01 Stats: 124 lines in 2 files changed: 121 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/305/head:pull/305 PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 07:15:05 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 07:15:05 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v3] In-Reply-To: References: Message-ID: <_sXJo-2MJWSSSz8KWt2dZKHVv5Zyd_KC5Bb-JKUQf18=.ee51ed82-c87b-4f79-a53c-017125e98efa@github.com> > https://bugs.openjdk.java.net/browse/JDK-8253086 > > ObservableListWrapper.java > * public boolean removeAll(Collection c) > * public boolean retainAll(Collection c) > > These two methods use BitSet, but it doesn't make sense. > By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range > of use cases. > The test is done with the following command. > > * gradle base: test > * gradle controls: test yosbits has updated the pull request incrementally with one additional commit since the last revision: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/305/files - new: https://git.openjdk.java.net/jfx/pull/305/files/6ba02baa..4c61c071 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/305/head:pull/305 PR: https://git.openjdk.java.net/jfx/pull/305 From brometeo at gmail.com Tue Sep 22 07:29:31 2020 From: brometeo at gmail.com (david) Date: Tue, 22 Sep 2020 09:29:31 +0200 Subject: Problems loading Control classes on JRuby project Message-ID: <20200922072931.GA766233@localhost> Hi all. I know that this problem is JRuby specific, but I have asked in JRuby mailing list without any response and I am desesperated now :( Question is, I have a very big project programmed in JRuby, with Maven dependencies. Trying to migrate project to JavaFX I have configured its dependency jars in pom.xml, as shown in web page tutorials. All works perfectly for base classes, like javafx.scene.Scene, javafx.stage.Stage, etc. But, although I configure explicitly javafx-controls module in pom.xml, the Control classes are not available. I get an error trying to access them of type: org.jruby.exceptions.NameError: (NameError) missing class name (`javafx.scene.control.Button') I don't understand why some classes exist and some don't. Do you have any clue for searching... anything? Thank you very much for any idea :) Greets. -- David From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 07:35:49 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 07:35:49 GMT Subject: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8253086 > > ObservableListWrapper.java > * public boolean removeAll(Collection c) > * public boolean retainAll(Collection c) > > These two methods use BitSet, but it doesn't make sense. > By rewriting to the equivalent behavior that does not use BitSet, it is possible to reduce the CPU load in a wide range > of use cases. > The test is done with the following command. > > * gradle base: test > * gradle controls: test yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/305/files - new: https://git.openjdk.java.net/jfx/pull/305/files/4c61c071..8b319c6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/305/head:pull/305 PR: https://git.openjdk.java.net/jfx/pull/305 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 08:54:52 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 08:54:52 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v2] In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of > TreeUtil.getTreeItem (). > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), > tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } yosbits has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - 8197991: Fix multi-select performance issues - 8197991: Fix multi-select performance issues ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/127/files - new: https://git.openjdk.java.net/jfx/pull/127/files/870e984f..791c03c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=127&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=127&range=00-01 Stats: 430170 lines in 6151 files changed: 215868 ins; 144739 del; 69563 mod Patch: https://git.openjdk.java.net/jfx/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/127/head:pull/127 PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 09:04:15 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 09:04:15 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: <0nkXdOP1Qvd8C_BbziQIQutPeBI7-AeCjVEmlVN0CYU=.544819c7-3a5a-4891-a995-2d40da4fa2b4@github.com> > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of > TreeUtil.getTreeItem (). > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), > tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8197991: Fix multi-select performance issues ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/127/files - new: https://git.openjdk.java.net/jfx/pull/127/files/791c03c9..59b6d0b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=127&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=127&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/127/head:pull/127 PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 09:04:16 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 09:04:16 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: On Mon, 14 Sep 2020 09:53:25 GMT, Ajit Ghaisas wrote: >> yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views >> will show differences compared to the previous content of the PR. The pull request contains one new commit since the >> last revision: >> 8197991: Fix multi-select performance issues > > modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 861: > >> 859: } >> 860: >> 861: /** Returns number of true bits in BitSet */ > > Method description and work done by it is no more matching. Can you please update the comment? This comment is correct. this.size is the cache. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 09:16:51 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 09:16:51 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: <0nkXdOP1Qvd8C_BbziQIQutPeBI7-AeCjVEmlVN0CYU=.544819c7-3a5a-4891-a995-2d40da4fa2b4@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <0nkXdOP1Qvd8C_BbziQIQutPeBI7-AeCjVEmlVN0CYU=.544819c7-3a5a-4891-a995-2d40da4fa2b4@github.com> Message-ID: On Tue, 22 Sep 2020 09:04:15 GMT, yosbits wrote: >> https://bugs.openjdk.java.net/browse/JDK-8197991 >> >> The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. >> >> This greatly improves the response when selecting multiple items in ListView and TableView. >> >> However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of >> TreeUtil.getTreeItem (). >> Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) >> >> ListView >> * selectAll: 400_000-> 10_000_000 >> * selectRange: 7_000-> 70_000 >> >> TableView >> * selectAll: 8_000-> 700_000 >> * selectRange: 7_000-> 50_000 >> >> >> You can see performance improvements in the following applications: >> >> >> SelectListViewTest.java >> import javafx.application.Application; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.ListView; >> import javafx.scene.control.SelectionMode; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class SelectListViewTest extends Application { >> final int ROW_COUNT = 70_000; >> // final int ROW_COUNT = 400_000; >> // final int ROW_COUNT = 10_000_000; >> // final int ROW_COUNT = 7_000; >> >> @Override >> public void start(Stage stage) { >> ListView listView = new ListView<>(); >> listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); >> >> >> ObservableList items = listView.getItems(); >> for(int i=0; i> String rec = String.valueOf(i); >> items.add(rec); >> } >> BorderPane root = new BorderPane(listView); >> Button selectAll = new Button("selectAll"); >> Button clearSelection = new Button("clearSelection"); >> Button selectToStart = new Button("selectToStart"); >> Button selectToEnd = new Button("selectToEnd"); >> Button selectPrevious = new Button("selectPrevious"); >> Button selectNext= new Button("selectNext"); >> >> selectAll.setFocusTraversable(true); >> clearSelection.setFocusTraversable(true); >> selectToStart.setFocusTraversable(true); >> selectToEnd.setFocusTraversable(true); >> selectPrevious.setFocusTraversable(true); >> selectNext.setFocusTraversable(true); >> >> root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); >> stage.setScene(new Scene(root, 600, 600)); >> >> selectAll.setOnAction((e)->selectAll(listView)); >> clearSelection.setOnAction((e)->clearSelection(listView)); >> selectToStart.setOnAction((e)->selectToStart(listView)); >> selectToEnd.setOnAction((e)->selectToLast(listView)); >> selectPrevious.setOnAction((e)->selectPrevious(listView)); >> selectNext.setOnAction((e)->selectNext(listView)); >> >> stage.show(); >> } >> >> private void selectAll(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectAll(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void clearSelection(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().clearSelection(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToStart(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToLast(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectPrevious(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectPrevious(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectNext(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectNext(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> public static void main(String[] args) { >> Application.launch(args); >> } >> } >> >> SelectTableViewTest.java >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.SelectionMode; >> import javafx.scene.control.TableColumn; >> import javafx.scene.control.TableView; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class SelectTableViewTest extends Application { >> >> final int ROW_COUNT = 700_000; >> // final int ROW_COUNT = 80_000; >> // final int ROW_COUNT = 50_000; >> // final int ROW_COUNT = 8_000; >> final int COL_COUNT = 3; >> >> @Override >> public void start(Stage stage) { >> TableView tableView = new TableView<>(); >> tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); >> // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); >> >> final ObservableList> columns = tableView.getColumns(); >> for(int i=0; i> TableColumn column = new TableColumn<>("Col"+i); >> final int colIndex=i; >> column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); >> column.setPrefWidth(150); >> columns.add(column); >> } >> >> ObservableList items = tableView.getItems(); >> for(int i=0; i> String[] rec = new String[COL_COUNT]; >> for(int j=0; j> rec[j] = i+":"+j; >> } >> items.add(rec); >> } >> BorderPane root = new BorderPane(tableView); >> Button selectAll = new Button("selectAll"); >> Button clearSelection = new Button("clearSelection"); >> Button selectToStart = new Button("selectToStart"); >> Button selectToEnd = new Button("selectToEnd"); >> Button selectPrevious = new Button("selectPrevious"); >> Button selectNext= new Button("selectNext"); >> >> selectAll.setFocusTraversable(true); >> clearSelection.setFocusTraversable(true); >> selectToStart.setFocusTraversable(true); >> selectToEnd.setFocusTraversable(true); >> selectPrevious.setFocusTraversable(true); >> selectNext.setFocusTraversable(true); >> >> root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); >> stage.setScene(new Scene(root, 600, 600)); >> >> selectAll.setOnAction((e)->selectAll(tableView)); >> clearSelection.setOnAction((e)->clearSelection(tableView)); >> selectToStart.setOnAction((e)->selectToStart(tableView)); >> selectToEnd.setOnAction((e)->selectToLast(tableView)); >> selectPrevious.setOnAction((e)->selectPrevious(tableView)); >> selectNext.setOnAction((e)->selectNext(tableView)); >> >> stage.show(); >> } >> >> private void selectAll(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectAll(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void clearSelection(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().clearSelection(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToStart(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToLast(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), >> tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectPrevious(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectPrevious(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectNext(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectNext(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> } > > yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views > will show differences compared to the previous content of the PR. I commented. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Tue Sep 22 09:16:51 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 22 Sep 2020 09:16:51 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: <9MKzR6VJE-tAI0m0xy1DsX81RTxP9A159e7raT7a2Ts=.f4084c6d-6e8e-4e65-9cfa-82cc1c803300@github.com> On Mon, 14 Sep 2020 09:50:05 GMT, Ajit Ghaisas wrote: >> yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views >> will show differences compared to the previous content of the PR. > > modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 899: > >> 897: for (;;) { >> 898: index = bitset.nextSetBit(index + 1); >> 899: if (index < 0) { > > As we are checking for nextSetBit, shouldn't we be checking for overflow rather than underflow? > Refer - [javadoc](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/BitSet.html#nextSetBit(int)) Since it cannot be loaded with a smaller number of items than Integer.MAX_VALUE (it looks like it freezes), overflow does not occur in the actual usage environment. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From arapte at openjdk.java.net Wed Sep 23 07:02:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 23 Sep 2020 07:02:09 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 10:30:05 GMT, Jeanette Winzenburg wrote: >> the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) >> >> - initially >> - after changing side >> - after resizing stage/tabPane >> - after modifying the list of tabs >> >> Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its >> scroll might need an update. >> Added tests that fail before and pass after the fix. >> >> Note that there still are issues while/after dragging, which are separated into >> [JDK-8253352](https://bugs.openjdk.java.net/browse/JDK-8253352) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > widened scope of fix to address review comment Looks good to me, left a minor comment. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 855: > 853: } else { > 854: } > 855: validateScrollOffset(); This seems to be an unintended change. If so please revert. ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From fastegal at openjdk.java.net Wed Sep 23 08:41:47 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 23 Sep 2020 08:41:47 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v2] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 06:55:42 GMT, Ambarish Rapte wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> widened scope of fix to address review comment > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 855: > >> 853: } else { >> 854: } >> 855: validateScrollOffset(); > > This seems to be an unintended change. If so please revert. good eye :) Forgot to remove the empty else block. Validate must be called always if the tabs are not fitting: needed if the last tab (in the list) is visible and we remove tabs from the end. Without, the now last tab is not kept glued to the trailing edge. There are two tests covering the corner case (testRemoveXXLast) which fail if we don't. Question is if that should be mentioned in a code comment? Personally, I tend to just delete the empty block. ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From jpereda at openjdk.java.net Wed Sep 23 10:26:12 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 23 Sep 2020 10:26:12 GMT Subject: RFR: 8178297: TableView scrolls slightly when adding new elements [v2] In-Reply-To: <_ip0Z6pUqZ5_FA0f1bsX3HgO4zQBf2krfIiAEGJaIhc=.47d6d48e-94ef-4ae5-a909-626f5e72c804@github.com> References: <_ip0Z6pUqZ5_FA0f1bsX3HgO4zQBf2krfIiAEGJaIhc=.47d6d48e-94ef-4ae5-a909-626f5e72c804@github.com> Message-ID: > This PR fixes an issue that happens when adding new items to a `TableView` or any other control that uses > `VirtualFlow`, if the scroll position is not 0: the virtual flow is slightly shifted down. > For instance, let's say that a cell has a layoutY of -10.0. After adding a new item to the table, during the layout > pass the new value is initially modified to -9.999999999999996 (`VirtualFlow::adjustByPixelAmount`) , and then, after > calling `VirtualFlow::positionCell` (that uses `snapSizeY(position)`) the layoutY is modified to -9.5, causing an > undesired positive shift of 0.5 pixels. `Region` has different snap methods: `snapSizeX/Y` are used to snap node > dimension values, like width or height, by ceiling to the nearest pixel (which explains the -9.5 value), while > `snapSpaceX/Y` are used to snap position values like insets, by rounding to the nearest pixel (this will give the > expected -10.0). Therefore, this PR modifies `VirtualFlow::positionCell` to use the `snapSpaceX/Y` methods, since > these are being used to set the layout of the cell and not its size. Test: A unity test has been included. It > simulates the case of adding new items to the virtual flow after an initial scroll. It currently fails after adding a > few items, and it passes with the changes of this PR. Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - Add test to verify the cell position remains constant when new cells are added to the virtualFlow. - Use correct snap method to set cell layout ------------- Changes: https://git.openjdk.java.net/jfx/pull/297/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=297&range=01 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/297.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/297/head:pull/297 PR: https://git.openjdk.java.net/jfx/pull/297 From johan.vos at gluonhq.com Wed Sep 23 14:15:01 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 23 Sep 2020 16:15:01 +0200 Subject: 11-dev backport request for gcc 9 issues Message-ID: Hi Kevin, I request approval to backport the following issues to 11-dev for 11.0.9: JDK-8241476 [1]: Linux build warnings issued on gcc 9 JDK-8242490 [2]: Upgrade to gcc 9.2 on Linux - Johan [1] https://bugs.openjdk.java.net/browse/JDK-8241476 [2] https://bugs.openjdk.java.net/browse/JDK-8242490 From kevin.rushforth at oracle.com Wed Sep 23 15:52:35 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Sep 2020 08:52:35 -0700 Subject: 11-dev backport request for gcc 9 issues In-Reply-To: References: Message-ID: <91f022f2-5413-ff56-9cc2-22d5dbecc8c5@oracle.com> Approved. -- Kevin On 9/23/2020 7:15 AM, Johan Vos wrote: > Hi Kevin, > > I request approval to backport the following issues to 11-dev for 11.0.9: > > JDK-8241476 [1]: Linux build warnings issued on gcc 9 > JDK-8242490 [2]: Upgrade to gcc 9.2 on Linux > > - Johan > > [1] https://bugs.openjdk.java.net/browse/JDK-8241476 > [2] https://bugs.openjdk.java.net/browse/JDK-8242490 From nlisker at openjdk.java.net Thu Sep 24 02:46:31 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 24 Sep 2020 02:46:31 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v14] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Change range after clamping ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/af0b1794..21f91dd7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=43&range=12-13 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Thu Sep 24 07:11:33 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 24 Sep 2020 07:11:33 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v2] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 08:39:32 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 855: >> >>> 853: } else { >>> 854: } >>> 855: validateScrollOffset(); >> >> This seems to be an unintended change. If so please revert. > > good eye :) Forgot to remove the empty else block. > > Validate must be called always if the tabs are not fitting: needed if the last tab (in the list) is visible and we > remove tabs from the end. Without, the now last tab is not kept glued to the trailing edge. There are two tests > covering the corner case (testRemoveXXLast) which fail if we don't. Question is if that should be mentioned in a code > comment? Personally, I tend to just delete the empty block. Thanks, I confirmed that it is a needed change. I think, a comment will be useful here, as the problem that is solved by this change is not very vivid from source. ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From fastegal at openjdk.java.net Thu Sep 24 13:10:41 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 24 Sep 2020 13:10:41 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v3] In-Reply-To: References: Message-ID: <-FzegWDvMUdN-s7ZDofsPTG6-uHPdh3xqSvzTMkyt7o=.cc1a3ca5-c86e-46f2-9f08-5893c0b150a3@github.com> > the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) > > - initially > - after changing side > - after resizing stage/tabPane > - after modifying the list of tabs > > Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its > scroll might need an update. > Added tests that fail before and pass after the fix. > > Note that there still are issues while/after dragging, which are separated into > [JDK-8253352](https://bugs.openjdk.java.net/browse/JDK-8253352) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: removed empty else-block and added code comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/300/files - new: https://git.openjdk.java.net/jfx/pull/300/files/c3583829..9b95e0f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=300&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=300&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/300.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/300/head:pull/300 PR: https://git.openjdk.java.net/jfx/pull/300 From fastegal at openjdk.java.net Thu Sep 24 13:10:41 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 24 Sep 2020 13:10:41 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v2] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 07:08:55 GMT, Ambarish Rapte wrote: >> good eye :) Forgot to remove the empty else block. >> >> Validate must be called always if the tabs are not fitting: needed if the last tab (in the list) is visible and we >> remove tabs from the end. Without, the now last tab is not kept glued to the trailing edge. There are two tests >> covering the corner case (testRemoveXXLast) which fail if we don't. Question is if that should be mentioned in a code >> comment? Personally, I tend to just delete the empty block. > > Thanks, I confirmed that it is a needed change. I think, a comment will be useful here, as the problem that is solved > by this change is not very vivid from source. added a comment to clarify what the validate is doing ------------- PR: https://git.openjdk.java.net/jfx/pull/300 From johan.vos at gluonhq.com Thu Sep 24 13:43:37 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 24 Sep 2020 15:43:37 +0200 Subject: 11-dev backport request for linux gcc warnings Message-ID: Hi Kevin, I request approval to backport the following issue to 11-dev for 11.0.9: JDK-8215435 [1]: Warn on usage of trampolines with gcc This patch is needed before the patch for JDK-8241476 can be applied. - Johan [1] https://bugs.openjdk.java.net/browse/JDK-8215435 From johan.vos at gluonhq.com Thu Sep 24 14:50:12 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 24 Sep 2020 16:50:12 +0200 Subject: 11-dev backport requests Message-ID: Hi Kevin, I request approval to backport the following issues to 11-dev for 11.0.9. All patches apply clean. JDK-8246099: Intermittent test failures in SandboxAppTest JDK-8246357: Allow static build of webkit library on linux JDK-8208169: can not print selected pages of web page (does not touch native WebKit code) JDK-8248365: Debug build crashes on Windows when playing media file JDK-8234471: Canvas in webview displayed with wrong scale on Windows (does not touch native WebKit code) JDK-8220484 : JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% - Johan From kevin.rushforth at oracle.com Thu Sep 24 16:04:52 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 24 Sep 2020 09:04:52 -0700 Subject: 11-dev backport request for linux gcc warnings In-Reply-To: References: Message-ID: <9db8742d-e2de-8ff3-afdc-397081e587a5@oracle.com> Approved. -- Kevin On 9/24/2020 6:43 AM, Johan Vos wrote: > Hi Kevin, > > I request approval to backport the following issue to 11-dev for 11.0.9: > > JDK-8215435 [1]:?Warn on usage of trampolines with gcc > > This patch is needed before the patch for JDK-8241476 can be applied. > > - Johan > > [1] https://bugs.openjdk.java.net/browse/JDK-8215435 From kevin.rushforth at oracle.com Thu Sep 24 16:05:55 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 24 Sep 2020 09:05:55 -0700 Subject: 11-dev backport requests In-Reply-To: References: Message-ID: Approved. -- Kevin On 9/24/2020 7:50 AM, Johan Vos wrote: > Hi Kevin, > > > I request approval to backport the following issues to 11-dev for > 11.0.9. All patches apply clean. > > JDK-8246099: Intermittent test failures in SandboxAppTest > JDK-8246357: Allow static build of webkit library on linux > JDK-8208169: can not print selected pages of web page ?(does not touch > native WebKit code) > JDK-8248365: Debug build crashes on Windows when playing media file > JDK-8234471: Canvas in webview displayed with wrong scale on Windows > ?(does not touch native WebKit code) > JDK-8220484 : JFXPanel renders a slanted image with a hidpi monitor > scale of 125% or 175% > > - Johan From arapte at openjdk.java.net Thu Sep 24 18:36:30 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 24 Sep 2020 18:36:30 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification In-Reply-To: References: Message-ID: On Tue, 18 Aug 2020 19:50:55 GMT, Leon Linhart wrote: > Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was > actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling > `#clear()`), or if 2. it was modified as result of the `#addAll()` call. > > If you want any test coverage for this please let me know. > > I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see > that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle > JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or > that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission > is still pending anyway.) Change seems good, suggested minor changes. modules/javafx.base/src/main/java/javafx/collections/ModifiableObservableListBase.java line 32: > 30: import java.util.List; > 31: import java.util.ListIterator; > 32: import java.util.Objects; This import seems unused, please remove. modules/javafx.base/src/main/java/javafx/collections/ModifiableObservableListBase.java line 97: > 95: clear(); > 96: addAll(col); > 97: return true; I think following code would be more suitable here, boolean res = super.addAll(c); return res; This code is already used in two `addAll()` methods of this class. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/284 From arapte at openjdk.java.net Thu Sep 24 18:40:03 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 24 Sep 2020 18:40:03 GMT Subject: RFR: 8252236: TabPane: must keep header of selected tab visible [v3] In-Reply-To: <-FzegWDvMUdN-s7ZDofsPTG6-uHPdh3xqSvzTMkyt7o=.cc1a3ca5-c86e-46f2-9f08-5893c0b150a3@github.com> References: <-FzegWDvMUdN-s7ZDofsPTG6-uHPdh3xqSvzTMkyt7o=.cc1a3ca5-c86e-46f2-9f08-5893c0b150a3@github.com> Message-ID: On Thu, 24 Sep 2020 13:10:41 GMT, Jeanette Winzenburg wrote: >> the issue is that the header of the selected tab is not always visible (or kept visible, see report for details) >> >> - initially >> - after changing side >> - after resizing stage/tabPane >> - after modifying the list of tabs >> >> Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is responsible for layout the tabs) whenever its >> scroll might need an update. >> Added tests that fail before and pass after the fix. >> >> Note that there still are issues while/after dragging, which are separated into >> [JDK-8253352](https://bugs.openjdk.java.net/browse/JDK-8253352) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > removed empty else-block and added code comment Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/300 From fthevenet at openjdk.java.net Thu Sep 24 19:02:47 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Thu, 24 Sep 2020 19:02:47 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling Message-ID: This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: - The node, or one of its parents, must have set `Node::cacheProperty` to `true` - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) - The effective layout X or Y coordinates for the cached node must not be != 0; Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. ------------- Commit messages: - Round up the translation coordinates when rendering a cached node to screen to prevent it from appearing blurry Changes: https://git.openjdk.java.net/jfx/pull/308/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211294 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/308/head:pull/308 PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Thu Sep 24 19:12:03 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Thu, 24 Sep 2020 19:12:03 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: Message-ID: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> On Thu, 24 Sep 2020 18:57:13 GMT, Frederic Thevenet wrote: > This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with > a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output > scaling). Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not > appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). > The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to `true` > > - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number > (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered > to the screen may be non integer numbers, which is the cause for the blurriness. > Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) > before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the > previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce > other noticeable visual artifacts. Still, there might be a better place somewhere else higher up in the call chain > where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet > familiar enough with the code to see if it is really the case. Also, I don't really have an idea on how this could be tested other than visually, so I'm open to suggestions. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From arapte at openjdk.java.net Fri Sep 25 07:10:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 25 Sep 2020 07:10:13 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: References: Message-ID: On Thu, 7 May 2020 16:08:25 GMT, Florian Kirmaier wrote: >> It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 >> >> I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. >> >> It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. >> I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very >> stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but >> the tests with JMemoryBuddy are basically always correct. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8244297 > Improved the JavaDoc for JMemoryBuddy Tests fail to compile, please correct the import. Pointed error in `ToggleButtonTest`, please check other files also when correcting this. modules/javafx.controls/src/test/java/test/javafx/scene/control/ToggleButtonTest.java line 45: > 43: import org.junit.Before; > 44: import org.junit.Test; > 45: import de.sandec.jmemorybuddy.JMemoryBuddy; Throws compilation error: package de.sandec.jmemorybuddy does not exist modules/javafx.controls/src/test/java/test/javafx/scene/control/ToggleButtonTest.java line 161: > 159: > 160: @Test public void toggleGroupViaGroupAddAndRemoveClearsReference() { > 161: JMemoryBuddy.memoryTest(checker -> { Compilation error: cannot find symbol JMemoryBuddy ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/204 From jvos at openjdk.java.net Fri Sep 25 07:50:33 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 25 Sep 2020 07:50:33 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> Message-ID: On Thu, 24 Sep 2020 19:09:19 GMT, Frederic Thevenet wrote: >> This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with >> a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output >> scaling). Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not >> appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). >> The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: >> >> - The node, or one of its parents, must have set `Node::cacheProperty` to `true` >> >> - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number >> (e.g. 1.25, 1.5, 175) >> >> - The effective layout X or Y coordinates for the cached node must be != 0; >> >> Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered >> to the screen may be non integer numbers, which is the cause for the blurriness. >> Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) >> before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the >> previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce >> other noticeable visual artifacts. Still, there might be a better place somewhere else higher up in the call chain >> where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet >> familiar enough with the code to see if it is really the case. > > Also, I don't really have an idea on how this could be tested other than visually, so I'm open to suggestions. The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect them to be. It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the bug? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From github.com+11281461+danielpeintner at openjdk.java.net Fri Sep 25 08:19:55 2020 From: github.com+11281461+danielpeintner at openjdk.java.net (danielpeintner) Date: Fri, 25 Sep 2020 08:19:55 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> Message-ID: On Fri, 25 Sep 2020 07:47:41 GMT, Johan Vos wrote: >> Also, I don't really have an idea on how this could be tested other than visually, so I'm open to suggestions. > > The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect > them to be. It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear > to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the > bug? FYI: there is another bug [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592) that *reads* somewhat similar even though the issues are very different. It is also marked as a "Windows" bug. Maybe the root of both issues is the same... ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Fri Sep 25 09:35:14 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 25 Sep 2020 09:35:14 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> Message-ID: On Fri, 25 Sep 2020 07:47:41 GMT, Johan Vos wrote: > > > The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect > them to be. It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear > to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the > bug? The issue will appear consistently as long as the conditions I listed are met, regardless of the actual number of pixels the physical screen can display. For instance you'll see the problem, if you apply a 125% scaling on 1080p screen (a common configuration on 13'' laptops). Also, it will occur regardless of whether the scaling is applied at the OS level and picked up by javafx or if it is only set for a single application using the `glass.xxx.uiScale` property. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From github.com+4029915+TheMrMilchmann at openjdk.java.net Fri Sep 25 10:26:52 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Fri, 25 Sep 2020 10:26:52 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v2] In-Reply-To: References: Message-ID: <_2zfWHaBf8_LY1Y9JhIyAoVcBmEEC9UrBOLiwNvsfD4=.598f2d36-ee5e-41a6-919b-4a57d798b518@github.com> > Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was > actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling > `#clear()`), or if 2. it was modified as result of the `#addAll()` call. > > If you want any test coverage for this please let me know. > > I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see > that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle > JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or > that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission > is still pending anyway.) Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: Removed unused import and addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/284/files - new: https://git.openjdk.java.net/jfx/pull/284/files/5f360384..e8857913 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=284&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=284&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/284/head:pull/284 PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+4029915+TheMrMilchmann at openjdk.java.net Fri Sep 25 10:26:53 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Fri, 25 Sep 2020 10:26:53 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v2] In-Reply-To: References: Message-ID: <_wn8RclGjd09QfGpRneQuckXuhAnG0Zh5k7Dyhi10WI=.fc27959b-a0a3-448b-ac02-01caa76bbaa2@github.com> On Thu, 24 Sep 2020 18:23:54 GMT, Ambarish Rapte wrote: >> Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unused import and addressed review comments > > modules/javafx.base/src/main/java/javafx/collections/ModifiableObservableListBase.java line 32: > >> 30: import java.util.List; >> 31: import java.util.ListIterator; >> 32: import java.util.Objects; > > This import seems unused, please remove. Indeed. Removed it. > modules/javafx.base/src/main/java/javafx/collections/ModifiableObservableListBase.java line 97: > >> 95: clear(); >> 96: addAll(col); >> 97: return true; > > I think following code would be more suitable here, > boolean res = super.addAll(c); > return res; > This code is already used in two `addAll()` methods of this class. Makes sense to me. I changed it accordingly. ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From fastegal at openjdk.java.net Fri Sep 25 11:17:39 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 25 Sep 2020 11:17:39 GMT Subject: RFR: 8253634: TreeCell/Skin: misbehavior on switching skin Message-ID: <9d4VS8CCZTJ-8dosR1FEWkS1gi870X_aIu29GW6xJbo=.f0d842db-67ff-493a-9ae8-a91412d2bba9@github.com> TreeCellSkin installs listeners to the TreeView/fixedCellSize that introduce a memory leak, NPE on replacing the treeView and incorrect update of internal state. Fixed by removing the listeners (and the internal state had been copied from treeView on change) and access of listView state when needed. Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior before/after. Issue and fix is basically the same as for ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745) ------------- Commit messages: - 8253634: TreeCell/Skin: misbehavior on switching skin Changes: https://git.openjdk.java.net/jfx/pull/309/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=309&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253634 Stats: 101 lines in 4 files changed: 60 ins; 36 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/309.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/309/head:pull/309 PR: https://git.openjdk.java.net/jfx/pull/309 From kcr at openjdk.java.net Fri Sep 25 15:51:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Sep 2020 15:51:38 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v2] In-Reply-To: <_wn8RclGjd09QfGpRneQuckXuhAnG0Zh5k7Dyhi10WI=.fc27959b-a0a3-448b-ac02-01caa76bbaa2@github.com> References: <_wn8RclGjd09QfGpRneQuckXuhAnG0Zh5k7Dyhi10WI=.fc27959b-a0a3-448b-ac02-01caa76bbaa2@github.com> Message-ID: <2NJk4oAJwhSv11M2apZtwlWXKx_RwAEJ4r3gP3lsnsM=.52d85801-28f2-4559-8916-8d8d5c4863f9@github.com> On Fri, 25 Sep 2020 10:23:54 GMT, Leon Linhart wrote: >> modules/javafx.base/src/main/java/javafx/collections/ModifiableObservableListBase.java line 97: >> >>> 95: clear(); >>> 96: addAll(col); >>> 97: return true; >> >> I think following code would be more suitable here, >> boolean res = super.addAll(c); >> return res; >> This code is already used in two `addAll()` methods of this class. > > Makes sense to me. I changed it accordingly. I don't think this change is correct. `setAll(Collection)` should return true if the list is modified. As discussed in an [earlier comment](#issuecomment-684117392) this means returning true if either the existing Collection or the new Collection is non-empty. ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+4029915+TheMrMilchmann at openjdk.java.net Fri Sep 25 16:47:37 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Fri, 25 Sep 2020 16:47:37 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v3] In-Reply-To: References: Message-ID: <1hwkSOY1yWNg7mGT9bCMw387oZEdb5aEGGVhcewVDbc=.7ad342dd-8cbe-44e4-ae2a-bc57a2e7fb2b@github.com> > Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was > actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling > `#clear()`), or if 2. it was modified as result of the `#addAll()` call. > > If you want any test coverage for this please let me know. > > I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see > that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle > JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or > that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission > is still pending anyway.) Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: Reverted incorrect change and improved test coverage ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/284/files - new: https://git.openjdk.java.net/jfx/pull/284/files/e8857913..5f260d7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=284&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=284&range=01-02 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/284/head:pull/284 PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+4029915+TheMrMilchmann at openjdk.java.net Fri Sep 25 16:47:37 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Fri, 25 Sep 2020 16:47:37 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v3] In-Reply-To: <2NJk4oAJwhSv11M2apZtwlWXKx_RwAEJ4r3gP3lsnsM=.52d85801-28f2-4559-8916-8d8d5c4863f9@github.com> References: <_wn8RclGjd09QfGpRneQuckXuhAnG0Zh5k7Dyhi10WI=.fc27959b-a0a3-448b-ac02-01caa76bbaa2@github.com> <2NJk4oAJwhSv11M2apZtwlWXKx_RwAEJ4r3gP3lsnsM=.52d85801-28f2-4559-8916-8d8d5c4863f9@github.com> Message-ID: <-0Sbvy6DhI_XoJTinSEwUy7D91v5uMO4c44N3UKEzaY=.29cb2159-c1f4-4122-8985-b4aad2f46c09@github.com> On Fri, 25 Sep 2020 15:49:12 GMT, Kevin Rushforth wrote: >> Makes sense to me. I changed it accordingly. > > I don't think this change is correct. `setAll(Collection)` should return true if the list is modified. As discussed in > an [earlier comment](#issuecomment-684117392) this means returning true if either the existing Collection or the new > Collection is non-empty. I'm sorry, you're absolutely right. I didn't spend enough time thinking about the change and assumed it was fine since the tests passed. Turns out the test didn't cover it. I reverted that part of the change and improved the test. ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+1413266+jgneff at openjdk.java.net Fri Sep 25 22:21:36 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 25 Sep 2020 22:21:36 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2] In-Reply-To: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Message-ID: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into zforce-command-overrun - 8201568: zForce touchscreen input device fails when closed and immediately reopened ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/258/files - new: https://git.openjdk.java.net/jfx/pull/258/files/54631e7f..68c05234 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=258&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=258&range=00-01 Stats: 391615 lines in 5768 files changed: 194160 ins; 135443 del; 62012 mod Patch: https://git.openjdk.java.net/jfx/pull/258.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/258/head:pull/258 PR: https://git.openjdk.java.net/jfx/pull/258 From kcr at openjdk.java.net Sat Sep 26 13:55:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 26 Sep 2020 13:55:29 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v3] In-Reply-To: <1hwkSOY1yWNg7mGT9bCMw387oZEdb5aEGGVhcewVDbc=.7ad342dd-8cbe-44e4-ae2a-bc57a2e7fb2b@github.com> References: <1hwkSOY1yWNg7mGT9bCMw387oZEdb5aEGGVhcewVDbc=.7ad342dd-8cbe-44e4-ae2a-bc57a2e7fb2b@github.com> Message-ID: On Fri, 25 Sep 2020 16:47:37 GMT, Leon Linhart wrote: >> Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was >> actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling >> `#clear()`), or if 2. it was modified as result of the `#addAll()` call. >> >> If you want any test coverage for this please let me know. >> >> I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see >> that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle >> JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or >> that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission >> is still pending anyway.) > > Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: > > Reverted incorrect change and improved test coverage The code change looks good. I have one suggestion for the test. modules/javafx.base/src/test/java/test/javafx/collections/ObservableListTest.java line 268: > 266: > 267: r = list.setAll(); > 268: assertTrue(r); Can you also test that calling `setAll` when the list is currently empty returns true? Repeating one of the earlier checks should work: r = list.setAll("one"); assertTrue(r); ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+4029915+TheMrMilchmann at openjdk.java.net Sat Sep 26 16:04:16 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Sat, 26 Sep 2020 16:04:16 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v4] In-Reply-To: References: Message-ID: <0UXvqSHXhA9KxweOoUbiLLgk_M919soTNP_O3-1qPyI=.e82aa5ac-919a-4e73-8d42-681f6e676541@github.com> > Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was > actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling > `#clear()`), or if 2. it was modified as result of the `#addAll()` call. > > If you want any test coverage for this please let me know. > > I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see > that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle > JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or > that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission > is still pending anyway.) Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: Test return value of setAll on an empty list ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/284/files - new: https://git.openjdk.java.net/jfx/pull/284/files/5f260d7e..5de1a51f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=284&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=284&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/284/head:pull/284 PR: https://git.openjdk.java.net/jfx/pull/284 From github.com+4029915+TheMrMilchmann at openjdk.java.net Sat Sep 26 16:04:17 2020 From: github.com+4029915+TheMrMilchmann at openjdk.java.net (Leon Linhart) Date: Sat, 26 Sep 2020 16:04:17 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v3] In-Reply-To: References: <1hwkSOY1yWNg7mGT9bCMw387oZEdb5aEGGVhcewVDbc=.7ad342dd-8cbe-44e4-ae2a-bc57a2e7fb2b@github.com> Message-ID: On Sat, 26 Sep 2020 13:51:10 GMT, Kevin Rushforth wrote: >> Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverted incorrect change and improved test coverage > > modules/javafx.base/src/test/java/test/javafx/collections/ObservableListTest.java line 268: > >> 266: >> 267: r = list.setAll(); >> 268: assertTrue(r); > > Can you also test that calling `setAll` when the list is currently empty returns true? Repeating one of the earlier > checks should work: > r = list.setAll("one"); > assertTrue(r); Sure. Added in #284 5de1a51fd3a8d744acf0b831ab4f5a0441e417d7. ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From nlisker at gmail.com Sun Sep 27 18:29:18 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 27 Sep 2020 21:29:18 +0300 Subject: Preparing migrations to inline classes Message-ID: Hi, Project Valhalla is planning to create an annotation to apply to classes that are planned to be migrated to inline classes [1]. As part of the migration requirements, classes can't have a public or protected constructor, and this is the main breaking change. They must also be final, though I doubt many of these were extended. We should start compiling a list of classes that are candidates for migration so we will have enough time to deprecate constructors and otherwise prepare developers for these changes when inline classes will be ready. As an example, Point2D/3D are good migration candidates. They will need to have their constrictors removed and the classes made final. Other candidates are: javafx.css.Size javafx.geometry.Dimension2D javafx.geometry.Insets Internal classes are less of a problem and can be migrated without preparation. - Nir [1] https://openjdk.java.net/jeps/390 From github.com+7517141+yososs at openjdk.java.net Mon Sep 28 12:01:14 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 28 Sep 2020 12:01:14 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) Message-ID: * https://bugs.openjdk.java.net/browse/JDK-8090110 * https://bugs.openjdk.java.net/browse/JDK-8089418 TextArea slows down as the number of characters increases. This problem can be greatly improved by setting the clip of the display area. It also improves performance when increasing the font size. The TextArea performance improvement from this change can be seen even when dealing with Latin characters only. In the change, the Clip area is bound only vertically. When binding horizontally, a stack overflow occurs when resizing the window.This looks like a potential problem with the Text control. A fix for this problem can be found in the next test. Java import java.util.Random; import javafx.application.Application; import javafx.geometry.Insets; import javafx.geometry.Pos; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.CheckBox; import javafx.scene.control.TextArea; import javafx.scene.layout.BorderPane; import javafx.scene.layout.HBox; import javafx.scene.text.Font; import javafx.stage.Stage; public class BigTextAreaTest extends Application { // private static final int TEST_TEXT_LENGTH = 1*1024*1024; // 1MB private static final int TEST_TEXT_LENGTH = 100*1024; // 100KB private static final String alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; private static final String number = "0123456789"; private static final String hiragana = "??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; private static final String katakana = "??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; private static final String jis_lv1 = "????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; @Override public void start(Stage stage) throws Exception { BorderPane pane = new BorderPane(); CheckBox padding = new CheckBox("Padding"); CheckBox wrap = new CheckBox("Wrap"); CheckBox hugeFont = new CheckBox("Huge font"); Button recreate = new Button("recreate"); HBox header = new HBox(8, wrap, hugeFont, padding, recreate); header.setAlignment(Pos.CENTER); pane.setTop(header); Scene scene = new Scene(pane, 700, 300); stage.setScene(scene); stage.show(); padding.selectedProperty().addListener((on,oldValue,newValue)->{ ((TextArea)pane.getCenter()).setPadding(new Insets(newValue.booleanValue()?20:0)); }); wrap.selectedProperty().addListener((on,oldValue,newValue)->{ ((TextArea)pane.getCenter()).setWrapText(newValue.booleanValue()); }); hugeFont.selectedProperty().addListener((on,oldValue,newValue)->{ ((TextArea)pane.getCenter()).setFont(Font.font(Font.getDefault().getFamily(), newValue.booleanValue()?120:12)); }); recreate.setOnAction(e->pane.setCenter(createTextArea())); pane.setCenter(createTextArea()); } public static void main(String[] args) { Application.launch(args); } TextArea createTextArea(){ TextArea textArea = new TextArea(); StringBuilder buf = new StringBuilder(); // String testchar = alpha; // String testchar = hiragana; // String testchar = katakana; // String testchar = jis_lv1; String testchar = alpha + number + hiragana + katakana + jis_lv1; Random r = new Random(); for(int i=0; i0 && i%100 == 0){ buf.append("\n"); } } textArea.setFont(Font.getDefault().font(15.0)); textArea.setText(buf.toString()); return textArea; } } **Next Step:** This is a proposal for the next step, but I think it may be included in this Pull Request. MULTIPLE_NODES mode is not as responsive as this Pull Request change for the following reasons: * In MULTIPLE_NODES mode, the number of nodes becomes huge and the response deteriorates without virtualization. * Implementation of MULTIPLE_NODES mode is in progress (probably giving up) It is suggested that the existing implementation of MULTIPLE_NODES mode be discarded as it is not worth leaving at all. ------------- Commit messages: - 8090110: TextArea performance improvements Changes: https://git.openjdk.java.net/jfx/pull/307/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8090110 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/307.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/307/head:pull/307 PR: https://git.openjdk.java.net/jfx/pull/307 From github.com+7517141+yososs at openjdk.java.net Mon Sep 28 12:01:19 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 28 Sep 2020 12:01:19 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 15:41:43 GMT, yosbits wrote: > * https://bugs.openjdk.java.net/browse/JDK-8090110 > * https://bugs.openjdk.java.net/browse/JDK-8089418 > > TextArea slows down as the number of characters increases. This problem can be greatly improved by setting the clip of > the display area. It also improves performance when increasing the font size. > The TextArea performance improvement from this change can be seen even when dealing with Latin characters only. > > In the change, the Clip area is bound only vertically. When binding horizontally, a stack overflow occurs when resizing > the window.This looks like a potential problem with the Text control. > A fix for this problem can be found in the next test. > > Java > import java.util.Random; > > import javafx.application.Application; > import javafx.geometry.Insets; > import javafx.geometry.Pos; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.CheckBox; > import javafx.scene.control.TextArea; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.scene.text.Font; > import javafx.stage.Stage; > > public class BigTextAreaTest extends Application { > > // private static final int TEST_TEXT_LENGTH = 1*1024*1024; // 1MB > private static final int TEST_TEXT_LENGTH = 100*1024; // 100KB > > private static final String alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; > private static final String number = "0123456789"; > private static final String hiragana = "??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; > private static final String katakana = "??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; > private static final String jis_lv1 = > "??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; > @Override > public void start(Stage stage) throws Exception { > > BorderPane pane = new BorderPane(); > CheckBox padding = new CheckBox("Padding"); > CheckBox wrap = new CheckBox("Wrap"); > CheckBox hugeFont = new CheckBox("Huge font"); > Button recreate = new Button("recreate"); > > HBox header = new HBox(8, wrap, hugeFont, padding, recreate); > header.setAlignment(Pos.CENTER); > pane.setTop(header); > Scene scene = new Scene(pane, 700, 300); > stage.setScene(scene); > stage.show(); > > padding.selectedProperty().addListener((on,oldValue,newValue)->{ > ((TextArea)pane.getCenter()).setPadding(new Insets(newValue.booleanValue()?20:0)); > }); > wrap.selectedProperty().addListener((on,oldValue,newValue)->{ > ((TextArea)pane.getCenter()).setWrapText(newValue.booleanValue()); > }); > hugeFont.selectedProperty().addListener((on,oldValue,newValue)->{ > ((TextArea)pane.getCenter()).setFont(Font.font(Font.getDefault().getFamily(), newValue.booleanValue()?120:12)); > }); > recreate.setOnAction(e->pane.setCenter(createTextArea())); > > pane.setCenter(createTextArea()); > } > > public static void main(String[] args) { > Application.launch(args); > } > > TextArea createTextArea(){ > TextArea textArea = new TextArea(); > StringBuilder buf = new StringBuilder(); > // String testchar = alpha; > // String testchar = hiragana; > // String testchar = katakana; > // String testchar = jis_lv1; > String testchar = alpha + number + hiragana + katakana + jis_lv1; > > Random r = new Random(); > for(int i=0; i buf.append(testchar.charAt(Math.abs(r.nextInt())%testchar.length())); > if(i>0 && i%100 == 0){ > buf.append("\n"); > } > } > > textArea.setFont(Font.getDefault().font(15.0)); > textArea.setText(buf.toString()); > return textArea; > } > } > > **Next Step:** > > This is a proposal for the next step, but I think it may be included in this Pull Request. > > MULTIPLE_NODES mode is not as responsive as this Pull Request change for the following reasons: > > * In MULTIPLE_NODES mode, the number of nodes becomes huge and the response deteriorates without virtualization. > * Implementation of MULTIPLE_NODES mode is in progress (probably giving up) > > It is suggested that the existing implementation of MULTIPLE_NODES mode be discarded as it is not worth leaving at all. @kevinrushforth I don't know how to avoid the jcheck error, but what can I do? yosbits is Naohiro Yoshimoto. ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From fastegal at openjdk.java.net Mon Sep 28 12:01:24 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 28 Sep 2020 12:01:24 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 02:24:06 GMT, yosbits wrote: >> * https://bugs.openjdk.java.net/browse/JDK-8090110 >> * https://bugs.openjdk.java.net/browse/JDK-8089418 >> >> TextArea slows down as the number of characters increases. This problem can be greatly improved by setting the clip of >> the display area. It also improves performance when increasing the font size. >> The TextArea performance improvement from this change can be seen even when dealing with Latin characters only. >> >> In the change, the Clip area is bound only vertically. When binding horizontally, a stack overflow occurs when resizing >> the window.This looks like a potential problem with the Text control. >> A fix for this problem can be found in the next test. >> >> Java >> import java.util.Random; >> >> import javafx.application.Application; >> import javafx.geometry.Insets; >> import javafx.geometry.Pos; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.CheckBox; >> import javafx.scene.control.TextArea; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.HBox; >> import javafx.scene.text.Font; >> import javafx.stage.Stage; >> >> public class BigTextAreaTest extends Application { >> >> // private static final int TEST_TEXT_LENGTH = 1*1024*1024; // 1MB >> private static final int TEST_TEXT_LENGTH = 100*1024; // 100KB >> >> private static final String alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; >> private static final String number = "0123456789"; >> private static final String hiragana = "??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; >> private static final String katakana = "??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; >> private static final String jis_lv1 = >> "?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"; >> @Override >> public void start(Stage stage) throws Exception { >> >> BorderPane pane = new BorderPane(); >> CheckBox padding = new CheckBox("Padding"); >> CheckBox wrap = new CheckBox("Wrap"); >> CheckBox hugeFont = new CheckBox("Huge font"); >> Button recreate = new Button("recreate"); >> >> HBox header = new HBox(8, wrap, hugeFont, padding, recreate); >> header.setAlignment(Pos.CENTER); >> pane.setTop(header); >> Scene scene = new Scene(pane, 700, 300); >> stage.setScene(scene); >> stage.show(); >> >> padding.selectedProperty().addListener((on,oldValue,newValue)->{ >> ((TextArea)pane.getCenter()).setPadding(new Insets(newValue.booleanValue()?20:0)); >> }); >> wrap.selectedProperty().addListener((on,oldValue,newValue)->{ >> ((TextArea)pane.getCenter()).setWrapText(newValue.booleanValue()); >> }); >> hugeFont.selectedProperty().addListener((on,oldValue,newValue)->{ >> ((TextArea)pane.getCenter()).setFont(Font.font(Font.getDefault().getFamily(), newValue.booleanValue()?120:12)); >> }); >> recreate.setOnAction(e->pane.setCenter(createTextArea())); >> >> pane.setCenter(createTextArea()); >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> >> TextArea createTextArea(){ >> TextArea textArea = new TextArea(); >> StringBuilder buf = new StringBuilder(); >> // String testchar = alpha; >> // String testchar = hiragana; >> // String testchar = katakana; >> // String testchar = jis_lv1; >> String testchar = alpha + number + hiragana + katakana + jis_lv1; >> >> Random r = new Random(); >> for(int i=0; i> buf.append(testchar.charAt(Math.abs(r.nextInt())%testchar.length())); >> if(i>0 && i%100 == 0){ >> buf.append("\n"); >> } >> } >> >> textArea.setFont(Font.getDefault().font(15.0)); >> textArea.setText(buf.toString()); >> return textArea; >> } >> } >> >> **Next Step:** >> >> This is a proposal for the next step, but I think it may be included in this Pull Request. >> >> MULTIPLE_NODES mode is not as responsive as this Pull Request change for the following reasons: >> >> * In MULTIPLE_NODES mode, the number of nodes becomes huge and the response deteriorates without virtualization. >> * Implementation of MULTIPLE_NODES mode is in progress (probably giving up) >> >> It is suggested that the existing implementation of MULTIPLE_NODES mode be discarded as it is not worth leaving at all. > > @kevinrushforth > I don't know how to avoid the jcheck error, but what can I do? > yosbits is Naohiro Yoshimoto. beware: all listeners that are manually added by the skin (as opposed to those added via skin.registerXX) must be manually removed again! Also there must be tests added to guard against memory leaks and side-effects when switching the skin. For guidance, see [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364) and related (fixed and open) issues. ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From github.com+7517141+yososs at openjdk.java.net Mon Sep 28 12:01:29 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 28 Sep 2020 12:01:29 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: References: Message-ID: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> On Fri, 25 Sep 2020 11:19:39 GMT, Jeanette Winzenburg wrote: >> @kevinrushforth >> I don't know how to avoid the jcheck error, but what can I do? >> yosbits is Naohiro Yoshimoto. > > beware: all listeners that are manually added by the skin (as opposed to those added via skin.registerXX) must be > manually removed again! Also there must be tests added to guard against memory leaks and side-effects when switching > the skin. For guidance, see [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364) and related (fixed and > open) issues. @kleopatra It's a very good point, but the original source code seems to have a memory leak problem due to an incomplete implementation of dispose (). Checking with the profile tool, it looks like you need a cleanup of over 20 references. I think this is a problem that should be fixed in another issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From fastegal at openjdk.java.net Mon Sep 28 12:01:32 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 28 Sep 2020 12:01:32 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> References: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> Message-ID: <5BDq3WXflNNJ8C_gRTWqrmeSi_28kLvdxNnLhPr5LlY=.b473d1c1-3536-427a-a4e6-0e9c1e75d7e7@github.com> On Fri, 25 Sep 2020 18:29:35 GMT, yosbits wrote: >> beware: all listeners that are manually added by the skin (as opposed to those added via skin.registerXX) must be >> manually removed again! Also there must be tests added to guard against memory leaks and side-effects when switching >> the skin. For guidance, see [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364) and related (fixed and >> open) issues. > > @kleopatra > It's a very good point, but the original source code seems to have a memory leak problem due to an incomplete > implementation of dispose (). Checking with the profile tool, it looks like you need a cleanup of over 20 references. I > think this is a problem that should be fixed in another issue. agreed that cleanup of the existing leaks (and misbehavior due to missing listener removal is off scope for this :) - but you must not add new leaks/side-effects in this fix: guarding this change against additional misbehavior definitely is in scope, IMO. ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From github.com+7517141+yososs at openjdk.java.net Mon Sep 28 12:01:35 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 28 Sep 2020 12:01:35 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: <5BDq3WXflNNJ8C_gRTWqrmeSi_28kLvdxNnLhPr5LlY=.b473d1c1-3536-427a-a4e6-0e9c1e75d7e7@github.com> References: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> <5BDq3WXflNNJ8C_gRTWqrmeSi_28kLvdxNnLhPr5LlY=.b473d1c1-3536-427a-a4e6-0e9c1e75d7e7@github.com> Message-ID: On Fri, 25 Sep 2020 19:01:35 GMT, Jeanette Winzenburg wrote: >> @kleopatra >> It's a very good point, but the original source code seems to have a memory leak problem due to an incomplete >> implementation of dispose (). Checking with the profile tool, it looks like you need a cleanup of over 20 references. I >> think this is a problem that should be fixed in another issue. > > agreed that cleanup of the existing leaks (and misbehavior due to missing listener removal is off scope for this :) - > but you must not add new leaks/side-effects in this fix: guarding this change against additional misbehavior definitely > is in scope, IMO. Added the **Next Step** paragraph to the PR overview. I think it is necessary to judge this step before fixing the resource leak. The existing code is an incomplete implementation of dispose, assuming the development of MULTIPLE NODES mode. @kleopatra TextArea setSkin is not supported. Therefore, there is no existing application that depends on it. I can't write additional tests for incomplete implementations (it always fails). ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From hjohn at xs4all.nl Mon Sep 28 12:28:15 2020 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 28 Sep 2020 14:28:15 +0200 Subject: Preparing migrations to inline classes In-Reply-To: References: Message-ID: <8825c3c0-55d8-e6cd-cae1-0eb23da4a9f8@xs4all.nl> Perhaps some of the classes in javafx.util. Duration springs to mind. Others I think could be Bounds/BoundingBox, Rectangle2D. On 27/09/2020 20:29, Nir Lisker wrote: > Hi, > > Project Valhalla is planning to create an annotation to apply to classes > that are planned to be migrated to inline classes [1]. As part of the > migration requirements, classes can't have a public or protected > constructor, and this is the main breaking change. They must also be final, > though I doubt many of these were extended. > > We should start compiling a list of classes that are candidates > for migration so we will have enough time to deprecate constructors and > otherwise prepare developers for these changes when inline classes will be > ready. > > As an example, Point2D/3D are good migration candidates. They will need to > have their constrictors removed and the classes made final. Other > candidates are: > javafx.css.Size > javafx.geometry.Dimension2D > javafx.geometry.Insets > > Internal classes are less of a problem and can be migrated without > preparation. > > - Nir > > [1] https://openjdk.java.net/jeps/390 > From johan.vos at gluonhq.com Mon Sep 28 13:02:27 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 28 Sep 2020 15:02:27 +0200 Subject: backport requests for 11-dev Message-ID: Hi Kevin, I request approval to backport the following issues to 11-dev for 11.0.9. JDK-8223760 support static build for macosx JDK-8227808 Make GTK3 libraries mandatory for building on Linux - Johan From kevin.rushforth at oracle.com Mon Sep 28 13:24:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 28 Sep 2020 06:24:49 -0700 Subject: backport requests for 11-dev In-Reply-To: References: Message-ID: Approved. -- Kevin On 9/28/2020 6:02 AM, Johan Vos wrote: > Hi Kevin, > > I request approval to backport the following issues to 11-dev for 11.0.9. > > JDK-8223760 support static build for macosx > JDK-8227808 Make GTK3 libraries mandatory for building on Linux > > - Johan From michaelstrau2 at gmail.com Mon Sep 28 23:25:44 2020 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 29 Sep 2020 01:25:44 +0200 Subject: Purpose of specialized BidirectionalBinding classes for primitive property types Message-ID: The com.sun.javafx.binding.BidirectionalBinding class contains specialized implementations for primitive types: 1. BidirectionalDoubleBinding 2. BidirectionalFloatBinding 3. BidirectionalIntegerBinding 4. BidirectionalLongBinding 5. BidirectionalBooleanBinding These private implementation classes are selected by the static BidirectionalBinding.bind(Property, Property) method iff the runtime type of both provided property objects corresponds to the respective primitive property implementation (DoubleProperty, FloatProperty, etc.). In all other cases, the generic TypedGenericBidirectionalBinding implementation is selected. The only meaningful difference between the specialized classes and TypedGenericBidirectionalBinding seems to be an attempt to avoid boxing conversions by replacing the generic property1.setValue(newValue) with variations of the following code: property1.set(newValue.doubleValue()) However, if I'm not mistaken, this doesn't prevent any boxing conversion, thus rendering all of the specialized binding classes useless: 1. All of these classes implement the ChangeListener interface, which provides the changed(ObservableValue, T oldValue, T newValue) method. 2. Calling this method will box both 'oldValue' and 'newValue' parameters if the values come from a primitive property type like DoubleProperty, FloatProperty, etc. 3. Since both parameters are already boxed, the attempt to use 'set(newValue.doubleValue())' yields no advantage compared to just calling 'setValue(newValue)'. If the purpose was indeed to prevent boxing conversions, these classes would need to implement InvalidationListener, not ChangeListener. From fastegal at openjdk.java.net Tue Sep 29 09:53:26 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 29 Sep 2020 09:53:26 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: References: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> <5BDq3WXflNNJ8C_gRTWqrmeSi_28kLvdxNnLhPr5LlY=.b473d1c1-3536-427a-a4e6-0e9c1e75d7e7@github.com> Message-ID: <-KM7qbZC2OCmEGlSd4sHXd9munDFd5i0in4x1kUX_rA=.c5dd4371-3bc5-47ee-95ce-19d9b641c7e4@github.com> On Sat, 26 Sep 2020 08:38:50 GMT, yosbits wrote: > > > @kleopatra > TextArea setSkin is not supported. Therefore, there is no existing application that depends on it. I can't write > additional tests for incomplete implementations (it always fails). what a fancy excuse to not write tests *chuckling Assuming you mean [JDK-8244419](https://bugs.openjdk.java.net/browse/JDK-8244419): the way round could be to comment the unconditional exception throwing in dispose, write tests against your change that fail before your change and pass after. I'm aware that might be difficult, given that there is no cleanup whatever - but should be tried, ast least :). At the end, mark them with Ignore("8244419") and uncomment the exception throwing in dispose again. ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From github.com+7517141+yososs at openjdk.java.net Tue Sep 29 15:32:03 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Tue, 29 Sep 2020 15:32:03 GMT Subject: RFR: 8090110: Very bad TextArea of performance in a language environment that uses the Chinese character (KANJI) In-Reply-To: <-KM7qbZC2OCmEGlSd4sHXd9munDFd5i0in4x1kUX_rA=.c5dd4371-3bc5-47ee-95ce-19d9b641c7e4@github.com> References: <86UJqGYdrlV361I2fsisdWWMz3Gls4Ma0FznzUOU8WM=.e80d9ae2-7d96-4c5f-9ca7-851f2a04075c@github.com> <5BDq3WXflNNJ8C_gRTWqrmeSi_28kLvdxNnLhPr5LlY=.b473d1c1-3536-427a-a4e6-0e9c1e75d7e7@github.com> <-KM7qbZC2OCmEGlSd4sHXd9munDFd5i0in4x1kUX_rA=.c5dd4371-3bc5-47ee-95ce-19d9b641c7e4@github.com> Message-ID: On Tue, 29 Sep 2020 09:51:06 GMT, Jeanette Winzenburg wrote: >> Added the **Next Step** paragraph to the PR overview. >> >> I think it is necessary to judge this step before fixing the resource leak. The existing code is an incomplete >> implementation of dispose, assuming the development of MULTIPLE NODES mode. >> @kleopatra >> TextArea setSkin is not supported. Therefore, there is no existing application that depends on it. I can't write >> additional tests for incomplete implementations (it always fails). > >> >> >> @kleopatra >> TextArea setSkin is not supported. Therefore, there is no existing application that depends on it. I can't write >> additional tests for incomplete implementations (it always fails). > > what a fancy excuse to not write tests *chuckling > > Assuming you mean [JDK-8244419](https://bugs.openjdk.java.net/browse/JDK-8244419): the way round could be to comment > the unconditional exception throwing in dispose, write tests against your change that fail before your change and pass > after. I'm aware that might be difficult, given that there is no cleanup whatever - but should be tried, ast least :). > At the end, mark them with Ignore("8244419") and uncomment the exception throwing in dispose again. I understand that some people want support for the **new features** of Skin Swiching. ------------- PR: https://git.openjdk.java.net/jfx/pull/307 From github.com+1413266+jgneff at openjdk.java.net Tue Sep 29 19:50:24 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 29 Sep 2020 19:50:24 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2] In-Reply-To: References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> Message-ID: On Mon, 21 Sep 2020 18:34:29 GMT, John Neffenger wrote: >> Based on my notes below, I believe this change is safe for any Linux input device driver because the driver shouldn't >> receive the intermediate *open* and *close* calls at all. >> Nonetheless, it would be reassuring if someone could try [this change](https://github.com/openjdk/jfx/pull/258/files) >> just once on a mainstream device, such as the Raspberry Pi with a touchscreen LCD panel. I only have six obscure ARM >> devices and a headless QEMU ARM virtual machine for testing. @johanvos or @dellgreen - Is that something you could >> test? If you think it's overkill and not worth it, that's fine, too. #### Notes >> The Linux kernel documentation about [opening and >> closing](https://www.kernel.org/doc/html/latest/input/input-programming.html#dev-open-and-dev-close) input devices >> states: >>> Note that input core keeps track of number of users for the device and makes sure that dev->open() is called only when >>> the first user connects to the device and that dev->close() is called when the very last user disconnects. Calls to >>> both callbacks are serialized. >> >> Also, the Linux Programmer's Manual for the *close* system call (`man 2 close`) states: >> >>> If *fd* is the last file descriptor referring to the underlying open file description (see **open**(2)), the resources >>> associated with the open file description are freed. >> >> Running a JavaFX program with `strace -f -e trace=open,close -o strace.log` shows the one *open* for the *event0* >> keyboard, and the *open, open, close* for the *event1* touchscreen: >> 5847 open("/dev/input/event0", O_RDONLY) = 11 >> ... >> 5847 open("/dev/input/event1", O_RDONLY) = 12 >> 5847 open("/dev/input/event1", O_RDONLY) = 13 >> 5847 close(13) = 0 >> >> Both devices are actually closed by the kernel when the JavaFX program ends. > >> Nonetheless, it would be reassuring if someone could try [this change](https://github.com/openjdk/jfx/pull/258/files) >> just once on a mainstream device, such as the Raspberry Pi with a touchscreen LCD panel. > > I just placed an order for a Raspberry Pi 2 Model B -- the older model with the 32-bit ARMv7-A architecture. It's the > oldest, slowest, and coolest-running Raspberry Pi supported by Ubuntu, and it's also the closest match to the > processors found in devices with e-paper displays. The Raspberry Pi should finally let me test changes like this to the > Linux Monocle platform on which the EPD platform is based. I may eventually add a touchscreen, but I'm hoping to get by > with just the mouse for now. @johanvos, would you mind approving this pull request again? It looks as if your prior approval was removed when I merged the master branch. All of the tests I ran this week worked as expected and are described below. ### Tests I ran additional tests on the following devices after merging the master branch: * Kobo Touch Model N905C, * Kobo Glo HD Model N437, and * Raspberry Pi 2 Model B. I ran the tests: * without this fix and without the workaround, * with this fix but without the workaround, * with this fix and with the workaround (representing this pull request). The workaround is the code in `EPDInputDeviceRegistry.createDevice` that lets the current JavaFX 15 release avoid the problem even without this fix. The goal of this pull request is to be able eventually to remove the `EPDInputDeviceRegistry` subclass entirely. The test results are shown below. The system call trace was captured with the following command using the [epd-javafx][1] application. $ sudo strace -f -e trace=open,openat,close -o strace.log \ bin/run.sh --pattern=3 --loops=1 **Note:** In the messages below from the kernel ring buffer, the final two lines with `zforce_i2c_close` and `Deactivate` are printed when the program terminates. That call made by the kernel on behalf of the program is not recorded in the program's system call trace. ### Kobo Touch Model N905C This device has the "command overrun" bug. #### Without fix, without workaround The system call trace shows: 3576 open("/dev/input/event1", O_RDONLY) = 12 3576 close(12) = 0 3576 open("/dev/input/event1", O_RDONLY) = 12 The error occurs, and the touchscreen is disabled: $ dmesg | grep -i zforce [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() [zForce_ir_touch_recv_data-145] command Activate (0) ... [zForce_ir_touch_recv_data-154] command Resolution (0) ... [zForce_ir_touch_recv_data-179] command Frequency (0) ... [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() [zForce_ir_touch_recv_data-142] command Deactivate ... [zForce_ir_touch_recv_data-198] command overrun (8) ... [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() [zForce_ir_touch_recv_data-142] command Deactivate ... #### With fix, without workaround The system call trace shows: 3997 open("/dev/input/event1", O_RDONLY) = 12 3997 open("/dev/input/event1", O_RDONLY) = 13 3997 close(13) = 0 The error does not occur, and the touchscreen works as expected: $ dmesg | grep -i zforce [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() [zForce_ir_touch_recv_data-145] command Activate (0) ... [zForce_ir_touch_recv_data-154] command Resolution (0) ... [zForce_ir_touch_recv_data-179] command Frequency (0) ... [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() [zForce_ir_touch_recv_data-142] command Deactivate ... #### With fix, with workaround The system call trace shows the additional *open* call due to the workaround: 4123 open("/dev/input/event1", O_RDONLY) = 13 4123 open("/dev/input/event1", O_RDONLY) = 14 4123 open("/dev/input/event1", O_RDONLY) = 15 4123 close(15) = 0 The error does not occur, and the touchscreen works as expected: $ dmesg | grep -i zforce [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() [zForce_ir_touch_recv_data-145] command Activate (0) ... [zForce_ir_touch_recv_data-154] command Resolution (0) ... [zForce_ir_touch_recv_data-179] command Frequency (0) ... [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() [zForce_ir_touch_recv_data-142] command Deactivate ... ### Kobo Glo HD Model N437 This device does not have the "command overrun" bug. #### Without fix, without workaround The system call trace shows: 3396 open("/dev/input/event1", O_RDONLY) = 11 3396 close(11) = 0 3396 open("/dev/input/event1", O_RDONLY) = 11 The error does not occur, and the touchscreen works as expected: $ dmesg | grep -i zforce [drivers/input/touchscreen/zforce_i2c.c-740] zforce_i2c_open() [zForce_ir_touch_recv_data-233] command Activate (0) ... ... [zForce_ir_touch_recv_data-250] command Resolution (0) ... [zForce_ir_touch_recv_data-278] command Frequency (0) ... [zForce_ir_touch_recv_data-260] command Configuration ... [drivers/input/touchscreen/zforce_i2c.c-756] zforce_i2c_close() [zForce_ir_touch_recv_data-230] command Deactivate ... #### With fix, without workaround The system call trace shows: 3620 open("/dev/input/event1", O_RDONLY) = 15 3620 open("/dev/input/event1", O_RDONLY) = 16 3620 close(16) = 0 The error does not occur, and the touchscreen works as expected: $ dmesg | grep -i zforce [drivers/input/touchscreen/zforce_i2c.c-740] zforce_i2c_open() [zForce_ir_touch_recv_data-233] command Activate (0) ... ... [zForce_ir_touch_recv_data-250] command Resolution (0) ... [zForce_ir_touch_recv_data-278] command Frequency (0) ... [zForce_ir_touch_recv_data-260] command Configuration ... [drivers/input/touchscreen/zforce_i2c.c-756] zforce_i2c_close() [zForce_ir_touch_recv_data-230] command Deactivate ... #### With fix, with workaround The system call trace shows the additional *open* call due to the workaround: 3913 open("/dev/input/event1", O_RDONLY) = 18 3913 open("/dev/input/event1", O_RDONLY) = 19 3913 open("/dev/input/event1", O_RDONLY) = 20 3913 close(20) = 0 The error does not occur, and the touchscreen works as expected: $ dmesg | grep -i zforce [drivers/input/touchscreen/zforce_i2c.c-740] zforce_i2c_open() [zForce_ir_touch_recv_data-233] command Activate (0) ... ... [zForce_ir_touch_recv_data-250] command Resolution (0) ... [zForce_ir_touch_recv_data-278] command Frequency (0) ... [zForce_ir_touch_recv_data-260] command Configuration ... [drivers/input/touchscreen/zforce_i2c.c-756] zforce_i2c_close() [zForce_ir_touch_recv_data-230] command Deactivate ... ### Raspberry Pi 2 Model B This device has a normal mouse rather than a touchscreen. #### Without fix, without workaround The system call trace shows: 19407 openat(AT_FDCWD, "/dev/input/event0", O_RDONLY) = 18 There is no output to the kernel ring buffer, and the mouse (event0) works as expected. #### With fix, without workaround The system call trace shows: 19548 openat(AT_FDCWD, "/dev/input/event0", O_RDONLY) = 18 There is no output to the kernel ring buffer, and the mouse (event0) works as expected. #### With fix, with workaround The system call trace shows: 19802 openat(AT_FDCWD, "/dev/input/event0", O_RDONLY) = 18 There is no output to the kernel ring buffer, and the mouse (event0) works as expected. [1]: https://github.com/jgneff/epd-javafx ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From kcr at openjdk.java.net Tue Sep 29 23:39:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Sep 2020 23:39:21 GMT Subject: RFR: 8252191: Update to gcc 10.2 on Linux Message-ID: This patch updates the compiler to gcc 10.2 on Linux, in order to match JDK 16 -- see [JDK-8253616](https://bugs.openjdk.java.net/browse/JDK-8253616). I ran a full build and test, including media and WebKit. ------------- Commit messages: - 8252191: Update to gcc 10.2 on Linux Changes: https://git.openjdk.java.net/jfx/pull/311/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=311&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252191 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/311.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/311/head:pull/311 PR: https://git.openjdk.java.net/jfx/pull/311 From kcr at openjdk.java.net Tue Sep 29 23:44:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 29 Sep 2020 23:44:00 GMT Subject: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 Message-ID: This patch updates the compiler to Visual Studio 2019 version 16.7.2 on Windows, in order to match JDK 16 -- see [JDK-8253615](https://bugs.openjdk.java.net/browse/JDK-8253615). I ran a full build and test, including media and WebKit. ------------- Commit messages: - 8252192: Update to Visual Studio 2019 version 16.7.2 Changes: https://git.openjdk.java.net/jfx/pull/312/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=312&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252192 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/312.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/312/head:pull/312 PR: https://git.openjdk.java.net/jfx/pull/312 From fkirmaier at openjdk.java.net Wed Sep 30 11:46:24 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 30 Sep 2020 11:46:24 GMT Subject: RFR: 8244297: memory leak test utility [v5] In-Reply-To: References: Message-ID: > It's based on the discussion of my previous PR: https://github.com/openjdk/jfx/pull/71 > > I Added test utility class copied from JMemoryBuddy and used it to simplify 4 of the existing unit tests. > > It's a direct copy of my project [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy) without any changes. > I'm also using it in most of the projects I'm involved with and in my experience, the tests with this Library are very > stable. I can't remember wrong test results. Sometimes the memory behaviour of some libraries itself is not stable but > the tests with JMemoryBuddy are basically always correct. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8244297 Fixing some wrong imports ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/204/files - new: https://git.openjdk.java.net/jfx/pull/204/files/08528777..adc870cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=204&range=03-04 Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/204/head:pull/204 PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Wed Sep 30 11:46:25 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 30 Sep 2020 11:46:25 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 07:07:07 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8244297 >> Improved the JavaDoc for JMemoryBuddy > > Tests fail to compile, please correct the import. > Pointed error in `ToggleButtonTest`, please check other files also when correcting this. I've fixed the wrong imports. It would be great if Travis could check whether all systemTests are compiling. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ToggleButtonTest.java line 45: > >> 43: import org.junit.Before; >> 44: import org.junit.Test; >> 45: import de.sandec.jmemorybuddy.JMemoryBuddy; > > Throws compilation error: package de.sandec.jmemorybuddy does not exist fixed > modules/javafx.controls/src/test/java/test/javafx/scene/control/ToggleButtonTest.java line 161: > >> 159: >> 160: @Test public void toggleGroupViaGroupAddAndRemoveClearsReference() { >> 161: JMemoryBuddy.memoryTest(checker -> { > > Compilation error: cannot find symbol JMemoryBuddy fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Wed Sep 30 12:39:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Sep 2020 12:39:35 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: References: Message-ID: <2-4P8pUbsWMYD2cYtyraM1Kw1VAQJjw4Bhg-B1YMhlw=.09cf1de1-f281-4c49-9ae0-53f1c24599dd@github.com> On Wed, 30 Sep 2020 11:43:34 GMT, Florian Kirmaier wrote: >> Tests fail to compile, please correct the import. >> Pointed error in `ToggleButtonTest`, please check other files also when correcting this. > > I've fixed the wrong imports. It would be great if Travis could check whether all systemTests are compiling. Thanks, we'll review it now. Btw, we don't plan to hook up Travis, but instead will be looking at GitHub actions now that the `jdk` project is using them successfully. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Wed Sep 30 12:57:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Sep 2020 12:57:54 GMT Subject: RFR: 8251946: ObservableList.setAll does not conform to specification [v4] In-Reply-To: <0UXvqSHXhA9KxweOoUbiLLgk_M919soTNP_O3-1qPyI=.e82aa5ac-919a-4e73-8d42-681f6e676541@github.com> References: <0UXvqSHXhA9KxweOoUbiLLgk_M919soTNP_O3-1qPyI=.e82aa5ac-919a-4e73-8d42-681f6e676541@github.com> Message-ID: On Sat, 26 Sep 2020 16:04:16 GMT, Leon Linhart wrote: >> Hi, this PR fixes [JDK-8251946](https://bugs.openjdk.java.net/browse/JDK-8251946) computing whether the list was >> actually modified instead of just returning `true`. The list was modified if 1. it was not empty (modified by calling >> `#clear()`), or if 2. it was modified as result of the `#addAll()` call. >> >> If you want any test coverage for this please let me know. >> >> I reported the issue a couple of days ago via web formula and waited for the confirmation to open this PR but now I see >> that @kevinrushforth (sorry for pinging) is already assigned to the JBS issue. I'm not too familiar with how you handle >> JBS issues or more specifically whether assigning is used to indicate that the issue is in the assignee's "domain", or >> that the assignee is already working on it. In the latter case, please feel free to close this PR. (My OCA submission >> is still pending anyway.) > > Leon Linhart has updated the pull request incrementally with one additional commit since the last revision: > > Test return value of setAll on an empty list Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/284 From kcr at openjdk.java.net Wed Sep 30 18:42:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Sep 2020 18:42:07 GMT Subject: RFR: 8169501: GIF animation is too fast In-Reply-To: <1SYEtVlOUYtRfxjBOUMRCptchjizzMF93Fh7h-iSOqI=.663c8e72-d60c-4eef-b69c-74c77c84ba0b@github.com> References: <1SYEtVlOUYtRfxjBOUMRCptchjizzMF93Fh7h-iSOqI=.663c8e72-d60c-4eef-b69c-74c77c84ba0b@github.com> Message-ID: On Sat, 19 Sep 2020 17:02:44 GMT, Kevin Rushforth wrote: >>> >>> >>> Is this related to https://bugs.openjdk.java.net/browse/JDK-8209560? >> >> it seems not. > > Using the images you posted above, it appears that the browsers (Firefox and Edge on Windows, Firefox and Safari on > Mac) have a threshold of 20ms, not 51 ms. Looks like the formula should be > delay < 20 : set to 100 > delay >= 20 : use the value as is > > Your fix does make the 19 ms image match the browsers (whereas existing WebView is too fast), but the 20ms, 21ms, and > 40ms images no longer do (they are fine in the existing WebVIew and too slow with your patch). > So I recommend changing the value to 20 and then re-testing. This PR is on hold. It can be reopened or a new PR can be sent as and when it is ready to proceed. ------------- PR: https://git.openjdk.java.net/jfx/pull/221 From bchoudhary at openjdk.java.net Wed Sep 30 18:42:08 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 30 Sep 2020 18:42:08 GMT Subject: Withdrawn: 8169501: GIF animation is too fast In-Reply-To: References: Message-ID: On Fri, 15 May 2020 07:42:40 GMT, Bhawesh Choudhary wrote: > issue is caused by the threshold value for frame duration used by javaFx before it gets normalized. JavaFx is using > threshold value 10 while other browser (Safari, Firefox) is using 50 due to which, value between 10 and 50 don't get > normalized and animation runs at faster speed. To fix the issue change frame duration normalization value to <= 50. > Safari : https://bugs.webkit.org/show_bug.cgi?id=14413 Firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=386269 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/221 From kcr at openjdk.java.net Wed Sep 30 18:42:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Sep 2020 18:42:38 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v13] In-Reply-To: References: Message-ID: <9BE6UJNwyB130Ne3XzilY1nao3NQAYM8xTAtm7Gepv0=.55eb9a8c-6d64-488d-9014-9afcd25176ab@github.com> On Thu, 17 Sep 2020 06:35:16 GMT, Arun Joseph wrote: >> The fix works when the shape is displayed initially on the screen, but fails when we scroll the image off-screen and >> then, back. To see the issue, you need to either rotate the gradient transform (by 90 degrees) or use a circle (any >> shape other than a rectangle) as the mask shape, as this bug can't be seen using a mask rectangle. > > To reproduce the above issue, you can either modify `` or > ` ` in `svgMask.html` and resize the > window for scrolling. This PR is on hold. It can be reopened or a new PR can be sent as and when it is ready to proceed. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Wed Sep 30 18:42:38 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 30 Sep 2020 18:42:38 GMT Subject: Withdrawn: 8218973: SVG with masking is not rendering image with mask effect In-Reply-To: References: Message-ID: On Thu, 7 May 2020 09:19:28 GMT, Bhawesh Choudhary wrote: > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/213