From arapte at openjdk.java.net Sun Nov 1 10:29:51 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sun, 1 Nov 2020 10:29:51 GMT Subject: RFR: 8253634: TreeCell/Skin: misbehavior on switching skin In-Reply-To: <9d4VS8CCZTJ-8dosR1FEWkS1gi870X_aIu29GW6xJbo=.f0d842db-67ff-493a-9ae8-a91412d2bba9@github.com> References: <9d4VS8CCZTJ-8dosR1FEWkS1gi870X_aIu29GW6xJbo=.f0d842db-67ff-493a-9ae8-a91412d2bba9@github.com> Message-ID: On Fri, 25 Sep 2020 11:10:20 GMT, Jeanette Winzenburg wrote: > 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) As @kleopatra has already mentioned it that Issue and fix is basically the same as for ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745). It looks good... ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/309 From fastegal at openjdk.java.net Sun Nov 1 13:54:53 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 1 Nov 2020 13:54:53 GMT Subject: Integrated: 8253634: TreeCell/Skin: misbehavior on switching skin In-Reply-To: <9d4VS8CCZTJ-8dosR1FEWkS1gi870X_aIu29GW6xJbo=.f0d842db-67ff-493a-9ae8-a91412d2bba9@github.com> References: <9d4VS8CCZTJ-8dosR1FEWkS1gi870X_aIu29GW6xJbo=.f0d842db-67ff-493a-9ae8-a91412d2bba9@github.com> Message-ID: On Fri, 25 Sep 2020 11:10:20 GMT, Jeanette Winzenburg wrote: > 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) This pull request has now been integrated. Changeset: cb545cc6 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/cb545cc6 Stats: 101 lines in 4 files changed: 60 ins; 36 del; 5 mod 8253634: TreeCell/Skin: misbehavior on switching skin Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/309 From tsayao at openjdk.java.net Mon Nov 2 01:14:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 2 Nov 2020 01:14:02 GMT Subject: RFR: 8237491: Maximized undecorated stage behaves inconsistently on different platforms (fix for Linux) Message-ID: Simple fix to enable maximizing functionality on the window manager. Test provided gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.stage.MaximizeUndecorated ------------- Commit messages: - Change copyright year - Enable maximize functionality when maximizing - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - Merge pull request #11 from openjdk/master - Merge pull request #10 from openjdk/master - Merge pull request #9 from openjdk/master - Merge pull request #8 from openjdk/master - Merge pull request #7 from openjdk/master - Merge pull request #6 from openjdk/master - ... and 2 more: https://git.openjdk.java.net/jfx/compare/cb545cc6...821e9ad2 Changes: https://git.openjdk.java.net/jfx/pull/345/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=345&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237491 Stats: 96 lines in 2 files changed: 96 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/345.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/345/head:pull/345 PR: https://git.openjdk.java.net/jfx/pull/345 From tsayao at openjdk.java.net Mon Nov 2 01:25:59 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 2 Nov 2020 01:25:59 GMT Subject: RFR: 8255723: Gtk glass backend should run with Gtk+ 3.8 (minimum) Message-ID: Simple fix to not build with GTK+ greater than 3.8 symbols. ------------- Commit messages: - Fix minimum GTK version (glass DND) - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - Merge pull request #11 from openjdk/master - Merge pull request #10 from openjdk/master - Merge pull request #9 from openjdk/master - Merge pull request #8 from openjdk/master - Merge pull request #7 from openjdk/master - Merge pull request #6 from openjdk/master - Merge pull request #5 from openjdk/master - ... and 1 more: https://git.openjdk.java.net/jfx/compare/cb545cc6...4f589df9 Changes: https://git.openjdk.java.net/jfx/pull/346/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=346&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255723 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/346.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/346/head:pull/346 PR: https://git.openjdk.java.net/jfx/pull/346 From wiverson at gmail.com Mon Nov 2 01:38:42 2020 From: wiverson at gmail.com (Will Iverson) Date: Sun, 1 Nov 2020 17:38:42 -0800 Subject: Taskbar API from JavaFX Window? Message-ID: Looking at native desktop integration with JavaFX. As I was exploring, I noticed that the java.awt.Taskbar API does not appear to be available for JavaFX Windows. https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State) Many of the other methods on this class (e.g. setting progress, custom icons) work fine on macOS from my testing so far. Is there any way to use the AWT methods from a JavaFX app? Cheers, -Will From swpalmer at gmail.com Mon Nov 2 01:48:53 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 1 Nov 2020 20:48:53 -0500 Subject: Taskbar API from JavaFX Window? In-Reply-To: References: Message-ID: <5B85B348-5A75-43EC-B559-5AB6F242EF5A@gmail.com> They work fine. Just remember to use the Swing/AWT event thread to call them. Scott > On Nov 1, 2020, at 8:39 PM, Will Iverson wrote: > > ?Looking at native desktop integration with JavaFX. As I was exploring, I > noticed that the java.awt.Taskbar API does not appear to be available for > JavaFX Windows. > > https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State) > > Many of the other methods on this class (e.g. setting progress, custom > icons) work fine on macOS from my testing so far. > > Is there any way to use the AWT methods from a JavaFX app? > > Cheers, > -Will From fastegal at swingempire.de Mon Nov 2 12:11:07 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 02 Nov 2020 13:11:07 +0100 Subject: compile errors around JMemoryBuddy Message-ID: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> just fetched the latest upstream master and getting compile errors around xx.management packages (eclipse wants to add requires into the module-info - which certainly is the wrong way to go ;) Compiling against jdk12, if that matters (will update one of these days but shouldn't jdk11 be good enough). Any quick ideas on what might be wrong? -- Jeanette From fastegal at openjdk.java.net Mon Nov 2 12:16:56 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 2 Nov 2020 12:16:56 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v5] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda wrote: >> As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. >> >> This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. >> >> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. >> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). >> With the proposed fix, it doesn't fail at all. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Apply fix to snapPortionXX methods, extend test. not the requested reviewer, but this looks good to me :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/336 From fastegal at swingempire.de Mon Nov 2 12:44:00 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 02 Nov 2020 13:44:00 +0100 Subject: compile errors around JMemoryBuddy In-Reply-To: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> Message-ID: <20201102134400.Horde.Vw_HyE3A7eKG8lOAyGdO_g1@webmail.df.eu> seems to be an Eclipse problem, compiling (and running tests in controls) via gradle on commandline looks okay .. Zitat von Jeanette Winzenburg : > just fetched the latest upstream master and getting compile errors > around xx.management packages (eclipse wants to add requires into > the module-info - which certainly is the wrong way to go ;) > Compiling against jdk12, if that matters (will update one of these > days but shouldn't jdk11 be good enough). > > Any quick ideas on what might be wrong? > > -- Jeanette From kcr at openjdk.java.net Mon Nov 2 12:52:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Nov 2020 12:52:59 GMT Subject: RFR: 8255714: Switch FX build to use JDK 15.0.1 as boot JDK Message-ID: Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the minimum boot JDK which remains at JDK 11. ------------- Commit messages: - 8255714: Switch FX build to use JDK 15.0.1 as boot JDK Changes: https://git.openjdk.java.net/jfx/pull/347/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=347&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255714 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/347.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/347/head:pull/347 PR: https://git.openjdk.java.net/jfx/pull/347 From kevin.rushforth at oracle.com Mon Nov 2 12:59:33 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 2 Nov 2020 04:59:33 -0800 Subject: compile errors around JMemoryBuddy In-Reply-To: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> Message-ID: <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> I didn't try it with an earlier JDK, but if it breaks when using JDK 11 it will need to be fixed. -- Kevin On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote: > > just fetched the latest upstream master and getting compile errors > around xx.management packages (eclipse wants to add requires into the > module-info - which certainly is the wrong way to go ;) Compiling > against jdk12, if that matters (will update one of these days but > shouldn't jdk11 be good enough). > > Any quick ideas on what might be wrong? > > -- Jeanette > > From jvos at openjdk.java.net Mon Nov 2 13:09:53 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 Nov 2020 13:09:53 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v5] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda wrote: >> As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. >> >> This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. >> >> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. >> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). >> With the proposed fix, it doesn't fail at all. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Apply fix to snapPortionXX methods, extend test. Looks good now. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/336 From nmrview at mac.com Mon Nov 2 13:18:42 2020 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 2 Nov 2020 08:18:42 -0500 Subject: GraphicsContext and export to vector format files Message-ID: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. It would be much simpler if 1) GraphicsContext was not final and could be extended. or 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. ? Bruce From herve.girod at gmail.com Mon Nov 2 13:51:22 2020 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Mon, 2 Nov 2020 14:51:22 +0100 Subject: GraphicsContext and export to vector format files In-Reply-To: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> Message-ID: <0F9FF0E4-451B-4DFA-9326-03D4213A30BF@gmail.com> Hello, Ivhabe created some time ago an OpenSource project called jfcClnvertercwhichvtefurect the Jz aFX calls to a Graphics2D context. I don?t know if it answers at least partially to this need. The project is here: https://sourceforge.net/projects/jfxconverter/ Herv? Sent from my iPhone > On Nov 2, 2020, at 14:19, Bruce Johnson wrote: > > ? > A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. > > These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). > > The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. > > This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). > > I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. > > This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. > > It would be much simpler if > 1) GraphicsContext was not final and could be extended. > or > 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. > > Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. > > If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. > > ? Bruce > From nmrview at mac.com Mon Nov 2 14:04:49 2020 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 2 Nov 2020 09:04:49 -0500 Subject: GraphicsContext and export to vector format files In-Reply-To: <0F9FF0E4-451B-4DFA-9326-03D4213A30BF@gmail.com> References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> <0F9FF0E4-451B-4DFA-9326-03D4213A30BF@gmail.com> Message-ID: Looks like a nice and useful project! But,I?m looking for something specific to the JavaFX canvas and that doesn?t require use of java.awt. There are many examples of code that has been built on top of java.awt.Graphics2D (like yours), but this doesn?t seem to be possible with the JavaFX GraphicsContext. I think some small changes within JavaFX would allow a lot of nice tools to be developed in a way similar to what was done with Graphics2D. Bruce > On Nov 2, 2020, at 8:51 AM, Herv? Girod wrote: > > Hello, Ivhabe created some time ago an OpenSource project called jfcClnvertercwhichvtefurect the Jz aFX calls to a Graphics2D context. I don?t know if it answers at least partially to this need. The project is here: https://sourceforge.net/projects/jfxconverter/ > > Herv? > > Sent from my iPhone > >> On Nov 2, 2020, at 14:19, Bruce Johnson wrote: >> >> ? >> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >> >> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >> >> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >> >> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >> >> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >> >> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >> >> It would be much simpler if >> 1) GraphicsContext was not final and could be extended. >> or >> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >> >> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >> >> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >> >> ? Bruce >> From kcr at openjdk.java.net Mon Nov 2 14:14:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 2 Nov 2020 14:14:55 GMT Subject: RFR: 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 16:04:51 GMT, Ambarish Rapte wrote: > Each test in RegionBackgroundImageUITest makes several calls to `robot.getPixelColor()` on App thread. Due to this each test requires more than **60** seconds for execution. > > Fix is to save a screen capture of Scene (on App thread) and then read pixel color from the screen capture(not on app thread). This reduces execution time of each test to less than **3** seconds. > Ideally with this fix(commit#1) all the tests should pass. All tests do pass on Windows and Linux but three tests fail on Mac, which used to pass without this change. > - RegionBackgroundImageUITest.unalignedImage > - RegionBackgroundFillUITest.testScenario2 > - RegionBackgroundFillUITest.testScenario3 > > commit#2 solves the above problem. Solution is to fallback to test color again by reading it using `robot.getPixelColor()` on App thread when a test fails. > > One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac platform, before and after this fix. > It is reported as a new issue [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679) > > This is a test fix and affects only the tests that extend from `RegionUITestBase` test class and does not affect other tests. > Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` tests pass on all three platforms(except RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac). The fact that you needed to implement a fallback to `Robot::getPixelColor` if reading a pixel from the buffer obtained by `Robot::getScreenCapture` fails (on Mac) suggests that `RegionBackgroundImageUITest` has some issues running on HiDPI displays. It also points out that there is a difference between the scaling algorithm used to read a single pixel vs an array of pixels (this might be a bug in Robot itself). I confirmed the fact that these problems are related to HiDPI scaling by running it on my Windows 10 system with 125% scaling, and I get 30 test failures. I instrumented the code and I see a couple hundred fallbacks per test even for the non-failing tests. If I force screen scale to 1 on Windows then all tests pass with no fallbacks. We used to have this problem for some of the tests in `RegionBackgroundFillUITest` as well. The fix for [JDK-8170026](https://bugs.openjdk.java.net/browse/JDK-8170026) addressed this by skipping the tests that were sensitive to screen scale (14 of them). You either need to do something similar for `RegionBackgroundImageUITest` or else fix the tests to work with different screen scales (this would be challenging). ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/344 From mp at jugs.org Mon Nov 2 14:17:15 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 2 Nov 2020 15:17:15 +0100 Subject: GraphicsContext and export to vector format files In-Reply-To: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> Message-ID: Hi, I very much like the idea in general but I think it falls too short. Such an interface should not be tied to any existing graphics framework. Instead it should be just pure Java. This would allow to write complex graphics rendering code for a lot of different platforms and not only platforms where JavaFX already exists and can be used. Just think of the Android canvas or, via cross- compilation, even the HTML 5 canvas. Just my two ?ent. Michael Am 02.11.20 um 14:18 schrieb Bruce Johnson: > A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. > > These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). > > The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. > > This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). > > I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. > > This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. > > It would be much simpler if > 1) GraphicsContext was not final and could be extended. > or > 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. > > Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. > > If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. > > ? Bruce > From nmrview at mac.com Mon Nov 2 14:37:35 2020 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 2 Nov 2020 09:37:35 -0500 Subject: GraphicsContext and export to vector format files In-Reply-To: References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> Message-ID: <44D0F85F-DCB4-4321-806A-492B1BFBBAC9@mac.com> I think were? not too far different in our ideas, but I think the practical odds of getting this implemented are much higher if the existing GraphicsContext methods are the base for the interface I propose. I think (but could be wrong) that in fact the GraphicsContext was modeled after the HTML 5 canvas so in that sense it forms a good base for what you suggest. One could write code that drew to the Canvas, to an HTML 5 canvas, to graphics files etc. It?s just that now, with GraphicsContext being a final class rather than non-final or an interface, one can?t do any of this. Bruce > On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: > > Hi, > I very much like the idea in general but I think it falls too short. > Such an interface should not be tied to any existing graphics > framework. Instead it should be just pure Java. This would allow > to write complex graphics rendering code for a lot of different > platforms and not only platforms where JavaFX already exists > and can be used. Just think of the Android canvas or, via cross- > compilation, even the HTML 5 canvas. > Just my two ?ent. > Michael > > Am 02.11.20 um 14:18 schrieb Bruce Johnson: >> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >> >> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >> >> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >> >> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >> >> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >> >> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >> >> It would be much simpler if >> 1) GraphicsContext was not final and could be extended. >> or >> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >> >> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >> >> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >> >> ? Bruce >> > From nmrview at mac.com Mon Nov 2 14:42:14 2020 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 2 Nov 2020 09:42:14 -0500 Subject: GraphicsContext and export to vector format files In-Reply-To: References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> Message-ID: And if you want to think of even further advances (which I?d avoid at this point because I?d like this to get done in a useful time frame), I?ve often thought that all JavaFX scene drawing should use the Canvas GraphicsContext. So with the changes I?m suggesting that would allow export of the complete scene graph to another device (vector graphics files etc.) Bruce > On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: > > Hi, > I very much like the idea in general but I think it falls too short. > Such an interface should not be tied to any existing graphics > framework. Instead it should be just pure Java. This would allow > to write complex graphics rendering code for a lot of different > platforms and not only platforms where JavaFX already exists > and can be used. Just think of the Android canvas or, via cross- > compilation, even the HTML 5 canvas. > Just my two ?ent. > Michael > > Am 02.11.20 um 14:18 schrieb Bruce Johnson: >> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >> >> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >> >> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >> >> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >> >> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >> >> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >> >> It would be much simpler if >> 1) GraphicsContext was not final and could be extended. >> or >> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >> >> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >> >> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >> >> ? Bruce >> > From mp at jugs.org Mon Nov 2 14:58:25 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 2 Nov 2020 15:58:25 +0100 Subject: GraphicsContext and export to vector format files In-Reply-To: References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> Message-ID: <694bc47f-fb5b-2413-379d-1ce9b3cde41b@jugs.org> At this point I would disagree with you. Doing so would just result in a sever performance hit. I will not go into the details here because that idea is out of reach anyway. Am 02.11.20 um 15:42 schrieb Bruce Johnson: > And if you want to think of even further advances (which I?d avoid at this point because I?d like this to get done in a useful time frame), I?ve often thought that all JavaFX scene drawing should use the Canvas GraphicsContext. So with the changes I?m suggesting that would allow export of the complete scene graph to another device (vector graphics files etc.) > > Bruce > > >> On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: >> >> Hi, >> I very much like the idea in general but I think it falls too short. >> Such an interface should not be tied to any existing graphics >> framework. Instead it should be just pure Java. This would allow >> to write complex graphics rendering code for a lot of different >> platforms and not only platforms where JavaFX already exists >> and can be used. Just think of the Android canvas or, via cross- >> compilation, even the HTML 5 canvas. >> Just my two ?ent. >> Michael >> >> Am 02.11.20 um 14:18 schrieb Bruce Johnson: >>> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >>> >>> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >>> >>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >>> >>> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >>> >>> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >>> >>> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >>> >>> It would be much simpler if >>> 1) GraphicsContext was not final and could be extended. >>> or >>> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >>> >>> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >>> >>> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >>> >>> ? Bruce >>> From arapte at openjdk.java.net Mon Nov 2 15:59:56 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 2 Nov 2020 15:59:56 GMT Subject: RFR: 8255415: Nested calls to snap methods in Region give different results [v5] In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 13:07:11 GMT, Johan Vos wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply fix to snapPortionXX methods, extend test. > > Looks good now. Please go ahead and integrate with the current approvals. ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From wiverson at gmail.com Mon Nov 2 16:46:29 2020 From: wiverson at gmail.com (Will Iverson) Date: Mon, 2 Nov 2020 08:46:29 -0800 Subject: Taskbar API from JavaFX Window? In-Reply-To: <5B85B348-5A75-43EC-B559-5AB6F242EF5A@gmail.com> References: <5B85B348-5A75-43EC-B559-5AB6F242EF5A@gmail.com> Message-ID: What Window should I pass in for the setWindowProgressState window argument? It requires a java.awt.Window? On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer wrote: > They work fine. Just remember to use the Swing/AWT event thread to call > them. > > Scott > > > On Nov 1, 2020, at 8:39 PM, Will Iverson wrote: > > > > ?Looking at native desktop integration with JavaFX. As I was exploring, > I > > noticed that the java.awt.Taskbar API does not appear to be available for > > JavaFX Windows. > > > > > https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State) > > > > Many of the other methods on this class (e.g. setting progress, custom > > icons) work fine on macOS from my testing so far. > > > > Is there any way to use the AWT methods from a JavaFX app? > > > > Cheers, > > -Will > From florian.kirmaier at gmail.com Mon Nov 2 17:26:48 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Mon, 2 Nov 2020 18:26:48 +0100 Subject: compile errors around JMemoryBuddy In-Reply-To: <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> Message-ID: Eclipse probably handles the modules differently than Gradle. The simplest solution would be to remove the code to automatically create heap dumps. Adding java.management to module-info of the tests doesn't sound wrong to me if it's using it. On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth wrote: > I didn't try it with an earlier JDK, but if it breaks when using JDK 11 > it will need to be fixed. > > -- Kevin > > > On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote: > > > > just fetched the latest upstream master and getting compile errors > > around xx.management packages (eclipse wants to add requires into the > > module-info - which certainly is the wrong way to go ;) Compiling > > against jdk12, if that matters (will update one of these days but > > shouldn't jdk11 be good enough). > > > > Any quick ideas on what might be wrong? > > > > -- Jeanette > > > > > > From jpereda at openjdk.java.net Mon Nov 2 17:29:55 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 2 Nov 2020 17:29:55 GMT Subject: Integrated: 8255415: Nested calls to snap methods in Region give different results In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 08:32:59 GMT, Jose Pereda wrote: > As discussed in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an already snapped value (either intentionally or by mistake), the result should be the same, otherwise we'll be jumping unnecessary from a valid pixel to another pixel. > > This PR provides a fix to `snapSizeXX` methods used in `Region`, which ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value before ceiling, to ensure snapping a snapped value gives the same value. > > A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 different UI scales is provided. > For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. Only for 1.75 and the random 1.374562997 value fails (the test fails for around 2% of the values with 1.75 and around 10% with 1.374562997). > With the proposed fix, it doesn't fail at all. This pull request has now been integrated. Changeset: c31ed6bf Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/c31ed6bf Stats: 114 lines in 3 files changed: 108 ins; 0 del; 6 mod 8255415: Nested calls to snap methods in Region give different results Reviewed-by: kcr, fastegal, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/336 From jvos at openjdk.java.net Mon Nov 2 19:36:54 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 2 Nov 2020 19:36:54 GMT Subject: RFR: 8255714: Switch FX build to use JDK 15.0.1 as boot JDK In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 12:47:06 GMT, Kevin Rushforth wrote: > Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the minimum boot JDK which remains at JDK 11. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/347 From swpalmer at gmail.com Mon Nov 2 21:29:19 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 2 Nov 2020 16:29:19 -0500 Subject: Taskbar API from JavaFX Window? In-Reply-To: References: <5B85B348-5A75-43EC-B559-5AB6F242EF5A@gmail.com> Message-ID: For that API, you might consider using an AWT root Window with a JFXPanel rather than a JavaFX Window to hold your JavaFX UI. But discussion of how to code the application side is not relevant for this list. For the record here are the relevant JavaFX issues: https://bugs.openjdk.java.net/browse/JDK-8091107 https://bugs.openjdk.java.net/browse/JDK-8091517 If you want to discuss those further, this list might be the right place. Currently JavaFX modules require the java.desktop module, so it doesn't hurt your JRE footprint to use the Swing integration. Hopefully that dependency won't last long though (see https://bugs.openjdk.java.net/browse/JDK-8240844), and perhaps at the point the desktop module dependency is removed, the motivation to implement the above issues will be higher. Cheers, Scott On Mon, Nov 2, 2020 at 11:46 AM Will Iverson wrote: > What Window should I pass in for the setWindowProgressState window > argument? It requires a java.awt.Window? > > On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer wrote: > >> They work fine. Just remember to use the Swing/AWT event thread to call >> them. >> >> Scott >> >> > On Nov 1, 2020, at 8:39 PM, Will Iverson wrote: >> > >> > ?Looking at native desktop integration with JavaFX. As I was >> exploring, I >> > noticed that the java.awt.Taskbar API does not appear to be available >> for >> > JavaFX Windows. >> > >> > >> https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State) >> > >> > Many of the other methods on this class (e.g. setting progress, custom >> > icons) work fine on macOS from my testing so far. >> > >> > Is there any way to use the AWT methods from a JavaFX app? >> > >> > Cheers, >> > -Will >> > From kevin.rushforth at oracle.com Mon Nov 2 22:04:55 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 2 Nov 2020 14:04:55 -0800 Subject: GraphicsContext and export to vector format files In-Reply-To: <694bc47f-fb5b-2413-379d-1ce9b3cde41b@jugs.org> References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> <694bc47f-fb5b-2413-379d-1ce9b3cde41b@jugs.org> Message-ID: Yeah, there is no chance we would consider changing the JavaFX to use Canvas GraphicsContext for scene graph rendering. As for the original question, we are unlikely to make GraphicsContext extensible in the core JavaFX. I think the solution you came up with for your application (with a proxy class and interface) is a reasonable approach. -- Kevin On 11/2/2020 6:58 AM, Michael Paus wrote: > At this point I would disagree with you. Doing so would just > result in a sever performance hit. I will not go into the details > here because that idea is out of reach anyway. > > Am 02.11.20 um 15:42 schrieb Bruce Johnson: >> And if you want to think of even further advances (which I?d avoid at >> this point because I?d like this to get done in a useful time frame), >> I?ve often thought that all JavaFX scene drawing should use the >> Canvas GraphicsContext.? So with the changes I?m suggesting that >> would allow export of the complete scene graph to another device >> (vector graphics files etc.) >> >> Bruce >> >> >>> On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: >>> >>> Hi, >>> I very much like the idea in general but I think it falls too short. >>> Such an interface should not be tied to any existing graphics >>> framework. Instead it should be just pure Java. This would allow >>> to write complex graphics rendering code for a lot of different >>> platforms and not only platforms where JavaFX already exists >>> and can be used. Just think of the Android canvas or, via cross- >>> compilation, even the HTML 5 canvas. >>> Just my two ?ent. >>> Michael >>> >>> Am 02.11.20 um 14:18 schrieb Bruce Johnson: >>>> A variety of packages (for example, VectorGraphics or JFreeSVG) >>>> exist that allow redirecting Java2D drawing to output other than >>>> the Java2D canvas. >>>> >>>> These work by extending java.awt.Graphics2D.? By passing the >>>> extended Graphics2D object into a paint method, output can be >>>> redirected to a file (.svg, .pdf, etc.). >>>> >>>> The GraphicsContext class of JavaFX serves a similar function to >>>> Graphics2D of java.awt, but because it is a final class it cannot >>>> be extended to create similar functionality as found in >>>> VectorgGraphics or JFreeSVG. >>>> >>>> This is a serious limitation (at least as far as I can tell) to >>>> JavaFX applications.? It would be highly desirable to be able to >>>> redirect drawing on a Canvas to other output formats such as vector >>>> graphics files (.svg, .pdf etc.). >>>> >>>> I currently work around this by using composition.? I have a Java >>>> interface that has most methods of GraphicsContext. Then a >>>> GraphicsContextProxy class implements the interface and contains an >>>> instance of GraphicsContext.? This class is used for drawing to the >>>> Canvas.? I?ve then created a SVGGraphicsContext and >>>> PDFGraphicsContext that implement the interface and these can be >>>> used to draw to .svg or .pdf files. >>>> >>>> This works, but means that all code that draws on the canvas has to >>>> be rewritten to take the GraphicsContextInterface rather than the >>>> normal GraphicsContext. >>>> >>>> It would be much simpler if >>>> ????1) GraphicsContext was not final and could be extended. >>>> ????or >>>> ????2) A GraphicsContextInterface existed that GraphicsContext >>>> implemented.? Developers could then have alternative >>>> GraphicsContext implementations that implemented that interface.? >>>> This would require canvas drawing code to be written to use the >>>> interface, but would still be very useful. >>>> >>>> Either solution could (I think) be easily implemented in JavaFX >>>> without breaking existing code and add a significant advance to the >>>> toolkit. >>>> >>>> If there are alternative solutions to the problem, that would allow >>>> exporting canvas drawing to vector graphics files without requiring >>>> a change to the code that draws to the canvas, I?d appreciate >>>> hearing them. >>>> >>>> ? Bruce >>>> > From nmrview at mac.com Mon Nov 2 22:34:17 2020 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 2 Nov 2020 17:34:17 -0500 Subject: GraphicsContext and export to vector format files In-Reply-To: References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> <694bc47f-fb5b-2413-379d-1ce9b3cde41b@jugs.org> Message-ID: <2A894CF7-50AA-4C76-B8DE-AFCA52D85077@mac.com> I should not even have mentioned the GraphicsContext for scene graph rendering. There is something elegant about being able to easily make the whole scene render to some other device/file, but I?m well aware of the practical issues. But I do wish there was a better solution for the original question. Libraries like VectorGraphics and JFreeSVG are really useful for actual real world applications and I don?t see comparable tools appearing for JavaFX without some changes like I propose (or better ones than I can think of). Bruce > On Nov 2, 2020, at 5:04 PM, Kevin Rushforth wrote: > > Yeah, there is no chance we would consider changing the JavaFX to use Canvas GraphicsContext for scene graph rendering. > > As for the original question, we are unlikely to make GraphicsContext extensible in the core JavaFX. I think the solution you came up with for your application (with a proxy class and interface) is a reasonable approach. > > -- Kevin > > > On 11/2/2020 6:58 AM, Michael Paus wrote: >> At this point I would disagree with you. Doing so would just >> result in a sever performance hit. I will not go into the details >> here because that idea is out of reach anyway. >> >> Am 02.11.20 um 15:42 schrieb Bruce Johnson: >>> And if you want to think of even further advances (which I?d avoid at this point because I?d like this to get done in a useful time frame), I?ve often thought that all JavaFX scene drawing should use the Canvas GraphicsContext. So with the changes I?m suggesting that would allow export of the complete scene graph to another device (vector graphics files etc.) >>> >>> Bruce >>> >>> >>>> On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: >>>> >>>> Hi, >>>> I very much like the idea in general but I think it falls too short. >>>> Such an interface should not be tied to any existing graphics >>>> framework. Instead it should be just pure Java. This would allow >>>> to write complex graphics rendering code for a lot of different >>>> platforms and not only platforms where JavaFX already exists >>>> and can be used. Just think of the Android canvas or, via cross- >>>> compilation, even the HTML 5 canvas. >>>> Just my two ?ent. >>>> Michael >>>> >>>> Am 02.11.20 um 14:18 schrieb Bruce Johnson: >>>>> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >>>>> >>>>> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >>>>> >>>>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >>>>> >>>>> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >>>>> >>>>> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >>>>> >>>>> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >>>>> >>>>> It would be much simpler if >>>>> 1) GraphicsContext was not final and could be extended. >>>>> or >>>>> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >>>>> >>>>> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >>>>> >>>>> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >>>>> >>>>> ? Bruce >>>>> >> > From wiverson at gmail.com Mon Nov 2 22:45:43 2020 From: wiverson at gmail.com (Will Iverson) Date: Mon, 2 Nov 2020 14:45:43 -0800 Subject: Taskbar API from JavaFX Window? In-Reply-To: References: <5B85B348-5A75-43EC-B559-5AB6F242EF5A@gmail.com> Message-ID: The bug reports are great, thank you. Aside from philosophically voting up the issue not sure what else I can add. Here is the (somewhat amusing) workaround thread from StackOverflow: https://stackoverflow.com/questions/64616443/how-to-get-awt-window-for-javafx-stage/64651359#64651359 Cheers, -Will On Mon, Nov 2, 2020 at 1:29 PM Scott Palmer wrote: > For that API, you might consider using an AWT root Window with a JFXPanel > rather than a JavaFX Window to hold your JavaFX UI. But discussion of how > to code the application side is not relevant for this list. > > For the record here are the relevant JavaFX issues: > https://bugs.openjdk.java.net/browse/JDK-8091107 > https://bugs.openjdk.java.net/browse/JDK-8091517 > > If you want to discuss those further, this list might be the right place. > Currently JavaFX modules require the java.desktop module, so it doesn't > hurt your JRE footprint to use the Swing integration. Hopefully > that dependency won't last long though (see > https://bugs.openjdk.java.net/browse/JDK-8240844), and perhaps at the > point the desktop module dependency is removed, the motivation to implement > the above issues will be higher. > > Cheers, > > Scott > > > On Mon, Nov 2, 2020 at 11:46 AM Will Iverson wrote: > >> What Window should I pass in for the setWindowProgressState window >> argument? It requires a java.awt.Window? >> >> On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer wrote: >> >>> They work fine. Just remember to use the Swing/AWT event thread to call >>> them. >>> >>> Scott >>> >>> > On Nov 1, 2020, at 8:39 PM, Will Iverson wrote: >>> > >>> > ?Looking at native desktop integration with JavaFX. As I was >>> exploring, I >>> > noticed that the java.awt.Taskbar API does not appear to be available >>> for >>> > JavaFX Windows. >>> > >>> > >>> https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State) >>> > >>> > Many of the other methods on this class (e.g. setting progress, custom >>> > icons) work fine on macOS from my testing so far. >>> > >>> > Is there any way to use the AWT methods from a JavaFX app? >>> > >>> > Cheers, >>> > -Will >>> >> From kevin.rushforth at oracle.com Mon Nov 2 23:07:19 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 2 Nov 2020 15:07:19 -0800 Subject: GraphicsContext and export to vector format files In-Reply-To: <2A894CF7-50AA-4C76-B8DE-AFCA52D85077@mac.com> References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> <694bc47f-fb5b-2413-379d-1ce9b3cde41b@jugs.org> <2A894CF7-50AA-4C76-B8DE-AFCA52D85077@mac.com> Message-ID: <52e55b08-00d6-bccc-a8d2-85b7076f89e1@oracle.com> I can see how this could be useful to a certain class of applications, but I'm not convinced there is enough value, since the work that the application would need to do is pretty much the same even if we added the ability to subclass. As for providing an interface, I think that a third-party library could do that just as easily. What you wouldn't get is standardization of that interface. -- Kevin On 11/2/2020 2:34 PM, Bruce Johnson wrote: > I should not even have mentioned the GraphicsContext for scene graph rendering. There is something elegant about being able to easily make the whole scene render to some other device/file, but I?m well aware of the practical issues. > > But I do wish there was a better solution for the original question. Libraries like VectorGraphics and JFreeSVG are really useful for actual real world applications and I don?t see comparable tools appearing for JavaFX without some changes like I propose (or better ones than I can think of). > > Bruce > > > >> On Nov 2, 2020, at 5:04 PM, Kevin Rushforth wrote: >> >> Yeah, there is no chance we would consider changing the JavaFX to use Canvas GraphicsContext for scene graph rendering. >> >> As for the original question, we are unlikely to make GraphicsContext extensible in the core JavaFX. I think the solution you came up with for your application (with a proxy class and interface) is a reasonable approach. >> >> -- Kevin >> >> >> On 11/2/2020 6:58 AM, Michael Paus wrote: >>> At this point I would disagree with you. Doing so would just >>> result in a sever performance hit. I will not go into the details >>> here because that idea is out of reach anyway. >>> >>> Am 02.11.20 um 15:42 schrieb Bruce Johnson: >>>> And if you want to think of even further advances (which I?d avoid at this point because I?d like this to get done in a useful time frame), I?ve often thought that all JavaFX scene drawing should use the Canvas GraphicsContext. So with the changes I?m suggesting that would allow export of the complete scene graph to another device (vector graphics files etc.) >>>> >>>> Bruce >>>> >>>> >>>>> On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: >>>>> >>>>> Hi, >>>>> I very much like the idea in general but I think it falls too short. >>>>> Such an interface should not be tied to any existing graphics >>>>> framework. Instead it should be just pure Java. This would allow >>>>> to write complex graphics rendering code for a lot of different >>>>> platforms and not only platforms where JavaFX already exists >>>>> and can be used. Just think of the Android canvas or, via cross- >>>>> compilation, even the HTML 5 canvas. >>>>> Just my two ?ent. >>>>> Michael >>>>> >>>>> Am 02.11.20 um 14:18 schrieb Bruce Johnson: >>>>>> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >>>>>> >>>>>> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >>>>>> >>>>>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >>>>>> >>>>>> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >>>>>> >>>>>> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >>>>>> >>>>>> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >>>>>> >>>>>> It would be much simpler if >>>>>> 1) GraphicsContext was not final and could be extended. >>>>>> or >>>>>> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >>>>>> >>>>>> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >>>>>> >>>>>> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >>>>>> >>>>>> ? Bruce >>>>>> From nmrview at mac.com Mon Nov 2 23:43:42 2020 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 2 Nov 2020 18:43:42 -0500 Subject: GraphicsContext and export to vector format files In-Reply-To: <52e55b08-00d6-bccc-a8d2-85b7076f89e1@oracle.com> References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> <694bc47f-fb5b-2413-379d-1ce9b3cde41b@jugs.org> <2A894CF7-50AA-4C76-B8DE-AFCA52D85077@mac.com> <52e55b08-00d6-bccc-a8d2-85b7076f89e1@oracle.com> Message-ID: But standardization of the interface is they key. I can imagine one group writing a really useful charting library that just took a GraphicsContextInterface and used it to render to the canvas. Someone else could independently develop something like JFreeSVG that took a GraphicsContextInterface and drew to .svg files. A third group could simply plug the two together and get nice plots displayed on the Canvas or written to a .svg file without even starting up the GUI. Instead I?ve got my basic plotting code (for rendering NMR spectra) and my own SVG exporter that only knows how to export the methods that I use in the plotting. Those two don?t lead to a whole ecosystem of tools that leads to great applications. Bruce > On Nov 2, 2020, at 6:07 PM, Kevin Rushforth wrote: > > I can see how this could be useful to a certain class of applications, but I'm not convinced there is enough value, since the work that the application would need to do is pretty much the same even if we added the ability to subclass. As for providing an interface, I think that a third-party library could do that just as easily. What you wouldn't get is standardization of that interface. > > -- Kevin > > > On 11/2/2020 2:34 PM, Bruce Johnson wrote: >> I should not even have mentioned the GraphicsContext for scene graph rendering. There is something elegant about being able to easily make the whole scene render to some other device/file, but I?m well aware of the practical issues. >> >> But I do wish there was a better solution for the original question. Libraries like VectorGraphics and JFreeSVG are really useful for actual real world applications and I don?t see comparable tools appearing for JavaFX without some changes like I propose (or better ones than I can think of). >> >> Bruce >> >> >> >>> On Nov 2, 2020, at 5:04 PM, Kevin Rushforth wrote: >>> >>> Yeah, there is no chance we would consider changing the JavaFX to use Canvas GraphicsContext for scene graph rendering. >>> >>> As for the original question, we are unlikely to make GraphicsContext extensible in the core JavaFX. I think the solution you came up with for your application (with a proxy class and interface) is a reasonable approach. >>> >>> -- Kevin >>> >>> >>> On 11/2/2020 6:58 AM, Michael Paus wrote: >>>> At this point I would disagree with you. Doing so would just >>>> result in a sever performance hit. I will not go into the details >>>> here because that idea is out of reach anyway. >>>> >>>> Am 02.11.20 um 15:42 schrieb Bruce Johnson: >>>>> And if you want to think of even further advances (which I?d avoid at this point because I?d like this to get done in a useful time frame), I?ve often thought that all JavaFX scene drawing should use the Canvas GraphicsContext. So with the changes I?m suggesting that would allow export of the complete scene graph to another device (vector graphics files etc.) >>>>> >>>>> Bruce >>>>> >>>>> >>>>>> On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: >>>>>> >>>>>> Hi, >>>>>> I very much like the idea in general but I think it falls too short. >>>>>> Such an interface should not be tied to any existing graphics >>>>>> framework. Instead it should be just pure Java. This would allow >>>>>> to write complex graphics rendering code for a lot of different >>>>>> platforms and not only platforms where JavaFX already exists >>>>>> and can be used. Just think of the Android canvas or, via cross- >>>>>> compilation, even the HTML 5 canvas. >>>>>> Just my two ?ent. >>>>>> Michael >>>>>> >>>>>> Am 02.11.20 um 14:18 schrieb Bruce Johnson: >>>>>>> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >>>>>>> >>>>>>> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >>>>>>> >>>>>>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >>>>>>> >>>>>>> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >>>>>>> >>>>>>> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >>>>>>> >>>>>>> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >>>>>>> >>>>>>> It would be much simpler if >>>>>>> 1) GraphicsContext was not final and could be extended. >>>>>>> or >>>>>>> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >>>>>>> >>>>>>> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >>>>>>> >>>>>>> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >>>>>>> >>>>>>> ? Bruce >>>>>>> > From kcr at openjdk.java.net Tue Nov 3 00:48:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Nov 2020 00:48:54 GMT Subject: RFR: 8255723: Gtk glass backend should run with Gtk+ 3.8 (minimum) In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 01:20:53 GMT, Thiago Milczarek Sayao wrote: > Simple fix to not build with GTK+ greater than 3.8 symbols. Looks good. In general we shouldn't use compile-time version checks for OS or platform software, since the binaries we produce should run on anything greater than the minimum. I see we still have a few, but the rest are at least consistently no greater than 3.8. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/346 From dave at jfree.org Tue Nov 3 07:25:46 2020 From: dave at jfree.org (David Gilbert) Date: Tue, 3 Nov 2020 08:25:46 +0100 Subject: GraphicsContext and export to vector format files In-Reply-To: References: <292F7843-8050-4AC1-8917-5B56BE434F00@mac.com> <694bc47f-fb5b-2413-379d-1ce9b3cde41b@jugs.org> <2A894CF7-50AA-4C76-B8DE-AFCA52D85077@mac.com> <52e55b08-00d6-bccc-a8d2-85b7076f89e1@oracle.com> Message-ID: I would totally support this request from Bruce. I?ve implemented a number of libraries (JFreeSVG, OrsonPDF, FXGraphics2D and SWTGraphics2D) on top of the Graphics2D API, as have others. The Java2D engineers got this right back in 1999! All it needs is an API (interface) that users can code against without having to think about the implementation, and the ability to swap in an alternative implementation. JavaFX prevents that, but it wouldn?t be that hard to rectify (as far as I can tell). Best regards, David > On 03 Nov 2020, at 00:43, Bruce Johnson wrote: > > But standardization of the interface is they key. I can imagine one group writing a really useful charting library that just took a GraphicsContextInterface and used it to render to the canvas. Someone else could independently develop something like JFreeSVG that took a GraphicsContextInterface and drew to .svg files. A third group could simply plug the two together and get nice plots displayed on the Canvas or written to a .svg file without even starting up the GUI. > > Instead I?ve got my basic plotting code (for rendering NMR spectra) and my own SVG exporter that only knows how to export the methods that I use in the plotting. Those two don?t lead to a whole ecosystem of tools that leads to great applications. > > Bruce > > > > >> On Nov 2, 2020, at 6:07 PM, Kevin Rushforth wrote: >> >> I can see how this could be useful to a certain class of applications, but I'm not convinced there is enough value, since the work that the application would need to do is pretty much the same even if we added the ability to subclass. As for providing an interface, I think that a third-party library could do that just as easily. What you wouldn't get is standardization of that interface. >> >> -- Kevin >> >> >> On 11/2/2020 2:34 PM, Bruce Johnson wrote: >>> I should not even have mentioned the GraphicsContext for scene graph rendering. There is something elegant about being able to easily make the whole scene render to some other device/file, but I?m well aware of the practical issues. >>> >>> But I do wish there was a better solution for the original question. Libraries like VectorGraphics and JFreeSVG are really useful for actual real world applications and I don?t see comparable tools appearing for JavaFX without some changes like I propose (or better ones than I can think of). >>> >>> Bruce >>> >>> >>> >>>> On Nov 2, 2020, at 5:04 PM, Kevin Rushforth wrote: >>>> >>>> Yeah, there is no chance we would consider changing the JavaFX to use Canvas GraphicsContext for scene graph rendering. >>>> >>>> As for the original question, we are unlikely to make GraphicsContext extensible in the core JavaFX. I think the solution you came up with for your application (with a proxy class and interface) is a reasonable approach. >>>> >>>> -- Kevin >>>> >>>> >>>> On 11/2/2020 6:58 AM, Michael Paus wrote: >>>>> At this point I would disagree with you. Doing so would just >>>>> result in a sever performance hit. I will not go into the details >>>>> here because that idea is out of reach anyway. >>>>> >>>>> Am 02.11.20 um 15:42 schrieb Bruce Johnson: >>>>>> And if you want to think of even further advances (which I?d avoid at this point because I?d like this to get done in a useful time frame), I?ve often thought that all JavaFX scene drawing should use the Canvas GraphicsContext. So with the changes I?m suggesting that would allow export of the complete scene graph to another device (vector graphics files etc.) >>>>>> >>>>>> Bruce >>>>>> >>>>>> >>>>>>> On Nov 2, 2020, at 9:17 AM, Michael Paus wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I very much like the idea in general but I think it falls too short. >>>>>>> Such an interface should not be tied to any existing graphics >>>>>>> framework. Instead it should be just pure Java. This would allow >>>>>>> to write complex graphics rendering code for a lot of different >>>>>>> platforms and not only platforms where JavaFX already exists >>>>>>> and can be used. Just think of the Android canvas or, via cross- >>>>>>> compilation, even the HTML 5 canvas. >>>>>>> Just my two ?ent. >>>>>>> Michael >>>>>>> >>>>>>> Am 02.11.20 um 14:18 schrieb Bruce Johnson: >>>>>>>> A variety of packages (for example, VectorGraphics or JFreeSVG) exist that allow redirecting Java2D drawing to output other than the Java2D canvas. >>>>>>>> >>>>>>>> These work by extending java.awt.Graphics2D. By passing the extended Graphics2D object into a paint method, output can be redirected to a file (.svg, .pdf, etc.). >>>>>>>> >>>>>>>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D of java.awt, but because it is a final class it cannot be extended to create similar functionality as found in VectorgGraphics or JFreeSVG. >>>>>>>> >>>>>>>> This is a serious limitation (at least as far as I can tell) to JavaFX applications. It would be highly desirable to be able to redirect drawing on a Canvas to other output formats such as vector graphics files (.svg, .pdf etc.). >>>>>>>> >>>>>>>> I currently work around this by using composition. I have a Java interface that has most methods of GraphicsContext. Then a GraphicsContextProxy class implements the interface and contains an instance of GraphicsContext. This class is used for drawing to the Canvas. I?ve then created a SVGGraphicsContext and PDFGraphicsContext that implement the interface and these can be used to draw to .svg or .pdf files. >>>>>>>> >>>>>>>> This works, but means that all code that draws on the canvas has to be rewritten to take the GraphicsContextInterface rather than the normal GraphicsContext. >>>>>>>> >>>>>>>> It would be much simpler if >>>>>>>> 1) GraphicsContext was not final and could be extended. >>>>>>>> or >>>>>>>> 2) A GraphicsContextInterface existed that GraphicsContext implemented. Developers could then have alternative GraphicsContext implementations that implemented that interface. This would require canvas drawing code to be written to use the interface, but would still be very useful. >>>>>>>> >>>>>>>> Either solution could (I think) be easily implemented in JavaFX without breaking existing code and add a significant advance to the toolkit. >>>>>>>> >>>>>>>> If there are alternative solutions to the problem, that would allow exporting canvas drawing to vector graphics files without requiring a change to the code that draws to the canvas, I?d appreciate hearing them. >>>>>>>> >>>>>>>> ? Bruce >>>>>>>> >> > From arapte at openjdk.java.net Tue Nov 3 12:10:58 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 3 Nov 2020 12:10:58 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 03:11:18 GMT, Arun Joseph wrote: >> fillPath() and fillRect() functions in [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as ImagePattern doesn't have the same attribute. So, the final image won't be transformed. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect concat param order Added a small query comment. Rest looks good to me, change seems specific to `ImagePattern` transformation. This transformation is set only when specified from webkit and is identity otherwise. modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/PaintHelper.java line 754: > 752: > 753: BaseTransform paintXform = paint.getPatternTransformNoClone(); > 754: if (paintXform != null) { Minor: Is the null check needed ? I could not find an instance where an object of `ImagePattern` is constructed using default constructor. If `ImagePattern.getPatternTransformNoClone()` could return null then should we do null check with other calls to `ImagePattern.getPatternTransformNoClone()` ? OR may be remove this null check. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From kcr at openjdk.java.net Tue Nov 3 12:36:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Nov 2020 12:36:52 GMT Subject: RFR: 8237491: Maximized undecorated stage behaves inconsistently on different platforms In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 01:08:39 GMT, Thiago Milczarek Sayao wrote: > Simple fix to enable maximizing functionality on the window manager. > > Test provided > gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.stage.MaximizeUndecorated > > Fix for linux only. Since this is a partial fix for this bug (it fixes Linux, but not macOS), I split [JDK-8237491](https://bugs.openjdk.java.net/browse/JDK-8237491) into two bugs. I also updated the summary to indicate that JDK-8237491 is specific to Linux so you will need to update this PR title to match. ------------- PR: https://git.openjdk.java.net/jfx/pull/345 From pedro.duquevieira at gmail.com Tue Nov 3 12:40:22 2020 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 3 Nov 2020 12:40:22 +0000 Subject: GraphicsContext and export to vector format files Message-ID: One thing I've always felt is a downfall of JavaFX is that it's too closed for extension. Don't get me wrong I love JavaFX and a lot of stuff you guys did but nothing is perfect and there is always room for improvement. This lack of extensibility ends up hurting third parties' ability to extend JavaFX functionality with new libraries, at least in some areas (like the one Bruce is mentioning). This is in contrast to Swing where more extension points were possible (there were less final classes/methods, private methods, etc). I understand that the main driver was to be more conservative and not allow scenarios that weren't well thought through. However, I believe this ends up having more cons than pros and maybe a slightly less conservative approach would be preferable. I agree with the 2 proposed solutions that Bruce brought forward. And as a general rule, I would prefer JavaFX would allow for more extension points on other areas, either by not having as many private/final methods, etc, or by adding interfaces which would then allow for composing classes. Which would probably be preferred. By adding interfaces (and JavaFX making use of these interfaces, instead of concrete classes), a conservative approach would still be possible. I.e. concrete implementations would still be able to have private, final fields/methods, etc but developers would now have the possibility of doing composition to extend JavaFX's behavior. My 2 cents, Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com From fastegal at swingempire.de Tue Nov 3 13:07:50 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 03 Nov 2020 14:07:50 +0100 Subject: compile errors around JMemoryBuddy In-Reply-To: References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> Message-ID: <20201103140750.Horde.a5GyOAdQ60rKUzGpS70Ofg1@webmail.df.eu> Zitat von Florian Kirmaier : > Eclipse probably handles the modules differently than Gradle. probably - couldn't find gradle's magic in the build script (and lost interest, because that part is running okay and there are enough experts around to keep it that way :) > The simplest solution would be to remove the code to automatically create > heap dumps. > Adding java.management to module-info of the tests doesn't sound wrong to > me if it's using it. > that's basically, what I ended up with. To summarize the problem: when compiling base and running tests of controls in Eclipse I got a) JMemoryBuddy doesn't compile, Eclipse suggests to add requires jdk.management and java.management b) following the suggestion, some controls test don't compile due to base:test.util.memory not being accessible As changing production module-info is not an option (and Eclipse' support for test module-info is wip - see https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601 ) I played a bit with the (new to me ;) module dependencies tab in build path config and added reads to both modules. Couldn't find a way to add them to test sources only (Eclipse added them to java src), so manually moved in .classpath file, its test entry now is: This fixed the error in base. To fix the error in controls, I added the export of new base test package in :controls .classpath no idea how stable all this is, working for me at least. Should the eclipse specific files updated in master, with this or something similar/better? Opinions, please? -- Jeanette > On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth > wrote: > >> I didn't try it with an earlier JDK, but if it breaks when using JDK 11 >> it will need to be fixed. >> >> -- Kevin >> >> >> On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote: >> > >> > just fetched the latest upstream master and getting compile errors >> > around xx.management packages (eclipse wants to add requires into the >> > module-info - which certainly is the wrong way to go ;) Compiling >> > against jdk12, if that matters (will update one of these days but >> > shouldn't jdk11 be good enough). >> > >> > Any quick ideas on what might be wrong? >> > >> > -- Jeanette >> > >> > >> >> From arapte at openjdk.java.net Tue Nov 3 18:01:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 3 Nov 2020 18:01:52 GMT Subject: RFR: 8255714: Switch FX build to use JDK 15.0.1 as boot JDK In-Reply-To: References: Message-ID: <0-r8L5tFrbevW8X85x0FwUXvvPMYrNQHwK1Ytm9LOgE=.6004d7ae-a609-42ea-938f-721ad5315dc0@github.com> On Mon, 2 Nov 2020 12:47:06 GMT, Kevin Rushforth wrote: > Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the minimum boot JDK which remains at JDK 11. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/347 From kcr at openjdk.java.net Tue Nov 3 21:26:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Nov 2020 21:26:58 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 15:09:49 GMT, Johan Vos wrote: > Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. Looks OK as near as I can tell. I left a few questions along with a comment about a missing copyright header (that's the only thing that definitely needs to be fixed). modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 45: > 43: * implementation to get the best matching configuration. > 44: */ > 45: EGLAcceleratedScreen(int[] attributes) throws GLException { I presume you intended to call the (newly added) default `super` method and not `super(int[])`? modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLPlatform.java line 37: > 35: String lib = System.getProperty("monocle.egl.lib"); > 36: if (lib != null) { > 37: LinuxSystem.getLinuxSystem().dlopen(lib, LinuxSystem.RTLD_LAZY | LinuxSystem.RTLD_GLOBAL); Do you need to check the return value (and maybe throw an Exception)? modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLPlatform.java line 43: > 41: @Override > 42: public synchronized AcceleratedScreen getAcceleratedScreen(int[] attributes) throws GLException { > 43: return new EGLAcceleratedScreen(attributes); Should this method cache the result so it returns a singleton (not sure, but the other `NativePlatform` subclasses, including `Dispman` do)? modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c line 56: > 54: JNIEXPORT jlong JNICALL Java_com_sun_glass_ui_monocle_EGLAcceleratedScreen_nEglChooseConfig > 55: (JNIEnv *env, jclass clazz, jlong eglDisplay, jintArray attribs) { > 56: jint *attrArray = (*env)->GetIntArrayElements(env, attribs, JNI_FALSE); Should this check the return value in case it fails (returns NULL)? modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 1: > 1: #include This needs a standard copyright header. Also should it have a guard to prevent including it more than once? ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From kcr at openjdk.java.net Tue Nov 3 21:29:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Nov 2020 21:29:51 GMT Subject: Integrated: 8255714: Switch FX build to use JDK 15.0.1 as boot JDK In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 12:47:06 GMT, Kevin Rushforth wrote: > Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the minimum boot JDK which remains at JDK 11. This pull request has now been integrated. Changeset: eece20b3 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/eece20b3 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8255714: Switch FX build to use JDK 15.0.1 as boot JDK Reviewed-by: jvos, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/347 From kcr at openjdk.java.net Tue Nov 3 23:17:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 Nov 2020 23:17:55 GMT Subject: RFR: 8237491: Undecorated stage cannot be maximized In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 01:08:39 GMT, Thiago Milczarek Sayao wrote: > Simple fix to enable maximizing functionality on the window manager. > > Test provided > gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.stage.MaximizeUndecorated > > Fix for linux only. The fix looks good. I added a couple comments with suggestions and pointed out one thing that must be fixed (the test needs to be excluded on macOS until [JDK-8255835](https://bugs.openjdk.java.net/browse/JDK-8255835) is fixed). modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1347: > 1345: is_maximized = maximize; > 1346: if (maximize) { > 1347: // enable the functionality Maybe expand this comment similar to what was done for minimize (since the reason for doing it is the same)? tests/system/src/test/java/test/javafx/stage/MaximizeUndecorated.java line 49: > 47: static Stage stage; > 48: // might be offscreen and that's ok > 49: static final int POS = 1000; I might recommend something a little smaller (maybe 500 instead of 1000), since some window systems constrain at least the top left corner to be visible. tests/system/src/test/java/test/javafx/stage/MaximizeUndecorated.java line 80: > 78: > 79: @Test > 80: public void testMaximize() throws Exception { This test fails on macOS, so you will need to exclude it using `assumeTrue` like this: assumeTrue(!PlatformUtil.isMac()); // JDK-8255835 tests/system/src/test/java/test/javafx/stage/MaximizeUndecorated.java line 83: > 81: Util.sleep(200); > 82: > 83: boolean movedToTopCorner = stage.getY() != POS && stage.getX() != POS; This presumes that the window system will not reposition it (else you will get a false negative). Given that this is using an undecorated window, it should be fine, and I verified that it did correctly detect the failure when your fix is not applied on both Oracle Linux 7.7 and Ubuntu 20.04. ------------- PR: https://git.openjdk.java.net/jfx/pull/345 From tsayao at openjdk.java.net Wed Nov 4 01:12:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 4 Nov 2020 01:12:02 GMT Subject: RFR: 8237491: Undecorated stage cannot be maximized [v2] In-Reply-To: References: Message-ID: > Simple fix to enable maximizing functionality on the window manager. > > Test provided > gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.stage.MaximizeUndecorated > > Fix for linux only. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Requested adjustments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/345/files - new: https://git.openjdk.java.net/jfx/pull/345/files/821e9ad2..586723e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=345&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=345&range=00-01 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/345.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/345/head:pull/345 PR: https://git.openjdk.java.net/jfx/pull/345 From kcr at openjdk.java.net Wed Nov 4 01:12:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 Nov 2020 01:12:03 GMT Subject: RFR: 8237491: Undecorated stage cannot be maximized [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 23:15:13 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Requested adjustments > > The fix looks good. I added a couple comments with suggestions and pointed out one thing that must be fixed (the test needs to be excluded on macOS until [JDK-8255835](https://bugs.openjdk.java.net/browse/JDK-8255835) is fixed). The changes looks good. I'll finish the review tomorrow. Btw, the title still doesn't match exactly, so it will prevent integration. ------------- PR: https://git.openjdk.java.net/jfx/pull/345 From jvos at openjdk.java.net Wed Nov 4 10:22:55 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 10:22:55 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 21:17:57 GMT, Kevin Rushforth wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLPlatform.java line 43: > >> 41: @Override >> 42: public synchronized AcceleratedScreen getAcceleratedScreen(int[] attributes) throws GLException { >> 43: return new EGLAcceleratedScreen(attributes); > > Should this method cache the result so it returns a singleton (not sure, but the other `NativePlatform` subclasses, including `Dispman` do)? Good question. In theory (e.g. on the Pi 4), there can be 2 different hardware accelerated screens, but their is no application logic in the higher layers for distributing rendering to 2 different interfaces. Hence, it is indeed better to cache the result. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Wed Nov 4 10:17:55 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 10:17:55 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering In-Reply-To: References: Message-ID: <3IBzsdX0dZiCq5pKMxdNSxxV7WEUe_sx-wuA25HWNjI=.cf05ebc5-d05f-4bec-8d2f-35ceab0f3c6a@github.com> On Tue, 3 Nov 2020 21:15:34 GMT, Kevin Rushforth wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLPlatform.java line 37: > >> 35: String lib = System.getProperty("monocle.egl.lib"); >> 36: if (lib != null) { >> 37: LinuxSystem.getLinuxSystem().dlopen(lib, LinuxSystem.RTLD_LAZY | LinuxSystem.RTLD_GLOBAL); > > Do you need to check the return value (and maybe throw an Exception)? Good idea. Added. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Wed Nov 4 11:12:06 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 11:12:06 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v2] In-Reply-To: References: Message-ID: > Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: process reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/343/files - new: https://git.openjdk.java.net/jfx/pull/343/files/f2408c9f..551af690 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=00-01 Stats: 43 lines in 4 files changed: 41 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/343.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/343/head:pull/343 PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Wed Nov 4 11:12:08 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 11:12:08 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 21:20:49 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> process reviewer comments > > modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c line 56: > >> 54: JNIEXPORT jlong JNICALL Java_com_sun_glass_ui_monocle_EGLAcceleratedScreen_nEglChooseConfig >> 55: (JNIEnv *env, jclass clazz, jlong eglDisplay, jintArray attribs) { >> 56: jint *attrArray = (*env)->GetIntArrayElements(env, attribs, JNI_FALSE); > > Should this check the return value in case it fails (returns NULL)? I checked other places in the code, and calls to env->GetIntArrayElements are typically not checked. However, if something fails in that call, it must be something really bad that happened. I added a fprintf to stderr, and throw an IllegalArgumentException in the java code (as there is something wrong with the attribs) > modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 1: > >> 1: #include > > This needs a standard copyright header. > > Also should it have a guard to prevent including it more than once? correct. fixed. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 45: > >> 43: * implementation to get the best matching configuration. >> 44: */ >> 45: EGLAcceleratedScreen(int[] attributes) throws GLException { > > I presume you intended to call the (newly added) default `super` method and not `super(int[])`? Yes, this will (implicitly) call the super() method instead of the super(int[] ) method. The problem with the latter (and actually the reason for this approach) is that the flow in the super(int[]) constructor is very specific to specific use-cases, and would require subclasses for every EGL-system that does not behave 100% similar to the specific usecase. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From tsayao at openjdk.java.net Wed Nov 4 13:45:53 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 4 Nov 2020 13:45:53 GMT Subject: Integrated: 8255723: Gtk glass backend should run with Gtk+ 3.8 (minimum) In-Reply-To: References: Message-ID: <4w-RyiuNDXzwr1a6vnZbg3lvH4GbvI2dMwfORxWBgmI=.525e1591-490a-472b-8357-f7b0c0bd0f17@github.com> On Mon, 2 Nov 2020 01:20:53 GMT, Thiago Milczarek Sayao wrote: > Simple fix to not build with GTK+ greater than 3.8 symbols. This pull request has now been integrated. Changeset: 92804f36 Author: Thiago Milczarek Sayao Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/92804f36 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8255723: Gtk glass backend should run with Gtk+ 3.8 (minimum) Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/346 From kcr at openjdk.java.net Wed Nov 4 14:16:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 Nov 2020 14:16:53 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v2] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 11:12:06 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/343 From ajoseph at openjdk.java.net Wed Nov 4 15:43:58 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 4 Nov 2020 15:43:58 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 12:01:38 GMT, Ambarish Rapte wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix incorrect concat param order > > modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/PaintHelper.java line 754: > >> 752: >> 753: BaseTransform paintXform = paint.getPatternTransformNoClone(); >> 754: if (paintXform != null) { > > Minor: Is the null check needed ? I could not find an instance where an object of `ImagePattern` is constructed using default constructor. > If `ImagePattern.getPatternTransformNoClone()` could return null then should we do null check with other calls to `ImagePattern.getPatternTransformNoClone()` ? OR may be remove this null check. The null check is not actually required as instances of `ImagePattern` can't have a null `patternTransform`. I added this check as `setLinearGradient` and `setRadialGradient` functions have also added them, when instances of `Gradient` can't have null as its transform. Should this null check be removed? ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From jpereda at openjdk.java.net Wed Nov 4 15:58:57 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 4 Nov 2020 15:58:57 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v2] In-Reply-To: References: Message-ID: <8UnL62Jr4ncULNfdhzB7jZ7tYAF5rVWyA4M6dTSsTg0=.b9b63a3c-f80f-42cb-8b81-2c73175b38e8@github.com> On Wed, 4 Nov 2020 11:12:06 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comments modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 64: > 62: } > 63: > 64: public void enableRendering(boolean flag) { Add `@Override` annotation ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jpereda at openjdk.java.net Wed Nov 4 16:08:09 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 4 Nov 2020 16:08:09 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v2] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 11:12:06 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comments modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 73: > 71: } > 72: > 73: public boolean swapBuffers() { Add @Override annotation modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 75: > 73: public boolean swapBuffers() { > 74: boolean result = false; > 75: synchronized(NativeScreen.framebufferSwapLock) { Add white space after `synchronized` ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Wed Nov 4 16:08:07 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 16:08:07 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v3] In-Reply-To: References: Message-ID: > Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: process reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/343/files - new: https://git.openjdk.java.net/jfx/pull/343/files/551af690..ac419e48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/343.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/343/head:pull/343 PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Wed Nov 4 16:08:09 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 16:08:09 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v2] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 15:56:44 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> process reviewer comments > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 75: > >> 73: public boolean swapBuffers() { >> 74: boolean result = false; >> 75: synchronized(NativeScreen.framebufferSwapLock) { > > Add white space after `synchronized` fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Wed Nov 4 16:14:06 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 16:14:06 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: > Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: add one more @override to process reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/343/files - new: https://git.openjdk.java.net/jfx/pull/343/files/ac419e48..e715fd86 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/343.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/343/head:pull/343 PR: https://git.openjdk.java.net/jfx/pull/343 From jpereda at openjdk.java.net Wed Nov 4 16:14:07 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 4 Nov 2020 16:14:07 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 16:11:21 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > add one more @override to process reviewer comments Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Wed Nov 4 16:14:08 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 4 Nov 2020 16:14:08 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v2] In-Reply-To: <8UnL62Jr4ncULNfdhzB7jZ7tYAF5rVWyA4M6dTSsTg0=.b9b63a3c-f80f-42cb-8b81-2c73175b38e8@github.com> References: <8UnL62Jr4ncULNfdhzB7jZ7tYAF5rVWyA4M6dTSsTg0=.b9b63a3c-f80f-42cb-8b81-2c73175b38e8@github.com> Message-ID: On Wed, 4 Nov 2020 15:55:46 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> process reviewer comments > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 64: > >> 62: } >> 63: >> 64: public void enableRendering(boolean flag) { > > Add `@Override` annotation done > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 73: > >> 71: } >> 72: >> 73: public boolean swapBuffers() { > > Add @Override annotation Indeed, I added it. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jpereda at openjdk.java.net Wed Nov 4 17:30:01 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 4 Nov 2020 17:30:01 GMT Subject: RFR: 8177945: Single cell selection flickers when adding data to TableView Message-ID: As discussed in the JBS [issue](https://bugs.openjdk.java.net/browse/JDK-8177945), there are some inconsistencies in the use of `VirtualContainerBase::requestRebuildCells` from `VirtualContainerBase::updateItemCount()`, which is implemented in the different skin classes for virtualised controls `TableViewSkinBase`, `ListViewSkin` or `TreeTableViewSkin`. The latter already commented out this call (related to JDK-8155798 and JDK-8147483). This PR removes now the calls to `VirtualContainerBase::requestRebuildCells` from `TableViewSkinBase` (except for the case `itemCount = 0` based on JDK-8118897 and JDK-8098235) and `ListViewSkin`. A test is provided for TableView, that verifies that the `selected` pseudo-class state remains set for the selected cell while adding more items. Without this fix, as the cells are rebuilt, the pseudo-class states are clean and set all over again, thus the flickering. For ListView, the test rt_35395 (JDK-8091726) is updated, as now there are way less calls to updateItem. ------------- Commit messages: - Don?t rebuild VirtualFlow cells when TableView/ListView item count changes. Provide test for TableView, update test for ListView Changes: https://git.openjdk.java.net/jfx/pull/348/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=348&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8177945 Stats: 71 lines in 4 files changed: 59 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/348/head:pull/348 PR: https://git.openjdk.java.net/jfx/pull/348 From kcr at openjdk.java.net Wed Nov 4 19:42:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 Nov 2020 19:42:54 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 16:14:06 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > add one more @override to process reviewer comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From github.com+1413266+jgneff at openjdk.java.net Thu Nov 5 03:08:57 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 5 Nov 2020 03:08:57 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 16:14:06 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > add one more @override to process reviewer comments I wanted to put the EGL bridge into a library called `libglass_monocle_egl.so` built by JavaFX, as we do for X11 and EPD, and then simply drop the custom library that implements `egl_ext.h` into the same directory. Yet I was unable to get `glass_monocle_egl` to resolve the symbols in my custom library at runtime, even when both were loaded successfully. I ended up having to build the bridge and custom implementation into one shared library. So instead of just the `egl_ext.h` header file and my `test01.c` source file, I required all of the following: com_sun_glass_ui_monocle_EGLAcceleratedScreen.h Monocle.h egl_ext.h eglBridge.c test01.c I thought it would be nice to build and load them separately, but I haven't been able to figure it out. The code change would be something like the following: **EGLPlatform.java** import com.sun.glass.utils.NativeLibLoader; public EGLPlatform() { String lib = System.getProperty("monocle.egl.lib"); if (lib != null) { NativeLibLoader.loadLibrary(lib); } NativeLibLoader.loadLibrary("glass_monocle_egl"); } modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c line 112: > 110: void *handle = asPtr(libraryHandle); > 111: if (libraryHandle == 0) { > 112: handle = RTLD_DEFAULT; I had to add the following two lines for the constant `RTLD_DEFAULT` when building for ARM (`PCOMPILE_TARGETS=armv6hf`). #define __USE_GNU #include Otherwise, I got the compilation error: MonocleGLFactory.c:112:19: error: ?RTLD_DEFAULT? undeclared (first use in this function) modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLPlatform.java line 42: > 40: } > 41: } > 42: } I changed the constructor to the following: import com.sun.glass.utils.NativeLibLoader; public EGLPlatform() { String lib = System.getProperty("monocle.egl.lib"); if (lib != null) { NativeLibLoader.loadLibrary(lib); } } Using the `NativeLibLoader` allowed me to define my native library with `monocle.egl.lib=test01` (instead of `libtest01.so`) and drop it in the JavaFX SDK with all the other JavaFX libraries. You also get good error messages when it fails. The current code did load the library after adding its path to the environment variable `LD_LIBRARY_PATH`, but it failed with the following message on first use: java.lang.UnsatisfiedLinkError: 'long com.sun.glass.ui.monocle.EGLAcceleratedScreen .nPlatformGetNativeWindow(java.lang.String)' The call to `NativeLibLoader` solved these problems, with no `LD_LIBRARY_PATH` required. modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 46: > 44: */ > 45: EGLAcceleratedScreen(int[] attributes) throws GLException { > 46: eglWindowHandle = platformGetNativeWindow(); My IDE flags this line with "Overridable method call in constructor" (Item 19 in Bloch's *Effective Java Third Edition*): "the overriding method in the subclass will get invoked before the subclass constructor has run." modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 29: > 27: #include > 28: extern long getNativeWindowHandle(const char *v); > 29: extern long getEGLDisplayHandle(); Rename to `getEglDisplayHandle` like all the others? modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 32: > 30: extern jboolean doEglInitialize(void* handle); > 31: extern jboolean doEglBindApi(int api); > 32: extern jlong doEglChooseConfig (long eglDisplay, int* attribs); This function definition and the three that follow have a space before the left parenthesis. modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 42: > 40: jlong readSurface, jlong eglContext); > 41: > 42: extern jboolean doEglSwapBuffers(jlong eglDisplay, jlong eglSurface); Is there a reason for using different types for the same variables in the method definitions? * The *window handle* is `long` and `jlong`. * The *display handle* is `long`, `void*`, and `jlong`. * The others (*config*, *surface*, and *context*) are all `jlong`. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Thu Nov 5 12:56:53 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Nov 2020 12:56:53 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 02:44:01 GMT, John Neffenger wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> add one more @override to process reviewer comments > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLPlatform.java line 42: > >> 40: } >> 41: } >> 42: } > > I changed the constructor to the following: > > import com.sun.glass.utils.NativeLibLoader; > > public EGLPlatform() { > String lib = System.getProperty("monocle.egl.lib"); > if (lib != null) { > NativeLibLoader.loadLibrary(lib); > } > } > > Using the `NativeLibLoader` allowed me to define my native library with `monocle.egl.lib=test01` (instead of `libtest01.so`) and drop it in the JavaFX SDK with all the other JavaFX libraries. You also get good error messages when it fails. > > The current code did load the library after adding its path to the environment variable `LD_LIBRARY_PATH`, but it failed with the following message on first use: > > java.lang.UnsatisfiedLinkError: > 'long com.sun.glass.ui.monocle.EGLAcceleratedScreen > .nPlatformGetNativeWindow(java.lang.String)' > > The call to `NativeLibLoader` solved these problems, with no `LD_LIBRARY_PATH` required. The difference between how I'm building it and how you are building is that I combine all monocle code in 1 library (libglass_monocle.so) where you have a common monocle library and a egl-specific one -- and this is what you do with the EPD as well. For Android, we use a single library as well. At build time, the android-specific classes are added in libglass_monocle.so and dlopen() is used to load android-specific libraries at runtime. Both approaches are valid, but can't be mixed. Hence we need to decide to either go for 1 or 2 monocle libraries (the android approach, where there is libglass_monocle only or the epd approach where there is also libglass_monocle_epd). I don't have a strong preference, but I think libglass_monocle will be really very small. Bundling the device-specific library (in your case the one containing test01.o) with the monocle library (the general or a specific one) seems less interesting, as that means you need e.g. 4 different monocle libraries for 4 different Pi-configurations. I believe it is better to share the monocle libraries, and have a single OpenJFX library for monocle, and then platform/configuration-specific libraries. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From johan.vos at gluonhq.com Thu Nov 5 13:23:14 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 5 Nov 2020 14:23:14 +0100 Subject: Request to backport issue to JavaFX 11 Message-ID: Hi Kevin, I ask permission to backport JDK-8237469 (Inherited styles don't update when node is moved) to JavaFX 11 (for 11.0.10). The patch applies clean. - Johan From kevin.rushforth at oracle.com Thu Nov 5 13:27:28 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 5 Nov 2020 05:27:28 -0800 Subject: Request to backport issue to JavaFX 11 In-Reply-To: References: Message-ID: <114ab9c7-fc22-64c0-3cea-a97f9edecd65@oracle.com> +1 This is a good one to get in. -- Kevin On 11/5/2020 5:23 AM, Johan Vos wrote: > Hi Kevin, > > I ask permission to backport JDK-8237469 (Inherited styles don't update > when node is moved) to JavaFX 11 (for 11.0.10). The patch applies clean. > > - Johan From jvos at openjdk.java.net Thu Nov 5 13:38:08 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Nov 2020 13:38:08 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v5] In-Reply-To: References: Message-ID: > Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: process reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/343/files - new: https://git.openjdk.java.net/jfx/pull/343/files/e715fd86..932fd001 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/343.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/343/head:pull/343 PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Thu Nov 5 13:38:10 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Nov 2020 13:38:10 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 02:45:00 GMT, John Neffenger wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> add one more @override to process reviewer comments > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 46: > >> 44: */ >> 45: EGLAcceleratedScreen(int[] attributes) throws GLException { >> 46: eglWindowHandle = platformGetNativeWindow(); > > My IDE flags this line with "Overridable method call in constructor" (Item 19 in Bloch's *Effective Java Third Edition*): "the overriding method in the subclass will get invoked before the subclass constructor has run." We can make this private, but that would give a wrong sense of security, as the native method can still be implemented in different ways. @kevinrushforth Do we have the policy of not using overridable method calls in constructors? > modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 29: > >> 27: #include >> 28: extern long getNativeWindowHandle(const char *v); >> 29: extern long getEGLDisplayHandle(); > > Rename to `getEglDisplayHandle` like all the others? fixed. > modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 32: > >> 30: extern jboolean doEglInitialize(void* handle); >> 31: extern jboolean doEglBindApi(int api); >> 32: extern jlong doEglChooseConfig (long eglDisplay, int* attribs); > > This function definition and the three that follow have a space before the left parenthesis. fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Thu Nov 5 13:41:54 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Nov 2020 13:41:54 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 02:48:17 GMT, John Neffenger wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> add one more @override to process reviewer comments > > modules/javafx.graphics/src/main/native-glass/monocle/egl/egl_ext.h line 42: > >> 40: jlong readSurface, jlong eglContext); >> 41: >> 42: extern jboolean doEglSwapBuffers(jlong eglDisplay, jlong eglSurface); > > Is there a reason for using different types for the same variables in the method definitions? > > * The *window handle* is `long` and `jlong`. > * The *display handle* is `long`, `void*`, and `jlong`. > * The others (*config*, *surface*, and *context*) are all `jlong`. Initially, I wanted to avoid jni.h in this external file. However, since 2 of the functions return a boolean value, I introduced jboolean, but didn't change all values. We can still go back to the non-jni types, e.g. by having an int instead of a jboolean, but at this moment I think the presence of jni.h should not be a showstopper. Implementations of this interface will be (or bundled with) code that does not know about Java, hence I tried to avoid jni types, but in case jni.h is not available, the implementation can easily typedef the required types. I made it consistent now to use jlong instead of long. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From kcr at openjdk.java.net Thu Nov 5 13:41:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Nov 2020 13:41:56 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 13:34:40 GMT, Johan Vos wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EGLAcceleratedScreen.java line 46: >> >>> 44: */ >>> 45: EGLAcceleratedScreen(int[] attributes) throws GLException { >>> 46: eglWindowHandle = platformGetNativeWindow(); >> >> My IDE flags this line with "Overridable method call in constructor" (Item 19 in Bloch's *Effective Java Third Edition*): "the overriding method in the subclass will get invoked before the subclass constructor has run." > > We can make this private, but that would give a wrong sense of security, as the native method can still be implemented in different ways. > @kevinrushforth Do we have the policy of not using overridable method calls in constructors? We do this in other places as well. It needs to be considered carefully, but in this case seems reasonable to do as long as the subclass doesn't rely on anything initialized in its constructor. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From kcr at openjdk.java.net Thu Nov 5 14:01:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Nov 2020 14:01:53 GMT Subject: RFR: 8237491: [Linux] Undecorated stage cannot be maximized [v2] In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 01:12:02 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to enable maximizing functionality on the window manager. >> >> Test provided >> gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.stage.MaximizeUndecorated >> >> Fix for linux only. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Requested adjustments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/345 From tsayao at openjdk.java.net Thu Nov 5 16:03:55 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 5 Nov 2020 16:03:55 GMT Subject: Integrated: 8237491: [Linux] Undecorated stage cannot be maximized In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 01:08:39 GMT, Thiago Milczarek Sayao wrote: > Simple fix to enable maximizing functionality on the window manager. > > Test provided > gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.javafx.stage.MaximizeUndecorated > > Fix for linux only. This pull request has now been integrated. Changeset: 08d8a980 Author: Thiago Milczarek Sayao Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/08d8a980 Stats: 100 lines in 2 files changed: 100 ins; 0 del; 0 mod 8237491: [Linux] Undecorated stage cannot be maximized Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/345 From kcr at openjdk.java.net Thu Nov 5 16:05:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Nov 2020 16:05:53 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v5] In-Reply-To: References: Message-ID: <5sH9-vv91QeJcTP3S-gNLLL_8E1Eo2Kwfl6LS70VlCQ=.1171b56a-8c65-4926-80fd-9015a1e5c071@github.com> On Thu, 5 Nov 2020 13:38:08 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From kcr at openjdk.java.net Thu Nov 5 16:08:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Nov 2020 16:08:57 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7] In-Reply-To: References: Message-ID: <_i3_DvmguGnXmnGMBsfOi5kDyCqBArSvC2g6FkKjKcc=.3588366a-ba01-4a4d-a444-d112eb785f1b@github.com> On Wed, 4 Nov 2020 15:41:12 GMT, Arun Joseph wrote: >> modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/PaintHelper.java line 754: >> >>> 752: >>> 753: BaseTransform paintXform = paint.getPatternTransformNoClone(); >>> 754: if (paintXform != null) { >> >> Minor: Is the null check needed ? I could not find an instance where an object of `ImagePattern` is constructed using default constructor. >> If `ImagePattern.getPatternTransformNoClone()` could return null then should we do null check with other calls to `ImagePattern.getPatternTransformNoClone()` ? OR may be remove this null check. > > The null check is not actually required as instances of `ImagePattern` can't have a null `patternTransform`. I added this check as `setLinearGradient` and `setRadialGradient` functions have also added them, when instances of `Gradient` can't have null as its transform. Should this null check be removed? I think leaving it for consistency is fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From jvos at openjdk.java.net Thu Nov 5 16:41:09 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Nov 2020 16:41:09 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6] In-Reply-To: References: Message-ID: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> > Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: change invocation of getEGLDisplayHandle into getEglDisplayHandle Conditionally add dlfcn ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/343/files - new: https://git.openjdk.java.net/jfx/pull/343/files/932fd001..dd6cf712 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=343&range=04-05 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/343.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/343/head:pull/343 PR: https://git.openjdk.java.net/jfx/pull/343 From jpereda at openjdk.java.net Thu Nov 5 18:19:58 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 5 Nov 2020 18:19:58 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6] In-Reply-To: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> References: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> Message-ID: On Thu, 5 Nov 2020 16:41:09 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > change invocation of getEGLDisplayHandle into getEglDisplayHandle > Conditionally add dlfcn Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From github.com+1413266+jgneff at openjdk.java.net Thu Nov 5 19:30:55 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 5 Nov 2020 19:30:55 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6] In-Reply-To: References: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> Message-ID: <3U7GPR_bR24CGpsb7o_mzO6ktffveq25OE2vSl11nLs=.e44ddb66-619f-4e0a-9cf4-6854c3d43bb1@github.com> On Thu, 5 Nov 2020 18:16:58 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> change invocation of getEGLDisplayHandle into getEglDisplayHandle >> Conditionally add dlfcn > > Marked as reviewed by jpereda (Committer). The fix for the compile-time error still fails for target *armv6hf*: `MonocleGLFactory.c:110:19: error: ?RTLD_DEFAULT? undeclared (first use in this function)`. Here's one solution: --- a/modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c +++ b/modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c @@ -29,16 +29,13 @@ #include #include +#ifndef ANDROID_NDK +#define __USE_GNU +#endif #include #include "eglUtils.h" -#include "../PrismES2Defs.h" - #include "com_sun_prism_es2_MonocleGLContext.h" -#ifndef ANDROID -#define __USE_GNU -#include -#endif extern void *get_dlsym(void *handle, const char *symbol, int warn); ``` Turns out `eglUtils.h` already includes `../PrismES2Defs.h`, which also includes `` and defines `__USE_GNU` if it's not already defined. I'm still trying to understand why we need to define `__USE_GNU` ahead of time right at the top there. I'll add another comment if I figure it out. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Thu Nov 5 20:12:54 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 5 Nov 2020 20:12:54 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6] In-Reply-To: <3U7GPR_bR24CGpsb7o_mzO6ktffveq25OE2vSl11nLs=.e44ddb66-619f-4e0a-9cf4-6854c3d43bb1@github.com> References: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> <3U7GPR_bR24CGpsb7o_mzO6ktffveq25OE2vSl11nLs=.e44ddb66-619f-4e0a-9cf4-6854c3d43bb1@github.com> Message-ID: On Thu, 5 Nov 2020 19:27:54 GMT, John Neffenger wrote: >> Marked as reviewed by jpereda (Committer). > > The fix for the compile-time error still fails for target *armv6hf*: `MonocleGLFactory.c:110:19: error: ?RTLD_DEFAULT? undeclared (first use in this function)`. Here's one solution: > > --- a/modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c > +++ b/modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c > @@ -29,16 +29,13 @@ > #include > #include > > +#ifndef ANDROID_NDK > +#define __USE_GNU > +#endif > #include > #include "eglUtils.h" > > -#include "../PrismES2Defs.h" > - > #include "com_sun_prism_es2_MonocleGLContext.h" > -#ifndef ANDROID > -#define __USE_GNU > -#include > -#endif > > extern void *get_dlsym(void *handle, const char *symbol, int warn); > ``` > > Turns out `eglUtils.h` already includes `../PrismES2Defs.h`, which also includes `` and defines `__USE_GNU` if it's not already defined. > > I'm still trying to understand why we need to define `__USE_GNU` ahead of time right at the top there. I'll add another comment if I figure it out. That sounds like an issue with your toolchain. RTLD_DEFAULT is not standard posix, but the toolchain should detect to use GNU_SOURCE. Maybe you can specify it to the compiler? ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From kcr at openjdk.java.net Thu Nov 5 20:35:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 5 Nov 2020 20:35:54 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6] In-Reply-To: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> References: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> Message-ID: On Thu, 5 Nov 2020 16:41:09 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > change invocation of getEGLDisplayHandle into getEglDisplayHandle > Conditionally add dlfcn Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From github.com+1413266+jgneff at openjdk.java.net Thu Nov 5 20:59:55 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 5 Nov 2020 20:59:55 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6] In-Reply-To: References: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> Message-ID: On Thu, 5 Nov 2020 20:33:05 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> change invocation of getEGLDisplayHandle into getEglDisplayHandle >> Conditionally add dlfcn > > Marked as reviewed by kcr (Lead). Thanks, Johan. Can we compare build environments? I cross-compile on Ubuntu 20.04.1 LTS. I followed the instructions at [Cross Building for ARM Hard Float][1] to fetch the toolchain. I use OpenJDK 14.0.2, Ant 1.10.7, and Gradle 6.3, by sourcing this script: # Sets up the environment for building JavaFX syspath=/usr/sbin:/usr/bin:/sbin:/bin export JAVA_HOME=/usr/lib/jvm/java-14-openjdk-amd64 export ANT_HOME=/usr/share/ant export GRADLE_HOME=$HOME/opt/gradle-6.3 # JDK_HOME and PATH are required by the build export JDK_HOME=$JAVA_HOME export PATH=$GRADLE_HOME/bin:$ANT_HOME/bin:$JAVA_HOME/bin:$syspath I build with the command: ubuntu at openjfx:~/src/jfx$ gradle -PCOMPILE_TARGETS=armv6hf [1]: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Fri Nov 6 08:10:54 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 6 Nov 2020 08:10:54 GMT Subject: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6] In-Reply-To: References: <_Z8uaqXnluugvp0bppBhZEa1u5P74OccncAFa6B74p0=.a0935135-966f-4181-b92e-8c6a5f6dc3f7@github.com> Message-ID: On Thu, 5 Nov 2020 20:57:13 GMT, John Neffenger wrote: >> Marked as reviewed by kcr (Lead). > > Thanks, Johan. Can we compare build environments? I cross-compile on Ubuntu 20.04.1 LTS. I followed the instructions at [Cross Building for ARM Hard Float][1] to fetch the toolchain. I use OpenJDK 14.0.2, Ant 1.10.7, and Gradle 6.3, by sourcing this script: > > # Sets up the environment for building JavaFX > syspath=/usr/sbin:/usr/bin:/sbin:/bin > > export JAVA_HOME=/usr/lib/jvm/java-14-openjdk-amd64 > export ANT_HOME=/usr/share/ant > export GRADLE_HOME=$HOME/opt/gradle-6.3 > > # JDK_HOME and PATH are required by the build > export JDK_HOME=$JAVA_HOME > export PATH=$GRADLE_HOME/bin:$ANT_HOME/bin:$JAVA_HOME/bin:$syspath > > I build with the command: > > ubuntu at openjfx:~/src/jfx$ gradle -PCOMPILE_TARGETS=armv6hf > > [1]: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float Let's discuss the build procedures offline. In case some changes are needed, we can file a new issue for this. ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From jvos at openjdk.java.net Fri Nov 6 08:10:57 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 6 Nov 2020 08:10:57 GMT Subject: Integrated: 8254569: Remove hard dependency on Dispman in Monocle fb rendering In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 15:09:49 GMT, Johan Vos wrote: > Allow the EGL functionality in monocle to leverage EGL-based systems. The low-level specific details about how the EGL calls should be constructed are left out, and a native interface (egl_ext.h) is created that can be mapped to any low-level system. This pull request has now been integrated. Changeset: ade32272 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/ade32272 Stats: 347 lines in 7 files changed: 343 ins; 0 del; 4 mod 8254569: Remove hard dependency on Dispman in Monocle fb rendering Reviewed-by: kcr, jpereda ------------- PR: https://git.openjdk.java.net/jfx/pull/343 From arapte at openjdk.java.net Fri Nov 6 09:55:57 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 6 Nov 2020 09:55:57 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 03:11:18 GMT, Arun Joseph wrote: >> fillPath() and fillRect() functions in [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as ImagePattern doesn't have the same attribute. So, the final image won't be transformed. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect concat param order Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From ajoseph at openjdk.java.net Fri Nov 6 10:02:56 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 6 Nov 2020 10:02:56 GMT Subject: Integrated: 8242861: Update ImagePattern to apply SVG pattern transforms In-Reply-To: References: Message-ID: On Mon, 20 Apr 2020 05:40:51 GMT, Arun Joseph wrote: > fillPath() and fillRect() functions in [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as ImagePattern doesn't have the same attribute. So, the final image won't be transformed. This pull request has now been integrated. Changeset: dd22cd2d Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/dd22cd2d Stats: 104 lines in 6 files changed: 83 ins; 11 del; 10 mod 8242861: Update ImagePattern to apply SVG pattern transforms Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From kcr at openjdk.java.net Fri Nov 6 23:37:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 Nov 2020 23:37:58 GMT Subject: RFR: 8177945: Single cell selection flickers when adding data to TableView In-Reply-To: References: Message-ID: <4TB8rPUtnx4KEZ1i2mSzVQNbqpantXYLy9cwceSBVso=.0a0c19b6-5a53-49be-af25-9d8981a691a9@github.com> On Wed, 4 Nov 2020 17:25:16 GMT, Jose Pereda wrote: > As discussed in the JBS [issue](https://bugs.openjdk.java.net/browse/JDK-8177945), there are some inconsistencies in the use of `VirtualContainerBase::requestRebuildCells` from `VirtualContainerBase::updateItemCount()`, which is implemented in the different skin classes for virtualised controls `TableViewSkinBase`, `ListViewSkin` or `TreeTableViewSkin`. > > The latter already commented out this call (related to JDK-8155798 and JDK-8147483). > > This PR removes now the calls to `VirtualContainerBase::requestRebuildCells` from `TableViewSkinBase` (except for the case `itemCount = 0` based on JDK-8118897 and JDK-8098235) and `ListViewSkin`. > > A test is provided for TableView, that verifies that the `selected` pseudo-class state remains set for the selected cell while adding more items. Without this fix, as the cells are rebuilt, the pseudo-class states are clean and set all over again, thus the flickering. > > For ListView, the test rt_35395 (JDK-8091726) is updated, as now there are way less calls to updateItem. The fix looks good with one question and one minor suggestion. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListViewSkin.java line 359: > 357: > 358: updatePlaceholderRegionVisibility(); > 359: if (newCount == oldCount) { Does this also need the same `else if (oldCount == 0)` test that you added to `TableViewSkinBase`? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5482: > 5480: > 5481: @Test > 5482: // see JDK-8177945 Minor: It seems best to not have the comment between the annotation and the method being annotated. I see this pattern also in `VirtualFlowTest`, but you might want to move the comment above the annotation. ------------- PR: https://git.openjdk.java.net/jfx/pull/348 From kevin.rushforth at oracle.com Sat Nov 7 14:02:40 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 7 Nov 2020 06:02:40 -0800 Subject: Result: New OpenJFX Committer: Pankaj Bansal Message-ID: Voting for Pankaj Bansal [1] to OpenJFX Committer [2] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#pbansal [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-October/027988.html From github.com+1413266+jgneff at openjdk.java.net Sat Nov 7 23:17:58 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 7 Nov 2020 23:17:58 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux Message-ID: This pull request fixes the error when building embedded JavaFX for Linux. The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the header file has already been included at that point, and the header contains include guards to ignore subsequent attempts. MonocleGLFactory.c ... #include #include "eglUtils.h" #include "../PrismES2Defs.h" #include "com_sun_prism_es2_MonocleGLContext.h" #ifndef ANDROID #define __USE_GNU #include #endif ... The `-H` option of `gcc` prints the name of each header file used. Its output shows that `egl.h` ends up including `dlfcn.h` indirectly, but without the required macro definition. $ grep -e 'EGL/egl.h' -e 'eglUtils.h' -e 'dlfcn.h' headers.log . opt/vc/include/EGL/egl.h ...... usr/include/dlfcn.h ....... usr/include/arm-linux-gnueabihf/bits/dlfcn.h . monocle/eglUtils.h For the proposed fix, I referred to the page of the *Linux Programmer's Manual* at "`man dlsym`" which states, "The `_GNU_SOURCE` feature test macro must be defined in order to obtain the definitions of `RTLD_DEFAULT` and `RTLD_NEXT` from ``." I also used information in the following two Stack Overflow conversations: * ['RTLD_NEXT' undeclared][1] * [_GNU_SOURCE and __USE_GNU][2] [1]: https://stackoverflow.com/q/1777397 [2]: https://stackoverflow.com/q/7296963 ------------- Commit messages: - 8256012: Fix build of Monocle for Linux Changes: https://git.openjdk.java.net/jfx/pull/350/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=350&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256012 Stats: 9 lines in 1 file changed: 3 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/350.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/350/head:pull/350 PR: https://git.openjdk.java.net/jfx/pull/350 From ajoseph at openjdk.java.net Mon Nov 9 03:54:54 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 9 Nov 2020 03:54:54 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 00:38:31 GMT, Kevin Rushforth wrote: >> We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. >> >> Test: Run PublicSuffixesTest.java > > modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 132: > >> 130: return null; >> 131: } >> 132: return rulesCache.computeIfAbsent(tld, k -> createRules(tld)); > > If the public_suffixes file cannot be loaded (for example, if it is removed from the JDK), then this causes a warning to be logged on every call to this (basically on every load of any web site). It might be better to call `createRules` from a static init block. If `createRules` is called from a static init block, then all the public suffix rules (for all TLDs) must be loaded during initialization. Another approach would be to set a `fileNotFound` flag which could be set to true in `getPubSuffixStream` and call `Rules.getRules` only when the value is `false`. ------------- PR: https://git.openjdk.java.net/jfx/pull/324 From jpereda at openjdk.java.net Mon Nov 9 09:29:58 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 9 Nov 2020 09:29:58 GMT Subject: RFR: 8177945: Single cell selection flickers when adding data to TableView In-Reply-To: <4TB8rPUtnx4KEZ1i2mSzVQNbqpantXYLy9cwceSBVso=.0a0c19b6-5a53-49be-af25-9d8981a691a9@github.com> References: <4TB8rPUtnx4KEZ1i2mSzVQNbqpantXYLy9cwceSBVso=.0a0c19b6-5a53-49be-af25-9d8981a691a9@github.com> Message-ID: On Fri, 6 Nov 2020 23:33:08 GMT, Kevin Rushforth wrote: >> As discussed in the JBS [issue](https://bugs.openjdk.java.net/browse/JDK-8177945), there are some inconsistencies in the use of `VirtualContainerBase::requestRebuildCells` from `VirtualContainerBase::updateItemCount()`, which is implemented in the different skin classes for virtualised controls `TableViewSkinBase`, `ListViewSkin` or `TreeTableViewSkin`. >> >> The latter already commented out this call (related to JDK-8155798 and JDK-8147483). >> >> This PR removes now the calls to `VirtualContainerBase::requestRebuildCells` from `TableViewSkinBase` (except for the case `itemCount = 0` based on JDK-8118897 and JDK-8098235) and `ListViewSkin`. >> >> A test is provided for TableView, that verifies that the `selected` pseudo-class state remains set for the selected cell while adding more items. Without this fix, as the cells are rebuilt, the pseudo-class states are clean and set all over again, thus the flickering. >> >> For ListView, the test rt_35395 (JDK-8091726) is updated, as now there are way less calls to updateItem. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListViewSkin.java line 359: > >> 357: >> 358: updatePlaceholderRegionVisibility(); >> 359: if (newCount == oldCount) { > > Does this also need the same `else if (oldCount == 0)` test that you added to `TableViewSkinBase`? `TableViewSkinBase` has an `itemsChangeListener` that triggers the `rowCountListener`, which sets `itemCount = 0` when an item has been replaced. `ListViewSkin` uses a different approach via `listViewItemsListener` -> `flow::setCellDirty`. However, the same approach (`itemCount = 0`) is used in both cases when the list of items is cleared, so I'll add it here as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/348 From jpereda at openjdk.java.net Mon Nov 9 09:39:11 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 9 Nov 2020 09:39:11 GMT Subject: RFR: 8177945: Single cell selection flickers when adding data to TableView [v2] In-Reply-To: References: Message-ID: > As discussed in the JBS [issue](https://bugs.openjdk.java.net/browse/JDK-8177945), there are some inconsistencies in the use of `VirtualContainerBase::requestRebuildCells` from `VirtualContainerBase::updateItemCount()`, which is implemented in the different skin classes for virtualised controls `TableViewSkinBase`, `ListViewSkin` or `TreeTableViewSkin`. > > The latter already commented out this call (related to JDK-8155798 and JDK-8147483). > > This PR removes now the calls to `VirtualContainerBase::requestRebuildCells` from `TableViewSkinBase` (except for the case `itemCount = 0` based on JDK-8118897 and JDK-8098235) and `ListViewSkin`. > > A test is provided for TableView, that verifies that the `selected` pseudo-class state remains set for the selected cell while adding more items. Without this fix, as the cells are rebuilt, the pseudo-class states are clean and set all over again, thus the flickering. > > For ListView, the test rt_35395 (JDK-8091726) is updated, as now there are way less calls to updateItem. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/348/files - new: https://git.openjdk.java.net/jfx/pull/348/files/ab640948..eb69b4ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=348&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=348&range=00-01 Stats: 4 lines in 2 files changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/348/head:pull/348 PR: https://git.openjdk.java.net/jfx/pull/348 From jpereda at openjdk.java.net Mon Nov 9 11:39:02 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 9 Nov 2020 11:39:02 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels Message-ID: As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. ------------- Commit messages: - Call updateOutputScales before the scene initialization, including system test Changes: https://git.openjdk.java.net/jfx/pull/351/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=351&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8199592 Stats: 121 lines in 2 files changed: 115 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/351.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/351/head:pull/351 PR: https://git.openjdk.java.net/jfx/pull/351 From fluidlogix.fi at gmail.com Mon Nov 9 13:54:31 2020 From: fluidlogix.fi at gmail.com (FluidLogix Studios) Date: Mon, 9 Nov 2020 15:54:31 +0200 Subject: Keep up the great work! Message-ID: I'm just here to say how nice it is that you are fixing these "little" but important long standing issues! (e.g. JDK-8199592, JDK-8255415, and JDK-8178297) While I'm here, I'll also sneak in a question: is anyone planning to tackle JDK-8211907? Most modern and popular desktop apps nowadays use undecorated frames (VS Code, Discord, Slack, Intellij IDEA, all Web Browsers, etc. etc.), and in my humble opinion, this seemingly little thing is quite important for Windows users. Anyways, thank you, and keep up the great work! From kcr at openjdk.java.net Mon Nov 9 16:08:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 Nov 2020 16:08:59 GMT Subject: RFR: 8177945: Single cell selection flickers when adding data to TableView [v2] In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 09:39:11 GMT, Jose Pereda wrote: >> As discussed in the JBS [issue](https://bugs.openjdk.java.net/browse/JDK-8177945), there are some inconsistencies in the use of `VirtualContainerBase::requestRebuildCells` from `VirtualContainerBase::updateItemCount()`, which is implemented in the different skin classes for virtualised controls `TableViewSkinBase`, `ListViewSkin` or `TreeTableViewSkin`. >> >> The latter already commented out this call (related to JDK-8155798 and JDK-8147483). >> >> This PR removes now the calls to `VirtualContainerBase::requestRebuildCells` from `TableViewSkinBase` (except for the case `itemCount = 0` based on JDK-8118897 and JDK-8098235) and `ListViewSkin`. >> >> A test is provided for TableView, that verifies that the `selected` pseudo-class state remains set for the selected cell while adding more items. Without this fix, as the cells are rebuilt, the pseudo-class states are clean and set all over again, thus the flickering. >> >> For ListView, the test rt_35395 (JDK-8091726) is updated, as now there are way less calls to updateItem. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/348 From fastegal at swingempire.de Wed Nov 11 10:00:37 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 11 Nov 2020 11:00:37 +0100 Subject: compile errors around JMemoryBuddy In-Reply-To: <20201103140750.Horde.a5GyOAdQ60rKUzGpS70Ofg1@webmail.df.eu> References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> <20201103140750.Horde.a5GyOAdQ60rKUzGpS70Ofg1@webmail.df.eu> Message-ID: <20201111110037.Horde.P7R31SRWuScl-GD90tn0zw7@webmail.df.eu> FYI: filed an issue https://bugs.openjdk.java.net/browse/JDK-8256184 don't know what the plans for supporting IDE builds are - but as long as it is available, they should work, IMO. -- Jeanette Zitat von Jeanette Winzenburg : > Zitat von Florian Kirmaier : > >> Eclipse probably handles the modules differently than Gradle. > > probably - couldn't find gradle's magic in the build script (and > lost interest, because that part is running okay and there are > enough experts around to keep it that way :) > >> The simplest solution would be to remove the code to automatically create >> heap dumps. >> Adding java.management to module-info of the tests doesn't sound wrong to >> me if it's using it. >> > > that's basically, what I ended up with. > > To summarize the problem: when compiling base and running tests of > controls in Eclipse I got > > a) JMemoryBuddy doesn't compile, Eclipse suggests to add requires > jdk.management and java.management > b) following the suggestion, some controls test don't compile due to > base:test.util.memory not being accessible > > As changing production module-info is not an option (and Eclipse' > support for test module-info is wip - see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601 ) I played a > bit with the (new to me ;) module dependencies tab in build path > config and added reads to both modules. Couldn't find a way to add > them to test sources only (Eclipse added them to java src), so > manually moved in .classpath file, its test entry now is: > > > > > > > value="javafx.base=jdk.management:javafx.base=java.management"/> > > > > This fixed the error in base. > > To fix the error in controls, I added the export of new base test > package in :controls .classpath > > > > > value="javafx.base/test.com.sun.javafx.binding=javafx.controls:javafx.base/test.util.memory=javafx.controls"/> > > > > no idea how stable all this is, working for me at least. Should the > eclipse specific files updated in master, with this or something > similar/better? > > Opinions, please? > > -- Jeanette > > > >> On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth >> wrote: >> >>> I didn't try it with an earlier JDK, but if it breaks when using JDK 11 >>> it will need to be fixed. >>> >>> -- Kevin >>> >>> >>> On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote: >>>> >>>> just fetched the latest upstream master and getting compile errors >>>> around xx.management packages (eclipse wants to add requires into the >>>> module-info - which certainly is the wrong way to go ;) Compiling >>>> against jdk12, if that matters (will update one of these days but >>>> shouldn't jdk11 be good enough). >>>> >>>> Any quick ideas on what might be wrong? >>>> >>>> -- Jeanette >>>> >>>> >>> >>> From kevin.rushforth at oracle.com Wed Nov 11 14:00:34 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 Nov 2020 06:00:34 -0800 Subject: compile errors around JMemoryBuddy In-Reply-To: <20201111110037.Horde.P7R31SRWuScl-GD90tn0zw7@webmail.df.eu> References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> <20201103140750.Horde.a5GyOAdQ60rKUzGpS70Ofg1@webmail.df.eu> <20201111110037.Horde.P7R31SRWuScl-GD90tn0zw7@webmail.df.eu> Message-ID: Yes, it does seem that as long as the .classpath files are in the repo, they should work. I assigned the JBS bug to you since you have proposed a fix. You can reassign it if you want. I'm not an Eclipse user, so it would need to be done by someone who is. -- Kevin On 11/11/2020 2:00 AM, Jeanette Winzenburg wrote: > > FYI: filed an issue https://bugs.openjdk.java.net/browse/JDK-8256184 > > don't know what the plans for supporting IDE builds are - but as long > as it is available, they should work, IMO. > > -- Jeanette > > Zitat von Jeanette Winzenburg : > >> Zitat von Florian Kirmaier : >> >>> Eclipse probably handles the modules differently than Gradle. >> >> probably - couldn't find gradle's magic in the build script (and lost >> interest, because that part is running okay and there are enough >> experts around to keep it that way :) >> >>> The simplest solution would be to remove the code to automatically >>> create >>> heap dumps. >>> Adding java.management to module-info of the tests doesn't sound >>> wrong to >>> me if it's using it. >>> >> >> that's basically, what I ended up with. >> >> To summarize the problem: when compiling base and running tests of >> controls in Eclipse I got >> >> a) JMemoryBuddy doesn't compile, Eclipse suggests to add requires >> jdk.management and java.management >> b) following the suggestion, some controls test don't compile due to >> base:test.util.memory not being accessible >> >> As changing production module-info is not an option (and Eclipse' >> support for test module-info is wip - see >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601 ) I played a bit >> with the (new to me ;) module dependencies tab in build path config >> and added reads to both modules. Couldn't find a way to add them to >> test sources only (Eclipse added them to java src), so manually moved >> in .classpath file, its test entry now is: >> >> >> ???? >> ??????? >> ??????? >> ??????? >> ??????? > value="javafx.base=jdk.management:javafx.base=java.management"/> >> ???? >> >> >> This fixed the error in base. >> >> To fix the error in controls, I added the export of new base test >> package in :controls .classpath >> >> >> ???? >> ??????? >> ??????? > value="javafx.base/test.com.sun.javafx.binding=javafx.controls:javafx.base/test.util.memory=javafx.controls"/> >> ???? >> >> >> no idea how stable all this is, working for me at least. Should the >> eclipse specific files updated in master, with this or something >> similar/better? >> >> Opinions, please? >> >> -- Jeanette >> >> >> >>> On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth >>> >>> wrote: >>> >>>> I didn't try it with an earlier JDK, but if it breaks when using >>>> JDK 11 >>>> it will need to be fixed. >>>> >>>> -- Kevin >>>> >>>> >>>> On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote: >>>>> >>>>> just fetched the latest upstream master and getting compile errors >>>>> around xx.management packages (eclipse wants to add requires into the >>>>> module-info - which certainly is the wrong way to go ;) Compiling >>>>> against jdk12, if that matters (will update one of these days but >>>>> shouldn't jdk11 be good enough). >>>>> >>>>> Any quick ideas on what might be wrong? >>>>> >>>>> -- Jeanette >>>>> >>>>> >>>> >>>> > > > From github.com+31666175+jonathanvusich at openjdk.java.net Wed Nov 11 16:01:02 2020 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Wed, 11 Nov 2020 16:01:02 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off Message-ID: As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. ------------- Commit messages: - Added fix and test Changes: https://git.openjdk.java.net/jfx/pull/342/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255572 Stats: 90 lines in 2 files changed: 90 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342 From kcr at openjdk.java.net Wed Nov 11 16:12:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 11 Nov 2020 16:12:00 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 15:15:22 GMT, Jonathan Vusich wrote: > As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. Can you merge in the latest `jfx/master`? That way the GitHub actions build/test will be run (although it won't run the new headful test). You also need a copyright header as noted below. tests/system/src/test/java/test/javafx/scene/chart/ChartAxisLayoutTest.java line 1: > 1: package test.javafx.scene.chart; You need a standard copyright header here. See any of the other test classes for an example (should be just a single `2020,` for the year). ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From github.com+31666175+jonathanvusich at openjdk.java.net Wed Nov 11 18:05:08 2020 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Wed, 11 Nov 2020 18:05:08 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v2] In-Reply-To: References: Message-ID: > As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Added copyright header - Merge branch 'master' into jonathan/fix-chart-axis-labels - Added fix and test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/342/files - new: https://git.openjdk.java.net/jfx/pull/342/files/e3eb791e..49a5e1f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=00-01 Stats: 1552 lines in 40 files changed: 1343 ins; 136 del; 73 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342 From github.com+31666175+jonathanvusich at openjdk.java.net Wed Nov 11 18:05:09 2020 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Wed, 11 Nov 2020 18:05:09 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v2] In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 16:08:20 GMT, Kevin Rushforth wrote: >> Jonathan Vusich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Added copyright header >> - Merge branch 'master' into jonathan/fix-chart-axis-labels >> - Added fix and test > > tests/system/src/test/java/test/javafx/scene/chart/ChartAxisLayoutTest.java line 1: > >> 1: package test.javafx.scene.chart; > > You need a standard copyright header here. See any of the other test classes for an example (should be just a single `2020,` for the year). I'll get right on it. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From johan.vos at gluonhq.com Thu Nov 12 10:09:32 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 12 Nov 2020 11:09:32 +0100 Subject: Request for permission to backport 3 issues to JavaFX 11 Message-ID: Hi Kevin, I request permission to backport the following issues to JavaFX 11 (for 11.0.10) JDK-8223296: NullPointerException in GlassScene.java at line 325 JDK-8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread JDK-8209764: JavaFX/Monocle - Partial Screen Capture Broken Thanks, - Johan From fastegal at openjdk.java.net Thu Nov 12 11:28:01 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 12 Nov 2020 11:28:01 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) Message-ID: Issue was broken build in Eclipse after fix of [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): - the new memory test class requires jdk.management/java.management - users of the test class (in controls) need access to its package Changed .classpath files in base and controls to fix this. ------------- Commit messages: - 8256184: Openjfx build broken (Eclipse) Changes: https://git.openjdk.java.net/jfx/pull/352/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=352&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256184 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/352.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/352/head:pull/352 PR: https://git.openjdk.java.net/jfx/pull/352 From kevin.rushforth at oracle.com Thu Nov 12 13:49:13 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Nov 2020 05:49:13 -0800 Subject: Request for permission to backport 3 issues to JavaFX 11 In-Reply-To: References: Message-ID: <4db04848-74cc-f156-a3ff-f049b53144be@oracle.com> +1 On 11/12/2020 2:09 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issues to JavaFX 11 (for > 11.0.10) > > JDK-8223296: NullPointerException in GlassScene.java at line 325 > JDK-8201567: QuantumRenderer modifies buffer in use by JavaFX Application > Thread > JDK-8209764: JavaFX/Monocle - Partial Screen Capture Broken > > Thanks, > > - Johan From kcr at openjdk.java.net Thu Nov 12 13:52:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Nov 2020 13:52:57 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 11:24:15 GMT, Jeanette Winzenburg wrote: > Issue was broken build in Eclipse after fix of [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): > > - the new memory test class requires jdk.management/java.management > - users of the test class (in controls) need access to its package > > Changed .classpath files in base and controls to fix this. The change looks reasonable to me, but since I don't use Eclipse it would be better for someone who does to review. @nlisker can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From tsayao at openjdk.java.net Thu Nov 12 17:34:16 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 12 Nov 2020 17:34:16 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend [v63] 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 13 additional commits since the last revision: - Restore WM_CLASS functionality (as described on the code comment). - Merge branch 'master' into jdk_8236651 - Merge pull request #13 from openjdk/master Merge master - 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 - Merge pull request #12 from openjdk/master Merge with main - Merge pull request #11 from openjdk/master Merge from upstream - Merge pull request #10 from openjdk/master Update from master - Merge pull request #9 from openjdk/master Merge from upstream - Merge pull request #8 from openjdk/master Merge upstream - Merge pull request #7 from openjdk/master merge from jfx - ... and 3 more: https://git.openjdk.java.net/jfx/compare/a93406ae...e19295f3 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/97c67419..e19295f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=77&range=62 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=77&range=61-62 Stats: 37178 lines in 274 files changed: 3827 ins; 32925 del; 426 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 nlisker at openjdk.java.net Mon Nov 16 08:34:57 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 16 Nov 2020 08:34:57 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 13:50:41 GMT, Kevin Rushforth wrote: >> Issue was broken build in Eclipse after fix of [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): >> >> - the new memory test class requires jdk.management/java.management >> - users of the test class (in controls) need access to its package >> >> Changed .classpath files in base and controls to fix this. > > The change looks reasonable to me, but since I don't use Eclipse it would be better for someone who does to review. > @nlisker can you review this? These changes look fine, but do you not get errors on the test module too? `test.javafx.scene.InitialNodesMemoryLeakTest` uses `import test.util.memory.JMemoryBuddy;`; so does `VirtualFlowMemoryLeakTest`. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Mon Nov 16 09:36:54 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 16 Nov 2020 09:36:54 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> On Mon, 16 Nov 2020 08:32:30 GMT, Nir Lisker wrote: > > > These changes look fine, but do you not get errors on the test module too? `test.javafx.scene.InitialNodesMemoryLeakTest` uses `import test.util.memory.JMemoryBuddy;`; so does `VirtualFlowMemoryLeakTest`. Good point .. didn't notice as I don't run system tests from Eclipse. Hmm .. would like to keep this focused on base/controls. We might open a reminder bug to check the other moduls. What do you think? ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From nlisker at openjdk.java.net Mon Nov 16 11:54:53 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 16 Nov 2020 11:54:53 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Mon, 16 Nov 2020 09:34:17 GMT, Jeanette Winzenburg wrote: >> These changes look fine, but do you not get errors on the test module too? `test.javafx.scene.InitialNodesMemoryLeakTest` uses `import test.util.memory.JMemoryBuddy;`; so does `VirtualFlowMemoryLeakTest`. > >> >> >> These changes look fine, but do you not get errors on the test module too? `test.javafx.scene.InitialNodesMemoryLeakTest` uses `import test.util.memory.JMemoryBuddy;`; so does `VirtualFlowMemoryLeakTest`. > > Good point .. didn't notice as I don't run system tests from Eclipse. > > Hmm .. would like to keep this focused on base/controls. We might open a reminder bug to check the other moduls. What do you think? I think that it should be fixed as part of this patch since it addresses exactly the same issue from the same cause. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Mon Nov 16 12:02:55 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 16 Nov 2020 12:02:55 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Mon, 16 Nov 2020 11:52:23 GMT, Nir Lisker wrote: > > > I think that it should be fixed as part of this patch since it addresses exactly the same issue from the same cause. perfectly valid (and what I would say as well ;) - but then I'm out - no intention to further fiddle with tooling that I'm not entirely confident with. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From florian.kirmaier at gmail.com Mon Nov 16 14:44:15 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Mon, 16 Nov 2020 15:44:15 +0100 Subject: RFR: JDK-8256397 MultipleSelectionModel throws IndexOutOfBoundException Message-ID: Hi everyone, I've developed a fix for an exception in the MultipleSelectionModel. Can someone look into it? https://github.com/openjdk/jfx/pull/353 Greetings Florian Kirmaier From fkirmaier at openjdk.java.net Mon Nov 16 14:46:15 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 16 Nov 2020 14:46:15 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException Message-ID: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` ------------- Commit messages: - 8256397 Changes: https://git.openjdk.java.net/jfx/pull/353/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=353&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256397 Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/353.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/353/head:pull/353 PR: https://git.openjdk.java.net/jfx/pull/353 From ajoseph at openjdk.java.net Tue Nov 17 04:08:15 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 17 Nov 2020 04:08:15 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v2] In-Reply-To: References: Message-ID: > We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Check whether PSL file exists ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/e5c9d4de..6ed148f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=00-01 Stats: 35 lines in 2 files changed: 27 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324 From nlisker at openjdk.java.net Tue Nov 17 09:28:59 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 17 Nov 2020 09:28:59 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Mon, 16 Nov 2020 11:59:59 GMT, Jeanette Winzenburg wrote: >> I think that it should be fixed as part of this patch since it addresses exactly the same issue from the same cause. > >> >> >> I think that it should be fixed as part of this patch since it addresses exactly the same issue from the same cause. > > perfectly valid (and what I would say as well ;) - but then I'm out - no intention to further fiddle with tooling that I'm not entirely confident with. Change the following in `\tests.classpath`: ^ add here See if these errors are resolved. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From nlisker at gmail.com Tue Nov 17 10:07:32 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 17 Nov 2020 12:07:32 +0200 Subject: Lanai and JavaFX Message-ID: Hi, I didn't see any concrete plans for Lanai and JavaFX, just a mention that it would help JavaFX too. Are there any more details regarding JavaFX? There is also the 3D API which will completely break for any MacOS user and I didn't see anything in Lanai about that. - Nir From fastegal at openjdk.java.net Tue Nov 17 11:10:01 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 17 Nov 2020 11:10:01 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Tue, 17 Nov 2020 09:26:32 GMT, Nir Lisker wrote: >>> >>> >>> I think that it should be fixed as part of this patch since it addresses exactly the same issue from the same cause. >> >> perfectly valid (and what I would say as well ;) - but then I'm out - no intention to further fiddle with tooling that I'm not entirely confident with. > > Change the following in `\tests.classpath`: > > > > > > ^ add here > > > > See if these errors are resolved. thanks, that's probably working :) Didn't try, though, because verifying does require to setup all modules as projects (which I don't have, not being interested in swing/web/fxml) Plus this extra effort would only fix the _current_ usage of memorybuddy, leaving future inclusions in the other modules still broken. So where to go from here: - keep the scope of this issue focused on base/controls leaving the remaining projects to a new bug - widen the scope of this bug to include all projects (current users as well as future users) as you already rejected the first option, the second seems the way to go - that is, I will unassign the bug and close this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From nlisker at openjdk.java.net Tue Nov 17 11:17:05 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 17 Nov 2020 11:17:05 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Tue, 17 Nov 2020 11:07:22 GMT, Jeanette Winzenburg wrote: >> Change the following in `\tests.classpath`: >> >> >> >> >> >> ^ add here >> >> >> >> See if these errors are resolved. > > thanks, that's probably working :) Didn't try, though, because verifying does require to setup all modules as projects (which I don't have, not being interested in swing/web/fxml) Plus this extra effort would only fix the _current_ usage of memorybuddy, leaving future inclusions in the other modules still broken. > > So where to go from here: > > - keep the scope of this issue focused on base/controls leaving the remaining projects to a new bug > - widen the scope of this bug to include all projects (current users as well as future users) > > as you already rejected the first option, the second seems the way to go - that is, I will unassign the bug and close this PR? > Plus this extra effort would only fix the current usage of memorybuddy, leaving future inclusions in the other modules still broken. I think that this is fine. When future uses occur they should be accompanied by the inclusion of the dependency, unless we know of plans to use it in other modules. In any case, there is no need to close this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Tue Nov 17 11:32:00 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 17 Nov 2020 11:32:00 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Tue, 17 Nov 2020 11:14:49 GMT, Nir Lisker wrote: >> thanks, that's probably working :) Didn't try, though, because verifying does require to setup all modules as projects (which I don't have, not being interested in swing/web/fxml) Plus this extra effort would only fix the _current_ usage of memorybuddy, leaving future inclusions in the other modules still broken. >> >> So where to go from here: >> >> - keep the scope of this issue focused on base/controls leaving the remaining projects to a new bug >> - widen the scope of this bug to include all projects (current users as well as future users) >> >> as you already rejected the first option, the second seems the way to go - that is, I will unassign the bug and close this PR? > >> Plus this extra effort would only fix the current usage of memorybuddy, leaving future inclusions in the other modules still broken. > > I think that this is fine. When future uses occur they should be accompanied by the inclusion of the dependency, unless we know of plans to use it in other modules. In any case, there is no need to close this PR. okay, so will simply unassign the issue and leave the PR open for someone else to complete - thanks for your input :) ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Tue Nov 17 12:41:00 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 17 Nov 2020 12:41:00 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException In-Reply-To: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Mon, 16 Nov 2020 14:41:57 GMT, Florian Kirmaier wrote: > Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. > ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 > run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` good catch :) No review, just a couple of comments: - other subclasses of MultipleSelectionModelBase might have similar issues - the fix gets rid of the error (good!) but might fire incorrect changes (see below) - there are quite a lot of open issues related to change notification, some might profit from a fix of this - tests, tests, tests .. :) selectIndices might involve disjoint intervals in the change (even for addition which is unusual in the "normal" implementations of observableLists) // initial selection, starting from empty selectionModel.selectIndices(0, /*1, IMPORTANT: remove some index */ 2, 3); System.out.println(change); // expected and actual change { [0, 2, 3] added at 0 } // add selection of disjoint indices (assuming a longer items list) selectionModel.selectIndices(1, 5, 7); System.out.println(change); // actual { [1, 2, 3] added at 1 } // expected { [1] added at 1, [5, 7] added at 4 } ------------- PR: https://git.openjdk.java.net/jfx/pull/353 From kevin.rushforth at oracle.com Tue Nov 17 17:37:41 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Nov 2020 09:37:41 -0800 Subject: Lanai and JavaFX In-Reply-To: References: Message-ID: <423a69dc-7e90-3bcb-40fc-d45ce777312b@oracle.com> We've done some very early prototyping looking at what it will take to implement a Prism Metal pipeline for JavaFX. We can't directly use the code from the Java2D Metal pipeline, but should be able to leverage a lot of the ideas. -- Kevin On 11/17/2020 2:07 AM, Nir Lisker wrote: > Hi, > > I didn't see any concrete plans for Lanai and JavaFX, just a mention that > it would help JavaFX too. Are there any more details regarding JavaFX? > There is also the 3D API which will completely break for any MacOS user and > I didn't see anything in Lanai about that. > > - Nir From kcr at openjdk.java.net Tue Nov 17 18:16:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Nov 2020 18:16:05 GMT Subject: RFR: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath Message-ID: This fix adds documentation and a warning to clarify that loading the JavaFX modules from the classpath is not a supported configuration. This will not affect deployments that put the JavaFX modular jars on the classpath, but will simply warn that it is an unsupported mode. JavaFX is built and distributed as a set of named modules, each in its own modular jar file. This supports running both modular and non-modular applications. The JavaFX runtime expects its classes to be loaded from a set of named `javafx.*` modules, and does not support loading those modules from the classpath. The Java launcher will fail to load applications that extend `javafx.application.Application` unless the `javafx.graphics` module is on the module path. Applications that do not extend `javafx.application.Application` can be loaded even if the `javafx.*` classes are loaded from the classpath, but this is an unsupported configuration. This creates the perception that there is a problem with the standard case of loading a subclass of `javafx.application.Application`, since it fails to load in the case where the JavaFX classes are loaded from the classpath. Further, allowing applications to run in an unsupported mode that likely has bugs creates a maintenance burden. Another problem is that when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we mo longer get the benefit of the java module system. The primary reason given for application deployments loading the javafx modules on the classpath usually boils down to one of tooling support, although both gradle and maven now support modules as do all of the popular IDEs. ------------- Commit messages: - 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath Changes: https://git.openjdk.java.net/jfx/pull/354/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=354&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256362 Stats: 39 lines in 4 files changed: 39 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/354.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/354/head:pull/354 PR: https://git.openjdk.java.net/jfx/pull/354 From nlisker at gmail.com Wed Nov 18 03:07:39 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 18 Nov 2020 05:07:39 +0200 Subject: Lanai and JavaFX In-Reply-To: <423a69dc-7e90-3bcb-40fc-d45ce777312b@oracle.com> References: <423a69dc-7e90-3bcb-40fc-d45ce777312b@oracle.com> Message-ID: So, bureaucratically speaking, will JavaFX have its own project? Is there a timeline? On Tue, Nov 17, 2020 at 7:38 PM Kevin Rushforth wrote: > We've done some very early prototyping looking at what it will take to > implement a Prism Metal pipeline for JavaFX. We can't directly use the > code from the Java2D Metal pipeline, but should be able to leverage a > lot of the ideas. > > -- Kevin > > > On 11/17/2020 2:07 AM, Nir Lisker wrote: > > Hi, > > > > I didn't see any concrete plans for Lanai and JavaFX, just a mention that > > it would help JavaFX too. Are there any more details regarding JavaFX? > > There is also the 3D API which will completely break for any MacOS user > and > > I didn't see anything in Lanai about that. > > > > - Nir > > From johan.vos at gluonhq.com Wed Nov 18 10:01:27 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 18 Nov 2020 11:01:27 +0100 Subject: Backport requests for JavaFX 11 Message-ID: Hi Kevin, I request approval to backport the following 2 issues to JavaFX 11 (for 11.0.10): JDK-8205092: NullPointerException in PickResultChooser.processOffer when using viewOrder JDK-8244112 : Skin implementations: must not violate contract of dispose - Johan From kevin.rushforth at oracle.com Wed Nov 18 13:23:57 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Nov 2020 05:23:57 -0800 Subject: Backport requests for JavaFX 11 In-Reply-To: References: Message-ID: <79dd32b6-baa2-03b1-a5e8-4598d2d85513@oracle.com> +1 -- Kevin On 11/18/2020 2:01 AM, Johan Vos wrote: > Hi Kevin, > > I request approval to backport the following 2 issues to JavaFX 11 (for > 11.0.10): > > JDK-8205092: NullPointerException in PickResultChooser.processOffer when > using viewOrder > JDK-8244112 : Skin implementations: must not violate contract of dispose > > - Johan From kcr at openjdk.java.net Thu Nov 19 02:15:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 02:15:07 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 11:34:25 GMT, Jose Pereda wrote: > As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. > > This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. > > It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java line 83: > 81: new Thread(() -> Application.launch(TestApp.class, (String[])null)).start(); > 82: try { > 83: if (!startupLatch.await(15, TimeUnit.SECONDS)) { If you add `throws Exception` to this method you can get rid of the try/catch and just do: assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); (this is the pattern we use for most of our newer tests) ------------- PR: https://git.openjdk.java.net/jfx/pull/351 From kcr at openjdk.java.net Thu Nov 19 02:20:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 02:20:02 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 11:34:25 GMT, Jose Pereda wrote: > As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. > > This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. > > It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. Looks good to me, but I want to run one more test on a dual screen setup tomorrow. I think that switching the order makes sense, and I can see no problems that it will cause. I am reasonably certain that whatever reason may have existed for the current order no longer pertains (there was a significant change to how screen scales were computed and tracked as a follow-on fix to the original HiDPI code that added the current block that you are moving). I verified that the new test catches the bug. I added one minor suggestion. ------------- PR: https://git.openjdk.java.net/jfx/pull/351 From aghaisas at openjdk.java.net Thu Nov 19 12:11:05 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 19 Nov 2020 12:11:05 GMT Subject: RFR: 8177945: Single cell selection flickers when adding data to TableView [v2] In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 09:39:11 GMT, Jose Pereda wrote: >> As discussed in the JBS [issue](https://bugs.openjdk.java.net/browse/JDK-8177945), there are some inconsistencies in the use of `VirtualContainerBase::requestRebuildCells` from `VirtualContainerBase::updateItemCount()`, which is implemented in the different skin classes for virtualised controls `TableViewSkinBase`, `ListViewSkin` or `TreeTableViewSkin`. >> >> The latter already commented out this call (related to JDK-8155798 and JDK-8147483). >> >> This PR removes now the calls to `VirtualContainerBase::requestRebuildCells` from `TableViewSkinBase` (except for the case `itemCount = 0` based on JDK-8118897 and JDK-8098235) and `ListViewSkin`. >> >> A test is provided for TableView, that verifies that the `selected` pseudo-class state remains set for the selected cell while adding more items. Without this fix, as the cells are rebuilt, the pseudo-class states are clean and set all over again, thus the flickering. >> >> For ListView, the test rt_35395 (JDK-8091726) is updated, as now there are way less calls to updateItem. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/348 From fastegal at openjdk.java.net Thu Nov 19 12:25:08 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 19 Nov 2020 12:25:08 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin Message-ID: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Cleanup of LabeledSkinBase to allow for switching skins - removed null check in listener on graphic's layoutBounds - added removal of listener in dispose ------------- Commit messages: - 8247576: Labeled/SkinBase: misbehavior on switching skin Changes: https://git.openjdk.java.net/jfx/pull/355/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247576 Stats: 147 lines in 2 files changed: 146 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/355.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/355/head:pull/355 PR: https://git.openjdk.java.net/jfx/pull/355 From fastegal at openjdk.java.net Thu Nov 19 13:14:06 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 19 Nov 2020 13:14:06 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin In-Reply-To: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: On Thu, 19 Nov 2020 12:20:47 GMT, Jeanette Winzenburg wrote: > Cleanup of LabeledSkinBase to allow for switching skins > > - removed null check in listener on graphic's layoutBounds > - added removal of listener in dispose hmm .. failing windows build, why? ------------- PR: https://git.openjdk.java.net/jfx/pull/355 From kcr at openjdk.java.net Thu Nov 19 13:38:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 13:38:02 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin In-Reply-To: References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: On Thu, 19 Nov 2020 13:11:05 GMT, Jeanette Winzenburg wrote: >> Cleanup of LabeledSkinBase to allow for switching skins >> >> - removed null check in listener on graphic's layoutBounds >> - added removal of listener in dispose > > hmm .. failing windows build, why? Not sure why it failed, but it's definitely not anything related to your change. I'll take a look at it, but in the mean time reviewers of this PR can ignore the failure. ------------- PR: https://git.openjdk.java.net/jfx/pull/355 From kevin.rushforth at oracle.com Thu Nov 19 13:56:54 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Nov 2020 05:56:54 -0800 Subject: Lanai and JavaFX In-Reply-To: References: <423a69dc-7e90-3bcb-40fc-d45ce777312b@oracle.com> Message-ID: <0db64432-505b-6bb3-8227-a711544b3353@oracle.com> I expect that the JavaFX Metal port will be done in OpenJFX project. We don't have a timeline yet. -- Kevin On 11/17/2020 7:07 PM, Nir Lisker wrote: > So, bureaucratically speaking, will JavaFX have its own project? Is > there a timeline? > > On Tue, Nov 17, 2020 at 7:38 PM Kevin Rushforth > > wrote: > > We've done some very early prototyping looking at what it will > take to > implement a Prism Metal pipeline for JavaFX. We can't directly use > the > code from the Java2D Metal pipeline, but should be able to leverage a > lot of the ideas. > > -- Kevin > > > On 11/17/2020 2:07 AM, Nir Lisker wrote: > > Hi, > > > > I didn't see any concrete plans for Lanai and JavaFX, just a > mention that > > it would help JavaFX too. Are there any more details regarding > JavaFX? > > There is also the 3D API which will completely break for any > MacOS user and > > I didn't see anything in Lanai about that. > > > > - Nir > From kcr at openjdk.java.net Thu Nov 19 14:02:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 14:02:02 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin In-Reply-To: References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: On Thu, 19 Nov 2020 13:35:25 GMT, Kevin Rushforth wrote: >> hmm .. failing windows build, why? > > Not sure why it failed, but it's definitely not anything related to your change. I'll take a look at it, but in the mean time reviewers of this PR can ignore the failure. I get the same build failure if I push to a branch that is even with master. Likely something changed in the GitHub configuration that we will need to adapt to. ------------- PR: https://git.openjdk.java.net/jfx/pull/355 From fastegal at openjdk.java.net Thu Nov 19 14:10:04 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 19 Nov 2020 14:10:04 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin In-Reply-To: References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: <1OANzCqaA8rNgeMb21npq3e3lcNOXM7U-lYJ4peR3Ws=.0552f330-4485-460c-ae12-d0bcbd48d67a@github.com> On Thu, 19 Nov 2020 13:35:25 GMT, Kevin Rushforth wrote: > > > Not sure why it failed, but it's definitely not anything related to your change. I'll take a look at it, but in the mean time reviewers of this PR can ignore the failure. thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/355 From fastegal at openjdk.java.net Thu Nov 19 15:18:07 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 19 Nov 2020 15:18:07 GMT Subject: RFR: 8256649: Parameterized tests must not use instances as parameters Message-ID: the issue was an (my ;) overzealous refactoring when introducing support for cross-control testing for memory leaks on switching skins. Fixed by - using control class as parameter - instantiate the control at setup time ------------- Commit messages: - 8256649: Parameterized tests must not use instances as parameters Changes: https://git.openjdk.java.net/jfx/pull/356/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=356&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256649 Stats: 23 lines in 2 files changed: 4 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/356.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/356/head:pull/356 PR: https://git.openjdk.java.net/jfx/pull/356 From jpereda at openjdk.java.net Thu Nov 19 15:23:02 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 19 Nov 2020 15:23:02 GMT Subject: Integrated: 8177945: Single cell selection flickers when adding data to TableView In-Reply-To: References: Message-ID: <-BFgOWhAqdSkNZtELafnmPX2_Iw6kwMzlehVELjDiF0=.defb0a4a-ddb3-491b-ae99-c321827c454e@github.com> On Wed, 4 Nov 2020 17:25:16 GMT, Jose Pereda wrote: > As discussed in the JBS [issue](https://bugs.openjdk.java.net/browse/JDK-8177945), there are some inconsistencies in the use of `VirtualContainerBase::requestRebuildCells` from `VirtualContainerBase::updateItemCount()`, which is implemented in the different skin classes for virtualised controls `TableViewSkinBase`, `ListViewSkin` or `TreeTableViewSkin`. > > The latter already commented out this call (related to JDK-8155798 and JDK-8147483). > > This PR removes now the calls to `VirtualContainerBase::requestRebuildCells` from `TableViewSkinBase` (except for the case `itemCount = 0` based on JDK-8118897 and JDK-8098235) and `ListViewSkin`. > > A test is provided for TableView, that verifies that the `selected` pseudo-class state remains set for the selected cell while adding more items. Without this fix, as the cells are rebuilt, the pseudo-class states are clean and set all over again, thus the flickering. > > For ListView, the test rt_35395 (JDK-8091726) is updated, as now there are way less calls to updateItem. This pull request has now been integrated. Changeset: a128952b Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/a128952b Stats: 73 lines in 4 files changed: 61 ins; 8 del; 4 mod 8177945: Single cell selection flickers when adding data to TableView Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/348 From kcr at openjdk.java.net Thu Nov 19 17:52:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 17:52:09 GMT Subject: RFR: 8256686: GitHub actions: build fails due to upgraded MSVC compiler Message-ID: Simple fix to get GitHub actions working again on Windows. In parallel I will bump the priority of [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) so we will detect the version of the compiler and not be sensitive to changes like this on the target machine. ------------- Commit messages: - 8256686: GitHub actions: build fails due to upgraded MSVC compiler Changes: https://git.openjdk.java.net/jfx/pull/357/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=357&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256686 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/357.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/357/head:pull/357 PR: https://git.openjdk.java.net/jfx/pull/357 From arapte at openjdk.java.net Thu Nov 19 18:07:01 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Nov 2020 18:07:01 GMT Subject: RFR: 8256686: GitHub actions: build fails due to upgraded MSVC compiler In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 17:47:28 GMT, Kevin Rushforth wrote: > Simple fix to get GitHub actions working again on Windows. In parallel I will bump the priority of [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) so we will detect the version of the compiler and not be sensitive to changes like this on the target machine. The Windows test passes on this PR, and it is the the fix we need. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/357 From kcr at openjdk.java.net Thu Nov 19 18:07:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 18:07:02 GMT Subject: Integrated: 8256686: GitHub actions: build fails due to upgraded MSVC compiler In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 17:47:28 GMT, Kevin Rushforth wrote: > Simple fix to get GitHub actions working again on Windows. In parallel I will bump the priority of [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) so we will detect the version of the compiler and not be sensitive to changes like this on the target machine. This pull request has now been integrated. Changeset: 767a1fd4 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/767a1fd4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256686: GitHub actions: build fails due to upgraded MSVC compiler Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/357 From kcr at openjdk.java.net Thu Nov 19 23:26:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 23:26:00 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 02:16:55 GMT, Kevin Rushforth wrote: >> As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. >> >> This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. >> >> It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. > > Looks good to me, but I want to run one more test on a dual screen setup tomorrow. > > I think that switching the order makes sense, and I can see no problems that it will cause. I am reasonably certain that whatever reason may have existed for the current order no longer pertains (there was a significant change to how screen scales were computed and tracked as a follow-on fix to the original HiDPI code that added the current block that you are moving). > > I verified that the new test catches the bug. I added one minor suggestion. Multi-screen testing looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/351 From kcr at openjdk.java.net Thu Nov 19 23:41:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Nov 2020 23:41:01 GMT Subject: RFR: 8256649: Parameterized tests must not use instances as parameters In-Reply-To: References: Message-ID: <3WD2e2LBjWBA1-UEP0AhoTjJLXjg_xVgYFG4C76kvhM=.3082d0ab-ed97-4c1c-9370-538c8e17ee47@github.com> On Thu, 19 Nov 2020 15:13:49 GMT, Jeanette Winzenburg wrote: > the issue was an (my ;) overzealous refactoring when introducing support for cross-control testing for memory leaks on switching skins. > > Fixed by > - using control class as parameter > - instantiate the control at setup time Ah, right. Parameters should be immutable to avoid this. Each test runs in its own instance, but if a test stores a reference to a parameter and then modifies it, that modification will leak into subsequent tests. FWIW, the same thing can happen if a test modifies a static field or if it modifies global state of the JavaFX runtime. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/356 From fastegal at openjdk.java.net Fri Nov 20 10:37:00 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 20 Nov 2020 10:37:00 GMT Subject: RFR: 8256649: Parameterized tests must not use instances as parameters In-Reply-To: <3WD2e2LBjWBA1-UEP0AhoTjJLXjg_xVgYFG4C76kvhM=.3082d0ab-ed97-4c1c-9370-538c8e17ee47@github.com> References: <3WD2e2LBjWBA1-UEP0AhoTjJLXjg_xVgYFG4C76kvhM=.3082d0ab-ed97-4c1c-9370-538c8e17ee47@github.com> Message-ID: On Thu, 19 Nov 2020 23:38:33 GMT, Kevin Rushforth wrote: > > > Parameters should be immutable would have been a far better bug title :) > to avoid this. Each test runs in its own instance, but if a test stores a reference to a parameter and then modifies it, that modification will leak into subsequent tests. FWIW, the same thing can happen if a test modifies a static field or if it modifies global state of the JavaFX runtime. .. and nice summary as well ------------- PR: https://git.openjdk.java.net/jfx/pull/356 From fastegal at openjdk.java.net Fri Nov 20 10:37:01 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 20 Nov 2020 10:37:01 GMT Subject: Integrated: 8256649: Parameterized tests must not use instances as parameters In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 15:13:49 GMT, Jeanette Winzenburg wrote: > the issue was an (my ;) overzealous refactoring when introducing support for cross-control testing for memory leaks on switching skins. > > Fixed by > - using control class as parameter > - instantiate the control at setup time This pull request has now been integrated. Changeset: 8e03018a Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/8e03018a Stats: 23 lines in 2 files changed: 4 ins; 13 del; 6 mod 8256649: Parameterized tests must not use instances as parameters Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/356 From fastegal at swingempire.de Fri Nov 20 10:50:54 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 20 Nov 2020 11:50:54 +0100 Subject: compile errors around JMemoryBuddy In-Reply-To: References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> <20201103140750.Horde.a5GyOAdQ60rKUzGpS70Ofg1@webmail.df.eu> <20201111110037.Horde.P7R31SRWuScl-GD90tn0zw7@webmail.df.eu> Message-ID: <20201120115054.Horde.IR5HRRAjcTv0Prc4rVtqDQ1@webmail.df.eu> Kevin, had taken it, created a PR https://github.com/openjdk/jfx/pull/352 with the suggested changes. In review it turned out to be not enough to cover its current usage, tests need it as well. Doing it completely would require to setup all fx modules (and tests) in my local Eclipse environment - which .. is off-scope for me ;) So stopped work, unassigned the issue - which the bot didn't notice: should I close the PR manually? -- Jeanette Zitat von Kevin Rushforth : > Yes, it does seem that as long as the .classpath files are in the > repo, they should work. I assigned the JBS bug to you since you have > proposed a fix. You can reassign it if you want. I'm not an Eclipse > user, so it would need to be done by someone who is. > > -- Kevin > > > On 11/11/2020 2:00 AM, Jeanette Winzenburg wrote: >> >> FYI: filed an issue https://bugs.openjdk.java.net/browse/JDK-8256184 >> >> don't know what the plans for supporting IDE builds are - but as >> long as it is available, they should work, IMO. >> >> -- Jeanette >> >> Zitat von Jeanette Winzenburg : >> >>> Zitat von Florian Kirmaier : >>> >>>> Eclipse probably handles the modules differently than Gradle. >>> >>> probably - couldn't find gradle's magic in the build script (and >>> lost interest, because that part is running okay and there are >>> enough experts around to keep it that way :) >>> >>>> The simplest solution would be to remove the code to automatically create >>>> heap dumps. >>>> Adding java.management to module-info of the tests doesn't sound wrong to >>>> me if it's using it. >>>> >>> >>> that's basically, what I ended up with. >>> >>> To summarize the problem: when compiling base and running tests of >>> controls in Eclipse I got >>> >>> a) JMemoryBuddy doesn't compile, Eclipse suggests to add requires >>> jdk.management and java.management >>> b) following the suggestion, some controls test don't compile due >>> to base:test.util.memory not being accessible >>> >>> As changing production module-info is not an option (and Eclipse' >>> support for test module-info is wip - see >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601 ) I played a >>> bit with the (new to me ;) module dependencies tab in build path >>> config and added reads to both modules. Couldn't find a way to add >>> them to test sources only (Eclipse added them to java src), so >>> manually moved in .classpath file, its test entry now is: >>> >>> >>> ???? >>> ??????? >>> ??????? >>> ??????? >>> ??????? >> value="javafx.base=jdk.management:javafx.base=java.management"/> >>> ???? >>> >>> >>> This fixed the error in base. >>> >>> To fix the error in controls, I added the export of new base test >>> package in :controls .classpath >>> >>> >>> ???? >>> ??????? >>> ??????? >> value="javafx.base/test.com.sun.javafx.binding=javafx.controls:javafx.base/test.util.memory=javafx.controls"/> >>> ???? >>> >>> >>> no idea how stable all this is, working for me at least. Should >>> the eclipse specific files updated in master, with this or >>> something similar/better? >>> >>> Opinions, please? >>> >>> -- Jeanette >>> >>> >>> >>>> On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth >>>> wrote: >>>> >>>>> I didn't try it with an earlier JDK, but if it breaks when using JDK 11 >>>>> it will need to be fixed. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote: >>>>>> >>>>>> just fetched the latest upstream master and getting compile errors >>>>>> around xx.management packages (eclipse wants to add requires into the >>>>>> module-info - which certainly is the wrong way to go ;) Compiling >>>>>> against jdk12, if that matters (will update one of these days but >>>>>> shouldn't jdk11 be good enough). >>>>>> >>>>>> Any quick ideas on what might be wrong? >>>>>> >>>>>> -- Jeanette >>>>>> >>>>>> >>>>> >>>>> >> >> >> From jpereda at openjdk.java.net Fri Nov 20 11:30:18 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 20 Nov 2020 11:30:18 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels [v2] In-Reply-To: References: Message-ID: <6hjydI2csW6vVoWJ4wKHIm12Ptg0_m0sPj-My25CVV8=.a585bd13-03bc-4a00-82c3-88003b23e062@github.com> > As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. > > This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. > > It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Use assertTrue instead of try-catch ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/351/files - new: https://git.openjdk.java.net/jfx/pull/351/files/0bcbdd27..ba0ff97a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=351&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=351&range=00-01 Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/351.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/351/head:pull/351 PR: https://git.openjdk.java.net/jfx/pull/351 From jpereda at openjdk.java.net Fri Nov 20 11:30:19 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 20 Nov 2020 11:30:19 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 02:12:05 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Use assertTrue instead of try-catch > > tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java line 83: > >> 81: new Thread(() -> Application.launch(TestApp.class, (String[])null)).start(); >> 82: try { >> 83: if (!startupLatch.await(15, TimeUnit.SECONDS)) { > > If you add `throws Exception` to this method you can get rid of the try/catch and just do: > > assertTrue("Timeout waiting for FX runtime to start", > startupLatch.await(15, TimeUnit.SECONDS)); > > (this is the pattern we use for most of our newer tests) Okay, thanks for the hint, I've just modified it. ------------- PR: https://git.openjdk.java.net/jfx/pull/351 From kevin.rushforth at oracle.com Fri Nov 20 14:06:24 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Nov 2020 06:06:24 -0800 Subject: compile errors around JMemoryBuddy In-Reply-To: <20201120115054.Horde.IR5HRRAjcTv0Prc4rVtqDQ1@webmail.df.eu> References: <20201102131107.Horde.BI40tWWS85W4IEdcpzsVxg3@webmail.df.eu> <5c59c36e-a94c-a5c3-0890-a859fbba6e0d@oracle.com> <20201103140750.Horde.a5GyOAdQ60rKUzGpS70Ofg1@webmail.df.eu> <20201111110037.Horde.P7R31SRWuScl-GD90tn0zw7@webmail.df.eu> <20201120115054.Horde.IR5HRRAjcTv0Prc4rVtqDQ1@webmail.df.eu> Message-ID: Yes, that seems best. Can you also add a comment to the JBS bug to that effect? That way if someone else wants to pick it back up they'll have a clear pointer to the old PR. Thanks. -- Kevin On 11/20/2020 2:50 AM, Jeanette Winzenburg wrote: > Kevin, > > had taken it, created a PR > https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/352__;!!GqivPVa7Brio!MZUfQlysgJ4YALuP_Dajocgq4pWaSfmMelA0rUxhP2IGide7fOOWSG3a9rikTniInRc3$ > with the suggested changes. In review it turned out to be not enough > to cover its current usage, tests need it as well. Doing it completely > would require to setup all fx modules (and tests) in my local Eclipse > environment - which .. is off-scope for me ;) > > So stopped work, unassigned the issue - which the bot didn't notice: > should I close the PR manually? > > -- Jeanette > > Zitat von Kevin Rushforth : > >> Yes, it does seem that as long as the .classpath files are in the >> repo, they should work. I assigned the JBS bug to you since you have >> proposed a fix. You can reassign it if you want. I'm not an Eclipse >> user, so it would need to be done by someone who is. >> >> -- Kevin >> >> >> On 11/11/2020 2:00 AM, Jeanette Winzenburg wrote: >>> >>> FYI: filed an issue https://bugs.openjdk.java.net/browse/JDK-8256184 >>> >>> don't know what the plans for supporting IDE builds are - but as >>> long as it is available, they should work, IMO. >>> >>> -- Jeanette >>> >>> Zitat von Jeanette Winzenburg : >>> >>>> Zitat von Florian Kirmaier : >>>> >>>>> Eclipse probably handles the modules differently than Gradle. >>>> >>>> probably - couldn't find gradle's magic in the build script (and >>>> lost interest, because that part is running okay and there are >>>> enough experts around to keep it that way :) >>>> >>>>> The simplest solution would be to remove the code to automatically >>>>> create >>>>> heap dumps. >>>>> Adding java.management to module-info of the tests doesn't sound >>>>> wrong to >>>>> me if it's using it. >>>>> >>>> >>>> that's basically, what I ended up with. >>>> >>>> To summarize the problem: when compiling base and running tests of >>>> controls in Eclipse I got >>>> >>>> a) JMemoryBuddy doesn't compile, Eclipse suggests to add requires >>>> jdk.management and java.management >>>> b) following the suggestion, some controls test don't compile due >>>> to base:test.util.memory not being accessible >>>> >>>> As changing production module-info is not an option (and Eclipse' >>>> support for test module-info is wip - see >>>> https://urldefense.com/v3/__https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601__;!!GqivPVa7Brio!MZUfQlysgJ4YALuP_Dajocgq4pWaSfmMelA0rUxhP2IGide7fOOWSG3a9rikTtQcIFO5$ >>>> ) I played a bit with the (new to me ;) module dependencies tab in >>>> build path config and added reads to both modules. Couldn't find a >>>> way to add them to test sources only (Eclipse added them to java >>>> src), so manually moved in .classpath file, its test entry now is: >>>> >>>> >>>> ???? >>>> ??????? >>>> ??????? >>>> ??????? >>>> ??????? >>> value="javafx.base=jdk.management:javafx.base=java.management"/> >>>> ???? >>>> >>>> >>>> This fixed the error in base. >>>> >>>> To fix the error in controls, I added the export of new base test >>>> package in :controls .classpath >>>> >>>> >>>> ???? >>>> ??????? >>>> ??????? >>> value="javafx.base/test.com.sun.javafx.binding=javafx.controls:javafx.base/test.util.memory=javafx.controls"/> >>>> ???? >>>> >>>> >>>> no idea how stable all this is, working for me at least. Should the >>>> eclipse specific files updated in master, with this or something >>>> similar/better? >>>> >>>> Opinions, please? >>>> >>>> -- Jeanette >>>> >>>> >>>> >>>>> On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth >>>>> >>>>> wrote: >>>>> >>>>>> I didn't try it with an earlier JDK, but if it breaks when using >>>>>> JDK 11 >>>>>> it will need to be fixed. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote: >>>>>>> >>>>>>> just fetched the latest upstream master and getting compile errors >>>>>>> around xx.management packages (eclipse wants to add requires >>>>>>> into the >>>>>>> module-info - which certainly is the wrong way to go ;) Compiling >>>>>>> against jdk12, if that matters (will update one of these days but >>>>>>> shouldn't jdk11 be good enough). >>>>>>> >>>>>>> Any quick ideas on what might be wrong? >>>>>>> >>>>>>> -- Jeanette >>>>>>> >>>>>>> >>>>>> >>>>>> >>> >>> >>> > > > From kcr at openjdk.java.net Fri Nov 20 14:18:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 20 Nov 2020 14:18:04 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels [v2] In-Reply-To: <6hjydI2csW6vVoWJ4wKHIm12Ptg0_m0sPj-My25CVV8=.a585bd13-03bc-4a00-82c3-88003b23e062@github.com> References: <6hjydI2csW6vVoWJ4wKHIm12Ptg0_m0sPj-My25CVV8=.a585bd13-03bc-4a00-82c3-88003b23e062@github.com> Message-ID: On Fri, 20 Nov 2020 11:30:18 GMT, Jose Pereda wrote: >> As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. >> >> This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. >> >> It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use assertTrue instead of try-catch Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/351 From nlisker at openjdk.java.net Fri Nov 20 14:43:03 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 20 Nov 2020 14:43:03 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Tue, 17 Nov 2020 11:29:02 GMT, Jeanette Winzenburg wrote: >>> Plus this extra effort would only fix the current usage of memorybuddy, leaving future inclusions in the other modules still broken. >> >> I think that this is fine. When future uses occur they should be accompanied by the inclusion of the dependency, unless we know of plans to use it in other modules. In any case, there is no need to close this PR. > > okay, so will simply unassign the issue and leave the PR open for someone else to complete - thanks for your input :) @kleopatra You can just add the line I gave in the .classpath file, there's no need for any setup. We can be listed as co-authors if you want. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Fri Nov 20 15:15:04 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 20 Nov 2020 15:15:04 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: <9hEFGKRr0idfFyFnRJxeJtJ0ImmBaE92GI5d-PJ7QtQ=.74c3469d-dc07-498f-b56b-3d52136a1e10@github.com> Message-ID: On Fri, 20 Nov 2020 14:40:08 GMT, Nir Lisker wrote: >> okay, so will simply unassign the issue and leave the PR open for someone else to complete - thanks for your input :) > > @kleopatra You can just add the line I gave in the .classpath file, there's no need for any setup. We can be listed as co-authors if you want. yes, I could add the change - and willing to trust you blindly :) But you said: _See if these errors are resolved._ .. without building in Eclipse, I can't see whether or not that's working, can I? ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From nlisker at openjdk.java.net Fri Nov 20 15:29:01 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 20 Nov 2020 15:29:01 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 13:50:41 GMT, Kevin Rushforth wrote: >> Issue was broken build in Eclipse after fix of [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): >> >> - the new memory test class requires jdk.management/java.management >> - users of the test class (in controls) need access to its package >> >> Changed .classpath files in base and controls to fix this. > > The change looks reasonable to me, but since I don't use Eclipse it would be better for someone who does to review. > @nlisker can you review this? Yes, but that's a problem of no reviewers. If I submit it myself then there will also be no one to review. @kevinrushforth What do we do? I think that previously when I updated the Eclipse files, there's wasn't a thorough review. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From jvos at openjdk.java.net Fri Nov 20 15:48:00 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 20 Nov 2020 15:48:00 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 15:26:15 GMT, Nir Lisker wrote: >> The change looks reasonable to me, but since I don't use Eclipse it would be better for someone who does to review. >> @nlisker can you review this? > > Yes, but that's a problem of no reviewers. If I submit it myself then there will also be no one to review. @kevinrushforth What do we do? I think that previously when I updated the Eclipse files, there's wasn't a thorough review. In this case, it seems to me that it would be a quick win to accept the PR as it is now. In general, I'm not sure the IDE files really belong in the code repository, but since they are there, it is better to fix them. I don't use Eclipse, so I can't test. But if the part that is dealt with here is confirmed to work, I suggest we merge that, and create a follow-up issue for the missing parts (test). ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From kcr at openjdk.java.net Fri Nov 20 16:25:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 20 Nov 2020 16:25:06 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 15:44:57 GMT, Johan Vos wrote: >> Yes, but that's a problem of no reviewers. If I submit it myself then there will also be no one to review. @kevinrushforth What do we do? I think that previously when I updated the Eclipse files, there's wasn't a thorough review. > > In this case, it seems to me that it would be a quick win to accept the PR as it is now. > In general, I'm not sure the IDE files really belong in the code repository, but since they are there, it is better to fix them. > I don't use Eclipse, so I can't test. But if the part that is dealt with here is confirmed to work, I suggest we merge that, and create a follow-up issue for the missing parts (test). I don't mind either way. If we want to proceed, I'm OK with either of: 1. Accept the PR as-is and file a follow-up issue 2. Add the change proposed by @nlisker and list him as a co-contributor (in which case he can still review it). Long term, as @johanvos pointed out, it might be better to get the IDE files out of the repo, but I'll leave that entirely up to the Eclipse users to decide. There is already an issue tracking this: [JDK-8223374](https://bugs.openjdk.java.net/browse/JDK-8223374). ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Fri Nov 20 16:42:59 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 20 Nov 2020 16:42:59 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: <7KSHafbUF3_0rFaefvKmSen0HrxH9XJo3bjSRLGGF_Q=.52545283-4cc9-4fc0-9577-ef6699679f30@github.com> On Fri, 20 Nov 2020 16:22:32 GMT, Kevin Rushforth wrote: > > > I don't mind either way. If we want to proceed, I'm OK with either of: > > 1. Accept the PR as-is and file a follow-up issue > > 2. Add the change proposed by @nlisker and list him as a co-contributor (in which case he can still review it). my preference would be 2 - would be as complete as required right now (and Nir sees it's working :). Still would need a follow-up issue to modify the .classpath of the other modules, to enable them to make use of the memory leak test. Might happen at the time they actually start using it. ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Sat Nov 21 11:15:20 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 21 Nov 2020 11:15:20 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) [v2] In-Reply-To: References: Message-ID: > Issue was broken build in Eclipse after fix of [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): > > - the new memory test class requires jdk.management/java.management > - users of the test class (in controls) need access to its package > > Changed .classpath files in base and controls to fix this. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: added exports to tests/.classpath ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/352/files - new: https://git.openjdk.java.net/jfx/pull/352/files/0ce67925..ca50bcf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=352&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=352&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/352.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/352/head:pull/352 PR: https://git.openjdk.java.net/jfx/pull/352 From nlisker at openjdk.java.net Sat Nov 21 11:54:07 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 21 Nov 2020 11:54:07 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) [v2] In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 11:15:20 GMT, Jeanette Winzenburg wrote: >> Issue was broken build in Eclipse after fix of [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): >> >> - the new memory test class requires jdk.management/java.management >> - users of the test class (in controls) need access to its package >> >> Changed .classpath files in base and controls to fix this. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > added exports to tests/.classpath Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Sat Nov 21 13:19:12 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 21 Nov 2020 13:19:12 GMT Subject: Integrated: 8256184: Openjfx build broken (Eclipse) In-Reply-To: References: Message-ID: <3Gtvv5ng9xnk8HpxevymTkF9tffeTAzgwkym1Q4yn8U=.4276dac4-d7b4-4129-93a4-3b4ae50e78ec@github.com> On Thu, 12 Nov 2020 11:24:15 GMT, Jeanette Winzenburg wrote: > Issue was broken build in Eclipse after fix of [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): > > - the new memory test class requires jdk.management/java.management > - users of the test class (in controls) need access to its package > > Changed .classpath files in base and controls to fix this. This pull request has now been integrated. Changeset: 2fe86773 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/2fe86773 Stats: 4 lines in 3 files changed: 2 ins; 0 del; 2 mod 8256184: Openjfx build broken (Eclipse) Co-authored-by: Nir Lisker Reviewed-by: nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Sat Nov 21 13:24:08 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 21 Nov 2020 13:24:08 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) [v2] In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 11:51:18 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> added exports to tests/.classpath > > Marked as reviewed by nlisker (Reviewer). > > @kleopatra > Contributor `Nir Lisker ` successfully added. hmm .. so bot says Nir was successfully added as contributor but he doesn't appear in the commit message (in the bug report)? How comes and how to fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Sat Nov 21 13:28:07 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 21 Nov 2020 13:28:07 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) [v2] In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 13:21:17 GMT, Jeanette Winzenburg wrote: >> Marked as reviewed by nlisker (Reviewer). > >> >> @kleopatra >> Contributor `Nir Lisker ` successfully added. > > hmm .. so bot says Nir was successfully added as contributor but he doesn't appear in the commit message (in the bug report)? How comes and how to fix? was wrong: contributor is taken (see above and real commit message) - just not showing up in the commit record that's added to the bug report ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From fastegal at openjdk.java.net Sat Nov 21 13:48:11 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 21 Nov 2020 13:48:11 GMT Subject: RFR: 8256184: Openjfx build broken (Eclipse) [v2] In-Reply-To: References: Message-ID: <9SrQFYIJ5xnABwce1Hmw5gmvRyqYefP7XIGD1Z6eSY0=.2795e1c8-aaf2-45c4-9c00-3a52f158a0dd@github.com> On Sat, 21 Nov 2020 13:25:44 GMT, Jeanette Winzenburg wrote: >>> >>> @kleopatra >>> Contributor `Nir Lisker ` successfully added. >> >> hmm .. so bot says Nir was successfully added as contributor but he doesn't appear in the commit message (in the bug report)? How comes and how to fix? > > was wrong: contributor is taken (see above and real commit message) - just not showing up in the commit record that's added to the bug report thanks everybody for guidance and contribution ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/352 From mblaesing at doppel-helix.eu Sat Nov 21 21:42:53 2020 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Sat, 21 Nov 2020 22:42:53 +0100 Subject: JDK-8242361: Web View crash with data urls: further information Message-ID: <3e311639cff6303fdfa2a07b11ac5eae4de8ba6b.camel@doppel-helix.eu> Hi, I found JDK-8242361, because I observed a segfault when running a web application of medium complexity in a WebView, that was embedded in NetBeans. Before you say it: NetBeans loads the openjfx jars via the classpath. I'm aware that OpenJFX should be loaded as a named module, but that is far from trivial to realize inside the environment, so at this point in time I'd like to try to fix the problem at hand. I managed to get a core dump from the crash and running it through gdb with debug symbols I get: ============================================================ #0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #1 0x00007f93c40e5864 in __GI_abort () at abort.c:79 #2 0x00007f93c30603e7 in os::abort(bool, void*, void const*) (dump_core=, siginfo=, context=) at ./src/hotspot/os/linux/os_linux.cpp:1503 #3 0x00007f93c3c58798 in VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) (id=, message=message at entry=0x0, detail_fmt=, detail_args=detail_args at entry=0x7f9189ffe368, thread=thread at entry=0x7f925c314000, pc=pc at entry=0x7f93c3348804 , (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+4> "H\213\a\303\017\037\204", siginfo=0x7f9189ffe6f0, context=0x7f9189ffe5c0, filename=, lineno=0, size=0) at ./src/hotspot/share/utilities/vmError.cpp:1603 #4 0x00007f93c3c590cf in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) (thread=thread at entry=0x7f925c314000, sig=sig at entry=11, pc=pc at entry=0x7f93c3348804 , (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+4> "H\213\a\303\017\037\204", siginfo=siginfo at entry=0x7f9189ffe6f0, context=context at entry=0x7f9189ffe5c0, detail_fmt=detail_fmt at entry=0x7f93c3d1348e "%s") at ./src/hotspot/share/utilities/vmError.cpp:1270 #5 0x00007f93c3c59102 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) (thread=thread at entry=0x7f925c314000, sig=sig at entry=11, pc=pc at entry=0x7f93c3348804 , (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+4> "H\213\a\303\017\037\204", siginfo=siginfo at entry=0x7f9189ffe6f0, context=context at entry=0x7f9189ffe5c0) at ./src/hotspot/share/utilities/vmError.cpp:1276 #6 0x00007f93c39b0d02 in JVM_handle_linux_signal(int, siginfo_t*, void*, int) (sig=sig at entry=11, info=info at entry=0x7f9189ffe6f0, ucVoid=ucVoid at entry=0x7f9189ffe5c0, abort_if_unrecognized=abort_if_unrecognized at entry=1) at ./src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:616 #7 0x00007f93c39a3fdc in signalHandler(int, siginfo_t*, void*) (sig=11, info=0x7f9189ffe6f0, uc=0x7f9189ffe5c0) at ./src/hotspot/os/linux/os_linux.cpp:4693 #8 0x00007f93c4100950 in () at /lib/x86_64-linux-gnu/libc.so.6 #9 AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*) (addr=0x0) at ./src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp:66 #10 0x00007f93c36b0073 in AccessInternal::RuntimeDispatch<1097812ul, oopDesc*, (AccessInternal::BarrierType)2>::load(void*) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:1325 #11 AccessInternal::PreRuntimeDispatch::load<1097812ul, oopDesc*>(void*) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:779 #12 AccessInternal::load_reduce_types<1097812ul, oopDesc*>(oopDesc**) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:1110 #13 AccessInternal::load<1048580ul, oopDesc*, oopDesc*>(oopDesc**) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:1211 #14 AccessInternal::OopLoadProxy::operator oopDesc*() (this=) at ./src/hotspot/share/oops/accessBackend.hpp:1326 #15 JNIHandles::resolve_impl<0ul, false>(_jobject*) (handle=0x7f91cd491060) at ./src/hotspot/share/runtime/jniHandles.inline.hpp:60 #16 JNIHandles::resolve_non_null(_jobject*) (handle=0x7f91cd491060) at ./src/hotspot/share/runtime/jniHandles.inline.hpp:92 #17 get_method_id(jclass, char const*, char const*, bool, Thread*, JNIEnv*) (clazz=clazz at entry=0x0, name_str=name_str at entry=0x7f915c3d3e8a "fwkScheduleDispatchFunctions", sig=sig at entry=0x7f915c396304 "()V", is_static=is_static at entry=true, __the_thread__=__the_thread__ at entry=0x7f925c314000, env=) at ./src/hotspot/share/prims/jni.cpp:1336 #18 0x00007f93c36b040b in jni_GetStaticMethodID(JNIEnv*, jclass, char const*, char const*) (env=, clazz=0x0, name=0x7f915c3d3e8a "fwkScheduleDispatchFunctions", sig=0x7f915c396304 "()V") at ./src/hotspot/share/prims/jni.cpp:1382 #19 0x00007f915c0869e6 in WTF::scheduleDispatchFunctionsOnMainThread() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #20 0x00007f915b2a745b in WTF::Function::CallableWrapper)>&&)::{lambda()#1}>::call() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #21 0x00007f915c089150 in WTF::Function::CallableWrapper&&)::{lambda()#1}>::call() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #22 0x00007f915c02215b in WTF::RunLoop::performWork() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #23 0x00007f915c088190 in WTF::RunLoop::runImpl(WTF::RunLoop::RunMode) () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #24 0x00007f915c023867 in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #25 0x00007f915c08a00d in WTF::wtfThreadEntryPoint(void*) () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #26 0x00007f93c4083590 in start_thread (arg=0x7f9189fff640) at pthread_create.c:463 #27 0x00007f93c41d8223 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 ============================================================ What I also found is, that this is not a general problem of the WebView on netbeans. I inserted seveal printf statements into the MainThreadJava.cpp and JavaEnv.h files and found, that there are several successful calls to isMainThread, but if fails for scheduleDispatchFunctionsOnMainThread. What I observe is, that the jclasses and jmethodID are resolved on each invocation. The few times I work with JNI, the correspoding libraries resolve the classids and methods at load time once and cache the results for the lifetime of the library. Wouldn't this also be an option for OpenJFX? From my observation, the jclasses can be found, just not for the schedule. Greetings Matthias From mblaesing at doppel-helix.eu Sun Nov 22 15:56:14 2020 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Sun, 22 Nov 2020 16:56:14 +0100 Subject: JDK-8242361: Web View crash with data urls: reproducer with named module In-Reply-To: <3e311639cff6303fdfa2a07b11ac5eae4de8ba6b.camel@doppel-helix.eu> References: <3e311639cff6303fdfa2a07b11ac5eae4de8ba6b.camel@doppel-helix.eu> Message-ID: Hi again, I experimented some more and I think this: https://github.com/matthiasblaesing/reproduce-openjfx-crash2 shows, that the problem also exists when used from named modules. The above sample can be run by: - clone the referenced sources - build the project with "mvn package" - run it with mvn -Dexec.args="-classpath %classpath eu.doppel_helix.dev.jdk.reproducecrash.TestBrowser" -Dexec.executable=java org.codehaus.mojo:exec-maven-plugin:3.0.0:exec I get an instant segfault on Ubuntu with OpenJDK 11.0.9. >From my interpretation this is caused by the behaviour of FindClass. Quote from the docs of JDK 11: ====================================================================== Since JDK 1.2, the Java security model allows non-system classes to load and call native methods. FindClass locates the class loader associated with the current native method; that is, the class loader of the class that declared the native method. If the native method belongs to a system class, no class loader will be involved. Otherwise, the proper class loader will be invoked to load and link the named class. Since JDK 1.2, when FindClass is called through the Invocation Interface, there is no current native method or its associated class loader. In that case, the result of ClassLoader.getSystemClassLoader is used. This is the class loader the virtual machine creates for applications, and is able to locate classes listed in the java.class.path property. ====================================================================== My take on this is, that in the common case OpenJFX hits the first assumption. Classes are loaded with the classloader of the native method, which should be able to load the necessary classes. In the case where Webkit calls back into the JVM, the second paragraph becomes important. OpenJFX is not loaded from the system class loader and loading of MainThread class fails. Based on this and my observation that isMainThread is successfully called multiple time before the crash, I added this hack to the last tag of OpenJFX 13 and rebuild: --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp @@ -30,20 +30,21 @@ #include namespace WTF { +static JGClass jMainThreadCls2; + void scheduleDispatchFunctionsOnMainThread() { AttachThreadAsNonDaemonToJavaEnv autoAttach; JNIEnv* env = autoAttach.env(); - static JGClass jMainThreadCls(env->FindClass("com/sun/webkit/MainThread")); static jmethodID mid = env->GetStaticMethodID( - jMainThreadCls, + jMainThreadCls2, "fwkScheduleDispatchFunctions", "()V"); ASSERT(mid); - env->CallStaticVoidMethod(jMainThreadCls, mid); + env->CallStaticVoidMethod(jMainThreadCls2, mid); WTF::CheckAndClearException(env); } @@ -61,7 +62,7 @@ AttachThreadAsNonDaemonToJavaEnv autoAttach; JNIEnv* env = autoAttach.env(); static JGClass jMainThreadCls(env->FindClass("com/sun/webkit/MainThread")); - + jMainThreadCls2 = jMainThreadCls; static jmethodID mid = env->GetStaticMethodID( jMainThreadCls, "fwkIsMainThread", The idea is, that I retain the reference to the class and use that in scheduleDispatchFunctionsOnMainThread. I'm sure, that that is not the right approach, but it works and proves, that the class is accessible. Greetings Matthias Am Samstag, den 21.11.2020, 22:42 +0100 schrieb Matthias Bl?sing: Hi, I found JDK-8242361, because I observed a segfault when running a web application of medium complexity in a WebView, that was embedded in NetBeans. Before you say it: NetBeans loads the openjfx jars via the classpath. I'm aware that OpenJFX should be loaded as a named module, but that is far from trivial to realize inside the environment, so at this point in time I'd like to try to fix the problem at hand. I managed to get a core dump from the crash and running it through gdb with debug symbols I get: ============================================================ #0? __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #1? 0x00007f93c40e5864 in __GI_abort () at abort.c:79 #2? 0x00007f93c30603e7 in os::abort(bool, void*, void const*) (dump_core=, siginfo=, context=) at ./src/hotspot/os/linux/os_linux.cpp:1503 #3? 0x00007f93c3c58798 in VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) ??? (id=, message=message at entry=0x0, detail_fmt=, detail_args=detail_args at entry=0x7f9189ffe368, thread=thread at entry=0x7f925c314000, pc=pc at entry=0x7f93c3348804 , (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+4> "H\213\a\303\017\037\204", siginfo=0x7f9189ffe6f0, context=0x7f9189ffe5c0, filename=, lineno=0, size=0) at ./src/hotspot/share/utilities/vmError.cpp:1603 #4? 0x00007f93c3c590cf in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) ??? (thread=thread at entry=0x7f925c314000, sig=sig at entry=11, pc=pc at entry=0x7f93c3348804 , (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+4> "H\213\a\303\017\037\204", siginfo=siginfo at entry=0x7f9189ffe6f0, context=context at entry=0x7f9189ffe5c0, detail_fmt=detail_fmt at entry=0x7f93c3d1348e "%s") at ./src/hotspot/share/utilities/vmError.cpp:1270 #5? 0x00007f93c3c59102 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) ??? (thread=thread at entry=0x7f925c314000, sig=sig at entry=11, pc=pc at entry=0x7f93c3348804 , (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+4> "H\213\a\303\017\037\204", siginfo=siginfo at entry=0x7f9189ffe6f0, context=context at entry=0x7f9189ffe5c0) ??? at ./src/hotspot/share/utilities/vmError.cpp:1276 #6? 0x00007f93c39b0d02 in JVM_handle_linux_signal(int, siginfo_t*, void*, int) ??? (sig=sig at entry=11, info=info at entry=0x7f9189ffe6f0, ucVoid=ucVoid at entry=0x7f9189ffe5c0, abort_if_unrecognized=abort_if_unrecognized at entry=1) at ./src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:616 #7? 0x00007f93c39a3fdc in signalHandler(int, siginfo_t*, void*) (sig=11, info=0x7f9189ffe6f0, uc=0x7f9189ffe5c0) at ./src/hotspot/os/linux/os_linux.cpp:4693 #8? 0x00007f93c4100950 in () at /lib/x86_64- linux-gnu/libc.so.6 #9? AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*) (addr=0x0) ??? at ./src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp:66 #10 0x00007f93c36b0073 in AccessInternal::RuntimeDispatch<1097812ul, oopDesc*, (AccessInternal::BarrierType)2>::load(void*) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:1325 #11 AccessInternal::PreRuntimeDispatch::load<1097812ul, oopDesc*>(void*) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:779 #12 AccessInternal::load_reduce_types<1097812ul, oopDesc*>(oopDesc**) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:1110 #13 AccessInternal::load<1048580ul, oopDesc*, oopDesc*>(oopDesc**) (addr=0x7f91cd491060) at ./src/hotspot/share/oops/accessBackend.hpp:1211 #14 AccessInternal::OopLoadProxy::operator oopDesc*() (this=) at ./src/hotspot/share/oops/accessBackend.hpp:1326 #15 JNIHandles::resolve_impl<0ul, false>(_jobject*) (handle=0x7f91cd491060) at ./src/hotspot/share/runtime/jniHandles.inline.hpp:60 #16 JNIHandles::resolve_non_null(_jobject*) (handle=0x7f91cd491060) at ./src/hotspot/share/runtime/jniHandles.inline.hpp:92 #17 get_method_id(jclass, char const*, char const*, bool, Thread*, JNIEnv*) ??? (clazz=clazz at entry=0x0, name_str=name_str at entry=0x7f915c3d3e8a "fwkScheduleDispatchFunctions", sig=sig at entry=0x7f915c396304 "()V", is_static=is_static at entry=true, __the_thread__=__the_thread__ at entry=0x7f925c314000, env=) at ./src/hotspot/share/prims/jni.cpp:1336 #18 0x00007f93c36b040b in jni_GetStaticMethodID(JNIEnv*, jclass, char const*, char const*) ??? (env=, clazz=0x0, name=0x7f915c3d3e8a "fwkScheduleDispatchFunctions", sig=0x7f915c396304 "()V") at ./src/hotspot/share/prims/jni.cpp:1382 #19 0x00007f915c0869e6 in WTF::scheduleDispatchFunctionsOnMainThread() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #20 0x00007f915b2a745b in WTF::Function::CallableWrapper)>&&)::{lambda()#1}>::ca ll() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #21 0x00007f915c089150 in WTF::Function::CallableWrapper&&)::{lambda()#1}>::call() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #22 0x00007f915c02215b in WTF::RunLoop::performWork() () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #23 0x00007f915c088190 in WTF::RunLoop::runImpl(WTF::RunLoop::RunMode) () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #24 0x00007f915c023867 in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #25 0x00007f915c08a00d in WTF::wtfThreadEntryPoint(void*) () at /home/matthias/.openjfx/cache/13/libjfxwebkit.so #26 0x00007f93c4083590 in start_thread (arg=0x7f9189fff640) at pthread_create.c:463 #27 0x00007f93c41d8223 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 ============================================================ What I also found is, that this is not a general problem of the WebView on netbeans. I inserted seveal printf statements into the MainThreadJava.cpp and JavaEnv.h files and found, that there are several successful calls to isMainThread, but if fails for scheduleDispatchFunctionsOnMainThread. What I observe is, that the jclasses and jmethodID are resolved on each invocation. The few times I work with JNI, the correspoding libraries resolve the classids and methods at load time once and cache the results for the lifetime of the library. Wouldn't this also be an option for OpenJFX? From my observation, the jclasses can be found, just not for the schedule. Greetings Matthias From kevin.rushforth at oracle.com Tue Nov 24 00:10:20 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Nov 2020 16:10:20 -0800 Subject: Bulk request to backport 9 fixes to 11-dev for 11.0.10 Message-ID: <75fee033-2091-f1c5-dfc5-64b298ea5ab3@oracle.com> Hi Johan, I request approval to backport the following 9 bug fixes to 11-dev for 11.0.10: JDK-8254100: FX: Update copyright year in docs, readme files to 2021 JDK-8251241: macOS: iconify property doesn't change after minimize when resizable is false JDK-8252060: gstreamer fails to build with gcc 10 JDK-8181775: JavaFX WebView does not calculate border-radius properly JDK-8251858: Update to Xcode 11.3.1 JDK-8252062: WebKit build fails with recent VS 2019 compiler JDK-8240499: Enforce whitespace checking for additional source files JDK-8252191: Update to gcc 10.2 on Linux JDK-8239822: Intermittent unit test failures in RegionCSSTest -- Kevin From johan.vos at gluonhq.com Tue Nov 24 08:56:33 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 24 Nov 2020 09:56:33 +0100 Subject: Bulk request to backport 9 fixes to 11-dev for 11.0.10 In-Reply-To: <75fee033-2091-f1c5-dfc5-64b298ea5ab3@oracle.com> References: <75fee033-2091-f1c5-dfc5-64b298ea5ab3@oracle.com> Message-ID: Approved. On Tue, Nov 24, 2020 at 1:10 AM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the following 9 bug fixes to 11-dev for > 11.0.10: > > JDK-8254100: FX: Update copyright year in docs, readme files to 2021 > JDK-8251241: macOS: iconify property doesn't change after minimize when > resizable is false > JDK-8252060: gstreamer fails to build with gcc 10 > JDK-8181775: JavaFX WebView does not calculate border-radius properly > JDK-8251858: Update to Xcode 11.3.1 > JDK-8252062: WebKit build fails with recent VS 2019 compiler > JDK-8240499: Enforce whitespace checking for additional source files > JDK-8252191: Update to gcc 10.2 on Linux > JDK-8239822: Intermittent unit test failures in RegionCSSTest > > -- Kevin > > From arapte at openjdk.java.net Tue Nov 24 10:21:56 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 24 Nov 2020 10:21:56 GMT Subject: RFR: 8199592: Control labels truncated at certain DPI scaling levels [v2] In-Reply-To: <6hjydI2csW6vVoWJ4wKHIm12Ptg0_m0sPj-My25CVV8=.a585bd13-03bc-4a00-82c3-88003b23e062@github.com> References: <6hjydI2csW6vVoWJ4wKHIm12Ptg0_m0sPj-My25CVV8=.a585bd13-03bc-4a00-82c3-88003b23e062@github.com> Message-ID: On Fri, 20 Nov 2020 11:30:18 GMT, Jose Pereda wrote: >> As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. >> >> This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. >> >> It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use assertTrue instead of try-catch Looks good to me, verified test and sample app on multi screen. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/351 From jpereda at openjdk.java.net Tue Nov 24 12:01:58 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 24 Nov 2020 12:01:58 GMT Subject: Integrated: 8199592: Control labels truncated at certain DPI scaling levels In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 11:34:25 GMT, Jose Pereda wrote: > As commented in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI scale 1.0 is used to perform initial calculations of preferred sizes of the scene, even if the scale has already a different value (i.e 175%). As a workaround, calling `Stage::sizeToScene` fix it, as it forces to do new calculations but now with the correct UI scale. > > This PR moves the call to `Window::updateOutputScales` before the scene initialization takes place, so the UI scale is correctly set for the initial preferred size of the scene, and no workaround is required. > > It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check`. This pull request has now been integrated. Changeset: a394fabd Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/a394fabd Stats: 117 lines in 2 files changed: 111 ins; 6 del; 0 mod 8199592: Control labels truncated at certain DPI scaling levels Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/351 From fastegal at openjdk.java.net Tue Nov 24 14:22:05 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 24 Nov 2020 14:22:05 GMT Subject: RFR: 8256821: TreeViewSkin/Behavior: misbehavior on switching skin Message-ID: issues with behavior: - memory leak due to an key eventHandler that's not removed - after dispose, still modifying treeView (anchor) state due to listeners selection that are not removed issues with skin: - memory leak due to behavior leaking - memory leak due to cellFactory in flow not removed - throws NPE after switching (on modifying root children, refresh) due to listeners not removed Fixed by cleaning up as needed. Added tests that are failing before and passing after the fix. ------------- Commit messages: - 8256821: TreeViewSkin/Behavior: misbehavior on switching skin Changes: https://git.openjdk.java.net/jfx/pull/358/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=358&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256821 Stats: 158 lines in 6 files changed: 142 ins; 13 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/358/head:pull/358 PR: https://git.openjdk.java.net/jfx/pull/358 From kcr at openjdk.java.net Tue Nov 24 16:00:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Nov 2020 16:00:04 GMT Subject: RFR: 8256978: GitHub actions: build fails on Linux due to missing package Message-ID: This is a simple fix to remove and unused package from the list of packages we specify to install on Linux when running GitHub actions. As a follow-on fix, I am going to do what the JDK did and specify the version of each OS to use to partially insulate us from such changes in the GitHub actions defaults. ------------- Commit messages: - 8256978: GitHub actions: build fails on Linux due to missing package Changes: https://git.openjdk.java.net/jfx/pull/359/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=359&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256978 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/359.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/359/head:pull/359 PR: https://git.openjdk.java.net/jfx/pull/359 From kcr at openjdk.java.net Tue Nov 24 16:00:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Nov 2020 16:00:04 GMT Subject: RFR: 8256978: GitHub actions: build fails on Linux due to missing package In-Reply-To: References: Message-ID: <-WfYvifaOmpaf_uXZ8Oy3yBvf-gGukEOg9wXe1Vor-I=.dc9a553b-0726-4842-bd0d-b7287ae46a1b@github.com> On Tue, 24 Nov 2020 15:55:07 GMT, Kevin Rushforth wrote: > This is a simple fix to remove and unused package from the list of packages we specify to install on Linux when running GitHub actions. > > As a follow-on fix, I am going to do what the JDK did and specify the version of each OS to use to partially insulate us from such changes in the GitHub actions defaults. @arapte Can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/359 From arapte at openjdk.java.net Tue Nov 24 16:28:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 24 Nov 2020 16:28:55 GMT Subject: RFR: 8256978: GitHub actions: build fails on Linux due to missing package In-Reply-To: References: Message-ID: <8ceKwFjUfOkhM3kbaS7AXK5MXGsqT4jIh4j2TZOPX8w=.ba074d90-3f8d-4b9d-a4d6-3dcea9945888@github.com> On Tue, 24 Nov 2020 15:55:07 GMT, Kevin Rushforth wrote: > This is a simple fix to remove and unused package from the list of packages we specify to install on Linux when running GitHub actions. > > As a follow-on fix, I am going to do what the JDK did and specify the version of each OS to use to partially insulate us from such changes in the GitHub actions defaults. Build succeeding on Linux itself is the verification for this PR. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/359 From kcr at openjdk.java.net Tue Nov 24 16:41:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Nov 2020 16:41:53 GMT Subject: Integrated: 8256978: GitHub actions: build fails on Linux due to missing package In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 15:55:07 GMT, Kevin Rushforth wrote: > This is a simple fix to remove and unused package from the list of packages we specify to install on Linux when running GitHub actions. > > As a follow-on fix, I am going to do what the JDK did and specify the version of each OS to use to partially insulate us from such changes in the GitHub actions defaults. This pull request has now been integrated. Changeset: bd510896 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/bd510896 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256978: GitHub actions: build fails on Linux due to missing package Remove unused libudev-dev package Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/359 From kcr at openjdk.java.net Tue Nov 24 19:33:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Nov 2020 19:33:00 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v2] In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 04:08:15 GMT, Arun Joseph wrote: >> We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. >> >> Test: Run PublicSuffixesTest.java > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Check whether PSL file exists I tested it both with and without the `public_suffix_list.dat` file in the JDK. I left a few inline comments, but this is almost ready to go. modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 79: > 77: String javaHome = System.getProperty("java.home"); > 78: String resourceName = "lib/security/public_suffix_list.dat"; > 79: File f = new File(javaHome, resourceName); I think it would be useful to log a warning here if the public suffix file does not exist (since this code is only executed once the warning would only be logged once). modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 191: > 189: (PrivilegedAction) () -> { > 190: String javaHome = System.getProperty("java.home"); > 191: String resourceName = "lib/security/public_suffix_list.dat"; Maybe have the path to the file in a static final field so you don't have to duplicate it in two places? modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 109: > 107: > 108: if (!pslFileExists()) > 109: return false; Please enclose this in curly braces per coding guidelines. ------------- PR: https://git.openjdk.java.net/jfx/pull/324 From jvos at openjdk.java.net Tue Nov 24 21:20:58 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 24 Nov 2020 21:20:58 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux In-Reply-To: References: Message-ID: On Sat, 7 Nov 2020 23:13:48 GMT, John Neffenger wrote: > This pull request fixes the error when building embedded JavaFX for Linux. > > The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the header file has already been included at that point, and the header contains include guards to ignore subsequent attempts. > > MonocleGLFactory.c > ... > #include > #include "eglUtils.h" > > #include "../PrismES2Defs.h" > > #include "com_sun_prism_es2_MonocleGLContext.h" > #ifndef ANDROID > #define __USE_GNU > #include > #endif > ... > > The `-H` option of `gcc` prints the name of each header file used. Its output shows that `egl.h` ends up including `dlfcn.h` indirectly, but without the required macro definition. > > $ grep -e 'EGL/egl.h' -e 'eglUtils.h' -e 'dlfcn.h' headers.log > . opt/vc/include/EGL/egl.h > ...... usr/include/dlfcn.h > ....... usr/include/arm-linux-gnueabihf/bits/dlfcn.h > . monocle/eglUtils.h > > For the proposed fix, I referred to the page of the *Linux Programmer's Manual* at "`man dlsym`" which states, "The `_GNU_SOURCE` feature test macro must be defined in order to obtain the definitions of `RTLD_DEFAULT` and `RTLD_NEXT` from ``." I also used information in the following two Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 I don't see any harm in this PR, but I wonder which toolchains are still not having `RTLD_NEXT` without specifying GNU_SOURCE. Does it also work if you specify `-D__USE_GNU` to the compiler? ------------- PR: https://git.openjdk.java.net/jfx/pull/350 From mblaesing at doppel-helix.eu Tue Nov 24 21:36:50 2020 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Tue, 24 Nov 2020 22:36:50 +0100 Subject: Connect github username with existing OCA Message-ID: Hi, I submitted a PR for OpenJFX (https://github.com/openjdk/jfx/pull/360) and the skara tooling asks me to submit an OCA. I have had an OCA on file for a long time since I began contributing to the netbeans project. I also contributed to OpenJFX, so in general I assume this is enough. I checked the OCA list signees and I'm listed. So it is unclear whether I can just run "/signed" (as I already have an OCA on file) or something else has to be done to connect my github account with that OCA. The seconde paragraph indicates, that Authors, Committers and Reviewers should open issues to get their username connected, I'm neither, so I'd appreciate advise. Thank you Matthias From kevin.rushforth at oracle.com Tue Nov 24 22:29:03 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Nov 2020 14:29:03 -0800 Subject: Connect github username with existing OCA In-Reply-To: References: Message-ID: Just follow this part of the instructions: > If you already are an OpenJDK Author > , Committer > or Reviewer > , please click here > > to open a new issue so that we can record that fact. Please use "Add > GitHub user matthiasblaesing" as summary for the issue. > -- Kevin On 11/24/2020 1:36 PM, Matthias Bl?sing wrote: > Hi, > > I submitted a PR for OpenJFX (https://github.com/openjdk/jfx/pull/360) > and the skara tooling asks me to submit an OCA. I have had an OCA on > file for a long time since I began contributing to the netbeans > project. I also contributed to OpenJFX, so in general I assume this is > enough. I checked the OCA list signees and I'm listed. > > So it is unclear whether I can just run "/signed" (as I already have an > OCA on file) or something else has to be done to connect my github > account with that OCA. The seconde paragraph indicates, that Authors, > Committers and Reviewers should open issues to get their username > connected, I'm neither, so I'd appreciate advise. > > Thank you > > Matthias > From kcr at openjdk.java.net Tue Nov 24 22:23:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Nov 2020 22:23:56 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v2] In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 16:08:47 GMT, Kevin Rushforth wrote: >> Jonathan Vusich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Added copyright header >> - Merge branch 'master' into jonathan/fix-chart-axis-labels >> - Added fix and test > > Can you merge in the latest `jfx/master`? That way the GitHub actions build/test will be run (although it won't run the new headful test). You also need a copyright header as noted below. While this does fix the specific problem, it introduces a new one. If the labels are initially too big, but after resizing the window would now fit, it does not recompute the orientation. This means that you are left with labels that are rotated even when they don't need to be. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From kevin.rushforth at oracle.com Tue Nov 24 22:30:39 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Nov 2020 14:30:39 -0800 Subject: Connect github username with existing OCA In-Reply-To: References: Message-ID: <0df5932f-47ab-b9e0-47c0-5358289e33f8@oracle.com> Hit send too soon... If you don't have an OpenJDK ID -- meaning you don't have a JBS account -- then you would add a comment with: /signed -- Kevin On 11/24/2020 2:29 PM, Kevin Rushforth wrote: > > > Just follow this part of the instructions: > >> If you already are an OpenJDK Author >> , Committer >> or Reviewer >> , please click here >> >> to open a new issue so that we can record that fact. Please use "Add >> GitHub user matthiasblaesing" as summary for the issue. >> > > -- Kevin > > On 11/24/2020 1:36 PM, Matthias Bl?sing wrote: >> Hi, >> >> I submitted a PR for OpenJFX (https://github.com/openjdk/jfx/pull/360) >> and the skara tooling asks me to submit an OCA. I have had an OCA on >> file for a long time since I began contributing to the netbeans >> project. I also contributed to OpenJFX, so in general I assume this is >> enough. I checked the OCA list signees and I'm listed. >> >> So it is unclear whether I can just run "/signed" (as I already have an >> OCA on file) or something else has to be done to connect my github >> account with that OCA. The seconde paragraph indicates, that Authors, >> Committers and Reviewers should open issues to get their username >> connected, I'm neither, so I'd appreciate advise. >> >> Thank you >> >> Matthias >> > From ajoseph at openjdk.java.net Wed Nov 25 07:09:09 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 25 Nov 2020 07:09:09 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v3] In-Reply-To: References: Message-ID: > We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Create pslFile variable ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/6ed148f6..be156736 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=01-02 Stats: 20 lines in 1 file changed: 10 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324 From kcr at openjdk.java.net Wed Nov 25 14:11:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 Nov 2020 14:11:02 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v3] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 07:09:09 GMT, Arun Joseph wrote: >> We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. >> >> Test: Run PublicSuffixesTest.java > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Create pslFile variable modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 76: > 74: */ > 75: private static final File pslFile = new File( > 76: System.getProperty("java.home"), "lib/security/public_suffix_list.dat"); I think this needs to be in a doPrivileged block. The rest looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/324 From github.com+31666175+jonathanvusich at openjdk.java.net Wed Nov 25 15:58:58 2020 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Wed, 25 Nov 2020 15:58:58 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v2] In-Reply-To: References: Message-ID: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> On Tue, 24 Nov 2020 22:21:04 GMT, Kevin Rushforth wrote: >> Can you merge in the latest `jfx/master`? That way the GitHub actions build/test will be run (although it won't run the new headful test). You also need a copyright header as noted below. > > While this does fix the specific problem, it introduces a new one. If the labels are initially too big, but after resizing the window would now fit, it does not recompute the orientation. This means that you are left with labels that are rotated even when they don't need to be. @kevinrushforth Thank you for catching that. Do you think it would be acceptable to simply rotate the labels back to zero if the user expands the window? ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From johan.vos at gluonhq.com Wed Nov 25 16:54:49 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 25 Nov 2020 17:54:49 +0100 Subject: Request to backport to JavaFX 11 (11.0.10) Message-ID: Hi Kevin, I request permission to backport the following issues to JavaFX 11 (for JavaFX 11.0.10) JDK-8177945: Single cell selection flickers when adding data to TableView JDK-8199592: Control labels truncated at certain DPI scaling levels Both patches apply clean. - Johan From philip.race at oracle.com Wed Nov 25 17:20:08 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 25 Nov 2020 09:20:08 -0800 Subject: Request to backport to JavaFX 11 (11.0.10) In-Reply-To: References: Message-ID: <5FBE9248.5000908@oracle.com> Kevin is out until Monday, but you can have a thumbs up from me if that counts. -phil. On 11/25/20, 8:54 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issues to JavaFX 11 (for > JavaFX 11.0.10) > > JDK-8177945: Single cell selection flickers when adding data to TableView > JDK-8199592: Control labels truncated at certain DPI scaling levels > > Both patches apply clean. > > - Johan From github.com+31666175+jonathanvusich at openjdk.java.net Wed Nov 25 18:06:10 2020 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Wed, 25 Nov 2020 18:06:10 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v3] In-Reply-To: References: Message-ID: <8LlhfU0Zb-0FAM7E1sOl-9LSEzP-unqsmkA8EhB9MiE=.e8024574-6050-4d0a-87a1-09f081136124@github.com> > As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request incrementally with one additional commit since the last revision: Unrotate labels if there is enough space for them ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/342/files - new: https://git.openjdk.java.net/jfx/pull/342/files/49a5e1f7..6d83f79c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=01-02 Stats: 19 lines in 2 files changed: 14 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342 From github.com+1413266+jgneff at openjdk.java.net Thu Nov 26 19:34:59 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 26 Nov 2020 19:34:59 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux In-Reply-To: References: Message-ID: <7EgqFi0m1En2o1W02xDUmGMwr1VXJC0adgkG8E2bAVo=.30870400-9bf8-4d72-a5b3-b6d109ff816f@github.com> On Tue, 24 Nov 2020 21:18:03 GMT, Johan Vos wrote: > I don't see any harm in this PR, but I wonder which toolchains are still not having `RTLD_NEXT` without specifying GNU_SOURCE. Thanks, Johan. I've been following the instructions in the [OpenJFX Wiki][1]. I use the GCC cross-compiler installed by the repository's [crosslibs-armv6hf.sh][2] script. Then I build for ARM using the repository's [armv6hf.gradle][3] build file. > Does it also work if you specify `-D__USE_GNU` to the compiler? No, that prints the same error. The comments in the header file `/usr/include/features.h` suggest that the macro `__USE_GNU` is for internal use, while `_GNU_SOURCE` is defined by the user. I tried the user macro, and it works! So below is an alternative fix in the ARM build file: diff --git a/buildSrc/armv6hf.gradle b/buildSrc/armv6hf.gradle index 05e3e83551..bd56dcf86c 100644 --- a/buildSrc/armv6hf.gradle +++ b/buildSrc/armv6hf.gradle @@ -140,7 +140,7 @@ def iioCFlags = [extraCFlags, ].flatten() def iioLFlags = [extraLFlags].flatten() -def es2EglfbCFlags = [extraCFlags, "-DIS_EGLFB", "-DLINUX"].flatten() +def es2EglfbCFlags = [extraCFlags, "-DIS_EGLFB", "-DLINUX", "-D_GNU_SOURCE"].flatten() def es2EglfbLFlags = [extraLFlags].flatten() def es2MonocleCFlags = [extraCFlags, "-DIS_EGLFB", "-DLINUX"].flatten() def es2MonocleLFlags = [extraLFlags].flatten() It seems the [`_GNU_SOURCE` macro does a lot][4], so it's a question of limiting its use to one C file or enabling it for the entire `prism_es2_monocle` library. I'm fine with either solution. [1]: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float [2]: https://github.com/openjdk/jfx/blob/master/buildSrc/crosslibs/crosslibs-armv6hf.sh [3]: https://github.com/openjdk/jfx/blob/master/buildSrc/armv6hf.gradle [4]: https://stackoverflow.com/q/5582211 ------------- PR: https://git.openjdk.java.net/jfx/pull/350 From jvos at openjdk.java.net Fri Nov 27 14:27:54 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 27 Nov 2020 14:27:54 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux In-Reply-To: <7EgqFi0m1En2o1W02xDUmGMwr1VXJC0adgkG8E2bAVo=.30870400-9bf8-4d72-a5b3-b6d109ff816f@github.com> References: <7EgqFi0m1En2o1W02xDUmGMwr1VXJC0adgkG8E2bAVo=.30870400-9bf8-4d72-a5b3-b6d109ff816f@github.com> Message-ID: On Thu, 26 Nov 2020 19:32:28 GMT, John Neffenger wrote: >> I don't see any harm in this PR, but I wonder which toolchains are still not having `RTLD_NEXT` without specifying GNU_SOURCE. Does it also work if you specify `-D__USE_GNU` to the compiler? > >> I don't see any harm in this PR, but I wonder which toolchains are still not having `RTLD_NEXT` without specifying GNU_SOURCE. > > Thanks, Johan. I've been following the instructions in the [OpenJFX Wiki][1]. I use the GCC cross-compiler installed by the repository's [crosslibs-armv6hf.sh][2] script. Then I build for ARM using the repository's [armv6hf.gradle][3] build file. > >> Does it also work if you specify `-D__USE_GNU` to the compiler? > > No, that prints the same error. The comments in the header file `/usr/include/features.h` suggest that the macro `__USE_GNU` is for internal use, while `_GNU_SOURCE` is defined by the user. I tried the user macro, and it works! > > So below is an alternative fix in the ARM build file: > > diff --git a/buildSrc/armv6hf.gradle b/buildSrc/armv6hf.gradle > index 05e3e83551..bd56dcf86c 100644 > --- a/buildSrc/armv6hf.gradle > +++ b/buildSrc/armv6hf.gradle > @@ -140,7 +140,7 @@ def iioCFlags = [extraCFlags, > ].flatten() > def iioLFlags = [extraLFlags].flatten() > > -def es2EglfbCFlags = [extraCFlags, "-DIS_EGLFB", "-DLINUX"].flatten() > +def es2EglfbCFlags = [extraCFlags, "-DIS_EGLFB", "-DLINUX", "-D_GNU_SOURCE"].flatten() > def es2EglfbLFlags = [extraLFlags].flatten() > def es2MonocleCFlags = [extraCFlags, "-DIS_EGLFB", "-DLINUX"].flatten() > def es2MonocleLFlags = [extraLFlags].flatten() > > It seems the [`_GNU_SOURCE` macro does a lot][4], so it's a question of limiting its use to one C file or enabling it for the entire `prism_es2_monocle` library. I'm fine with either solution. > > [1]: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float > [2]: https://github.com/openjdk/jfx/blob/master/buildSrc/crosslibs/crosslibs-armv6hf.sh > [3]: https://github.com/openjdk/jfx/blob/master/buildSrc/armv6hf.gradle > [4]: https://stackoverflow.com/q/5582211 I think it is safer to use it as a flag for all monocle-es2 compilation then. It is also less intrusive as it doesn't require code changes, so it only affects specific builds. ------------- PR: https://git.openjdk.java.net/jfx/pull/350 From github.com+2179736+matthiasblaesing at openjdk.java.net Fri Nov 27 17:29:08 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 27 Nov 2020 17:29:08 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs Message-ID: The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that the java class com.sun.webkit.MainThread can be found be the JNI function FindClass. This is only true if the class is loadable by the system class loader. One such case is when the OpenJFX modules are loaded from a new ModuleLayer. To fix this, the reference to the class needs to be loaded from when a JNI call from Java into native code is active. In that case FindClass uses the classloader associated with that method. The test code can be executed by running: cd tests/manual/web/dataurl ../../../../gradlew run ------------- Commit messages: - 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs Changes: https://git.openjdk.java.net/jfx/pull/360/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242361 Stats: 191 lines in 6 files changed: 170 ins; 16 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/360.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/360/head:pull/360 PR: https://git.openjdk.java.net/jfx/pull/360 From ajoseph at openjdk.java.net Sat Nov 28 04:54:06 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Sat, 28 Nov 2020 04:54:06 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v4] In-Reply-To: References: Message-ID: <1rqBodcESwVlyftethZ1SylIglmhM5cuDGF7zCHnAqI=.5358b77a-8553-4ad7-9634-1cc3f97f5adc@github.com> > We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add doPrivileged block ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/be156736..fc3b66cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324 From kevin.rushforth at oracle.com Sat Nov 28 17:20:29 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 28 Nov 2020 09:20:29 -0800 Subject: Request to backport to JavaFX 11 (11.0.10) In-Reply-To: References: Message-ID: +1 Since JDK-8199592 is a follow-on to: JDK-8255415 : Nested calls to snap methods in Region give different results I think that one should be backported, too. -- Kevin On 11/25/2020 8:54 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issues to JavaFX 11 (for > JavaFX 11.0.10) > > JDK-8177945: Single cell selection flickers when adding data to TableView > JDK-8199592: Control labels truncated at certain DPI scaling levels > > Both patches apply clean. > > - Johan From duncanmak at gmail.com Sat Nov 28 22:44:41 2020 From: duncanmak at gmail.com (Duncan Mak) Date: Sat, 28 Nov 2020 17:44:41 -0500 Subject: Extending Shape or implementing DelegateShape Message-ID: Hello, I'm interested in having a Node in my scene graph that I can change later on, without losing its place in the scene. I saw that in the old JavaFX 1.x, there used to be a type named DelegateShape which seems to be exactly what I'm looking for. I've tried defining my own Shape subclass, but the docs don't say what I need to override. There's also a line in the docs that says that: An application should not extend the Shape class directly. Doing so may > lead to an UnsupportedOperationException being thrown. Is it possible to write my own DelegateShape in JavaFX 15? Or should Shape and Node be considered effective "sealed"? -- Duncan. From kcr at openjdk.java.net Mon Nov 30 18:49:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 30 Nov 2020 18:49:59 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v4] In-Reply-To: <1rqBodcESwVlyftethZ1SylIglmhM5cuDGF7zCHnAqI=.5358b77a-8553-4ad7-9634-1cc3f97f5adc@github.com> References: <1rqBodcESwVlyftethZ1SylIglmhM5cuDGF7zCHnAqI=.5358b77a-8553-4ad7-9634-1cc3f97f5adc@github.com> Message-ID: On Sat, 28 Nov 2020 04:54:06 GMT, Arun Joseph wrote: >> We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. >> >> Test: Run PublicSuffixesTest.java > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Add doPrivileged block I verified that the doPrivileged change allows it to work with a security manager. The only issue I now see is related to the log warning. modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java line 86: > 84: if (!pslFile.exists()) { > 85: logger.warning("Resource not found: ", > 86: "lib/security/public_suffix_list.dat"); This should be a single string, so you need to concatenate them. ------------- PR: https://git.openjdk.java.net/jfx/pull/324