From a.ankit.srivastava at oracle.com Mon Jul 4 09:35:14 2016 From: a.ankit.srivastava at oracle.com (Ankit Srivastava) Date: Mon, 4 Jul 2016 02:35:14 -0700 (PDT) Subject: [9] Review Request: 8160757 Implement overridePreference() for DRT framework Message-ID: <926c9e5e-4996-4888-a416-fdf263d09dc7@default> Hi Arun, Murali, Please review the fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8160757 WebRev: http://cr.openjdk.java.net/~asrivastava/8160757/webrev.00/ Regards, Ankit From arunprasad.rajkumar at oracle.com Mon Jul 4 13:44:22 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 4 Jul 2016 19:14:22 +0530 Subject: [webkit] [9] Review request for 8160260: WebView cannot render CSS background image with SVG data In-Reply-To: References: Message-ID: <2b2892d7-4da1-26d2-b073-0d1c743515d3@oracle.com> Hello Alexander Z, Chien, Guru Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8160260 Webrev: http://cr.openjdk.java.net/~arajkumar/8160260/webrev.00 Issue: SVG images are not shown when rendering initiated in the context of or CSS background property. Analysis: After r179335[1], WebKit started using GraphicsContext::clipBounds from SVGImage::draw to eliminated unnecessary rendering. Our JavaFX port doesn't implement GraphicsContext::clipBounds and returns empty bounds which is (0,0 0x0). Due to empty bounds, SVG image drawing is skipped. In order to implement GraphicsContext::clipBounds, we need to get clip information from WCPrismGraphicsContext object, but is not accessible from WebCore. Solution: Added a shadow variable in GraphicsContextState to maintain current clip information, it will be updated on each call to platform clip API. [1] http://trac.webkit.org/changeset/179335 Regards, Arun From guru.hb at oracle.com Tue Jul 5 04:13:53 2016 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 5 Jul 2016 09:43:53 +0530 Subject: [webkit][9] Review request 8160563: jvm crash at javafx com.sun.webkit.WebPage.twkPrePaint (GFlag + Heap verification) Message-ID: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> Hi Alexander & Arun, Please review the fix for: JBS : https://bugs.openjdk.java.net/browse/JDK-8160563 webrev : file:///D:/ws/patch/8160563/webrev.00 RC and Solution updated in JBS. Thanks, Guru From guru.hb at oracle.com Tue Jul 5 04:59:33 2016 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 5 Jul 2016 10:29:33 +0530 Subject: [webkit][9] Review request 8160563: jvm crash at javafx com.sun.webkit.WebPage.twkPrePaint (GFlag + Heap verification) In-Reply-To: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> References: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> Message-ID: Please ref webrev : http://cr.openjdk.java.net/~ghb/8160563/webrev.00 On 5/7/16 9:43 AM, Guru Hb wrote: > Hi Alexander & Arun, > > Please review the fix for: > JBS : https://bugs.openjdk.java.net/browse/JDK-8160563 > webrev : file:///D:/ws/patch/8160563/webrev.00 > > RC and Solution updated in JBS. > > Thanks, > Guru From andrey.rusakov at oracle.com Tue Jul 5 09:56:09 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Tue, 5 Jul 2016 12:56:09 +0300 Subject: Fix for test runner review request. Message-ID: <577B8439.9070108@oracle.com> Hi everyone. Please take a look at my fix for openjfx test runner: JDK-8160349, webrev: 8160349/webrev.00 Fixes are applicable for both 8 and 9 tests. From chien.yang at oracle.com Wed Jul 6 00:01:59 2016 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 05 Jul 2016 17:01:59 -0700 Subject: [9] Code Review Request For 8090322: Need new tree visible property in Node that consider Scene and Stage visibility Message-ID: <577C4A77.2000003@oracle.com> Hi Jonathan, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8090322 Thanks, - Chien From chris.bensen at oracle.com Wed Jul 6 00:40:54 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 5 Jul 2016 17:40:54 -0700 Subject: [9] Review Request: 8149975: [packager] Programmatically Determine JDK or JRE Modules Message-ID: <0A146A88-B013-4AD0-9D3C-08285FFA9A0A@oracle.com> Hi David, Please review this change for the Java Packager to programmatically get a list of the modules that are to be redistributable. This was waiting on https://bugs.openjdk.java.net/browse/JDK-8155955 and https://bugs.openjdk.java.net/browse/JDK-8160005 which have now fixed, but is still waiting on https://bugs.openjdk.java.net/browse/JDK-8158410 but I thought I?d get the review complete in the meantime. Let me know if the build.gradle changes are to your liking. JIRA: https://bugs.openjdk.java.net/browse/JDK-8149975 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8149975/webrev.01/ Thanks, Chris From tom.schindl at bestsolution.at Wed Jul 6 10:05:03 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 6 Jul 2016 12:05:03 +0200 Subject: JavaFX with Eclipse and JDK9 In-Reply-To: References: Message-ID: <247bc16f-f607-cf26-1d52-a465b274e4db@bestsolution.at> For what is worth - the problem is that JDT-Beta-Builds are only modules starting with "java.". I've started a thread at jdt-core mailing list [1] - I started working on a patch to also add "javafx." and hope it gets accepted. Tom [1]http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg02626.html On 27.05.16 16:04, Dr. Michael Paus wrote: > I recently tried to get a JavaFX application running with the latest EA > build of JDK9 from > within Eclipse but I failed. Can anybody on this list tell me what I > have to do to get that > working? I have the latest milestone release of Eclipse Neon installed > together with the > latest JDK9 and I have also installed the Java 9 Support (BETA) for > Neon. I also installed > e(fx)clipse if that should matter. The problem is that I cannot access > any of the JavaFX > packages. I even added a module-info.java file to the project which > explicitly requires the > JavaFX modules but nothing helped so far. The JRE System Library only > contains the modules > which are in the java.* namespace but none of the other modules > especially the javafx.* > modules and I don't find any option to add these. Did anybody ever try > this and succeeded? > > Thanks, Michael > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From mp at jugs.org Wed Jul 6 12:55:36 2016 From: mp at jugs.org (Dr. Michael Paus) Date: Wed, 6 Jul 2016 14:55:36 +0200 Subject: JavaFX with Eclipse and JDK9 In-Reply-To: <247bc16f-f607-cf26-1d52-a465b274e4db@bestsolution.at> References: <247bc16f-f607-cf26-1d52-a465b274e4db@bestsolution.at> Message-ID: <5b98652e-9ad7-2278-b8db-7923dc23187d@jugs.org> Am 06.07.16 um 12:05 schrieb Tom Schindl: > For what is worth - the problem is that JDT-Beta-Builds are only modules > starting with "java.". > > I've started a thread at jdt-core mailing list [1] - I started working > on a patch to also add "javafx." and hope it gets accepted. I keep my fingers crossed. Keep us informed about the outcome. > > Tom > > [1]http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg02626.html > > On 27.05.16 16:04, Dr. Michael Paus wrote: >> I recently tried to get a JavaFX application running with the latest EA >> build of JDK9 from >> within Eclipse but I failed. Can anybody on this list tell me what I >> have to do to get that >> working? I have the latest milestone release of Eclipse Neon installed >> together with the >> latest JDK9 and I have also installed the Java 9 Support (BETA) for >> Neon. I also installed >> e(fx)clipse if that should matter. The problem is that I cannot access >> any of the JavaFX >> packages. I even added a module-info.java file to the project which >> explicitly requires the >> JavaFX modules but nothing helped so far. The JRE System Library only >> contains the modules >> which are in the java.* namespace but none of the other modules >> especially the javafx.* >> modules and I don't find any option to add these. Did anybody ever try >> this and succeeded? >> >> Thanks, Michael >> > From David.Hill at Oracle.com Wed Jul 6 19:58:59 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 06 Jul 2016 15:58:59 -0400 Subject: [9] Review Request: 8149975: [packager] Programmatically Determine JDK or JRE Modules In-Reply-To: <0A146A88-B013-4AD0-9D3C-08285FFA9A0A@oracle.com> References: <0A146A88-B013-4AD0-9D3C-08285FFA9A0A@oracle.com> Message-ID: <577D6303.8090104@Oracle.com> On 7/5/16, 8:40 PM, Chris Bensen wrote: > Hi David, > > Please review this change for the Java Packager to programmatically get a list of the modules that are to be redistributable. This was waiting on https://bugs.openjdk.java.net/browse/JDK-8155955 and https://bugs.openjdk.java.net/browse/JDK-8160005 which have now fixed, but is still waiting on https://bugs.openjdk.java.net/browse/JDK-8158410 but I thought I?d get the review complete in the meantime. Let me know if the build.gradle changes are to your liking. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8149975 > Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8149975/webrev.01/ > > Thanks, > Chris Couple of minor nits added to the jbs. Kevin did not say what the changes that are needed in 8158410 , I wonder if they are in place already. Dave -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From andrey.rusakov at oracle.com Wed Jul 6 20:21:00 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Wed, 6 Jul 2016 23:21:00 +0300 Subject: Fix for test runner review request. In-Reply-To: <577B8439.9070108@oracle.com> References: <577B8439.9070108@oracle.com> Message-ID: <577D682C.3050806@oracle.com> Could anyone commit this fix to open fx tests, 8 and 9? It's important for testing process. 05.07.2016 12:56, Andrey Rusakov ?????: > Hi everyone. > Please take a look at my fix for openjfx test runner: JDK-8160349, > webrev: > 8160349/webrev.00 > > Fixes are applicable for both 8 and 9 tests. From guru.hb at oracle.com Thu Jul 7 11:02:12 2016 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 7 Jul 2016 16:32:12 +0530 Subject: Fix for test runner review request. In-Reply-To: <577D682C.3050806@oracle.com> References: <577B8439.9070108@oracle.com> <577D682C.3050806@oracle.com> Message-ID: http://hg.openjdk.java.net/openjfx/8u-dev/tests/rev/7562f73c8642 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 On 7/7/16 1:51 AM, Andrey Rusakov wrote: > Could anyone commit this fix to open fx tests, 8 and 9? It's important > for testing process. > > 05.07.2016 12:56, Andrey Rusakov ?????: >> Hi everyone. >> Please take a look at my fix for openjfx test runner: JDK-8160349, >> webrev: >> 8160349/webrev.00 >> >> Fixes are applicable for both 8 and 9 tests. > From alexander at nyssen.org Fri Jul 8 21:28:18 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Fri, 8 Jul 2016 23:28:18 +0200 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> Message-ID: <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> Hi Kevin, all, attached please find a revised patch, where I have added the required export to PlatformImpl and have fixed the build script, so it does no longer break when being executed in jigsaw mode. As swt is no named module yet, I have disabled the JUnit test in jigsaw mode for now. We would probably have to set up swt as a named module to enable this, and would further have to make swt-debug.jar available as an automated module on its module path. But this is a different problem. Regards, Alexander -------------- next part -------------- > Am 30.06.2016 um 12:14 schrieb Alexander Nyssen : > > Hi Kevin, > >> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth : >> >> Hi Alexander, >> >> I attached the patch to the bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8088147 >> >> If I build it and run the manual test in "legacy" mode, meaning run everything with 9+109 and the legacy jfxrt.jar file, then it runs and the cursor now changes. So this looks like a good starting point for a fix. > > Fine. > >> >> I tried building and running this in Jigsaw mode (building with jdk-9+109, but running the tests with a more recent JDK that includes modularization support), and noticed two problems right away that must be addressed: >> >> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the build fails right away with an exception from gradle: >> >>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >> >> Wiring up SWT-based tests to our unit test harness will take a bit more work than what you have provided (not even counting the Mac issue, which could be handled by excluding the test on Mac). In the short term, relying on manual tests for this fix might be best. >> > > I did not execute the tests in jigsaw mode yet, because other tests failed in this mode, too (as indicated in an earlier discussion). I will try to set things up in a virtual machine with Windows and/or Linux so I can work on the Gradle tests without having to deal with the Mac issue. The test harness will IMHO also be required for other contributions, and it would of course be fine if the automated test, I included in this patch, could be executed as well. > >> >> 2. You have introduced a dependency on a new internal package, com.sun.javafx.tk. If this is required in order to implement the fix, then you will need to add this package to the list of packages exports to javafx.swt in PlatformImpl; otherwise the following exception is thrown at runtime: >> >> Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.tk to module javafx.swt > > This dependency is required unless there is public API to convert a platform image (which is provided by the image cursor frame) to an image. To me, > Image image = Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); > seemed to be the way to go. I will thus add the respective export in a revised patch. > >> >> >> I won't have time to sponsor this change until the second half of July, but if others have time, the review can proceed and I'll pick it back up then if it is in good enough shape to run. > > Especially setting up the SWT test harness will be kind of a blocker for succeeding contributions, so it would be nice if somebody could step in. > > Regards, > Alexander > >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >>> Hi Alexander, >>> >>> It looks like your patch was stripped out by the mailing list server. >>> >>> Can you please send me the patch offline, as a zip file (so line endings are preserved across different systems), and I will unzip it and attach it to the bug report. >>> >>> -- Kevin >>> >>> >>> Alexander Nyssen wrote: >>>> Hi, >>>> >>>> I have worked on a first contribution related to JDK-8088147. Attached please find a patch (created in extended Git format) that comprises the related changes. I have augmented the implementation of javafx.embed.swt.SWTCursors to handle the image cursor case. I further adjusted javafx.scene.Scene to update the cursor frame (in addition to the cursor) within synchronizeSceneProperties, so the cursor is not cleared in the first pulse succeeding the cursor property change. >>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, as well as a manual test (SWTImageCursorTest) to the systemTests module, with which the proper behavior can be verified. As no tests for SWT existed so far, I updated the build.gradle and gradle.properties files to support an SWT_TEST option, which allows to handle them similar to Swing tests. I also added the respective SWT dependency to the systemTests module. Please note that the JUnit test can currently not be executed using Gradle on the Mac (where the manual test currently is the single option; the automated tests are disabled), because there SWT-based tests require the -XstartOnFirstThread option that is currently not supported by the Gradle test runner (see https://issues.gradle.org/browse/GRADLE-3290 for details). We would have to use an ant task as a workaround. >>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>> > From alexander.matveev at oracle.com Fri Jul 8 21:44:19 2016 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 8 Jul 2016 14:44:19 -0700 Subject: [8u, 9] Review request for 8159869: HTTP Live Streaming not working anymore Message-ID: <17bb2407-02df-f78b-1b1b-db46cbb1afee@oracle.com> Hi David, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8159869 Thanks, Alexander From chien.yang at oracle.com Sat Jul 9 00:29:45 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 08 Jul 2016 17:29:45 -0700 Subject: [9] Code Review Request For 8088846: PopupWindow does not disappear when associated Control is not visible. Message-ID: <57804579.5020003@oracle.com> Hi Dave and Jonathan, Please review the proposed fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8088846 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088846/webrev.00/ Thanks, - Chien From alexander at nyssen.org Mon Jul 11 17:59:59 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Mon, 11 Jul 2016 19:59:59 +0200 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> Message-ID: <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> It seems my attachment has again been ?consumed? by the list. Trying again with an archive containing the patch file. Regards, Alexander -------------- next part -------------- > Am 08.07.2016 um 23:28 schrieb Alexander Nyssen : > > Hi Kevin, all, > > attached please find a revised patch, where I have added the required export to PlatformImpl and have fixed the build script, so it does no longer break when being executed in jigsaw mode. > > As swt is no named module yet, I have disabled the JUnit test in jigsaw mode for now. We would probably have to set up swt as a named module to enable this, and would further have to make swt-debug.jar available as an automated module on its module path. But this is a different problem. > > Regards, > Alexander > > >> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen : >> >> Hi Kevin, >> >>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth : >>> >>> Hi Alexander, >>> >>> I attached the patch to the bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>> >>> If I build it and run the manual test in "legacy" mode, meaning run everything with 9+109 and the legacy jfxrt.jar file, then it runs and the cursor now changes. So this looks like a good starting point for a fix. >> >> Fine. >> >>> >>> I tried building and running this in Jigsaw mode (building with jdk-9+109, but running the tests with a more recent JDK that includes modularization support), and noticed two problems right away that must be addressed: >>> >>> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the build fails right away with an exception from gradle: >>> >>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>> >>> Wiring up SWT-based tests to our unit test harness will take a bit more work than what you have provided (not even counting the Mac issue, which could be handled by excluding the test on Mac). In the short term, relying on manual tests for this fix might be best. >>> >> >> I did not execute the tests in jigsaw mode yet, because other tests failed in this mode, too (as indicated in an earlier discussion). I will try to set things up in a virtual machine with Windows and/or Linux so I can work on the Gradle tests without having to deal with the Mac issue. The test harness will IMHO also be required for other contributions, and it would of course be fine if the automated test, I included in this patch, could be executed as well. >> >>> >>> 2. You have introduced a dependency on a new internal package, com.sun.javafx.tk. If this is required in order to implement the fix, then you will need to add this package to the list of packages exports to javafx.swt in PlatformImpl; otherwise the following exception is thrown at runtime: >>> >>> Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.tk to module javafx.swt >> >> This dependency is required unless there is public API to convert a platform image (which is provided by the image cursor frame) to an image. To me, >> Image image = Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >> seemed to be the way to go. I will thus add the respective export in a revised patch. >> >>> >>> >>> I won't have time to sponsor this change until the second half of July, but if others have time, the review can proceed and I'll pick it back up then if it is in good enough shape to run. >> >> Especially setting up the SWT test harness will be kind of a blocker for succeeding contributions, so it would be nice if somebody could step in. >> >> Regards, >> Alexander >> >>> >>> -- Kevin >>> >>> >>> Kevin Rushforth wrote: >>>> Hi Alexander, >>>> >>>> It looks like your patch was stripped out by the mailing list server. >>>> >>>> Can you please send me the patch offline, as a zip file (so line endings are preserved across different systems), and I will unzip it and attach it to the bug report. >>>> >>>> -- Kevin >>>> >>>> >>>> Alexander Nyssen wrote: >>>>> Hi, >>>>> >>>>> I have worked on a first contribution related to JDK-8088147. Attached please find a patch (created in extended Git format) that comprises the related changes. I have augmented the implementation of javafx.embed.swt.SWTCursors to handle the image cursor case. I further adjusted javafx.scene.Scene to update the cursor frame (in addition to the cursor) within synchronizeSceneProperties, so the cursor is not cleared in the first pulse succeeding the cursor property change. >>>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, as well as a manual test (SWTImageCursorTest) to the systemTests module, with which the proper behavior can be verified. As no tests for SWT existed so far, I updated the build.gradle and gradle.properties files to support an SWT_TEST option, which allows to handle them similar to Swing tests. I also added the respective SWT dependency to the systemTests module. Please note that the JUnit test can currently not be executed using Gradle on the Mac (where the manual test currently is the single option; the automated tests are disabled), because there SWT-based tests require the -XstartOnFirstThread option that is currently not supported by the Gradle test runner (see https://issues.gradle.org/browse/GRADLE-3290 for details). We would have to use an ant task as a workaround. >>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>> >> > From alexander at nyssen.org Tue Jul 12 06:19:37 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Tue, 12 Jul 2016 08:19:37 +0200 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> Message-ID: <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> It seems I was unsuccessful again. If somebody would be willing to sponsor this contribution while Kevin is away (or at least update the patch provided for JDK-8088147), I could mail the patch privately. Regards, Alexander > Am 11.07.2016 um 19:59 schrieb Alexander Nyssen : > > It seems my attachment has again been ?consumed? by the list. Trying again with an archive containing the patch file. > > Regards, > Alexander > > >> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen : >> >> Hi Kevin, all, >> >> attached please find a revised patch, where I have added the required export to PlatformImpl and have fixed the build script, so it does no longer break when being executed in jigsaw mode. >> >> As swt is no named module yet, I have disabled the JUnit test in jigsaw mode for now. We would probably have to set up swt as a named module to enable this, and would further have to make swt-debug.jar available as an automated module on its module path. But this is a different problem. >> >> Regards, >> Alexander >> >> >>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen : >>> >>> Hi Kevin, >>> >>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth : >>>> >>>> Hi Alexander, >>>> >>>> I attached the patch to the bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>> >>>> If I build it and run the manual test in "legacy" mode, meaning run everything with 9+109 and the legacy jfxrt.jar file, then it runs and the cursor now changes. So this looks like a good starting point for a fix. >>> >>> Fine. >>> >>>> >>>> I tried building and running this in Jigsaw mode (building with jdk-9+109, but running the tests with a more recent JDK that includes modularization support), and noticed two problems right away that must be addressed: >>>> >>>> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the build fails right away with an exception from gradle: >>>> >>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>> >>>> Wiring up SWT-based tests to our unit test harness will take a bit more work than what you have provided (not even counting the Mac issue, which could be handled by excluding the test on Mac). In the short term, relying on manual tests for this fix might be best. >>>> >>> >>> I did not execute the tests in jigsaw mode yet, because other tests failed in this mode, too (as indicated in an earlier discussion). I will try to set things up in a virtual machine with Windows and/or Linux so I can work on the Gradle tests without having to deal with the Mac issue. The test harness will IMHO also be required for other contributions, and it would of course be fine if the automated test, I included in this patch, could be executed as well. >>> >>>> >>>> 2. You have introduced a dependency on a new internal package, com.sun.javafx.tk. If this is required in order to implement the fix, then you will need to add this package to the list of packages exports to javafx.swt in PlatformImpl; otherwise the following exception is thrown at runtime: >>>> >>>> Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.tk to module javafx.swt >>> >>> This dependency is required unless there is public API to convert a platform image (which is provided by the image cursor frame) to an image. To me, >>> Image image = Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>> seemed to be the way to go. I will thus add the respective export in a revised patch. >>> >>>> >>>> >>>> I won't have time to sponsor this change until the second half of July, but if others have time, the review can proceed and I'll pick it back up then if it is in good enough shape to run. >>> >>> Especially setting up the SWT test harness will be kind of a blocker for succeeding contributions, so it would be nice if somebody could step in. >>> >>> Regards, >>> Alexander >>> >>>> >>>> -- Kevin >>>> >>>> >>>> Kevin Rushforth wrote: >>>>> Hi Alexander, >>>>> >>>>> It looks like your patch was stripped out by the mailing list server. >>>>> >>>>> Can you please send me the patch offline, as a zip file (so line endings are preserved across different systems), and I will unzip it and attach it to the bug report. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Alexander Nyssen wrote: >>>>>> Hi, >>>>>> >>>>>> I have worked on a first contribution related to JDK-8088147. Attached please find a patch (created in extended Git format) that comprises the related changes. I have augmented the implementation of javafx.embed.swt.SWTCursors to handle the image cursor case. I further adjusted javafx.scene.Scene to update the cursor frame (in addition to the cursor) within synchronizeSceneProperties, so the cursor is not cleared in the first pulse succeeding the cursor property change. >>>>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, as well as a manual test (SWTImageCursorTest) to the systemTests module, with which the proper behavior can be verified. As no tests for SWT existed so far, I updated the build.gradle and gradle.properties files to support an SWT_TEST option, which allows to handle them similar to Swing tests. I also added the respective SWT dependency to the systemTests module. Please note that the JUnit test can currently not be executed using Gradle on the Mac (where the manual test currently is the single option; the automated tests are disabled), because there SWT-based tests require the -XstartOnFirstThread option that is currently not supported by the Gradle test runner (see https://issues.gradle.org/browse/GRADLE-3290 for details). We would have to use an ant task as a workaround. >>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>> >>> >> > From a.ankit.srivastava at oracle.com Tue Jul 12 10:15:23 2016 From: a.ankit.srivastava at oracle.com (Ankit Srivastava) Date: Tue, 12 Jul 2016 03:15:23 -0700 (PDT) Subject: [9] Review Request : Assertion fails with https://html-online.com/editor/ Message-ID: Hi Arun, Murali, Please review the patch: JBS: https://bugs.openjdk.java.net/browse/JDK-8161137 Webrev: http://cr.openjdk.java.net/~asrivastava/8161137/webrev.00/ JBS updated. Regards, Ankit From andrey.rusakov at oracle.com Tue Jul 12 14:00:36 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Tue, 12 Jul 2016 17:00:36 +0300 Subject: Test bug fix review request. Message-ID: <5784F804.9030103@oracle.com> Hi everyone. Please take a look at my fix for openjfx test: JDK-8161202 , webrev: 8161202/webrev.00 . Fix just removes test, that relies on external webpage which doesn't exist now. Fix is applicable for both 8 and 9 tests. P.S. I think, manual only tests could be completely moved back to "closed" test workspace. From arunprasad.rajkumar at oracle.com Wed Jul 13 08:09:53 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 13 Jul 2016 13:39:53 +0530 Subject: [webkit] [9] Review request for 8161258: [Win] Timer functionality is broken after JDK-8089563 In-Reply-To: <2b2892d7-4da1-26d2-b073-0d1c743515d3@oracle.com> References: <2b2892d7-4da1-26d2-b073-0d1c743515d3@oracle.com> Message-ID: <80129ade-ef03-2eca-74ee-1f8387166622@oracle.com> Hello Guru, Murali, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8161258 Webrev: http://cr.openjdk.java.net/~arajkumar/8161258/webrev.00 Issue: Timer functionality is broken after JDK-8161258 in Windows. Analysis: Our monotonically increasing time implementation for windows is based on glib's g_get_monotonic_time[1] function which returns time in microseconds. So the windows implementation of g_get_monotonic_time multiplies the ticks in millisecond by 1000 to convert to microseconds. Solution: WTF::monotonicallyIncreasingTime() expects time in seconds, so we need to divide by value returned by GetTickCount64 by 1000, since it is in milliseconds. Regards, Arun From arunprasad.rajkumar at oracle.com Wed Jul 13 10:58:30 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 13 Jul 2016 16:28:30 +0530 Subject: [webkit] [9] Review request for 8160769: [WebView] Unable to tile SVG image using css background property In-Reply-To: <80129ade-ef03-2eca-74ee-1f8387166622@oracle.com> References: <80129ade-ef03-2eca-74ee-1f8387166622@oracle.com> Message-ID: Hello Guru, Alexander Z, Murali, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8160769 Webrev: http://cr.openjdk.java.net/~arajkumar/8160769/webrev.00 Issue: Unable to tile SVG image using css background property Analysis: For tiled SVG image drawing, WebCore creates a temporary Graphics buffer(ImageBufferJava)[1] and renders SVG contents into it. Once the SVG is rendered in the temporary graphics buffer, WebCore will call Image::drawPattern to tile it on the WebPage's back buffer. As soon as drawing is completed, temporary graphics buffer will be destroyed. FX WebView's GraphicsContext APIs are asynchronous in nature(rendered in FX render thread using RenderQueue), so temporary graphics buffer would have been destroyed even before rendering the SVG content into it. At later point of time, when Image::drawPattern is executed in render thread, it will be accessing a GraphicsContext of an destroyed object. Solution: Before destroying an Native ImageBuffer, flush all its render queue commands synchronously, So that it's content will be rendered as expected. [1] http://trac.webkit.org/browser/trunk/Source/WebCore/svg/graphics/SVGImage.cpp?rev=187486#L202 Regards, Arun From andrey.rusakov at oracle.com Wed Jul 13 10:59:02 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Wed, 13 Jul 2016 13:59:02 +0300 Subject: Test bug fix review request. Message-ID: <57861EF6.8080507@oracle.com> Hi everyone. Please take a look at my fix for openjfx test: JDK-8157589 , webrev: 8157589/ With best regards, Andrew. From diego.cirujano-cuesta at zeiss.com Wed Jul 13 11:40:09 2016 From: diego.cirujano-cuesta at zeiss.com (Cirujano Cuesta, Diego) Date: Wed, 13 Jul 2016 11:40:09 +0000 Subject: ProgressIndicator indeterminate transition bugs In-Reply-To: <56DF2AB7.6070903@oracle.com> References: <56D36C5A.3080500@oracle.com> <73247A66-A5E4-4D28-9EB2-539CA8FC2CBD@oracle.com> <56DF2AB7.6070903@oracle.com> Message-ID: Hi Chien, Jonathan, I saw treeNode and the progress indicator issues are all done as talked, GREAT! Are they planned to be included in Java 8? Cheers, Diego -----Original Message----- From: Chien Yang [mailto:chien.yang at oracle.com] Sent: Dienstag, 8. M?rz 2016 20:41 To: Cirujano Cuesta, Diego ; jonathan.giles at oracle.com; openjfx-dev at openjdk.java.net Subject: Re: ProgressIndicator indeterminate transition bugs You may track the progress of this work with this JIRA for now. We are still investigating the scope and impact of this work. We may decide to create a new JIRA and resolve this as a duplicate if we decide to go with a better naming. https://bugs.openjdk.java.net/browse/JDK-8090322 - Chien On 03/08/16 01:58, Cirujano Cuesta, Diego wrote: > Great! In that case forget the patch I made, it doesn?t make sense until the treeVisible property is implemented. Is there any jira ticket that I could follow? > > Thank you Jonathan. > > From: Jonathan Giles [mailto:jonathan.giles at oracle.com] > Sent: Dienstag, 8. M?rz 2016 10:01 > To: Cirujano Cuesta, Diego; openjfx-dev at openjdk.java.net > Subject: RE: ProgressIndicator indeterminate transition bugs > > The plan is that a new public API will be developed that matches the expectations, whilst retaining the existing treeVisible semantics in that API. Chien will be looking into this in the coming weeks. At that point we can properly fix these issues. > > -- Jonathan > Sent from a touch device. Please excuse my brevity. > On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, Diego" > wrote: > > Hi all, > > As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is buggy. Is it still buggy? If yes, is there intention to fix the treeVisible behavior? In case of fixing this it could be used to fix this issue. If I am not wrong, treeVisible is still used by Node, SwingNode and MediaView. > > @Jonathan As you mentioned in JDK-8094829 "having a correctly working treeVisible property would be immensely useful." And I am completely agree and I would like to add that having in the public API would be even better :-). > > Thank you, > Diego > > -----Original Message----- > From: Jonathan Giles [mailto:jonathan.giles at oracle.com] > Sent: Sonntag, 28. Februar 2016 22:54 > To: Cirujano Cuesta, Diego; > openjfx-dev at openjdk.java.net > Subject: Re: ProgressIndicator indeterminate transition bugs > > If you can, are you able to file bug reports for these? > > -- Jonathan > > On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote: > > Hi all, > > We found two important bugs in ProgressIndicator that are related with the following tickets: > > https://bugs.openjdk.java.net/browse/JDK-8094829 > https://bugs.openjdk.java.net/browse/JDK-8094078 > > Now are quite critical because in a 4K monitor may cause OutOfMemoryException. > > Using the following example: > " > public class JFXMain extends Application{ > > @Override > public void start(Stage primaryStage) throws Exception { > HBox root = new HBox(); > ToggleButton toggleButton = new ToggleButton(); > ProgressIndicator progressIndicator = new ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS); > StackPane stackPane = new StackPane(progressIndicator); > stackPane.visibleProperty().bind(toggleButton.selectedProperty()); > root.getChildren().addAll(toggleButton, stackPane); > primaryStage.setScene(new Scene(root)); > primaryStage.show(); > } > } > " > > ** First bug ** > > Starting the Progress Indicator with indeterminate progress will > trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599 > start the animation even is not shown already: > indeterminateTransition.playFromStart(); > > ** Second bug ** > > With the last commits in ProgressIndicator, as commented in JDK-8094829, the listeners do not care about the real visibility of the node(before it was used impl_treeVisibleProperty()). The consequence is that the ProgressIndicator in the example won?t be stopped. > > I can imagine that impl_treeVisibleProperty() should not be used and Jonathan G. said: " but I can't reliably fix that without an API such as what I expect the treeVisible API should do." But we did not find such alternative property. > > The solution we though is the usage of internal tree visible property like this: > > 1. Modify method: > " > protected void updateAnimation(boolean isTreeVisible) { " > 2. Remove current calls to method in > " > @Override protected void handleControlPropertyChanged(String p) { > super.handleControlPropertyChanged(p); > > if ("INDETERMINATE".equals(p)) { > initialize(); > } else if ("PROGRESS".equals(p)) { > updateProgress(); > } > } > " > 3. Add listener at the end of the IndeterminateSpinner contructor the visibility listener: > " > private IndeterminateSpinner(boolean spinEnabled, Paint fillOverride) { > [...] > impl_treeVisibleProperty().addListener((obs, oldVal, newVal) ->{ > updateAnimation(newVal); > }); > } > " > > What do you think? > > Additional note: I would like to add one more thing. I think that could be very good a property ReadOnlyBooleanProperty treeVisibleProperty() available in all Nodes. > > Please let me know if we can do something else. > > Diego > > From alexander at nyssen.org Wed Jul 13 12:46:05 2016 From: alexander at nyssen.org (=?utf-8?Q?Alexander_Ny=C3=9Fen?=) Date: Wed, 13 Jul 2016 14:46:05 +0200 Subject: Fwd: Update Notification: Bug Report - JDK-8161282 References: <15624918.0.1468411285645.JavaMail.ndcosta@sc11152510.us.oracle.com> Message-ID: <9B905A25-5FB5-482B-98D6-B3F8015B40FA@nyssen.org> > Hi all, > > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8161282 has been resolved as a duplicate of http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8143596, but IMHO this is not the case, as JDK-8143596 is related to touch gesture events, whereas JDK-81611282 refers to mouse scroll events. I would propose to either update JDK-8143596 or not resolve JDK-8161282 as a duplicate. > > Regards, > Alexander > Von: Bug-Report-Daemon_WW at ORACLE.COM > Datum: 13. Juli 2016 um 14:01:25 MESZ > An: nyssen at itemis.de > Betreff: Update Notification: Bug Report - JDK-8161282 > > [This is an automated response. Please do not reply.] > > Dear Java Developer, > > We have finished evaluating your report and have assigned it a Bug ID: JDK-8161282. The issue is visible on bugs.java.com at the following url http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8161282 . > > We work to resolve the issues that are submitted to us according to their impact to the community as a whole, and make no promises as to the time or release in which a bug might be fixed. If this issue has a significant impact on your project you may want to consider using one of the technical support offerings available at Oracle Support. > > Regards, > Java Developer Support From murali.billa at oracle.com Wed Jul 13 14:02:56 2016 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 13 Jul 2016 07:02:56 -0700 (PDT) Subject: [9] Review request for 8161053: Passing objects between JavaScript (JavaFX / WebKit) and Java causes a memory leak In-Reply-To: References: <80129ade-ef03-2eca-74ee-1f8387166622@oracle.com> Message-ID: <44bc17ad-9081-4630-9576-9c6244f372f5@default> Hi Arun, Guru, Ankit Please review below fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8161053 Webrev: http://cr.openjdk.java.net/~mbilla/8161053/webrev.00/ Thanks, Murali From andrey.rusakov at oracle.com Wed Jul 13 15:52:29 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Wed, 13 Jul 2016 18:52:29 +0300 Subject: Yet another test bug review request. Message-ID: <578663BD.4090106@oracle.com> Hello, everyone! Please take a look at another testbug fix from me. Bug: JDK-8161287 Webrev: 8161287/webrev.00 Same fix is applicable for both 8 and 9 test workspaces. From chien.yang at oracle.com Wed Jul 13 17:00:14 2016 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 13 Jul 2016 10:00:14 -0700 Subject: ProgressIndicator indeterminate transition bugs In-Reply-To: References: <56D36C5A.3080500@oracle.com> <73247A66-A5E4-4D28-9EB2-539CA8FC2CBD@oracle.com> <56DF2AB7.6070903@oracle.com> Message-ID: <5786739E.2010503@oracle.com> Hi Diego, As far as I'm aware these fixes aren't candidates for back port to 8. We will have to evaluate them if you can provide us a good justification for doing so. Thanks, - Chien On 7/13/16, 4:40 AM, Cirujano Cuesta, Diego wrote: > Hi Chien, Jonathan, > > I saw treeNode and the progress indicator issues are all done as talked, GREAT! > > Are they planned to be included in Java 8? > > Cheers, > Diego > > -----Original Message----- > From: Chien Yang [mailto:chien.yang at oracle.com] > Sent: Dienstag, 8. M?rz 2016 20:41 > To: Cirujano Cuesta, Diego; jonathan.giles at oracle.com; openjfx-dev at openjdk.java.net > Subject: Re: ProgressIndicator indeterminate transition bugs > > You may track the progress of this work with this JIRA for now. We are still investigating the scope and impact of this work. We may decide to create a new JIRA and resolve this as a duplicate if we decide to go with a better naming. > > https://bugs.openjdk.java.net/browse/JDK-8090322 > > - Chien > > > On 03/08/16 01:58, Cirujano Cuesta, Diego wrote: >> Great! In that case forget the patch I made, it doesn?t make sense until the treeVisible property is implemented. Is there any jira ticket that I could follow? >> >> Thank you Jonathan. >> >> From: Jonathan Giles [mailto:jonathan.giles at oracle.com] >> Sent: Dienstag, 8. M?rz 2016 10:01 >> To: Cirujano Cuesta, Diego; openjfx-dev at openjdk.java.net >> Subject: RE: ProgressIndicator indeterminate transition bugs >> >> The plan is that a new public API will be developed that matches the expectations, whilst retaining the existing treeVisible semantics in that API. Chien will be looking into this in the coming weeks. At that point we can properly fix these issues. >> >> -- Jonathan >> Sent from a touch device. Please excuse my brevity. >> On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, Diego"> wrote: >> >> Hi all, >> >> As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is buggy. Is it still buggy? If yes, is there intention to fix the treeVisible behavior? In case of fixing this it could be used to fix this issue. If I am not wrong, treeVisible is still used by Node, SwingNode and MediaView. >> >> @Jonathan As you mentioned in JDK-8094829 "having a correctly working treeVisible property would be immensely useful." And I am completely agree and I would like to add that having in the public API would be even better :-). >> >> Thank you, >> Diego >> >> -----Original Message----- >> From: Jonathan Giles [mailto:jonathan.giles at oracle.com] >> Sent: Sonntag, 28. Februar 2016 22:54 >> To: Cirujano Cuesta, Diego; >> openjfx-dev at openjdk.java.net >> Subject: Re: ProgressIndicator indeterminate transition bugs >> >> If you can, are you able to file bug reports for these? >> >> -- Jonathan >> >> On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote: >> >> Hi all, >> >> We found two important bugs in ProgressIndicator that are related with the following tickets: >> >> https://bugs.openjdk.java.net/browse/JDK-8094829 >> https://bugs.openjdk.java.net/browse/JDK-8094078 >> >> Now are quite critical because in a 4K monitor may cause OutOfMemoryException. >> >> Using the following example: >> " >> public class JFXMain extends Application{ >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> HBox root = new HBox(); >> ToggleButton toggleButton = new ToggleButton(); >> ProgressIndicator progressIndicator = new ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS); >> StackPane stackPane = new StackPane(progressIndicator); >> stackPane.visibleProperty().bind(toggleButton.selectedProperty()); >> root.getChildren().addAll(toggleButton, stackPane); >> primaryStage.setScene(new Scene(root)); >> primaryStage.show(); >> } >> } >> " >> >> ** First bug ** >> >> Starting the Progress Indicator with indeterminate progress will >> trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599 >> start the animation even is not shown already: >> indeterminateTransition.playFromStart(); >> >> ** Second bug ** >> >> With the last commits in ProgressIndicator, as commented in JDK-8094829, the listeners do not care about the real visibility of the node(before it was used impl_treeVisibleProperty()). The consequence is that the ProgressIndicator in the example won?t be stopped. >> >> I can imagine that impl_treeVisibleProperty() should not be used and Jonathan G. said: " but I can't reliably fix that without an API such as what I expect the treeVisible API should do." But we did not find such alternative property. >> >> The solution we though is the usage of internal tree visible property like this: >> >> 1. Modify method: >> " >> protected void updateAnimation(boolean isTreeVisible) { " >> 2. Remove current calls to method in >> " >> @Override protected void handleControlPropertyChanged(String p) { >> super.handleControlPropertyChanged(p); >> >> if ("INDETERMINATE".equals(p)) { >> initialize(); >> } else if ("PROGRESS".equals(p)) { >> updateProgress(); >> } >> } >> " >> 3. Add listener at the end of the IndeterminateSpinner contructor the visibility listener: >> " >> private IndeterminateSpinner(boolean spinEnabled, Paint fillOverride) { >> [...] >> impl_treeVisibleProperty().addListener((obs, oldVal, newVal) ->{ >> updateAnimation(newVal); >> }); >> } >> " >> >> What do you think? >> >> Additional note: I would like to add one more thing. I think that could be very good a property ReadOnlyBooleanProperty treeVisibleProperty() available in all Nodes. >> >> Please let me know if we can do something else. >> >> Diego >> >> From David.Hill at Oracle.com Wed Jul 13 20:35:42 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 13 Jul 2016 16:35:42 -0400 Subject: Review: Clean up module relative paths in build.gradle Message-ID: <5786A61E.6050002@Oracle.com> Chien, could you review: https://bugs.openjdk.java.net/browse/JDK-8161227 webrev: http://cr.openjdk.java.net/~ddhill/8161227 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From jonathan.giles at oracle.com Wed Jul 13 21:29:34 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 14 Jul 2016 09:29:34 +1200 Subject: ProgressIndicator indeterminate transition bugs In-Reply-To: <5786739E.2010503@oracle.com> References: <56D36C5A.3080500@oracle.com> <73247A66-A5E4-4D28-9EB2-539CA8FC2CBD@oracle.com> <56DF2AB7.6070903@oracle.com> <5786739E.2010503@oracle.com> Message-ID: <3ace2e74-6c0d-93d1-8810-43372875fd0e@oracle.com> As Chien notes, I don't think there is a strong argument for back porting here. Back porting is extremely restricted now (I don't know the precise amount of restriction, but my instinct says "a lot"). Kevin can confirm once he is back from vacation (next week), but I wouldn't hold out much hope. Just think of this as Yet Another Reason To Upgrade To JDK 9 (or YARTUTJDK9 for easy remembering). -- Jonathan On 14/07/16 5:00 AM, Chien Yang wrote: > Hi Diego, > > As far as I'm aware these fixes aren't candidates for back port to 8. > We will have to evaluate them if you can provide us a good > justification for doing so. > > Thanks, > - Chien > > On 7/13/16, 4:40 AM, Cirujano Cuesta, Diego wrote: >> Hi Chien, Jonathan, >> >> I saw treeNode and the progress indicator issues are all done as >> talked, GREAT! >> >> Are they planned to be included in Java 8? >> >> Cheers, >> Diego >> >> -----Original Message----- >> From: Chien Yang [mailto:chien.yang at oracle.com] >> Sent: Dienstag, 8. M?rz 2016 20:41 >> To: Cirujano Cuesta, Diego; >> jonathan.giles at oracle.com; openjfx-dev at openjdk.java.net >> Subject: Re: ProgressIndicator indeterminate transition bugs >> >> You may track the progress of this work with this JIRA for now. We >> are still investigating the scope and impact of this work. We may >> decide to create a new JIRA and resolve this as a duplicate if we >> decide to go with a better naming. >> >> https://bugs.openjdk.java.net/browse/JDK-8090322 >> >> - Chien >> >> >> On 03/08/16 01:58, Cirujano Cuesta, Diego wrote: >>> Great! In that case forget the patch I made, it doesn?t make sense >>> until the treeVisible property is implemented. Is there any jira >>> ticket that I could follow? >>> >>> Thank you Jonathan. >>> >>> From: Jonathan Giles [mailto:jonathan.giles at oracle.com] >>> Sent: Dienstag, 8. M?rz 2016 10:01 >>> To: Cirujano Cuesta, Diego; openjfx-dev at openjdk.java.net >>> Subject: RE: ProgressIndicator indeterminate transition bugs >>> >>> The plan is that a new public API will be developed that matches the >>> expectations, whilst retaining the existing treeVisible semantics in >>> that API. Chien will be looking into this in the coming weeks. At >>> that point we can properly fix these issues. >>> >>> -- Jonathan >>> Sent from a touch device. Please excuse my brevity. >>> On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, >>> Diego"> >>> wrote: >>> >>> Hi all, >>> >>> As I understood in the comments(JDK-8094829, JDK-8094078), >>> treeVisible is buggy. Is it still buggy? If yes, is there intention >>> to fix the treeVisible behavior? In case of fixing this it could be >>> used to fix this issue. If I am not wrong, treeVisible is still used >>> by Node, SwingNode and MediaView. >>> >>> @Jonathan As you mentioned in JDK-8094829 "having a correctly >>> working treeVisible property would be immensely useful." And I am >>> completely agree and I would like to add that having in the public >>> API would be even better :-). >>> >>> Thank you, >>> Diego >>> >>> -----Original Message----- >>> From: Jonathan Giles [mailto:jonathan.giles at oracle.com] >>> Sent: Sonntag, 28. Februar 2016 22:54 >>> To: Cirujano Cuesta, Diego; >>> openjfx-dev at openjdk.java.net >>> Subject: Re: ProgressIndicator indeterminate transition bugs >>> >>> If you can, are you able to file bug reports for these? >>> >>> -- Jonathan >>> >>> On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote: >>> >>> Hi all, >>> >>> We found two important bugs in ProgressIndicator that are related >>> with the following tickets: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8094829 >>> https://bugs.openjdk.java.net/browse/JDK-8094078 >>> >>> Now are quite critical because in a 4K monitor may cause >>> OutOfMemoryException. >>> >>> Using the following example: >>> " >>> public class JFXMain extends Application{ >>> >>> @Override >>> public void start(Stage primaryStage) throws Exception { >>> HBox root = new HBox(); >>> ToggleButton toggleButton = new ToggleButton(); >>> ProgressIndicator progressIndicator = new >>> ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS); >>> StackPane stackPane = new StackPane(progressIndicator); >>> stackPane.visibleProperty().bind(toggleButton.selectedProperty()); >>> root.getChildren().addAll(toggleButton, stackPane); >>> primaryStage.setScene(new Scene(root)); >>> primaryStage.show(); >>> } >>> } >>> " >>> >>> ** First bug ** >>> >>> Starting the Progress Indicator with indeterminate progress will >>> trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599 >>> start the animation even is not shown already: >>> indeterminateTransition.playFromStart(); >>> >>> ** Second bug ** >>> >>> With the last commits in ProgressIndicator, as commented in >>> JDK-8094829, the listeners do not care about the real visibility of >>> the node(before it was used impl_treeVisibleProperty()). The >>> consequence is that the ProgressIndicator in the example won?t be >>> stopped. >>> >>> I can imagine that impl_treeVisibleProperty() should not be used >>> and Jonathan G. said: " but I can't reliably fix that without an API >>> such as what I expect the treeVisible API should do." But we did not >>> find such alternative property. >>> >>> The solution we though is the usage of internal tree visible >>> property like this: >>> >>> 1. Modify method: >>> " >>> protected void updateAnimation(boolean isTreeVisible) { " >>> 2. Remove current calls to method in >>> " >>> @Override protected void handleControlPropertyChanged(String p) { >>> super.handleControlPropertyChanged(p); >>> >>> if ("INDETERMINATE".equals(p)) { >>> initialize(); >>> } else if ("PROGRESS".equals(p)) { >>> updateProgress(); >>> } >>> } >>> " >>> 3. Add listener at the end of the IndeterminateSpinner contructor >>> the visibility listener: >>> " >>> private IndeterminateSpinner(boolean spinEnabled, Paint >>> fillOverride) { >>> [...] >>> impl_treeVisibleProperty().addListener((obs, oldVal, >>> newVal) ->{ >>> updateAnimation(newVal); >>> }); >>> } >>> " >>> >>> What do you think? >>> >>> Additional note: I would like to add one more thing. I think that >>> could be very good a property ReadOnlyBooleanProperty >>> treeVisibleProperty() available in all Nodes. >>> >>> Please let me know if we can do something else. >>> >>> Diego >>> >>> From guru.hb at oracle.com Thu Jul 14 05:00:44 2016 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 14 Jul 2016 10:30:44 +0530 Subject: [9] Review request 8160837: WebEngine doesn't handle html5 color picker In-Reply-To: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> References: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> Message-ID: <7ac9a346-2b91-fc15-60ad-5a0dd9be66a2@oracle.com> Hi Jonathan, Arun & Alexander Z, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8160837 Webrev : http://cr.openjdk.java.net/~ghb/8160837/webrev.00/ Thanks, Guru From r.lichtenberger at gmail.com Thu Jul 14 05:32:55 2016 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Thu, 14 Jul 2016 07:32:55 +0200 Subject: Running tests fails with Unrecognized option: -Xpatch:javafx.base=/home/rli/PWEs/rt/build/testing/modules/javafx.base Message-ID: <57872407.3000302@gmail.com> According to David Hill, one has to use ea109 as base JDK for OpenJFX development. I was able to setup the repository so that gradle tasks works and was able to build and sdk: [rli at rlimbus rt]$ ls build/sdk/lib/ amd64 javafx-mx.jar javafx-swt.jar javafx.properties jfxrt.jar However, when I try to run some tests (e.g. in the base-module), I just get loads of error messages: [rli at rlimbus base]$ gradle test :buildSrc:generateGrammarSource UP-TO-DATE :buildSrc:compileJava UP-TO-DATE ... Unrecognized option: -Xpatch:javafx.base=/home/rli/PWEs/rt/build/testing/modules/javafx.base Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Unrecognized option: -Xpatch:javafx.base=/home/rli/PWEs/rt/build/testing/modules/javafx.base Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. java.io.IOException: Stream closed at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:443) at java.io.OutputStream.write(OutputStream.java:116) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) Process 'Gradle Test Executor 2' finished with non-zero exit value 1 org.gradle.process.internal.ExecException: Process 'Gradle Test Executor 2' finished with non-zero exit value 1 at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:367) I've tried to use ea126 as base JDK but that fails (of course) with: Error occurred during initialization of VM java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: java.base) So how can I setup a system that will execute tests (in order to be able to contribute tests and patches...)? From peter.brunet at oracle.com Thu Jul 14 16:15:07 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 14 Jul 2016 11:15:07 -0500 Subject: RfR: JDK-8159723 Crash, JavaFX, JAWS - When pressing tab to change focus in HelloComboBox Message-ID: <5dfb37bf-0efb-14bb-1491-85b2ba8dfcf1@oracle.com> Please review the following: Bug: https://bugs.openjdk.java.net/browse/JDK-8159723 Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8159723/webrev.00/ There is a lot of detail in the bug report. TiA, Pete From peter.brunet at oracle.com Thu Jul 14 22:33:16 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 14 Jul 2016 17:33:16 -0500 Subject: RfR: JDK-8159723 Crash, JavaFX, JAWS - When pressing tab to change focus in HelloComboBox In-Reply-To: <5dfb37bf-0efb-14bb-1491-85b2ba8dfcf1@oracle.com> References: <5dfb37bf-0efb-14bb-1491-85b2ba8dfcf1@oracle.com> Message-ID: <6d24cbdc-1807-9de7-355f-2902396b4d69@oracle.com> Two approvals have been received and are listed at the bottom of the bug commentary. On 7/14/16 11:15 AM, Pete Brunet wrote: > Please review the following: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159723 > Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8159723/webrev.00/ > > There is a lot of detail in the bug report. > > TiA, > Pete From andrey.rusakov at oracle.com Fri Jul 15 15:39:17 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Fri, 15 Jul 2016 18:39:17 +0300 Subject: Some open test fixes to review Message-ID: <578903A5.5060801@oracle.com> Hello, guys. Please have a look at my another bunch of test bug fixes: JDK-8161202 , JDK-8157589 and JDK-8161287 . Thanks in advance. From kevin.rushforth at oracle.com Sat Jul 16 13:34:50 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 16 Jul 2016 06:34:50 -0700 Subject: ProgressIndicator indeterminate transition bugs In-Reply-To: <3ace2e74-6c0d-93d1-8810-43372875fd0e@oracle.com> References: <56D36C5A.3080500@oracle.com> <73247A66-A5E4-4D28-9EB2-539CA8FC2CBD@oracle.com> <56DF2AB7.6070903@oracle.com> <5786739E.2010503@oracle.com> <3ace2e74-6c0d-93d1-8810-43372875fd0e@oracle.com> Message-ID: <578A37FA.3080602@oracle.com> Jonathan and Chien are correct. In general, this is not something we would backport since they are not regressions nor trivial fixes. -- Kevin Jonathan Giles wrote: > As Chien notes, I don't think there is a strong argument for back > porting here. Back porting is extremely restricted now (I don't know > the precise amount of restriction, but my instinct says "a lot"). > Kevin can confirm once he is back from vacation (next week), but I > wouldn't hold out much hope. > > Just think of this as Yet Another Reason To Upgrade To JDK 9 (or > YARTUTJDK9 for easy remembering). > > -- Jonathan > > On 14/07/16 5:00 AM, Chien Yang wrote: >> Hi Diego, >> >> As far as I'm aware these fixes aren't candidates for back port to 8. >> We will have to evaluate them if you can provide us a good >> justification for doing so. >> >> Thanks, >> - Chien >> >> On 7/13/16, 4:40 AM, Cirujano Cuesta, Diego wrote: >>> Hi Chien, Jonathan, >>> >>> I saw treeNode and the progress indicator issues are all done as >>> talked, GREAT! >>> >>> Are they planned to be included in Java 8? >>> >>> Cheers, >>> Diego >>> >>> -----Original Message----- >>> From: Chien Yang [mailto:chien.yang at oracle.com] >>> Sent: Dienstag, 8. M?rz 2016 20:41 >>> To: Cirujano Cuesta, Diego; >>> jonathan.giles at oracle.com; openjfx-dev at openjdk.java.net >>> Subject: Re: ProgressIndicator indeterminate transition bugs >>> >>> You may track the progress of this work with this JIRA for now. We >>> are still investigating the scope and impact of this work. We may >>> decide to create a new JIRA and resolve this as a duplicate if we >>> decide to go with a better naming. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8090322 >>> >>> - Chien >>> >>> >>> On 03/08/16 01:58, Cirujano Cuesta, Diego wrote: >>>> Great! In that case forget the patch I made, it doesn?t make sense >>>> until the treeVisible property is implemented. Is there any jira >>>> ticket that I could follow? >>>> >>>> Thank you Jonathan. >>>> >>>> From: Jonathan Giles [mailto:jonathan.giles at oracle.com] >>>> Sent: Dienstag, 8. M?rz 2016 10:01 >>>> To: Cirujano Cuesta, Diego; openjfx-dev at openjdk.java.net >>>> Subject: RE: ProgressIndicator indeterminate transition bugs >>>> >>>> The plan is that a new public API will be developed that matches >>>> the expectations, whilst retaining the existing treeVisible >>>> semantics in that API. Chien will be looking into this in the >>>> coming weeks. At that point we can properly fix these issues. >>>> >>>> -- Jonathan >>>> Sent from a touch device. Please excuse my brevity. >>>> On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, >>>> Diego"> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> As I understood in the comments(JDK-8094829, JDK-8094078), >>>> treeVisible is buggy. Is it still buggy? If yes, is there intention >>>> to fix the treeVisible behavior? In case of fixing this it could be >>>> used to fix this issue. If I am not wrong, treeVisible is still >>>> used by Node, SwingNode and MediaView. >>>> >>>> @Jonathan As you mentioned in JDK-8094829 "having a correctly >>>> working treeVisible property would be immensely useful." And I am >>>> completely agree and I would like to add that having in the public >>>> API would be even better :-). >>>> >>>> Thank you, >>>> Diego >>>> >>>> -----Original Message----- >>>> From: Jonathan Giles [mailto:jonathan.giles at oracle.com] >>>> Sent: Sonntag, 28. Februar 2016 22:54 >>>> To: Cirujano Cuesta, Diego; >>>> openjfx-dev at openjdk.java.net >>>> Subject: Re: ProgressIndicator indeterminate transition bugs >>>> >>>> If you can, are you able to file bug reports for these? >>>> >>>> -- Jonathan >>>> >>>> On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote: >>>> >>>> Hi all, >>>> >>>> We found two important bugs in ProgressIndicator that are >>>> related with the following tickets: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8094829 >>>> https://bugs.openjdk.java.net/browse/JDK-8094078 >>>> >>>> Now are quite critical because in a 4K monitor may cause >>>> OutOfMemoryException. >>>> >>>> Using the following example: >>>> " >>>> public class JFXMain extends Application{ >>>> >>>> @Override >>>> public void start(Stage primaryStage) throws Exception { >>>> HBox root = new HBox(); >>>> ToggleButton toggleButton = new ToggleButton(); >>>> ProgressIndicator progressIndicator = new >>>> ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS); >>>> StackPane stackPane = new StackPane(progressIndicator); >>>> stackPane.visibleProperty().bind(toggleButton.selectedProperty()); >>>> root.getChildren().addAll(toggleButton, stackPane); >>>> primaryStage.setScene(new Scene(root)); >>>> primaryStage.show(); >>>> } >>>> } >>>> " >>>> >>>> ** First bug ** >>>> >>>> Starting the Progress Indicator with indeterminate progress will >>>> trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599 >>>> start the animation even is not shown already: >>>> indeterminateTransition.playFromStart(); >>>> >>>> ** Second bug ** >>>> >>>> With the last commits in ProgressIndicator, as commented in >>>> JDK-8094829, the listeners do not care about the real visibility of >>>> the node(before it was used impl_treeVisibleProperty()). The >>>> consequence is that the ProgressIndicator in the example won?t be >>>> stopped. >>>> >>>> I can imagine that impl_treeVisibleProperty() should not be used >>>> and Jonathan G. said: " but I can't reliably fix that without an >>>> API such as what I expect the treeVisible API should do." But we >>>> did not find such alternative property. >>>> >>>> The solution we though is the usage of internal tree visible >>>> property like this: >>>> >>>> 1. Modify method: >>>> " >>>> protected void updateAnimation(boolean isTreeVisible) { " >>>> 2. Remove current calls to method in >>>> " >>>> @Override protected void handleControlPropertyChanged(String p) { >>>> super.handleControlPropertyChanged(p); >>>> >>>> if ("INDETERMINATE".equals(p)) { >>>> initialize(); >>>> } else if ("PROGRESS".equals(p)) { >>>> updateProgress(); >>>> } >>>> } >>>> " >>>> 3. Add listener at the end of the IndeterminateSpinner >>>> contructor the visibility listener: >>>> " >>>> private IndeterminateSpinner(boolean spinEnabled, Paint >>>> fillOverride) { >>>> [...] >>>> impl_treeVisibleProperty().addListener((obs, >>>> oldVal, newVal) ->{ >>>> updateAnimation(newVal); >>>> }); >>>> } >>>> " >>>> >>>> What do you think? >>>> >>>> Additional note: I would like to add one more thing. I think >>>> that could be very good a property ReadOnlyBooleanProperty >>>> treeVisibleProperty() available in all Nodes. >>>> >>>> Please let me know if we can do something else. >>>> >>>> Diego >>>> >>>> > From kevin.rushforth at oracle.com Sat Jul 16 17:58:55 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 16 Jul 2016 10:58:55 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <576DCA7C.5050701@oracle.com> References: <576DCA7C.5050701@oracle.com> Message-ID: <578A75DF.3040102@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks. -- Kevin From kevin.rushforth at oracle.com Sat Jul 16 18:04:45 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 16 Jul 2016 11:04:45 -0700 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> Message-ID: <578A773D.2020503@oracle.com> I'm back, and given that the review will take some time anyway, I will sponsor this once the review is complete. I see that Guru uploaded the patch for you (thanks, Guru) so I can test it next week. -- Kevin Alexander Nyssen wrote: > It seems I was unsuccessful again. If somebody would be willing to sponsor this contribution while Kevin is away (or at least update the patch provided for JDK-8088147), I could mail the patch privately. > > Regards, > Alexander > > >> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen : >> >> It seems my attachment has again been ?consumed? by the list. Trying again with an archive containing the patch file. >> >> Regards, >> Alexander >> >> >> >>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen : >>> >>> Hi Kevin, all, >>> >>> attached please find a revised patch, where I have added the required export to PlatformImpl and have fixed the build script, so it does no longer break when being executed in jigsaw mode. >>> >>> As swt is no named module yet, I have disabled the JUnit test in jigsaw mode for now. We would probably have to set up swt as a named module to enable this, and would further have to make swt-debug.jar available as an automated module on its module path. But this is a different problem. >>> >>> Regards, >>> Alexander >>> >>> >>> >>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen : >>>> >>>> Hi Kevin, >>>> >>>> >>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth : >>>>> >>>>> Hi Alexander, >>>>> >>>>> I attached the patch to the bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>> >>>>> If I build it and run the manual test in "legacy" mode, meaning run everything with 9+109 and the legacy jfxrt.jar file, then it runs and the cursor now changes. So this looks like a good starting point for a fix. >>>>> >>>> Fine. >>>> >>>> >>>>> I tried building and running this in Jigsaw mode (building with jdk-9+109, but running the tests with a more recent JDK that includes modularization support), and noticed two problems right away that must be addressed: >>>>> >>>>> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the build fails right away with an exception from gradle: >>>>> >>>>> >>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>>>> >>>>> Wiring up SWT-based tests to our unit test harness will take a bit more work than what you have provided (not even counting the Mac issue, which could be handled by excluding the test on Mac). In the short term, relying on manual tests for this fix might be best. >>>>> >>>>> >>>> I did not execute the tests in jigsaw mode yet, because other tests failed in this mode, too (as indicated in an earlier discussion). I will try to set things up in a virtual machine with Windows and/or Linux so I can work on the Gradle tests without having to deal with the Mac issue. The test harness will IMHO also be required for other contributions, and it would of course be fine if the automated test, I included in this patch, could be executed as well. >>>> >>>> >>>>> 2. You have introduced a dependency on a new internal package, com.sun.javafx.tk. If this is required in order to implement the fix, then you will need to add this package to the list of packages exports to javafx.swt in PlatformImpl; otherwise the following exception is thrown at runtime: >>>>> >>>>> Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.tk to module javafx.swt >>>>> >>>> This dependency is required unless there is public API to convert a platform image (which is provided by the image cursor frame) to an image. To me, >>>> Image image = Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>>> seemed to be the way to go. I will thus add the respective export in a revised patch. >>>> >>>> >>>>> I won't have time to sponsor this change until the second half of July, but if others have time, the review can proceed and I'll pick it back up then if it is in good enough shape to run. >>>>> >>>> Especially setting up the SWT test harness will be kind of a blocker for succeeding contributions, so it would be nice if somebody could step in. >>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Kevin Rushforth wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> It looks like your patch was stripped out by the mailing list server. >>>>>> >>>>>> Can you please send me the patch offline, as a zip file (so line endings are preserved across different systems), and I will unzip it and attach it to the bug report. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Alexander Nyssen wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have worked on a first contribution related to JDK-8088147. Attached please find a patch (created in extended Git format) that comprises the related changes. I have augmented the implementation of javafx.embed.swt.SWTCursors to handle the image cursor case. I further adjusted javafx.scene.Scene to update the cursor frame (in addition to the cursor) within synchronizeSceneProperties, so the cursor is not cleared in the first pulse succeeding the cursor property change. >>>>>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, as well as a manual test (SWTImageCursorTest) to the systemTests module, with which the proper behavior can be verified. As no tests for SWT existed so far, I updated the build.gradle and gradle.properties files to support an SWT_TEST option, which allows to handle them similar to Swing tests. I also added the respective SWT dependency to the systemTests module. Please note that the JUnit test can currently not be executed using Gradle on the Mac (where the manual test currently is the single option; the automated tests are disabled), because there SWT-based tests require the -XstartOnFirstThread option that is currently not supported by the Gradle test runner (see https://issues.gradle.org/browse/GRADLE-3290 for details). We would have to use an ant task as a workaround. >>>>>>> >>>>>>> Regards, >>>>>>> Alexander >>>>>>> >>>>>>> >>>>>>> >>>>>>> > > From chien.yang at oracle.com Sat Jul 16 20:18:12 2016 From: chien.yang at oracle.com (Chien Yang) Date: Sat, 16 Jul 2016 13:18:12 -0700 Subject: [9] Code Review Request For 8148721: Memory leak caused by scroll gesture Message-ID: <578A9684.6070601@oracle.com> Hi Jonathan, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8148721 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8148721/webrev.00/ Thanks, - Chien From guru.hb at oracle.com Mon Jul 18 16:38:28 2016 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 18 Jul 2016 22:08:28 +0530 Subject: [9] Review request 8160837: WebEngine doesn't handle html5 color picker In-Reply-To: <7ac9a346-2b91-fc15-60ad-5a0dd9be66a2@oracle.com> References: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> <7ac9a346-2b91-fc15-60ad-5a0dd9be66a2@oracle.com> Message-ID: <5b0bb5ee-70c7-3e6d-35ef-1d57b6393c51@oracle.com> Hi Kevin, Arun & Alexander Z, Please review the updated webrev : http://cr.openjdk.java.net/~ghb/8160837/webrev.02/ Solution updated in JBS. Thanks, Guru On 14/7/16 10:30 AM, Guru Hb wrote: > Hi Jonathan, Arun & Alexander Z, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8160837 > Webrev : http://cr.openjdk.java.net/~ghb/8160837/webrev.00/ > > Thanks, > Guru From andrey.rusakov at oracle.com Mon Jul 18 16:40:38 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Mon, 18 Jul 2016 19:40:38 +0300 Subject: Review request: JDK-8151500 Message-ID: <578D0686.3050904@oracle.com> Hello, guys. Now I have really important improvement for our test workspace, so please have a look at it. Fix is applicable for both 8/tests and 9/tests without change. Jira: https://bugs.openjdk.java.net/browse/JDK-8151500 Webrev: http://cr.openjdk.java.net/~arusakov/8151500/webrev.00/ Thanks in advance. From David.Hill at Oracle.com Tue Jul 19 13:37:42 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 19 Jul 2016 09:37:42 -0400 Subject: CFV: New OpenJFX Committer: Ankit Srivastava Message-ID: <578E2D26.1010806@Oracle.com> I hereby nominate Ankit Srivastava to OpenJFX Committer. Ankit Srivastava is part of the JavaFX team focusing on Web. A list of Ankit's commits and reviews is available by the following links http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava Votes are due by August 3th, 2016. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave From guru.hb at oracle.com Tue Jul 19 13:47:08 2016 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 19 Jul 2016 19:17:08 +0530 Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E2D26.1010806@Oracle.com> References: <578E2D26.1010806@Oracle.com> Message-ID: <9acd340c-81cb-3e8c-ffda-f5011b1dc285@oracle.com> Vote: YES On 19/7/16 7:07 PM, David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From kevin.rushforth at oracle.com Tue Jul 19 14:14:45 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Jul 2016 07:14:45 -0700 Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E2D26.1010806@Oracle.com> References: <578E2D26.1010806@Oracle.com> Message-ID: <578E35D5.4070008@oracle.com> Vote: YES David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From murali.billa at oracle.com Tue Jul 19 14:24:19 2016 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 19 Jul 2016 07:24:19 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E35D5.4070008@oracle.com> References: <578E2D26.1010806@Oracle.com> <578E35D5.4070008@oracle.com> Message-ID: <8f4c509a-0823-45b7-b196-689e12c2b77a@default> Vote: YES David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following > links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastav > a at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From murali.billa at oracle.com Tue Jul 19 19:28:34 2016 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 19 Jul 2016 12:28:34 -0700 (PDT) Subject: [9] Review request for 8161699: [Win] Fix Compilation warnings In-Reply-To: <44bc17ad-9081-4630-9576-9c6244f372f5@default> References: <80129ade-ef03-2eca-74ee-1f8387166622@oracle.com> <44bc17ad-9081-4630-9576-9c6244f372f5@default> Message-ID: Hi Kevin, Arun, Ankit Please review below fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8161699 Webrev: ?http://cr.openjdk.java.net/~mbilla/8161699/webrev.00/ ? Thanks, Murali From jonathan.giles at oracle.com Tue Jul 19 21:12:49 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 20 Jul 2016 09:12:49 +1200 Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E2D26.1010806@Oracle.com> References: <578E2D26.1010806@Oracle.com> Message-ID: <5e0076e6-170a-8c63-1987-aba6f7e75fc8@oracle.com> vote: YES -- Jonathan On 20/07/16 1:37 AM, David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From vadim.pakhnushev at oracle.com Tue Jul 19 21:21:27 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 20 Jul 2016 00:21:27 +0300 Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E2D26.1010806@Oracle.com> References: <578E2D26.1010806@Oracle.com> Message-ID: Vote: yes On 19.07.2016 16:37, David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From murali.billa at oracle.com Tue Jul 19 21:28:25 2016 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 19 Jul 2016 14:28:25 -0700 (PDT) Subject: [9] Review request for 8161724: [Win] Exceptions while browsing In-Reply-To: References: <80129ade-ef03-2eca-74ee-1f8387166622@oracle.com> <44bc17ad-9081-4630-9576-9c6244f372f5@default> Message-ID: Hi Kevin, Arun, Ankit Please review below fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8161724 Webrev: ?http://cr.openjdk.java.net/~mbilla/8161724/webrev.00/ ? Thanks, Murali From kevin.rushforth at oracle.com Tue Jul 19 22:22:45 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Jul 2016 15:22:45 -0700 Subject: Changes for July 2016 CPU release (8u101/8u102) synced into FX 8u-dev and 9-dev Message-ID: <578EA835.2040007@oracle.com> I have synced the OpenJFX changes from the just-released July 2016 CPU release (8u91/8u92) into 8u and into 9. Here is a webrev of the FX 8u102 changes for those who are interested in the changes, but don't want to wade through the separate changesets I just pushed (most of which are tag or merge changesets). http://cr.openjdk.java.net/~kcr/8u102-8u-sync/webrev/ The webrev for 9 is identical except for the .hgtags (which are unmodified in 9), but here it is if anyone is interested: http://cr.openjdk.java.net/~kcr/9-cpu-1603-sync/webrev/ -- Kevin From kevin.rushforth at oracle.com Tue Jul 19 22:22:54 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Jul 2016 15:22:54 -0700 Subject: Problem building WebView with latest 8u-dev and 9-dev Message-ID: <578EA83E.1060007@oracle.com> With the recently-integrated changes from 8u102, the WebKit build requires a new version of the webview-deps bundle. This new bundle has not yet been uploaded to maven central. Until we are able to do this, you will not be able to build WebKit without applying a workaround. I have filed a tracking bug in JBS for this: https://bugs.openjdk.java.net/browse/JDK-8161766 The workaround is to locally revert the change to the version number of webview-deps in build.gradle. diff --git a/build.gradle b/build.gradle --- a/build.gradle +++ b/build.gradle @@ -2717,7 +2717,7 @@ IS_64 ? "${t.name}-amd64" : "${t.name}-i586" dependencies { webkit group: "com.sun.webkit", name: "webview-deps", - version: "1.3.1", classifier: "$classifier", ext: "zip" + version: "1.3", classifier: "$classifier", ext: "zip" } def webkitOutputDir = cygpath("$buildDir/${t.name}") -- Kevin From arunprasad.rajkumar at oracle.com Wed Jul 20 05:07:54 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 20 Jul 2016 10:37:54 +0530 Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E2D26.1010806@Oracle.com> References: <578E2D26.1010806@Oracle.com> Message-ID: <4cc5479b-a181-c50e-a778-b96ffe4efbc8@oracle.com> Vote: YES On 7/19/2016 7:07 PM, David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From alexander.zvegintsev at oracle.com Wed Jul 20 14:04:35 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 20 Jul 2016 17:04:35 +0300 Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E2D26.1010806@Oracle.com> References: <578E2D26.1010806@Oracle.com> Message-ID: Vote: yes On 7/19/16 4:37 PM, David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave -- Thanks, Alexander. From itaisha at gmail.com Sun Jul 17 08:38:29 2016 From: itaisha at gmail.com (Itai) Date: Sun, 17 Jul 2016 11:38:29 +0300 Subject: Memory leaks on Linux with hardware renderer Message-ID: I'm experiencing multiple memory leaks with JavaFX on Linux, to the point where I'm not sure which bug to report, as it seems like a systematic issue. The memory leak seems to be completely absent when using the software renderer (-Dprism.order=sw), and does not seem to happen on Windows (presumably not on Mac either, although I have no Mac to test it). Test cases include: 1. Use ProgressIndicator with progress set to Indeterminate - with default (HW) renderer memory consumption quickly rises, climbing to 8GB and more if not killed. With software renderer memory usage is reasonable. 2. Using Scene Builder - after a few minutes with Scene Builder it quickly gobbles up all system memory - again, problem seems to go away if using software renderer. This test is less repeatable, as some actions seem more detrimental than others. 3. Using Transitions on nodes (See attached code "Demo.java". I have filed a bug report about this issue, JI-9041860). Running with default renderer the simple program reaches 3GB within 30 seconds, and memory continues to climb. On software renderer memory consumption remains <100MB for a minute and more. As I said, I am no longer sure it is prudent to report specific bugs, as this seems to be some low-level problem. I just want to know if this is a known issue and if there is any way to get around it (besides using the software pipe, which obviously has it's own disadvantages). For reference, I'm using Debian (testing, updated today), kernel version 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms driver), OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical on Oracle version). If there is any other information needed please let me know. If this is a known issue I apologize, but I have tried searching and didn't find any reports of such behavior. Thank you. From felix.bembrick at gmail.com Wed Jul 20 02:14:37 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 20 Jul 2016 12:14:37 +1000 Subject: Scene graph performance Message-ID: Having written and tested FXMark on various platforms and devices, one thing has really struck me as quite "odd". I started work on FXMark as a kind of side project a while ago and, at the time, my machine was powerful but not "super powerful". So when I purchased a new machine with just about the highest specs available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X GPUs in SLI mode, I was naturally expecting to see significant performance improvements when I ran FXMark on this machine. But to my surprise, and disappointment, the scene graph animations ran almost NO faster whatsoever! So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a rudimentary (single) GPU and, guess what - almost the same level of performance (i.e. FPS and smoothness etc.) was achieved on this considerably less powerful machine (in terms of both CPU and GPU). So, it seems there is some kind of "performance wall" that limits the rendering speed of the scene graph (and this is with full speed animations enabled). What is the nature of this "wall"? Is it simply that the rendering pipeline is not making efficient use of the GPU? Is too much being done on the CPU? Whatever the cause, I really think it needs to be addressed. If I can't get better performance out of a machine that scores in the top 0.01% of all machine in the world in the 3DMark Index than an entry level PC, isn't this a MAJOR issue for JavaFX? Blessings, Felix From kevin.rushforth at oracle.com Wed Jul 20 23:16:30 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Jul 2016 16:16:30 -0700 Subject: Fwd: Update Notification: Bug Report - JDK-8161282 In-Reply-To: <9B905A25-5FB5-482B-98D6-B3F8015B40FA@nyssen.org> References: <15624918.0.1468411285645.JavaMail.ndcosta@sc11152510.us.oracle.com> <9B905A25-5FB5-482B-98D6-B3F8015B40FA@nyssen.org> Message-ID: <5790064E.1000104@oracle.com> OK, I reopened https://bugs.openjdk.java.net/browse/JDK-8161282 -- Kevin Alexander Ny?en wrote: >> Hi all, >> >> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8161282 has been resolved as a duplicate of http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8143596, but IMHO this is not the case, as JDK-8143596 is related to touch gesture events, whereas JDK-81611282 refers to mouse scroll events. I would propose to either update JDK-8143596 or not resolve JDK-8161282 as a duplicate. >> >> Regards, >> Alexander >> > > > >> Von: Bug-Report-Daemon_WW at ORACLE.COM >> Datum: 13. Juli 2016 um 14:01:25 MESZ >> An: nyssen at itemis.de >> Betreff: Update Notification: Bug Report - JDK-8161282 >> >> [This is an automated response. Please do not reply.] >> >> Dear Java Developer, >> >> We have finished evaluating your report and have assigned it a Bug ID: JDK-8161282. The issue is visible on bugs.java.com at the following url http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8161282 . >> >> We work to resolve the issues that are submitted to us according to their impact to the community as a whole, and make no promises as to the time or release in which a bug might be fixed. If this issue has a significant impact on your project you may want to consider using one of the technical support offerings available at Oracle Support. >> >> Regards, >> Java Developer Support >> From kevin.rushforth at oracle.com Wed Jul 20 23:27:13 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Jul 2016 16:27:13 -0700 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: References: Message-ID: <579008D1.1030407@oracle.com> JI-9041860 has now been transferred to the JDK project as: https://bugs.openjdk.java.net/browse/JDK-8161911 Our support engineer was not able to reproduce the problem, so closed it as such. Based on the additional information you provided, I have reopened the bug and will ask someone on our team with a physical Linux setup to try to reproduce it. To answer your question, we are not aware of any such leaks. -- Kevin Itai wrote: > I'm experiencing multiple memory leaks with JavaFX on Linux, to the point > where I'm not sure which bug to report, as it seems like a systematic > issue. > > The memory leak seems to be completely absent when using the software > renderer (-Dprism.order=sw), and does not seem to happen on Windows > (presumably not on Mac either, although I have no Mac to test it). > > Test cases include: > > 1. Use ProgressIndicator with progress set to Indeterminate - with default > (HW) renderer memory consumption quickly rises, climbing to 8GB and more if > not killed. With software renderer memory usage is reasonable. > 2. Using Scene Builder - after a few minutes with Scene Builder it quickly > gobbles up all system memory - again, problem seems to go away if using > software renderer. This test is less repeatable, as some actions seem more > detrimental than others. > 3. Using Transitions on nodes (See attached code "Demo.java". I have filed > a bug report about this issue, JI-9041860). Running with default renderer > the simple program reaches 3GB within 30 seconds, and memory continues to > climb. On software renderer memory consumption remains <100MB for a minute > and more. > > As I said, I am no longer sure it is prudent to report specific bugs, as > this seems to be some low-level problem. I just want to know if this is a > known issue and if there is any way to get around it (besides using the > software pipe, which obviously has it's own disadvantages). > > > For reference, I'm using Debian (testing, updated today), kernel version > 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms driver), > OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical on Oracle > version). > > If there is any other information needed please let me know. If this is a > known issue I apologize, but I have tried searching and didn't find any > reports of such behavior. > > Thank you. > From kevin.rushforth at oracle.com Wed Jul 20 23:38:49 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Jul 2016 16:38:49 -0700 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: References: <579008D1.1030407@oracle.com> Message-ID: <57900B89.2070401@oracle.com> I'll add a comment to that effect (although our incident triage team is good about spotting such duplicates). -- Kevin Itai wrote: > Thank you. Having gotten no reply, and seeing the bug report was > closed and with not means of commenting in the bug report system, I > have since (about an hour ago) filed a more detailed report > (JI-9042009). I believe they could be safely merged, but the second > one does contain some more info. > > On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth > > wrote: > > JI-9041860 has now been transferred to the JDK project as: > > https://bugs.openjdk.java.net/browse/JDK-8161911 > > Our support engineer was not able to reproduce the problem, so > closed it as such. Based on the additional information you > provided, I have reopened the bug and will ask someone on our team > with a physical Linux setup to try to reproduce it. > > To answer your question, we are not aware of any such leaks. > > -- Kevin > > > > Itai wrote: > > I'm experiencing multiple memory leaks with JavaFX on Linux, > to the point > where I'm not sure which bug to report, as it seems like a > systematic > issue. > > The memory leak seems to be completely absent when using the > software > renderer (-Dprism.order=sw), and does not seem to happen on > Windows > (presumably not on Mac either, although I have no Mac to test it). > > Test cases include: > > 1. Use ProgressIndicator with progress set to Indeterminate - > with default > (HW) renderer memory consumption quickly rises, climbing to > 8GB and more if > not killed. With software renderer memory usage is reasonable. > 2. Using Scene Builder - after a few minutes with Scene > Builder it quickly > gobbles up all system memory - again, problem seems to go away > if using > software renderer. This test is less repeatable, as some > actions seem more > detrimental than others. > 3. Using Transitions on nodes (See attached code "Demo.java". > I have filed > a bug report about this issue, JI-9041860). Running with > default renderer > the simple program reaches 3GB within 30 seconds, and memory > continues to > climb. On software renderer memory consumption remains <100MB > for a minute > and more. > > As I said, I am no longer sure it is prudent to report > specific bugs, as > this seems to be some low-level problem. I just want to know > if this is a > known issue and if there is any way to get around it (besides > using the > software pipe, which obviously has it's own disadvantages). > > > For reference, I'm using Debian (testing, updated today), > kernel version > 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms > driver), > OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical > on Oracle > version). > > If there is any other information needed please let me know. > If this is a > known issue I apologize, but I have tried searching and didn't > find any > reports of such behavior. > > Thank you. > > > From itaisha at gmail.com Wed Jul 20 23:34:59 2016 From: itaisha at gmail.com (Itai) Date: Thu, 21 Jul 2016 02:34:59 +0300 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: <579008D1.1030407@oracle.com> References: <579008D1.1030407@oracle.com> Message-ID: Thank you. Having gotten no reply, and seeing the bug report was closed and with not means of commenting in the bug report system, I have since (about an hour ago) filed a more detailed report (JI-9042009). I believe they could be safely merged, but the second one does contain some more info. On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth wrote: > JI-9041860 has now been transferred to the JDK project as: > > https://bugs.openjdk.java.net/browse/JDK-8161911 > > Our support engineer was not able to reproduce the problem, so closed it > as such. Based on the additional information you provided, I have reopened > the bug and will ask someone on our team with a physical Linux setup to try > to reproduce it. > > To answer your question, we are not aware of any such leaks. > > -- Kevin > > > > Itai wrote: > >> I'm experiencing multiple memory leaks with JavaFX on Linux, to the point >> where I'm not sure which bug to report, as it seems like a systematic >> issue. >> >> The memory leak seems to be completely absent when using the software >> renderer (-Dprism.order=sw), and does not seem to happen on Windows >> (presumably not on Mac either, although I have no Mac to test it). >> >> Test cases include: >> >> 1. Use ProgressIndicator with progress set to Indeterminate - with default >> (HW) renderer memory consumption quickly rises, climbing to 8GB and more >> if >> not killed. With software renderer memory usage is reasonable. >> 2. Using Scene Builder - after a few minutes with Scene Builder it quickly >> gobbles up all system memory - again, problem seems to go away if using >> software renderer. This test is less repeatable, as some actions seem more >> detrimental than others. >> 3. Using Transitions on nodes (See attached code "Demo.java". I have filed >> a bug report about this issue, JI-9041860). Running with default renderer >> the simple program reaches 3GB within 30 seconds, and memory continues to >> climb. On software renderer memory consumption remains <100MB for a minute >> and more. >> >> As I said, I am no longer sure it is prudent to report specific bugs, as >> this seems to be some low-level problem. I just want to know if this is a >> known issue and if there is any way to get around it (besides using the >> software pipe, which obviously has it's own disadvantages). >> >> >> For reference, I'm using Debian (testing, updated today), kernel version >> 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms driver), >> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical on Oracle >> version). >> >> If there is any other information needed please let me know. If this is a >> known issue I apologize, but I have tried searching and didn't find any >> reports of such behavior. >> >> Thank you. >> >> > From rahman.usta.88 at gmail.com Thu Jul 21 06:57:52 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 21 Jul 2016 09:57:52 +0300 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: <57900B89.2070401@oracle.com> References: <579008D1.1030407@oracle.com> <57900B89.2070401@oracle.com> Message-ID: Hello Kevin; One of our user reported "Must be a memory leak somewhere" in AsciidocFX project. It seems a similar issue. You can see the issue here https://github.com/asciidocfx/AsciidocFX/issues/227 Thanks. 2016-07-21 2:38 GMT+03:00 Kevin Rushforth : > I'll add a comment to that effect (although our incident triage team is > good about spotting such duplicates). > > -- Kevin > > > Itai wrote: > >> Thank you. Having gotten no reply, and seeing the bug report was closed >> and with not means of commenting in the bug report system, I have since >> (about an hour ago) filed a more detailed report (JI-9042009). I believe >> they could be safely merged, but the second one does contain some more >> info. >> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com > wrote: >> >> JI-9041860 has now been transferred to the JDK project as: >> >> https://bugs.openjdk.java.net/browse/JDK-8161911 >> >> Our support engineer was not able to reproduce the problem, so >> closed it as such. Based on the additional information you >> provided, I have reopened the bug and will ask someone on our team >> with a physical Linux setup to try to reproduce it. >> >> To answer your question, we are not aware of any such leaks. >> >> -- Kevin >> >> >> >> Itai wrote: >> >> I'm experiencing multiple memory leaks with JavaFX on Linux, >> to the point >> where I'm not sure which bug to report, as it seems like a >> systematic >> issue. >> >> The memory leak seems to be completely absent when using the >> software >> renderer (-Dprism.order=sw), and does not seem to happen on >> Windows >> (presumably not on Mac either, although I have no Mac to test it). >> >> Test cases include: >> >> 1. Use ProgressIndicator with progress set to Indeterminate - >> with default >> (HW) renderer memory consumption quickly rises, climbing to >> 8GB and more if >> not killed. With software renderer memory usage is reasonable. >> 2. Using Scene Builder - after a few minutes with Scene >> Builder it quickly >> gobbles up all system memory - again, problem seems to go away >> if using >> software renderer. This test is less repeatable, as some >> actions seem more >> detrimental than others. >> 3. Using Transitions on nodes (See attached code "Demo.java". >> I have filed >> a bug report about this issue, JI-9041860). Running with >> default renderer >> the simple program reaches 3GB within 30 seconds, and memory >> continues to >> climb. On software renderer memory consumption remains <100MB >> for a minute >> and more. >> >> As I said, I am no longer sure it is prudent to report >> specific bugs, as >> this seems to be some low-level problem. I just want to know >> if this is a >> known issue and if there is any way to get around it (besides >> using the >> software pipe, which obviously has it's own disadvantages). >> >> >> For reference, I'm using Debian (testing, updated today), >> kernel version >> 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms >> driver), >> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical >> on Oracle >> version). >> >> If there is any other information needed please let me know. >> If this is a >> known issue I apologize, but I have tried searching and didn't >> find any >> reports of such behavior. >> >> Thank you. >> >> >> -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From mp at jugs.org Thu Jul 21 10:07:20 2016 From: mp at jugs.org (Dr. Michael Paus) Date: Thu, 21 Jul 2016 12:07:20 +0200 Subject: Scene graph performance In-Reply-To: References: Message-ID: Hi Felix, I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. The maximum performance is reached when one CPU/Core is at 100%. The performance of your graphics hardware seems to be almost irrelevant. I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) Michael Am 20.07.16 um 04:14 schrieb Felix Bembrick: > Having written and tested FXMark on various platforms and devices, one > thing has really struck me as quite "odd". > > I started work on FXMark as a kind of side project a while ago and, at the > time, my machine was powerful but not "super powerful". > > So when I purchased a new machine with just about the highest specs > available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X > GPUs in SLI mode, I was naturally expecting to see significant performance > improvements when I ran FXMark on this machine. > > But to my surprise, and disappointment, the scene graph animations ran > almost NO faster whatsoever! > > So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a > rudimentary (single) GPU and, guess what - almost the same level of > performance (i.e. FPS and smoothness etc.) was achieved on this > considerably less powerful machine (in terms of both CPU and GPU). > > So, it seems there is some kind of "performance wall" that limits the > rendering speed of the scene graph (and this is with full speed animations > enabled). > > What is the nature of this "wall"? Is it simply that the rendering pipeline > is not making efficient use of the GPU? Is too much being done on the CPU? > > Whatever the cause, I really think it needs to be addressed. > > If I can't get better performance out of a machine that scores in the top > 0.01% of all machine in the world in the 3DMark Index than an entry level > PC, isn't this a MAJOR issue for JavaFX? > > Blessings, > > Felix From felix.bembrick at gmail.com Thu Jul 21 10:39:41 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 21 Jul 2016 20:39:41 +1000 Subject: Scene graph performance In-Reply-To: References: Message-ID: <0988E56E-F186-44D0-B823-2AB542222663@gmail.com> Hi Michael, Thanks for your response. This is what I suspected: what is ostensibly a hardware accelerated toolkit seems to barely utilise the GPU for scene graph animations. But, even with that, my machine has dual high performance 16-core Xeons while my wife's machine has a single 2-core i5 and STILL the performance is barely indistinguishable! I would love to discuss this with you off-list as I see this as the biggest impediment to expanding the use cases for JavaFX. The Canvas node seems to perform quite well but, other than that, we basically have a toolkit suitable for forms with the occasional transition thrown in. I think I can fix these issues and I will continue to further investigate the cause. It's somewhat ridiculous that on my same machine I can write pure OpenGL code (not Direct3D) and animate 5000 Quake 3D characters and achieve at least 1000 FPS. I don't think we can blame Java the language as Java is not running on the GPU. It appears though that not much else is either! (It seems the Quantum Renderer thread is working really, really hard. The GPU should be doing most of the heavy lifting). Felix > On 21 Jul 2016, at 20:07, Dr. Michael Paus wrote: > > Hi Felix, > I have written various tests like the ones you use in FXMark and I have > obtained similar results. I have even tried to substitute 2D shapes by > using 3D MeshViews in the hope that this would give better performance > but the results were not that good. Of course all this depends on the > specific test case but in general I see that a JavaFX application which > makes heavy use of graphics animations is completely CPU-bounded. > The maximum performance is reached when one CPU/Core is at 100%. > The performance of your graphics hardware seems to be almost irrelevant. > I could for example run four instances of the same test with almost the > same performance at the same time. In this case all 4 cores of my machine > were at 100%. This proves that the graphics hardware is not the limiting > factor. My machine is a MacBook Pro with Retina graphics and a dedicated > NVidia graphics card which is already a couple of years old and certainly > not playing in the same league as your high-power card. > I myself have not yet found a way to really speed up the graphics performance > and I am a little bit frustrated because of that. But it is not only the general > graphic performance which is a problem. There are also a lot of other pitfalls > into which you can stumble and which can bring your animations to a halt > or even crash your system. Zooming for example is one of these issues. > > I would like to have some exchange on these issues and how to best address > them but my impression so far is that there are only very view people interested > in that. (I hope someone can prove me wrong on this :-) > > Michael > >> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >> Having written and tested FXMark on various platforms and devices, one >> thing has really struck me as quite "odd". >> >> I started work on FXMark as a kind of side project a while ago and, at the >> time, my machine was powerful but not "super powerful". >> >> So when I purchased a new machine with just about the highest specs >> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X >> GPUs in SLI mode, I was naturally expecting to see significant performance >> improvements when I ran FXMark on this machine. >> >> But to my surprise, and disappointment, the scene graph animations ran >> almost NO faster whatsoever! >> >> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a >> rudimentary (single) GPU and, guess what - almost the same level of >> performance (i.e. FPS and smoothness etc.) was achieved on this >> considerably less powerful machine (in terms of both CPU and GPU). >> >> So, it seems there is some kind of "performance wall" that limits the >> rendering speed of the scene graph (and this is with full speed animations >> enabled). >> >> What is the nature of this "wall"? Is it simply that the rendering pipeline >> is not making efficient use of the GPU? Is too much being done on the CPU? >> >> Whatever the cause, I really think it needs to be addressed. >> >> If I can't get better performance out of a machine that scores in the top >> 0.01% of all machine in the world in the 3DMark Index than an entry level >> PC, isn't this a MAJOR issue for JavaFX? >> >> Blessings, >> >> Felix > > From felix.bembrick at gmail.com Thu Jul 21 11:04:39 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 21 Jul 2016 21:04:39 +1000 Subject: Scene graph performance In-Reply-To: References: Message-ID: <59F25166-2E34-4F6E-9FAD-130EEFD05E3C@gmail.com> I would add that neither JOGL nor LWJGL have these issues. Yes, I know they are somewhat different "animals", but the point is, clearly *Java* is NOT the cause. > On 21 Jul 2016, at 20:07, Dr. Michael Paus wrote: > > Hi Felix, > I have written various tests like the ones you use in FXMark and I have > obtained similar results. I have even tried to substitute 2D shapes by > using 3D MeshViews in the hope that this would give better performance > but the results were not that good. Of course all this depends on the > specific test case but in general I see that a JavaFX application which > makes heavy use of graphics animations is completely CPU-bounded. > The maximum performance is reached when one CPU/Core is at 100%. > The performance of your graphics hardware seems to be almost irrelevant. > I could for example run four instances of the same test with almost the > same performance at the same time. In this case all 4 cores of my machine > were at 100%. This proves that the graphics hardware is not the limiting > factor. My machine is a MacBook Pro with Retina graphics and a dedicated > NVidia graphics card which is already a couple of years old and certainly > not playing in the same league as your high-power card. > I myself have not yet found a way to really speed up the graphics performance > and I am a little bit frustrated because of that. But it is not only the general > graphic performance which is a problem. There are also a lot of other pitfalls > into which you can stumble and which can bring your animations to a halt > or even crash your system. Zooming for example is one of these issues. > > I would like to have some exchange on these issues and how to best address > them but my impression so far is that there are only very view people interested > in that. (I hope someone can prove me wrong on this :-) > > Michael > >> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >> Having written and tested FXMark on various platforms and devices, one >> thing has really struck me as quite "odd". >> >> I started work on FXMark as a kind of side project a while ago and, at the >> time, my machine was powerful but not "super powerful". >> >> So when I purchased a new machine with just about the highest specs >> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X >> GPUs in SLI mode, I was naturally expecting to see significant performance >> improvements when I ran FXMark on this machine. >> >> But to my surprise, and disappointment, the scene graph animations ran >> almost NO faster whatsoever! >> >> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a >> rudimentary (single) GPU and, guess what - almost the same level of >> performance (i.e. FPS and smoothness etc.) was achieved on this >> considerably less powerful machine (in terms of both CPU and GPU). >> >> So, it seems there is some kind of "performance wall" that limits the >> rendering speed of the scene graph (and this is with full speed animations >> enabled). >> >> What is the nature of this "wall"? Is it simply that the rendering pipeline >> is not making efficient use of the GPU? Is too much being done on the CPU? >> >> Whatever the cause, I really think it needs to be addressed. >> >> If I can't get better performance out of a machine that scores in the top >> 0.01% of all machine in the world in the 3DMark Index than an entry level >> PC, isn't this a MAJOR issue for JavaFX? >> >> Blessings, >> >> Felix > > From kevin.rushforth at oracle.com Thu Jul 21 15:12:56 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Jul 2016 08:12:56 -0700 Subject: Memory leaks on Linux with hardware renderer In-Reply-To: References: <579008D1.1030407@oracle.com> <57900B89.2070401@oracle.com> Message-ID: <5790E678.8020905@oracle.com> Thanks. I added this to the bug report for https://bugs.openjdk.java.net/browse/JDK-8161911 -- Kevin Rahman USTA wrote: > Hello Kevin; > > One of our user reported "Must be a memory leak somewhere" in > AsciidocFX project. It seems a similar issue. > > You can see the issue > here https://github.com/asciidocfx/AsciidocFX/issues/227 > > Thanks. > > 2016-07-21 2:38 GMT+03:00 Kevin Rushforth >: > > I'll add a comment to that effect (although our incident triage > team is good about spotting such duplicates). > > -- Kevin > > > Itai wrote: > > Thank you. Having gotten no reply, and seeing the bug report > was closed and with not means of commenting in the bug report > system, I have since (about an hour ago) filed a more detailed > report (JI-9042009). I believe they could be safely merged, > but the second one does contain some more info. > On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth > > >> wrote: > > JI-9041860 has now been transferred to the JDK project as: > > https://bugs.openjdk.java.net/browse/JDK-8161911 > > Our support engineer was not able to reproduce the problem, so > closed it as such. Based on the additional information you > provided, I have reopened the bug and will ask someone on > our team > with a physical Linux setup to try to reproduce it. > > To answer your question, we are not aware of any such leaks. > > -- Kevin > > > > Itai wrote: > > I'm experiencing multiple memory leaks with JavaFX on > Linux, > to the point > where I'm not sure which bug to report, as it seems like a > systematic > issue. > > The memory leak seems to be completely absent when > using the > software > renderer (-Dprism.order=sw), and does not seem to > happen on > Windows > (presumably not on Mac either, although I have no Mac > to test it). > > Test cases include: > > 1. Use ProgressIndicator with progress set to > Indeterminate - > with default > (HW) renderer memory consumption quickly rises, > climbing to > 8GB and more if > not killed. With software renderer memory usage is > reasonable. > 2. Using Scene Builder - after a few minutes with Scene > Builder it quickly > gobbles up all system memory - again, problem seems to > go away > if using > software renderer. This test is less repeatable, as some > actions seem more > detrimental than others. > 3. Using Transitions on nodes (See attached code > "Demo.java". > I have filed > a bug report about this issue, JI-9041860). Running with > default renderer > the simple program reaches 3GB within 30 seconds, and > memory > continues to > climb. On software renderer memory consumption remains > <100MB > for a minute > and more. > > As I said, I am no longer sure it is prudent to report > specific bugs, as > this seems to be some low-level problem. I just want > to know > if this is a > known issue and if there is any way to get around it > (besides > using the > software pipe, which obviously has it's own > disadvantages). > > > For reference, I'm using Debian (testing, updated today), > kernel version > 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 > (kms > driver), > OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is > identical > on Oracle > version). > > If there is any other information needed please let me > know. > If this is a > known issue I apologize, but I have tried searching > and didn't > find any > reports of such behavior. > > Thank you. > > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From David.Hill at Oracle.com Thu Jul 21 16:32:55 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 21 Jul 2016 12:32:55 -0400 Subject: review: Fix more hardcoded paths in gradle build Message-ID: <5790F937.7080207@Oracle.com> Kevin, if you could review: https://bugs.openjdk.java.net/browse/JDK-8162114 webrev: http://cr.openjdk.java.net/~ddhill/8162114 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From richard.bair at oracle.com Thu Jul 21 16:41:53 2016 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jul 2016 09:41:53 -0700 Subject: Scene graph performance In-Reply-To: <59F25166-2E34-4F6E-9FAD-130EEFD05E3C@gmail.com> References: <59F25166-2E34-4F6E-9FAD-130EEFD05E3C@gmail.com> Message-ID: Have you guys profiled the application to see where the CPU time is spent? How many nodes in the app? In the past the majority of CPU time has been spent in one or more of the following (not sure if it still applies): - Computing changed bounds (a lot of work was done to speed this up, but I think it was always a single thread doing the work) - Synchronizing state to the render graph (a lot of work was done here too, so I wouldn?t expect this to be the problem area) - Walking the render graph to render shapes - Rasterization (A lot of optimization went here too, but it is still essentially a CPU bound operation) - Reading results back from the card (this is sometimes the culprit when it is slow on old hardware and fast on new hardware) These are all CPU bound tasks. I think that there are two angles to look at. First, we always wanted to break down the render stage into some parallel pipeline. Adobe Flex was good at this, where they?d saturate every CPU you had during the CPU intensive rasterization phase and scene graph computation phase. Depending on your particular test, this might actually be the bottleneck. So the idea here is to optimize the CPU tasks, which will (hopefully) remove CPU from the bottleneck and allow the GPU to take on more of the burden. You should also do some research or experiments with regards to battery life to make sure using more cores doesn?t make things worse (and if it does, to then have a flag to indicate the amount of parallelism). You also have to be careful because IIRC (and I may not!) if a lot of CPU activity happens on some laptops they?ll kick into a ?high performance? mode, which is sometimes what you want, and sometimes not. Games are happy to kick you into that mode (and drain your battery faster as a result) whereas business apps rarely want to do that. Another angle to look at is more of a research direction in the graphics rendering. We spent quite a lot of time looking into ways to go ?shader all the way? and avoid having to use a software rasterizer at all. The state of the art as likely advanced from the last time I looked at it, but at the time there really wasn?t anything that we could find that was really ready for production in terms of producing 2D screens using 3D that really gave you the polish of 2D. Also, the scene graph semantics are fundamentally painter?s algorithm, since this is what everybody is used to when coming from a 2D background. But that?s not the way it works in 3D. In 3D you feed a bunch of meshes to the video card and it determines which pixels to render and which are occluded and don?t need to be rendered. But when you have multiple geometries at the same z-depth, then the card can have ?z-fighting? where it renders the pixels from some items below you and some above. There are techniques to try to overcome this, but at least the last time we looked at it (according to my increasingly dimming memory!) there wasn?t a really brilliant solution to the problem. Anti-aliasing and transparency were big problems too. >>>> DETOUR Normal things that you would have in 2D like shadows, text, even rounded rectangles have historically been produced using various 2D algorithms and blend modes and so forth. Most people don?t even realize the degree to which their view of what a real 2D screen looks like has been tainted by the techniques that were available for producing those screens. Many (most? all? at least it was at the time) game developers recognized this and used 2D toolkits with CPU rasterization to produce their 2D screens and then overlaid this on 3D content. The normal way to do this is to render the 2D images in photoshop or something and then slice it up and load the pngs into the graphics card on app startup and then scale those to produce the images. This is fine, but in a general purpose toolkit like FX you can?t just do that, because we allow programmatic access to the scene graph and people can modify the ?images? in real time. So we draw them and cache them and reuse the cached images whenever possible etc. A lot was done in order to try to optimize this part of the problem. When I was benchmarking this stuff, we blew away pretty much everybody who was in the 2D+3D general purpose graphics toolkit world. We never tried to compete with the game vendors (like Unity). We weren?t trying to be a pure 3D scene graph. There was a huge discussion about this early on in FX, as to how to marry the 2D and 3D worlds. Developers in these different lands come at the problem differently, in terms of how they understand their world (y-up or y-down? 0,0 in the middle? Every scene scaled? Or 0,0 in top left and pixel scaled by default? Anti-aliasing?). We decided it was for 2D developers who wanted advanced graphics and animations, and a better toolkit for building apps (not games). We figured that for people who wanted to program games, we were never going to be really compelling without building out a lot of additional support, way beyond just graphics performance. Looking at Unity you can see where we?d have had to go to be a compelling game platform, and obviously Sun and Oracle are not in that business. <<<<< END DETOUR One of the projects I really wanted to do was to modify Prism to take advantage of multiple cores in the computation / rasterization steps. I think doing so would be a pretty major job and would have to be done quite carefully. My guess is that this would help with the problem you are seeing, but I couldn?t be 100% sure without digging into the details of the benchmark and profile. Richard > On Jul 21, 2016, at 4:04 AM, Felix Bembrick wrote: > > I would add that neither JOGL nor LWJGL have these issues. > > Yes, I know they are somewhat different "animals", but the point is, clearly *Java* is NOT the cause. > >> On 21 Jul 2016, at 20:07, Dr. Michael Paus wrote: >> >> Hi Felix, >> I have written various tests like the ones you use in FXMark and I have >> obtained similar results. I have even tried to substitute 2D shapes by >> using 3D MeshViews in the hope that this would give better performance >> but the results were not that good. Of course all this depends on the >> specific test case but in general I see that a JavaFX application which >> makes heavy use of graphics animations is completely CPU-bounded. >> The maximum performance is reached when one CPU/Core is at 100%. >> The performance of your graphics hardware seems to be almost irrelevant. >> I could for example run four instances of the same test with almost the >> same performance at the same time. In this case all 4 cores of my machine >> were at 100%. This proves that the graphics hardware is not the limiting >> factor. My machine is a MacBook Pro with Retina graphics and a dedicated >> NVidia graphics card which is already a couple of years old and certainly >> not playing in the same league as your high-power card. >> I myself have not yet found a way to really speed up the graphics performance >> and I am a little bit frustrated because of that. But it is not only the general >> graphic performance which is a problem. There are also a lot of other pitfalls >> into which you can stumble and which can bring your animations to a halt >> or even crash your system. Zooming for example is one of these issues. >> >> I would like to have some exchange on these issues and how to best address >> them but my impression so far is that there are only very view people interested >> in that. (I hope someone can prove me wrong on this :-) >> >> Michael >> >>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>> Having written and tested FXMark on various platforms and devices, one >>> thing has really struck me as quite "odd". >>> >>> I started work on FXMark as a kind of side project a while ago and, at the >>> time, my machine was powerful but not "super powerful". >>> >>> So when I purchased a new machine with just about the highest specs >>> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X >>> GPUs in SLI mode, I was naturally expecting to see significant performance >>> improvements when I ran FXMark on this machine. >>> >>> But to my surprise, and disappointment, the scene graph animations ran >>> almost NO faster whatsoever! >>> >>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a >>> rudimentary (single) GPU and, guess what - almost the same level of >>> performance (i.e. FPS and smoothness etc.) was achieved on this >>> considerably less powerful machine (in terms of both CPU and GPU). >>> >>> So, it seems there is some kind of "performance wall" that limits the >>> rendering speed of the scene graph (and this is with full speed animations >>> enabled). >>> >>> What is the nature of this "wall"? Is it simply that the rendering pipeline >>> is not making efficient use of the GPU? Is too much being done on the CPU? >>> >>> Whatever the cause, I really think it needs to be addressed. >>> >>> If I can't get better performance out of a machine that scores in the top >>> 0.01% of all machine in the world in the 3DMark Index than an entry level >>> PC, isn't this a MAJOR issue for JavaFX? >>> >>> Blessings, >>> >>> Felix >> >> From markus at headcrashing.eu Thu Jul 21 17:56:40 2016 From: markus at headcrashing.eu (Markus KARG) Date: Thu, 21 Jul 2016 19:56:40 +0200 Subject: Scene graph performance In-Reply-To: References: Message-ID: <00eb01d1e379$3f312b70$bd938250$@eu> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus Sent: Donnerstag, 21. Juli 2016 12:07 To: openjfx-dev at openjdk.java.net Subject: Re: Scene graph performance Hi Felix, I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. The maximum performance is reached when one CPU/Core is at 100%. The performance of your graphics hardware seems to be almost irrelevant. I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) Michael Am 20.07.16 um 04:14 schrieb Felix Bembrick: > Having written and tested FXMark on various platforms and devices, one > thing has really struck me as quite "odd". > > I started work on FXMark as a kind of side project a while ago and, at > the time, my machine was powerful but not "super powerful". > > So when I purchased a new machine with just about the highest specs > available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX > Titan X GPUs in SLI mode, I was naturally expecting to see significant > performance improvements when I ran FXMark on this machine. > > But to my surprise, and disappointment, the scene graph animations ran > almost NO faster whatsoever! > > So then I decided to try FXMark on my wife's entry-level Dell i5 PC > with a rudimentary (single) GPU and, guess what - almost the same > level of performance (i.e. FPS and smoothness etc.) was achieved on > this considerably less powerful machine (in terms of both CPU and GPU). > > So, it seems there is some kind of "performance wall" that limits the > rendering speed of the scene graph (and this is with full speed > animations enabled). > > What is the nature of this "wall"? Is it simply that the rendering > pipeline is not making efficient use of the GPU? Is too much being done on the CPU? > > Whatever the cause, I really think it needs to be addressed. > > If I can't get better performance out of a machine that scores in the > top 0.01% of all machine in the world in the 3DMark Index than an > entry level PC, isn't this a MAJOR issue for JavaFX? > > Blessings, > > Felix From richard.bair at oracle.com Thu Jul 21 18:17:57 2016 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jul 2016 11:17:57 -0700 Subject: Scene graph performance In-Reply-To: <00eb01d1e379$3f312b70$bd938250$@eu> References: <00eb01d1e379$3f312b70$bd938250$@eu> Message-ID: <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> I think you just nailed it on the head Markus :-). > On Jul 21, 2016, at 10:56 AM, Markus KARG wrote: > > The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). > > I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. > > If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus > Sent: Donnerstag, 21. Juli 2016 12:07 > To: openjfx-dev at openjdk.java.net > Subject: Re: Scene graph performance > > Hi Felix, > I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. > The maximum performance is reached when one CPU/Core is at 100%. > The performance of your graphics hardware seems to be almost irrelevant. > I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. > I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. > > I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) > > Michael > > Am 20.07.16 um 04:14 schrieb Felix Bembrick: >> Having written and tested FXMark on various platforms and devices, one >> thing has really struck me as quite "odd". >> >> I started work on FXMark as a kind of side project a while ago and, at >> the time, my machine was powerful but not "super powerful". >> >> So when I purchased a new machine with just about the highest specs >> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX >> Titan X GPUs in SLI mode, I was naturally expecting to see significant >> performance improvements when I ran FXMark on this machine. >> >> But to my surprise, and disappointment, the scene graph animations ran >> almost NO faster whatsoever! >> >> So then I decided to try FXMark on my wife's entry-level Dell i5 PC >> with a rudimentary (single) GPU and, guess what - almost the same >> level of performance (i.e. FPS and smoothness etc.) was achieved on >> this considerably less powerful machine (in terms of both CPU and GPU). >> >> So, it seems there is some kind of "performance wall" that limits the >> rendering speed of the scene graph (and this is with full speed >> animations enabled). >> >> What is the nature of this "wall"? Is it simply that the rendering >> pipeline is not making efficient use of the GPU? Is too much being done on the CPU? >> >> Whatever the cause, I really think it needs to be addressed. >> >> If I can't get better performance out of a machine that scores in the >> top 0.01% of all machine in the world in the 3DMark Index than an >> entry level PC, isn't this a MAJOR issue for JavaFX? >> >> Blessings, >> >> Felix > > > From kevin.rushforth at oracle.com Thu Jul 21 18:22:37 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Jul 2016 11:22:37 -0700 Subject: Scene graph performance In-Reply-To: <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> Message-ID: <579112ED.7070600@oracle.com> Yep. -- Kevin Richard Bair wrote: > I think you just nailed it on the head Markus :-). > > >> On Jul 21, 2016, at 10:56 AM, Markus KARG wrote: >> >> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). >> >> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >> >> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) >> >> -Markus >> >> -----Original Message----- >> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus >> Sent: Donnerstag, 21. Juli 2016 12:07 >> To: openjfx-dev at openjdk.java.net >> Subject: Re: Scene graph performance >> >> Hi Felix, >> I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. >> The maximum performance is reached when one CPU/Core is at 100%. >> The performance of your graphics hardware seems to be almost irrelevant. >> I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. >> I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. >> >> I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) >> >> Michael >> >> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >> >>> Having written and tested FXMark on various platforms and devices, one >>> thing has really struck me as quite "odd". >>> >>> I started work on FXMark as a kind of side project a while ago and, at >>> the time, my machine was powerful but not "super powerful". >>> >>> So when I purchased a new machine with just about the highest specs >>> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX >>> Titan X GPUs in SLI mode, I was naturally expecting to see significant >>> performance improvements when I ran FXMark on this machine. >>> >>> But to my surprise, and disappointment, the scene graph animations ran >>> almost NO faster whatsoever! >>> >>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC >>> with a rudimentary (single) GPU and, guess what - almost the same >>> level of performance (i.e. FPS and smoothness etc.) was achieved on >>> this considerably less powerful machine (in terms of both CPU and GPU). >>> >>> So, it seems there is some kind of "performance wall" that limits the >>> rendering speed of the scene graph (and this is with full speed >>> animations enabled). >>> >>> What is the nature of this "wall"? Is it simply that the rendering >>> pipeline is not making efficient use of the GPU? Is too much being done on the CPU? >>> >>> Whatever the cause, I really think it needs to be addressed. >>> >>> If I can't get better performance out of a machine that scores in the >>> top 0.01% of all machine in the world in the 3DMark Index than an >>> entry level PC, isn't this a MAJOR issue for JavaFX? >>> >>> Blessings, >>> >>> Felix >>> >> >> > > From felix.bembrick at gmail.com Thu Jul 21 18:28:31 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 04:28:31 +1000 Subject: Scene graph performance In-Reply-To: References: <59F25166-2E34-4F6E-9FAD-130EEFD05E3C@gmail.com> Message-ID: Hi Richard, Wow! Thanks - you really know your stuff! Yes, it's not a "one LOC change" and I get that it has a lot to do with the difficult marriage of 2D and 3D worlds. And it does seem like a large project in itself to solve these problems but, I really believe it *has* to be done and I intend to at least do whatever I can to achieve at least a linear relationship between CPU/GPU cores/grunt and JavaFX performance. At the moment, it doesn't seem to matter *what* hardware you throw it at, the JavaFX scene graph performance is almost static. The issues you have highlighted here will be very useful indeed in making this happen. I think I might have mentioned to you privately that the Qt rendering pipeline had similar problems but has been greatly optimised in the last couple of releases. I paid very close attention to the issues and how they resolved them and I'm sure many of those techniques could be applied in this scenario. Anyway - it's certainly worth a try! Felix > On 22 Jul 2016, at 02:41, Richard Bair wrote: > > Have you guys profiled the application to see where the CPU time is spent? How many nodes in the app? > > In the past the majority of CPU time has been spent in one or more of the following (not sure if it still applies): > - Computing changed bounds (a lot of work was done to speed this up, but I think it was always a single thread doing the work) > - Synchronizing state to the render graph (a lot of work was done here too, so I wouldn?t expect this to be the problem area) > - Walking the render graph to render shapes > - Rasterization (A lot of optimization went here too, but it is still essentially a CPU bound operation) > - Reading results back from the card (this is sometimes the culprit when it is slow on old hardware and fast on new hardware) > > These are all CPU bound tasks. > > I think that there are two angles to look at. First, we always wanted to break down the render stage into some parallel pipeline. Adobe Flex was good at this, where they?d saturate every CPU you had during the CPU intensive rasterization phase and scene graph computation phase. Depending on your particular test, this might actually be the bottleneck. So the idea here is to optimize the CPU tasks, which will (hopefully) remove CPU from the bottleneck and allow the GPU to take on more of the burden. You should also do some research or experiments with regards to battery life to make sure using more cores doesn?t make things worse (and if it does, to then have a flag to indicate the amount of parallelism). You also have to be careful because IIRC (and I may not!) if a lot of CPU activity happens on some laptops they?ll kick into a ?high performance? mode, which is sometimes what you want, and sometimes not. Games are happy to kick you into that mode (and drain your battery faster as a result) whereas business apps rarely want to do that. > > Another angle to look at is more of a research direction in the graphics rendering. We spent quite a lot of time looking into ways to go ?shader all the way? and avoid having to use a software rasterizer at all. The state of the art as likely advanced from the last time I looked at it, but at the time there really wasn?t anything that we could find that was really ready for production in terms of producing 2D screens using 3D that really gave you the polish of 2D. Also, the scene graph semantics are fundamentally painter?s algorithm, since this is what everybody is used to when coming from a 2D background. But that?s not the way it works in 3D. In 3D you feed a bunch of meshes to the video card and it determines which pixels to render and which are occluded and don?t need to be rendered. But when you have multiple geometries at the same z-depth, then the card can have ?z-fighting? where it renders the pixels from some items below you and some above. There are techniques to try to overcome this, but at least the last time we looked at it (according to my increasingly dimming memory!) there wasn?t a really brilliant solution to the problem. Anti-aliasing and transparency were big problems too. > >>>>> DETOUR > > Normal things that you would have in 2D like shadows, text, even rounded rectangles have historically been produced using various 2D algorithms and blend modes and so forth. Most people don?t even realize the degree to which their view of what a real 2D screen looks like has been tainted by the techniques that were available for producing those screens. Many (most? all? at least it was at the time) game developers recognized this and used 2D toolkits with CPU rasterization to produce their 2D screens and then overlaid this on 3D content. The normal way to do this is to render the 2D images in photoshop or something and then slice it up and load the pngs into the graphics card on app startup and then scale those to produce the images. This is fine, but in a general purpose toolkit like FX you can?t just do that, because we allow programmatic access to the scene graph and people can modify the ?images? in real time. So we draw them and cache them and reuse the cached images whenever possible etc. A lot was done in order to try to optimize this part of the problem. > > When I was benchmarking this stuff, we blew away pretty much everybody who was in the 2D+3D general purpose graphics toolkit world. We never tried to compete with the game vendors (like Unity). We weren?t trying to be a pure 3D scene graph. There was a huge discussion about this early on in FX, as to how to marry the 2D and 3D worlds. Developers in these different lands come at the problem differently, in terms of how they understand their world (y-up or y-down? 0,0 in the middle? Every scene scaled? Or 0,0 in top left and pixel scaled by default? Anti-aliasing?). We decided it was for 2D developers who wanted advanced graphics and animations, and a better toolkit for building apps (not games). We figured that for people who wanted to program games, we were never going to be really compelling without building out a lot of additional support, way beyond just graphics performance. Looking at Unity you can see where we?d have had to go to be a compelling game platform, and obviously Sun and Oracle are not in that business. > > <<<<< END DETOUR > > One of the projects I really wanted to do was to modify Prism to take advantage of multiple cores in the computation / rasterization steps. I think doing so would be a pretty major job and would have to be done quite carefully. My guess is that this would help with the problem you are seeing, but I couldn?t be 100% sure without digging into the details of the benchmark and profile. > > Richard > >> On Jul 21, 2016, at 4:04 AM, Felix Bembrick wrote: >> >> I would add that neither JOGL nor LWJGL have these issues. >> >> Yes, I know they are somewhat different "animals", but the point is, clearly *Java* is NOT the cause. >> >>> On 21 Jul 2016, at 20:07, Dr. Michael Paus wrote: >>> >>> Hi Felix, >>> I have written various tests like the ones you use in FXMark and I have >>> obtained similar results. I have even tried to substitute 2D shapes by >>> using 3D MeshViews in the hope that this would give better performance >>> but the results were not that good. Of course all this depends on the >>> specific test case but in general I see that a JavaFX application which >>> makes heavy use of graphics animations is completely CPU-bounded. >>> The maximum performance is reached when one CPU/Core is at 100%. >>> The performance of your graphics hardware seems to be almost irrelevant. >>> I could for example run four instances of the same test with almost the >>> same performance at the same time. In this case all 4 cores of my machine >>> were at 100%. This proves that the graphics hardware is not the limiting >>> factor. My machine is a MacBook Pro with Retina graphics and a dedicated >>> NVidia graphics card which is already a couple of years old and certainly >>> not playing in the same league as your high-power card. >>> I myself have not yet found a way to really speed up the graphics performance >>> and I am a little bit frustrated because of that. But it is not only the general >>> graphic performance which is a problem. There are also a lot of other pitfalls >>> into which you can stumble and which can bring your animations to a halt >>> or even crash your system. Zooming for example is one of these issues. >>> >>> I would like to have some exchange on these issues and how to best address >>> them but my impression so far is that there are only very view people interested >>> in that. (I hope someone can prove me wrong on this :-) >>> >>> Michael >>> >>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>>> Having written and tested FXMark on various platforms and devices, one >>>> thing has really struck me as quite "odd". >>>> >>>> I started work on FXMark as a kind of side project a while ago and, at the >>>> time, my machine was powerful but not "super powerful". >>>> >>>> So when I purchased a new machine with just about the highest specs >>>> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X >>>> GPUs in SLI mode, I was naturally expecting to see significant performance >>>> improvements when I ran FXMark on this machine. >>>> >>>> But to my surprise, and disappointment, the scene graph animations ran >>>> almost NO faster whatsoever! >>>> >>>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a >>>> rudimentary (single) GPU and, guess what - almost the same level of >>>> performance (i.e. FPS and smoothness etc.) was achieved on this >>>> considerably less powerful machine (in terms of both CPU and GPU). >>>> >>>> So, it seems there is some kind of "performance wall" that limits the >>>> rendering speed of the scene graph (and this is with full speed animations >>>> enabled). >>>> >>>> What is the nature of this "wall"? Is it simply that the rendering pipeline >>>> is not making efficient use of the GPU? Is too much being done on the CPU? >>>> >>>> Whatever the cause, I really think it needs to be addressed. >>>> >>>> If I can't get better performance out of a machine that scores in the top >>>> 0.01% of all machine in the world in the 3DMark Index than an entry level >>>> PC, isn't this a MAJOR issue for JavaFX? >>>> >>>> Blessings, >>>> >>>> Felix > From felix.bembrick at gmail.com Thu Jul 21 18:32:58 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 04:32:58 +1000 Subject: Scene graph performance In-Reply-To: <579112ED.7070600@oracle.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> Message-ID: <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> Well, I'm putting my hand up for this. Kevin, would you like to discuss this with me on or offline? Felix P.S. Thanks Markus for your insight! > On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: > > Yep. > > -- Kevin > > > Richard Bair wrote: >> I think you just nailed it on the head Markus :-). >> >> >>> On Jul 21, 2016, at 10:56 AM, Markus KARG wrote: >>> >>> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). >>> >>> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >>> >>> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) >>> >>> -Markus >>> >>> -----Original Message----- >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus >>> Sent: Donnerstag, 21. Juli 2016 12:07 >>> To: openjfx-dev at openjdk.java.net >>> Subject: Re: Scene graph performance >>> >>> Hi Felix, >>> I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. >>> The maximum performance is reached when one CPU/Core is at 100%. >>> The performance of your graphics hardware seems to be almost irrelevant. >>> I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. >>> I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. >>> >>> I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) >>> >>> Michael >>> >>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>>> >>>> Having written and tested FXMark on various platforms and devices, one thing has really struck me as quite "odd". >>>> >>>> I started work on FXMark as a kind of side project a while ago and, at the time, my machine was powerful but not "super powerful". >>>> >>>> So when I purchased a new machine with just about the highest specs available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X GPUs in SLI mode, I was naturally expecting to see significant performance improvements when I ran FXMark on this machine. >>>> >>>> But to my surprise, and disappointment, the scene graph animations ran almost NO faster whatsoever! >>>> >>>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a rudimentary (single) GPU and, guess what - almost the same level of performance (i.e. FPS and smoothness etc.) was achieved on this considerably less powerful machine (in terms of both CPU and GPU). >>>> >>>> So, it seems there is some kind of "performance wall" that limits the rendering speed of the scene graph (and this is with full speed animations enabled). >>>> >>>> What is the nature of this "wall"? Is it simply that the rendering pipeline is not making efficient use of the GPU? Is too much being done on the CPU? >>>> >>>> Whatever the cause, I really think it needs to be addressed. >>>> >>>> If I can't get better performance out of a machine that scores in the top 0.01% of all machine in the world in the 3DMark Index than an entry level PC, isn't this a MAJOR issue for JavaFX? >>>> >>>> Blessings, >>>> >>>> Felix >> >> From kevin.rushforth at oracle.com Thu Jul 21 18:42:29 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Jul 2016 11:42:29 -0700 Subject: Scene graph performance In-Reply-To: <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> Message-ID: <57911795.2060201@oracle.com> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list...compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. -- Kevin Felix Bembrick wrote: > Well, I'm putting my hand up for this. > > Kevin, would you like to discuss this with me on or offline? > > Felix > > P.S. Thanks Markus for your insight! > > >> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >> >> Yep. >> >> -- Kevin >> >> >> Richard Bair wrote: >> >>> I think you just nailed it on the head Markus :-). >>> >>> >>> >>>> On Jul 21, 2016, at 10:56 AM, Markus KARG wrote: >>>> >>>> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). >>>> >>>> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >>>> >>>> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) >>>> >>>> -Markus >>>> >>>> -----Original Message----- >>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus >>>> Sent: Donnerstag, 21. Juli 2016 12:07 >>>> To: openjfx-dev at openjdk.java.net >>>> Subject: Re: Scene graph performance >>>> >>>> Hi Felix, >>>> I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. >>>> The maximum performance is reached when one CPU/Core is at 100%. >>>> The performance of your graphics hardware seems to be almost irrelevant. >>>> I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. >>>> I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. >>>> >>>> I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) >>>> >>>> Michael >>>> >>>> >>>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>>>> >>>>> Having written and tested FXMark on various platforms and devices, one thing has really struck me as quite "odd". >>>>> >>>>> I started work on FXMark as a kind of side project a while ago and, at the time, my machine was powerful but not "super powerful". >>>>> >>>>> So when I purchased a new machine with just about the highest specs available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X GPUs in SLI mode, I was naturally expecting to see significant performance improvements when I ran FXMark on this machine. >>>>> >>>>> But to my surprise, and disappointment, the scene graph animations ran almost NO faster whatsoever! >>>>> >>>>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a rudimentary (single) GPU and, guess what - almost the same level of performance (i.e. FPS and smoothness etc.) was achieved on this considerably less powerful machine (in terms of both CPU and GPU). >>>>> >>>>> So, it seems there is some kind of "performance wall" that limits the rendering speed of the scene graph (and this is with full speed animations enabled). >>>>> >>>>> What is the nature of this "wall"? Is it simply that the rendering pipeline is not making efficient use of the GPU? Is too much being done on the CPU? >>>>> >>>>> Whatever the cause, I really think it needs to be addressed. >>>>> >>>>> If I can't get better performance out of a machine that scores in the top 0.01% of all machine in the world in the 3DMark Index than an entry level PC, isn't this a MAJOR issue for JavaFX? >>>>> >>>>> Blessings, >>>>> >>>>> Felix >>>>> >>> >>> From felix.bembrick at gmail.com Thu Jul 21 18:51:07 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 04:51:07 +1000 Subject: Scene graph performance In-Reply-To: <57911795.2060201@oracle.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> Message-ID: <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? > On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: > > Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list...compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. > > -- Kevin > > > Felix Bembrick wrote: >> Well, I'm putting my hand up for this. >> >> Kevin, would you like to discuss this with me on or offline? >> >> Felix >> >> P.S. Thanks Markus for your insight! >> >> >>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>> >>> Yep. >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>> >>>> I think you just nailed it on the head Markus :-). >>>> >>>> >>>>> On Jul 21, 2016, at 10:56 AM, Markus KARG wrote: >>>>> >>>>> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). >>>>> >>>>> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >>>>> >>>>> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) >>>>> >>>>> -Markus >>>>> >>>>> -----Original Message----- >>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus >>>>> Sent: Donnerstag, 21. Juli 2016 12:07 >>>>> To: openjfx-dev at openjdk.java.net >>>>> Subject: Re: Scene graph performance >>>>> >>>>> Hi Felix, >>>>> I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. >>>>> The maximum performance is reached when one CPU/Core is at 100%. >>>>> The performance of your graphics hardware seems to be almost irrelevant. >>>>> I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. >>>>> I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. >>>>> >>>>> I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) >>>>> >>>>> Michael >>>>> >>>>> >>>>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>>>>> Having written and tested FXMark on various platforms and devices, one thing has really struck me as quite "odd". >>>>>> >>>>>> I started work on FXMark as a kind of side project a while ago and, at the time, my machine was powerful but not "super powerful". >>>>>> >>>>>> So when I purchased a new machine with just about the highest specs available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X GPUs in SLI mode, I was naturally expecting to see significant performance improvements when I ran FXMark on this machine. >>>>>> >>>>>> But to my surprise, and disappointment, the scene graph animations ran almost NO faster whatsoever! >>>>>> >>>>>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a rudimentary (single) GPU and, guess what - almost the same level of performance (i.e. FPS and smoothness etc.) was achieved on this considerably less powerful machine (in terms of both CPU and GPU). >>>>>> >>>>>> So, it seems there is some kind of "performance wall" that limits the rendering speed of the scene graph (and this is with full speed animations enabled). >>>>>> >>>>>> What is the nature of this "wall"? Is it simply that the rendering pipeline is not making efficient use of the GPU? Is too much being done on the CPU? >>>>>> >>>>>> Whatever the cause, I really think it needs to be addressed. >>>>>> >>>>>> If I can't get better performance out of a machine that scores in the top 0.01% of all machine in the world in the 3DMark Index than an entry level PC, isn't this a MAJOR issue for JavaFX? >>>>>> >>>>>> Blessings, >>>>>> >>>>>> Felix >>>> From kevin.rushforth at oracle.com Thu Jul 21 20:41:56 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Jul 2016 13:41:56 -0700 Subject: Scene graph performance In-Reply-To: <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> Message-ID: <57913394.9070702@oracle.com> I don't think there is even a ball park date yet. -- Kevin Felix Bembrick wrote: > What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? > > >> On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: >> >> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list...compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. >> >> -- Kevin >> >> >> Felix Bembrick wrote: >> >>> Well, I'm putting my hand up for this. >>> >>> Kevin, would you like to discuss this with me on or offline? >>> >>> Felix >>> >>> P.S. Thanks Markus for your insight! >>> >>> >>> >>>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>>> >>>> Yep. >>>> >>>> -- Kevin >>>> >>>> >>>> Richard Bair wrote: >>>> >>>> >>>>> I think you just nailed it on the head Markus :-). >>>>> >>>>> >>>>> >>>>>> On Jul 21, 2016, at 10:56 AM, Markus KARG wrote: >>>>>> >>>>>> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). >>>>>> >>>>>> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >>>>>> >>>>>> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) >>>>>> >>>>>> -Markus >>>>>> >>>>>> -----Original Message----- >>>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus >>>>>> Sent: Donnerstag, 21. Juli 2016 12:07 >>>>>> To: openjfx-dev at openjdk.java.net >>>>>> Subject: Re: Scene graph performance >>>>>> >>>>>> Hi Felix, >>>>>> I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. >>>>>> The maximum performance is reached when one CPU/Core is at 100%. >>>>>> The performance of your graphics hardware seems to be almost irrelevant. >>>>>> I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. >>>>>> I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. >>>>>> >>>>>> I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) >>>>>> >>>>>> Michael >>>>>> >>>>>> >>>>>> >>>>>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>>>>>> Having written and tested FXMark on various platforms and devices, one thing has really struck me as quite "odd". >>>>>>> >>>>>>> I started work on FXMark as a kind of side project a while ago and, at the time, my machine was powerful but not "super powerful". >>>>>>> >>>>>>> So when I purchased a new machine with just about the highest specs available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X GPUs in SLI mode, I was naturally expecting to see significant performance improvements when I ran FXMark on this machine. >>>>>>> >>>>>>> But to my surprise, and disappointment, the scene graph animations ran almost NO faster whatsoever! >>>>>>> >>>>>>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a rudimentary (single) GPU and, guess what - almost the same level of performance (i.e. FPS and smoothness etc.) was achieved on this considerably less powerful machine (in terms of both CPU and GPU). >>>>>>> >>>>>>> So, it seems there is some kind of "performance wall" that limits the rendering speed of the scene graph (and this is with full speed animations enabled). >>>>>>> >>>>>>> What is the nature of this "wall"? Is it simply that the rendering pipeline is not making efficient use of the GPU? Is too much being done on the CPU? >>>>>>> >>>>>>> Whatever the cause, I really think it needs to be addressed. >>>>>>> >>>>>>> If I can't get better performance out of a machine that scores in the top 0.01% of all machine in the world in the 3DMark Index than an entry level PC, isn't this a MAJOR issue for JavaFX? >>>>>>> >>>>>>> Blessings, >>>>>>> >>>>>>> Felix >>>>>>> >>>>> >>>>> From dalibor.topic at oracle.com Thu Jul 21 20:51:08 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 21 Jul 2016 22:51:08 +0200 Subject: Scene graph performance In-Reply-To: <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> Message-ID: <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> There is no JDK 10 Project in OpenJDK yet, so there has been no proposed schedule for it yet. cheers, dalibor topic On 21.07.2016 20:51, Felix Bembrick wrote: > What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? > >> On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: >> >> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list...compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. >> >> -- Kevin >> >> >> Felix Bembrick wrote: >>> Well, I'm putting my hand up for this. >>> >>> Kevin, would you like to discuss this with me on or offline? >>> >>> Felix >>> >>> P.S. Thanks Markus for your insight! >>> >>> >>>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>>> >>>> Yep. >>>> >>>> -- Kevin >>>> >>>> >>>> Richard Bair wrote: >>>> >>>>> I think you just nailed it on the head Markus :-). >>>>> >>>>> >>>>>> On Jul 21, 2016, at 10:56 AM, Markus KARG wrote: >>>>>> >>>>>> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). >>>>>> >>>>>> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >>>>>> >>>>>> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) >>>>>> >>>>>> -Markus >>>>>> >>>>>> -----Original Message----- >>>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus >>>>>> Sent: Donnerstag, 21. Juli 2016 12:07 >>>>>> To: openjfx-dev at openjdk.java.net >>>>>> Subject: Re: Scene graph performance >>>>>> >>>>>> Hi Felix, >>>>>> I have written various tests like the ones you use in FXMark and I have obtained similar results. I have even tried to substitute 2D shapes by using 3D MeshViews in the hope that this would give better performance but the results were not that good. Of course all this depends on the specific test case but in general I see that a JavaFX application which makes heavy use of graphics animations is completely CPU-bounded. >>>>>> The maximum performance is reached when one CPU/Core is at 100%. >>>>>> The performance of your graphics hardware seems to be almost irrelevant. >>>>>> I could for example run four instances of the same test with almost the same performance at the same time. In this case all 4 cores of my machine were at 100%. This proves that the graphics hardware is not the limiting factor. My machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics card which is already a couple of years old and certainly not playing in the same league as your high-power card. >>>>>> I myself have not yet found a way to really speed up the graphics performance and I am a little bit frustrated because of that. But it is not only the general graphic performance which is a problem. There are also a lot of other pitfalls into which you can stumble and which can bring your animations to a halt or even crash your system. Zooming for example is one of these issues. >>>>>> >>>>>> I would like to have some exchange on these issues and how to best address them but my impression so far is that there are only very view people interested in that. (I hope someone can prove me wrong on this :-) >>>>>> >>>>>> Michael >>>>>> >>>>>> >>>>>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>>>>>> Having written and tested FXMark on various platforms and devices, one thing has really struck me as quite "odd". >>>>>>> >>>>>>> I started work on FXMark as a kind of side project a while ago and, at the time, my machine was powerful but not "super powerful". >>>>>>> >>>>>>> So when I purchased a new machine with just about the highest specs available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X GPUs in SLI mode, I was naturally expecting to see significant performance improvements when I ran FXMark on this machine. >>>>>>> >>>>>>> But to my surprise, and disappointment, the scene graph animations ran almost NO faster whatsoever! >>>>>>> >>>>>>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a rudimentary (single) GPU and, guess what - almost the same level of performance (i.e. FPS and smoothness etc.) was achieved on this considerably less powerful machine (in terms of both CPU and GPU). >>>>>>> >>>>>>> So, it seems there is some kind of "performance wall" that limits the rendering speed of the scene graph (and this is with full speed animations enabled). >>>>>>> >>>>>>> What is the nature of this "wall"? Is it simply that the rendering pipeline is not making efficient use of the GPU? Is too much being done on the CPU? >>>>>>> >>>>>>> Whatever the cause, I really think it needs to be addressed. >>>>>>> >>>>>>> If I can't get better performance out of a machine that scores in the top 0.01% of all machine in the world in the 3DMark Index than an entry level PC, isn't this a MAJOR issue for JavaFX? >>>>>>> >>>>>>> Blessings, >>>>>>> >>>>>>> Felix >>>>> -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From felix.bembrick at gmail.com Thu Jul 21 21:09:44 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 07:09:44 +1000 Subject: Scene graph performance In-Reply-To: <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> Message-ID: <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Yes, well I think this the problem: 1) Going on history, it would be a best case scenario for Java 10 to be released in 2020 (but more likely 2021). 2) With JavaFX, we are already "behind the game" (pun intended). 3) JavaFX itself has evolved much slower than its competitors. 4) Technology in general will have moved ahead by massive leaps by 2021 (including our competitors). 5) If the *first* optimised JavaFX scene graph is not released until 2021, I genuinely fear that not only would "the ship have sailed" but, it would actually be way over the horizon and completely out of sight. Felix > On 22 Jul 2016, at 06:51, dalibor topic wrote: > > There is no JDK 10 Project in OpenJDK yet, so there has been no proposed schedule for it yet. > > cheers, > dalibor topic > >> On 21.07.2016 20:51, Felix Bembrick wrote: >> What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? >> >>> On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: >>> >>> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list....compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. >>> >>> -- Kevin >>> >>> >>> Felix Bembrick wrote: >>>> Well, I'm putting my hand up for this. >>>> >>>> Kevin, would you like to discuss this with me on or offline? >>>> >>>> Felix >>>> >>>> P.S. Thanks Markus for your insight! >>>> >>>> >>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>>>> >>>>> Yep. From herve.girod at gmail.com Thu Jul 21 21:33:50 2016 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Thu, 21 Jul 2016 23:33:50 +0200 Subject: Scene graph performance In-Reply-To: <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: I really don't understand all this. We use Java FX 8 in a graphic framework where we need high performance (prototyping Cockpit Display Systems with dynamic Maps and Head Up Displays), and we find that JavaFX performance is pretty good our use case. For example, Qt / QML performance is far worse in our POV, for no real additional simplicity of usage for big projects. We also used OpenGL before (used JOGL), but (at least for our own usage) what additional performance benefits we could maybe achieve were not worth the amount of work we would have needed to get them (if we had any). Herv? Sent from my iPad > On 21 juil. 2016, at 23:09, Felix Bembrick wrote: > > Yes, well I think this the problem: > > 1) Going on history, it would be a best case scenario for Java 10 to be released in 2020 (but more likely 2021). > > 2) With JavaFX, we are already "behind the game" (pun intended). > > 3) JavaFX itself has evolved much slower than its competitors. > > 4) Technology in general will have moved ahead by massive leaps by 2021 (including our competitors). > > 5) If the *first* optimised JavaFX scene graph is not released until 2021, I genuinely fear that not only would "the ship have sailed" but, it would actually be way over the horizon and completely out of sight. > > Felix > >> On 22 Jul 2016, at 06:51, dalibor topic wrote: >> >> There is no JDK 10 Project in OpenJDK yet, so there has been no proposed schedule for it yet. >> >> cheers, >> dalibor topic >> >>> On 21.07.2016 20:51, Felix Bembrick wrote: >>> What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? >>> >>>> On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: >>>> >>>> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list....compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. >>>> >>>> -- Kevin >>>> >>>> >>>> Felix Bembrick wrote: >>>>> Well, I'm putting my hand up for this. >>>>> >>>>> Kevin, would you like to discuss this with me on or offline? >>>>> >>>>> Felix >>>>> >>>>> P.S. Thanks Markus for your insight! >>>>> >>>>> >>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>>>>> >>>>>> Yep. From steve at weblite.ca Thu Jul 21 21:42:51 2016 From: steve at weblite.ca (Steve Hannah) Date: Thu, 21 Jul 2016 14:42:51 -0700 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: I've just been a fly on the wall for this thread, but ... I think this thread has gone off track a bit. Felix's original observation was that he got the same benchmark results from two machines that should produce different results because one is more powerful than the other in both CPU and GPU). The talk of things that could be done to improve JavaFX performance don't seem relevant to this. The real question is, why is a slow computer performing as well as a fast computer? The answer is likely far simpler than the explanations proposed here. Either there is a problem with the benchmark methodology, there is an environment difference that isn't being accounted for (which is also a methodology problem), or there is some mechanism that is throttling performance. My hunch is that there is a problem with the benchmark. Steve On Thu, Jul 21, 2016 at 2:33 PM, Herv? Girod wrote: > I really don't understand all this. We use Java FX 8 in a graphic > framework where we need high performance (prototyping Cockpit Display > Systems with dynamic Maps and Head Up Displays), and we find that JavaFX > performance is pretty good our use case. For example, Qt / QML performance > is far worse in our POV, for no real additional simplicity of usage for big > projects. We also used OpenGL before (used JOGL), but (at least for our own > usage) what additional performance benefits we could maybe achieve were not > worth the amount of work we would have needed to get them (if we had any). > > Herv? > > Sent from my iPad > > > On 21 juil. 2016, at 23:09, Felix Bembrick > wrote: > > > > Yes, well I think this the problem: > > > > 1) Going on history, it would be a best case scenario for Java 10 to be > released in 2020 (but more likely 2021). > > > > 2) With JavaFX, we are already "behind the game" (pun intended). > > > > 3) JavaFX itself has evolved much slower than its competitors. > > > > 4) Technology in general will have moved ahead by massive leaps by 2021 > (including our competitors). > > > > 5) If the *first* optimised JavaFX scene graph is not released until > 2021, I genuinely fear that not only would "the ship have sailed" but, it > would actually be way over the horizon and completely out of sight. > > > > Felix > > > >> On 22 Jul 2016, at 06:51, dalibor topic > wrote: > >> > >> There is no JDK 10 Project in OpenJDK yet, so there has been no > proposed schedule for it yet. > >> > >> cheers, > >> dalibor topic > >> > >>> On 21.07.2016 20:51, Felix Bembrick wrote: > >>> What is a "ball park" figure (i.e. around the 6-9 month granularity if > possible) for the the release date for JDK 10? > >>> > >>>> On 22 Jul 2016, at 04:42, Kevin Rushforth > wrote: > >>>> > >>>> Oh, I was agreeing with the analysis of what *would* need to be done. > I am not saying that I think it *should* be done, given resources other > priorities, etc. Having said that, as I mentioned in an earlier post a > month or so ago, we will be collecting ideas for possible JDK 10 features > once JDK 9 is finished. Perhaps this could go into the bucket of things to > consider, but it isn't something I would think would be high on the > list....compared to, say, WebGL, some sort of interop with native > rendering, updated graphics pipelines (we're current stuck on DX 9 and GL > 2), public API for UI Controls Behaviors, etc. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> Felix Bembrick wrote: > >>>>> Well, I'm putting my hand up for this. > >>>>> > >>>>> Kevin, would you like to discuss this with me on or offline? > >>>>> > >>>>> Felix > >>>>> > >>>>> P.S. Thanks Markus for your insight! > >>>>> > >>>>> > >>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >>>>>> > >>>>>> Yep. > -- Steve Hannah Web Lite Solutions Corp. From felix.bembrick at gmail.com Thu Jul 21 21:55:21 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 07:55:21 +1000 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> Are you using nodes, transitions, effects and animations? Or are you using the Canvas node only? > On 22 Jul 2016, at 07:33, Herv? Girod wrote: > > I really don't understand all this. We use Java FX 8 in a graphic framework where we need high performance (prototyping Cockpit Display Systems with dynamic Maps and Head Up Displays), and we find that JavaFX performance is pretty good our use case. For example, Qt / QML performance is far worse in our POV, for no real additional simplicity of usage for big projects. We also used OpenGL before (used JOGL), but (at least for our own usage) what additional performance benefits we could maybe achieve were not worth the amount of work we would have needed to get them (if we had any). > > Herv? > > Sent from my iPad > >> On 21 juil. 2016, at 23:09, Felix Bembrick wrote: >> >> Yes, well I think this the problem: >> >> 1) Going on history, it would be a best case scenario for Java 10 to be released in 2020 (but more likely 2021). >> >> 2) With JavaFX, we are already "behind the game" (pun intended). >> >> 3) JavaFX itself has evolved much slower than its competitors. >> >> 4) Technology in general will have moved ahead by massive leaps by 2021 (including our competitors). >> >> 5) If the *first* optimised JavaFX scene graph is not released until 2021, I genuinely fear that not only would "the ship have sailed" but, it would actually be way over the horizon and completely out of sight. >> >> Felix >> >>> On 22 Jul 2016, at 06:51, dalibor topic wrote: >>> >>> There is no JDK 10 Project in OpenJDK yet, so there has been no proposed schedule for it yet. >>> >>> cheers, >>> dalibor topic >>> >>>> On 21.07.2016 20:51, Felix Bembrick wrote: >>>> What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? >>>> >>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: >>>>> >>>>> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list....compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Felix Bembrick wrote: >>>>>> Well, I'm putting my hand up for this. >>>>>> >>>>>> Kevin, would you like to discuss this with me on or offline? >>>>>> >>>>>> Felix >>>>>> >>>>>> P.S. Thanks Markus for your insight! >>>>>> >>>>>> >>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>>>>>> >>>>>>> Yep. From felix.bembrick at gmail.com Thu Jul 21 21:57:20 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 07:57:20 +1000 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: <18D80187-8F06-457C-8758-C9C1B962A275@gmail.com> I agree that the original question has led to a discussion of a somewhat different nature and I accept that the benchmark itself may be problematic. But others have reported similar observation using different benchmarks. > On 22 Jul 2016, at 07:42, Steve Hannah wrote: > > I've just been a fly on the wall for this thread, but ... I think this > thread has gone off track a bit. Felix's original observation was that he > got the same benchmark results from two machines that should produce > different results because one is more powerful than the other in both CPU > and GPU). The talk of things that could be done to improve JavaFX > performance don't seem relevant to this. The real question is, why is a > slow computer performing as well as a fast computer? > > The answer is likely far simpler than the explanations proposed here. > Either there is a problem with the benchmark methodology, there is an > environment difference that isn't being accounted for (which is also a > methodology problem), or there is some mechanism that is throttling > performance. > > My hunch is that there is a problem with the benchmark. > > Steve > >> On Thu, Jul 21, 2016 at 2:33 PM, Herv? Girod wrote: >> >> I really don't understand all this. We use Java FX 8 in a graphic >> framework where we need high performance (prototyping Cockpit Display >> Systems with dynamic Maps and Head Up Displays), and we find that JavaFX >> performance is pretty good our use case. For example, Qt / QML performance >> is far worse in our POV, for no real additional simplicity of usage for big >> projects. We also used OpenGL before (used JOGL), but (at least for our own >> usage) what additional performance benefits we could maybe achieve were not >> worth the amount of work we would have needed to get them (if we had any). >> >> Herv? >> >> Sent from my iPad >> >>>> On 21 juil. 2016, at 23:09, Felix Bembrick >>> wrote: >>> >>> Yes, well I think this the problem: >>> >>> 1) Going on history, it would be a best case scenario for Java 10 to be >> released in 2020 (but more likely 2021). >>> >>> 2) With JavaFX, we are already "behind the game" (pun intended). >>> >>> 3) JavaFX itself has evolved much slower than its competitors. >>> >>> 4) Technology in general will have moved ahead by massive leaps by 2021 >> (including our competitors). >>> >>> 5) If the *first* optimised JavaFX scene graph is not released until >> 2021, I genuinely fear that not only would "the ship have sailed" but, it >> would actually be way over the horizon and completely out of sight. >>> >>> Felix >>> >>>> On 22 Jul 2016, at 06:51, dalibor topic >> wrote: >>>> >>>> There is no JDK 10 Project in OpenJDK yet, so there has been no >> proposed schedule for it yet. >>>> >>>> cheers, >>>> dalibor topic >>>> >>>>> On 21.07.2016 20:51, Felix Bembrick wrote: >>>>> What is a "ball park" figure (i.e. around the 6-9 month granularity if >> possible) for the the release date for JDK 10? >>>>> >>>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth >> wrote: >>>>>> >>>>>> Oh, I was agreeing with the analysis of what *would* need to be done. >> I am not saying that I think it *should* be done, given resources other >> priorities, etc. Having said that, as I mentioned in an earlier post a >> month or so ago, we will be collecting ideas for possible JDK 10 features >> once JDK 9 is finished. Perhaps this could go into the bucket of things to >> consider, but it isn't something I would think would be high on the >> list....compared to, say, WebGL, some sort of interop with native >> rendering, updated graphics pipelines (we're current stuck on DX 9 and GL >> 2), public API for UI Controls Behaviors, etc. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Felix Bembrick wrote: >>>>>>> Well, I'm putting my hand up for this. >>>>>>> >>>>>>> Kevin, would you like to discuss this with me on or offline? >>>>>>> >>>>>>> Felix >>>>>>> >>>>>>> P.S. Thanks Markus for your insight! >>>>>>> >>>>>>> >>>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >>>>>>>> >>>>>>>> Yep. > > > > -- > Steve Hannah > Web Lite Solutions Corp. From richard.bair at oracle.com Thu Jul 21 22:04:32 2016 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jul 2016 15:04:32 -0700 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: Hi Herve, Thanks for chiming in. I agree. From my own experience and benchmarking with other app-dev GUI toolkits, JavaFX performs very well for a very wide range of use cases. That being said, performance was always a passion of mine and I know there is more to be had. I like Kevin?s idea of updating to newer graphics pipelines too. Our first goal was to get broad coverage, so OpenGL ES 2 and DX 9 were the hot ticket. But getting onto the newer pipelines opens up a lot of additional possibilities. Richard > On Jul 21, 2016, at 2:33 PM, Herv? Girod wrote: > > I really don't understand all this. We use Java FX 8 in a graphic framework where we need high performance (prototyping Cockpit Display Systems with dynamic Maps and Head Up Displays), and we find that JavaFX performance is pretty good our use case. For example, Qt / QML performance is far worse in our POV, for no real additional simplicity of usage for big projects. We also used OpenGL before (used JOGL), but (at least for our own usage) what additional performance benefits we could maybe achieve were not worth the amount of work we would have needed to get them (if we had any). > > Herv? > > Sent from my iPad > >> On 21 juil. 2016, at 23:09, Felix Bembrick wrote: >> >> Yes, well I think this the problem: >> >> 1) Going on history, it would be a best case scenario for Java 10 to be released in 2020 (but more likely 2021). >> >> 2) With JavaFX, we are already "behind the game" (pun intended). >> >> 3) JavaFX itself has evolved much slower than its competitors. >> >> 4) Technology in general will have moved ahead by massive leaps by 2021 (including our competitors). >> >> 5) If the *first* optimised JavaFX scene graph is not released until 2021, I genuinely fear that not only would "the ship have sailed" but, it would actually be way over the horizon and completely out of sight. >> >> Felix >> >>> On 22 Jul 2016, at 06:51, dalibor topic wrote: >>> >>> There is no JDK 10 Project in OpenJDK yet, so there has been no proposed schedule for it yet. >>> >>> cheers, >>> dalibor topic >>> >>>> On 21.07.2016 20:51, Felix Bembrick wrote: >>>> What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? >>>> >>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: >>>>> >>>>> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list....compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Felix Bembrick wrote: >>>>>> Well, I'm putting my hand up for this. >>>>>> >>>>>> Kevin, would you like to discuss this with me on or offline? >>>>>> >>>>>> Felix >>>>>> >>>>>> P.S. Thanks Markus for your insight! >>>>>> >>>>>> >>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>>>>>> >>>>>>> Yep. From richard.bair at oracle.com Thu Jul 21 22:18:03 2016 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jul 2016 15:18:03 -0700 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: Hi Steve, It could be a benchmark problem, although I wouldn?t be surprised at all if the benchmark was exercising the platform in some way that was CPU limited. Assuming it is CPU limited (and not going multi-core), I think the problem really comes down to what Markus said: > The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). > > I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. > > If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) JavaFX was setup to be multi-threaded ? in fact there are always at least 2 threads ? the application / scene graph thread and the render thread. Going way, way back the goal was for multi-core computation/rasterizing on the NG side (Prism), but it didn?t get done for a variety of reasons. I couldn?t even say what kind of performance win/loss it would bring. I?m sure for some workloads it would be way better,but for many others it probably wouldn?t make any difference. A lot of other more pressing features had to be implemented first which would allow people to build apps at all on top of FX (like controls and effects and animations and so forth), and Prism has served us really well. There are a few places we could play with fork/join to see if we can get performance boosts, all of which would be tricky and have to be done very carefully because they are part of highly tuned code paths: Computing and applying CSS styles Computing bounds Computing layout Syncing state between scene graph and the render graph Updating state on the render graph (not sure much time is spent here?) Rasterizing (fonts, anti-aliased glyphs, etc) Some of these might be easier to try out than others. For example, using multiple threads at sync time should be safe, but probably won?t see much of any gain (as it takes a couple MS maximum to do this sync anyway). The more difficult one is probably making the rasterizing steps multi-threaded, but that would probably bring the biggest win. Computing bounds and layout and CSS in parallel would be very tricky, but if it could be done, would likely result in a nice speed boost for very large scenes (it would have no impact on rendering performance). Cheers! Richard From herve.girod at gmail.com Thu Jul 21 22:51:10 2016 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Fri, 22 Jul 2016 00:51:10 +0200 Subject: Scene graph performance In-Reply-To: <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> Message-ID: <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> We use a lot of Nodes which we update dynamically from another Client App. We also use JavaFX animations, but admittedly not a lot of them concurrently. In our case JavaFX animations are mainly linked to user interactions, a lot of what is dynamic in our apps is directly a result of real data changing in real time (such as track positions or plane attitude for example). But these changes can update a lot of Nodes concurrently, and not always simply by translating a parent container. For example if you have a digital Map with a lot of real world content (flight plan, waypoints, tracks, etc...), and the reference of the Map is the aircraft, you can't just move the whole map when the position of the aircraft changes, because you have to compute the coordinates of each element in the projection system. Herv? Sent from my iPhone > On Jul 21, 2016, at 23:55, Felix Bembrick wrote: > > Are you using nodes, transitions, effects and animations? Or are you using the Canvas node only? > >> On 22 Jul 2016, at 07:33, Herv? Girod wrote: >> >> I really don't understand all this. We use Java FX 8 in a graphic framework where we need high performance (prototyping Cockpit Display Systems with dynamic Maps and Head Up Displays), and we find that JavaFX performance is pretty good our use case. For example, Qt / QML performance is far worse in our POV, for no real additional simplicity of usage for big projects. We also used OpenGL before (used JOGL), but (at least for our own usage) what additional performance benefits we could maybe achieve were not worth the amount of work we would have needed to get them (if we had any). >> >> Herv? >> >> Sent from my iPad >> >>> On 21 juil. 2016, at 23:09, Felix Bembrick wrote: >>> >>> Yes, well I think this the problem: >>> >>> 1) Going on history, it would be a best case scenario for Java 10 to be released in 2020 (but more likely 2021). >>> >>> 2) With JavaFX, we are already "behind the game" (pun intended). >>> >>> 3) JavaFX itself has evolved much slower than its competitors. >>> >>> 4) Technology in general will have moved ahead by massive leaps by 2021 (including our competitors). >>> >>> 5) If the *first* optimised JavaFX scene graph is not released until 2021, I genuinely fear that not only would "the ship have sailed" but, it would actually be way over the horizon and completely out of sight. >>> >>> Felix >>> >>>> On 22 Jul 2016, at 06:51, dalibor topic wrote: >>>> >>>> There is no JDK 10 Project in OpenJDK yet, so there has been no proposed schedule for it yet. >>>> >>>> cheers, >>>> dalibor topic >>>> >>>>> On 21.07.2016 20:51, Felix Bembrick wrote: >>>>> What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10? >>>>> >>>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth wrote: >>>>>> >>>>>> Oh, I was agreeing with the analysis of what *would* need to be done. I am not saying that I think it *should* be done, given resources other priorities, etc. Having said that, as I mentioned in an earlier post a month or so ago, we will be collecting ideas for possible JDK 10 features once JDK 9 is finished. Perhaps this could go into the bucket of things to consider, but it isn't something I would think would be high on the list....compared to, say, WebGL, some sort of interop with native rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls Behaviors, etc. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Felix Bembrick wrote: >>>>>>> Well, I'm putting my hand up for this. >>>>>>> >>>>>>> Kevin, would you like to discuss this with me on or offline? >>>>>>> >>>>>>> Felix >>>>>>> >>>>>>> P.S. Thanks Markus for your insight! >>>>>>> >>>>>>> >>>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth wrote: >>>>>>>> >>>>>>>> Yep. From swpalmer at gmail.com Thu Jul 21 23:58:44 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 21 Jul 2016 19:58:44 -0400 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: > On Jul 21, 2016, at 6:18 PM, Richard Bair wrote: > > Hi Steve, > > It could be a benchmark problem, although I wouldn?t be surprised at all if the benchmark was exercising the platform in some way that was CPU limited. Assuming it is CPU limited (and not going multi-core), I think the problem really comes down to what Markus said: > >> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering). >> >> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >> >> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-) > > > JavaFX was setup to be multi-threaded ? in fact there are always at least 2 threads ? the application / scene graph thread and the render thread. Going way, way back the goal was for multi-core computation/rasterizing on the NG side (Prism), but it didn?t get done for a variety of reasons. I couldn?t even say what kind of performance win/loss it would bring. I?m sure for some workloads it would be way better,but for many others it probably wouldn?t make any difference. A lot of other more pressing features had to be implemented first which would allow people to build apps at all on top of FX (like controls and effects and animations and so forth), and Prism has served us really well. > > There are a few places we could play with fork/join to see if we can get performance boosts, all of which would be tricky and have to be done very carefully because they are part of highly tuned code paths: > Computing and applying CSS styles > Computing bounds > Computing layout ^ That. Computing layout and CSS is the most time consuming aspect of my application. I get pauses of more than a second or two in some cases for only a few thousand nodes. Recently JDK-8153329 was fixed which helped a little (e.g. 3-4 seconds to add a panel full of controls to my UI down to 2-3 seconds)? but it lead me to believe that these highly tuned code paths could use more tuning. Adding or remove nodes can be very expensive. I suspect changes in bounds can be very expensive. And it seems that Path drawing is expensive. That?s what would help my application the most. Cheers, Scott From felix.bembrick at gmail.com Fri Jul 22 00:35:24 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 10:35:24 +1000 Subject: Scene graph performance In-Reply-To: <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> Message-ID: I am willing to accept that perhaps FXMark is written so poorly that it does not permit JavaFX to perform as well as it could (possibly significantly so) on any particular platform. And I am indeed going through the code line-by-line and doing all manner of profiling to try to answer this question. But ultimately, the actual scene graph animations are *very* simple in structure. They simply comprise a number of nodes with parallel transitions built up from those selected in the list and the effects selected are applied to each node. It's basically just using transitions and effects exactly as documented and in the simplest way possible. Now, perhaps there are "other" less obvious ways of constructing parallel transitions and applying effects or special tweaks that I am not aware of. Perhaps there are ways of optimising the performance in a number of ways that I am not aware of. But, I have researched these issues on StackOverflow etc. (in fact the whole interwebs) and I have yet to find anything which I am obviously doing very wrongly or anything which can even marginally improve the performance (and by performance I refer to FPS and a visual interpretation of "smoothness"). Now the latter of those metrics is clearly not at all scientific, but FPS is very scientific. But, maybe it's a case that JavaFX *could* render at a faster frame rate but simply *doesn't need to* (as 60 FPS is really ample for most scenarios). However, when you apply certain transitions (especially rotation for example) and certain effects (especially Glow or Bloom), the entire animation of even just 25 nodes can literally "grind to a halt". Does that matter? Well, I guess it matters to some and not to others. Like most things. I guess my overriding concern is that it's not so much that the frame rate shows little "improvement" on my beast of a machine, but also that those especially slow transitions and effects show little or no improvement either. So, if for example, you wanted to build a game with JavaFX, you cannot use the scene graph and utilise nodes for every "entity" in the game and expect to get high performance "action". Your only realistic option is to write a 2D (or pseudo-3D) game using Canvas because the Canvas node performance is quite good. Which of course could raise the question, why even *have* a scene graph in JavaFX? When JavaFX was first "conceived", a different approach could have been to simply add the key missing components to Swing such as media and a decent browser control and improve the GPU utlisation of what was already an immediate mode (and hardware accelerated) toolkit (ala Canvas) and you would have much more quickly had effectively what we have right now: a toolkit primarily aimed at building business/forms applications (not games or advanced visualisations) with a few "fancy/sexy" bits thrown in, BUT you would also have a vastly larger collection of highly customisable controls that have stood the test of time and there would also be almost no learning curve. So, yes it's a different topic and a different thread and it may not be one that people want to discuss, but I would like to pose the question at some point: "What advantages does the scene graph give JavaFX over the immediate mode rendering of Swing?". Well, I guess one obvious thing is a declarative representation such a FXML but, then again, there have been a number of GUI builders for Swing for many years that basically do something very similar (only it's "optional"). At the moment, it's almost as though the scene graph is more of a hindrance (at least in terms of rendering performance) than a benefit. I personally would love to see the JavaFX scene graph be able to work just as OpenSceneGraph or the way scene graphs of advanced game engines work with greatly improved performance over what we have now. That however seems to be at least 4 years away from ever happening... Felix On 22 July 2016 at 08:51, Herv? Girod wrote: > We use a lot of Nodes which we update dynamically from another Client App. > We also use JavaFX animations, but admittedly not a lot of them > concurrently. > > In our case JavaFX animations are mainly linked to user interactions, a > lot of what is dynamic in our apps is directly a result of real data > changing in real time (such as track positions or plane attitude for > example). > > But these changes can update a lot of Nodes concurrently, and not always > simply by translating a parent container. For example if you have a digital > Map with a lot of real world content (flight plan, waypoints, tracks, > etc...), and the reference of the Map is the aircraft, you can't just move > the whole map when the position of the aircraft changes, because you have > to compute the coordinates of each element in the projection system. > > Herv? > > Sent from my iPhone > > > On Jul 21, 2016, at 23:55, Felix Bembrick > wrote: > > > > Are you using nodes, transitions, effects and animations? Or are you > using the Canvas node only? > > > >> On 22 Jul 2016, at 07:33, Herv? Girod wrote: > >> > >> I really don't understand all this. We use Java FX 8 in a graphic > framework where we need high performance (prototyping Cockpit Display > Systems with dynamic Maps and Head Up Displays), and we find that JavaFX > performance is pretty good our use case. For example, Qt / QML performance > is far worse in our POV, for no real additional simplicity of usage for big > projects. We also used OpenGL before (used JOGL), but (at least for our own > usage) what additional performance benefits we could maybe achieve were not > worth the amount of work we would have needed to get them (if we had any). > >> > >> Herv? > >> > >> Sent from my iPad > >> > >>> On 21 juil. 2016, at 23:09, Felix Bembrick > wrote: > >>> > >>> Yes, well I think this the problem: > >>> > >>> 1) Going on history, it would be a best case scenario for Java 10 to > be released in 2020 (but more likely 2021). > >>> > >>> 2) With JavaFX, we are already "behind the game" (pun intended). > >>> > >>> 3) JavaFX itself has evolved much slower than its competitors. > >>> > >>> 4) Technology in general will have moved ahead by massive leaps by > 2021 (including our competitors). > >>> > >>> 5) If the *first* optimised JavaFX scene graph is not released until > 2021, I genuinely fear that not only would "the ship have sailed" but, it > would actually be way over the horizon and completely out of sight. > >>> > >>> Felix > >>> > >>>> On 22 Jul 2016, at 06:51, dalibor topic > wrote: > >>>> > >>>> There is no JDK 10 Project in OpenJDK yet, so there has been no > proposed schedule for it yet. > >>>> > >>>> cheers, > >>>> dalibor topic > >>>> > >>>>> On 21.07.2016 20:51, Felix Bembrick wrote: > >>>>> What is a "ball park" figure (i.e. around the 6-9 month granularity > if possible) for the the release date for JDK 10? > >>>>> > >>>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >>>>>> > >>>>>> Oh, I was agreeing with the analysis of what *would* need to be > done. I am not saying that I think it *should* be done, given resources > other priorities, etc. Having said that, as I mentioned in an earlier post > a month or so ago, we will be collecting ideas for possible JDK 10 features > once JDK 9 is finished. Perhaps this could go into the bucket of things to > consider, but it isn't something I would think would be high on the > list....compared to, say, WebGL, some sort of interop with native > rendering, updated graphics pipelines (we're current stuck on DX 9 and GL > 2), public API for UI Controls Behaviors, etc. > >>>>>> > >>>>>> -- Kevin > >>>>>> > >>>>>> > >>>>>> Felix Bembrick wrote: > >>>>>>> Well, I'm putting my hand up for this. > >>>>>>> > >>>>>>> Kevin, would you like to discuss this with me on or offline? > >>>>>>> > >>>>>>> Felix > >>>>>>> > >>>>>>> P.S. Thanks Markus for your insight! > >>>>>>> > >>>>>>> > >>>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >>>>>>>> > >>>>>>>> Yep. > From vadim.pakhnushev at oracle.com Fri Jul 22 07:56:56 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 22 Jul 2016 10:56:56 +0300 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> Message-ID: Felix, For me it's very useful to track CPU/GPU usage while running a benchmark. Could it be that your very fast machine is limited by some synchronization issues and CPU/GPU is essentially idle while slower machine is running 100% CPU? Vadim On 22.07.2016 3:35, Felix Bembrick wrote: > I am willing to accept that perhaps FXMark is written so poorly that it > does not permit JavaFX to perform as well as it could (possibly > significantly so) on any particular platform. > > From felix.bembrick at gmail.com Fri Jul 22 08:15:13 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 18:15:13 +1000 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> Message-ID: <8A45B8CD-B8EA-4D27-BADE-3DE8C8B849D9@gmail.com> Hi Vadim, I am very open-minded about this. Anything is possible (including, as I mentioned, that I wrote FXMark very poorly). Can you help by detailing what tools you use to track CPU/GPU usage? I am sure finding out the exact nature of what is happening and what is causing it will help everyone. And, quite frankly, I actually hope that my coding *is* the problem and not JavaFX. Why? Because I can fix my coding. Blessings, Felix > On 22 Jul 2016, at 17:56, Vadim Pakhnushev wrote: > > Felix, > > For me it's very useful to track CPU/GPU usage while running a benchmark. > Could it be that your very fast machine is limited by some synchronization issues and CPU/GPU is essentially idle while slower machine is running 100% CPU? > > Vadim > >> On 22.07.2016 3:35, Felix Bembrick wrote: >> I am willing to accept that perhaps FXMark is written so poorly that it >> does not permit JavaFX to perform as well as it could (possibly >> significantly so) on any particular platform. >> >> > From vadim.pakhnushev at oracle.com Fri Jul 22 09:02:02 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 22 Jul 2016 12:02:02 +0300 Subject: Scene graph performance In-Reply-To: <8A45B8CD-B8EA-4D27-BADE-3DE8C8B849D9@gmail.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> <8A45B8CD-B8EA-4D27-BADE-3DE8C8B849D9@gmail.com> Message-ID: <3e8c3772-67c2-0f0f-fdd8-b7634a6cd1ff@oracle.com> On 22.07.2016 11:15, Felix Bembrick wrote: > Hi Vadim, > > I am very open-minded about this. Anything is possible (including, as I mentioned, that I wrote FXMark very poorly). > > Can you help by detailing what tools you use to track CPU/GPU usage? I personally use Process Hacker (I'm on Windows) and it's sitting in my tray all the time so I can see exactly what's happening. Process Explorer is another very popular task manager replacement with similar features. It can show you overall system load as well as individual process's performance graphs including GPU load. Vadim From felix.bembrick at gmail.com Fri Jul 22 10:10:51 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 20:10:51 +1000 Subject: Scene graph performance In-Reply-To: <3e8c3772-67c2-0f0f-fdd8-b7634a6cd1ff@oracle.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> <8A45B8CD-B8EA-4D27-BADE-3DE8C8B849D9@gmail.com> <3e8c3772-67c2-0f0f-fdd8-b7634a6cd1ff@oracle.com> Message-ID: > On 22 Jul 2016, at 19:02, Vadim Pakhnushev wrote: > >> On 22.07.2016 11:15, Felix Bembrick wrote: >> Hi Vadim, >> >> I am very open-minded about this. Anything is possible (including, as I mentioned, that I wrote FXMark very poorly). >> >> Can you help by detailing what tools you use to track CPU/GPU usage? > > I personally use Process Hacker (I'm on Windows) and it's sitting in my tray all the time so I can see exactly what's happening. > Process Explorer is another very popular task manager replacement with similar features. > It can show you overall system load as well as individual process's performance graphs including GPU load. > > Vadim From felix.bembrick at gmail.com Fri Jul 22 10:13:46 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 22 Jul 2016 20:13:46 +1000 Subject: Scene graph performance In-Reply-To: <3e8c3772-67c2-0f0f-fdd8-b7634a6cd1ff@oracle.com> References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> <0F187ED6-DF0C-46B7-9A30-09CA7095D916@gmail.com> <29C9F776-6134-4DA2-A6F3-C171CE3FAE7E@gmail.com> <8A45B8CD-B8EA-4D27-BADE-3DE8C8B849D9@gmail.com> <3e8c3772-67c2-0f0f-fdd8-b7634a6cd1ff@oracle.com> Message-ID: <63EC6343-4CF4-48F4-AB18-8895B7DEFFBF@gmail.com> Sorry, take 2. Thanks - that's very helpful. I have been concentrating on profiling the Java aspects of FXMark so this gives me more things to try. I will report back with my findings. Blessings, Felix > On 22 Jul 2016, at 19:02, Vadim Pakhnushev wrote: > >> On 22.07.2016 11:15, Felix Bembrick wrote: >> Hi Vadim, >> >> I am very open-minded about this. Anything is possible (including, as I mentioned, that I wrote FXMark very poorly). >> >> Can you help by detailing what tools you use to track CPU/GPU usage? > > I personally use Process Hacker (I'm on Windows) and it's sitting in my tray all the time so I can see exactly what's happening. > Process Explorer is another very popular task manager replacement with similar features. > It can show you overall system load as well as individual process's performance graphs including GPU load. > > Vadim From vadim.pakhnushev at oracle.com Fri Jul 22 12:36:35 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 22 Jul 2016 15:36:35 +0300 Subject: In(Sanity) Testing Mondays Message-ID: Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Please note that assignments were changed. Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Sat Jul 23 14:42:39 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 23 Jul 2016 07:42:39 -0700 Subject: CFV: New OpenJFX Committer: Andrey Rusakov Message-ID: <5793825F.2050606@oracle.com> I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. Andrey is a member of JavaFX SQE team at Oracle working on test development, who has contributed 19 changesets [5] to OpenJFX, at least 8 of which are significant. Votes are due by August 6, 2016. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks, -- Kevin [1] http://openjdk.java.net/census#arusakov [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer [5] List of changesets: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 From kevin.rushforth at oracle.com Sat Jul 23 14:43:39 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 23 Jul 2016 07:43:39 -0700 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: <5793829B.20108@oracle.com> Vote: YES Kevin Rushforth wrote: > I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. > > Andrey is a member of JavaFX SQE team at Oracle working on test > development, who has contributed 19 changesets [5] to OpenJFX, at > least 8 of which are significant. > > Votes are due by August 6, 2016. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#arusakov > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of changesets: > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 > From philip.race at oracle.com Sat Jul 23 15:33:00 2016 From: philip.race at oracle.com (Philip Race) Date: Sat, 23 Jul 2016 08:33:00 -0700 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: <57938E2C.5010801@oracle.com> Vote: yes -phil. From murali.billa at oracle.com Sat Jul 23 15:35:54 2016 From: murali.billa at oracle.com (Murali Billa) Date: Sat, 23 Jul 2016 08:35:54 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793829B.20108@oracle.com> References: <5793825F.2050606@oracle.com> <5793829B.20108@oracle.com> Message-ID: Vote: YES Kevin Rushforth wrote: > I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. > > Andrey is a member of JavaFX SQE team at Oracle working on test > development, who has contributed 19 changesets [5] to OpenJFX, at > least 8 of which are significant. > > Votes are due by August 6, 2016. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#arusakov > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of changesets: > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 > From guru.hb at oracle.com Mon Jul 25 04:04:36 2016 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 25 Jul 2016 09:34:36 +0530 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: References: <5793825F.2050606@oracle.com> <5793829B.20108@oracle.com> Message-ID: <7389ca80-5a56-83d1-5e9c-db5b7bed7bf2@oracle.com> Vote: YES On 23/7/16 9:05 PM, Murali Billa wrote: > Vote: YES > > Kevin Rushforth wrote: >> I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. >> >> Andrey is a member of JavaFX SQE team at Oracle working on test >> development, who has contributed 19 changesets [5] to OpenJFX, at >> least 8 of which are significant. >> >> Votes are due by August 6, 2016. >> >> Only current OpenJFX Committers [2] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this mailing >> list. >> >> For Lazy Consensus voting instructions, see [3]. Nomination to a >> project Committer is described in [4]. >> >> Thanks, >> >> -- Kevin >> >> [1] http://openjdk.java.net/census#arusakov >> >> [2] http://openjdk.java.net/census#openjfx >> >> [3] http://openjdk.java.net/bylaws#lazy-consensus >> >> [4] http://openjdk.java.net/projects#project-committer >> >> [5] List of changesets: >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 >> From jonathan.giles at oracle.com Mon Jul 25 04:06:24 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 25 Jul 2016 16:06:24 +1200 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: <6C4CB495-533D-4B46-A2A9-56EF11A7F5DA@oracle.com> Vote: yes -- Jonathan On 24 July 2016 02:42:39 GMT+12:00, Kevin Rushforth wrote: >I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. > >Andrey is a member of JavaFX SQE team at Oracle working on test >development, who has contributed 19 changesets [5] to OpenJFX, at least > >8 of which are significant. > >Votes are due by August 6, 2016. > >Only current OpenJFX Committers [2] are eligible to vote on this >nomination. Votes must be cast in the open by replying to this mailing >list. > >For Lazy Consensus voting instructions, see [3]. Nomination to a >project >Committer is described in [4]. > >Thanks, > >-- Kevin > >[1] http://openjdk.java.net/census#arusakov > >[2] http://openjdk.java.net/census#openjfx > >[3] http://openjdk.java.net/bylaws#lazy-consensus > >[4] http://openjdk.java.net/projects#project-committer > >[5] List of changesets: >http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e >http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 >http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf >http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 From guru.hb at oracle.com Mon Jul 25 04:18:13 2016 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 25 Jul 2016 09:48:13 +0530 Subject: Problem building WebView with latest 8u-dev and 9-dev In-Reply-To: <578EA83E.1060007@oracle.com> References: <578EA83E.1060007@oracle.com> Message-ID: <19b735ff-77ed-8d7a-6382-3cb6695ba191@oracle.com> webview-deps (version 1.3.1) has been uploaded to maven central. Please revert the work around suggested earlier. -- Guru On 20/7/16 3:52 AM, Kevin Rushforth wrote: > With the recently-integrated changes from 8u102, the WebKit build > requires a new version of the webview-deps bundle. This new bundle has > not yet been uploaded to maven central. Until we are able to do this, > you will not be able to build WebKit without applying a workaround. I > have filed a tracking bug in JBS for this: > > https://bugs.openjdk.java.net/browse/JDK-8161766 > > The workaround is to locally revert the change to the version number > of webview-deps in build.gradle. > > diff --git a/build.gradle b/build.gradle > --- a/build.gradle > +++ b/build.gradle > @@ -2717,7 +2717,7 @@ > IS_64 ? "${t.name}-amd64" : "${t.name}-i586" > dependencies { > webkit group: "com.sun.webkit", name: "webview-deps", > - version: "1.3.1", classifier: "$classifier", ext: > "zip" > + version: "1.3", classifier: "$classifier", ext: "zip" > } > > def webkitOutputDir = cygpath("$buildDir/${t.name}") > > > -- Kevin > From arunprasad.rajkumar at oracle.com Mon Jul 25 05:29:06 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 25 Jul 2016 10:59:06 +0530 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: Vote: YES On 7/23/2016 8:12 PM, Kevin Rushforth wrote: > I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. > > Andrey is a member of JavaFX SQE team at Oracle working on test > development, who has contributed 19 changesets [5] to OpenJFX, at > least 8 of which are significant. > > Votes are due by August 6, 2016. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#arusakov > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of changesets: > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 > From vadim.pakhnushev at oracle.com Mon Jul 25 08:19:36 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 25 Jul 2016 11:19:36 +0300 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: <937e89ce-d6ee-5518-a7c8-67605480a0b9@oracle.com> Vote: yes On 23.07.2016 17:42, Kevin Rushforth wrote: > I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. > > Andrey is a member of JavaFX SQE team at Oracle working on test > development, who has contributed 19 changesets [5] to OpenJFX, at > least 8 of which are significant. > > Votes are due by August 6, 2016. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#arusakov > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of changesets: > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 > From chris.bensen at oracle.com Mon Jul 25 14:30:20 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 25 Jul 2016 07:30:20 -0700 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: Vote: yes Chris > On Jul 23, 2016, at 7:42 AM, Kevin Rushforth wrote: > > I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. > > Andrey is a member of JavaFX SQE team at Oracle working on test development, who has contributed 19 changesets [5] to OpenJFX, at least 8 of which are significant. > > Votes are due by August 6, 2016. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#arusakov > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of changesets: > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 > From james.graham at oracle.com Mon Jul 25 20:19:51 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 25 Jul 2016 13:19:51 -0700 Subject: CFV: New OpenJFX Committer: Andrey Rusakov In-Reply-To: <5793825F.2050606@oracle.com> References: <5793825F.2050606@oracle.com> Message-ID: Vote: yes ...jim On 7/23/16 7:42 AM, Kevin Rushforth wrote: > I hereby nominate Andrey Rusakov [1] to OpenJFX Committer. > > Andrey is a member of JavaFX SQE team at Oracle working on test development, who has contributed 19 changesets [5] to > OpenJFX, at least 8 of which are significant. > > Votes are due by August 6, 2016. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#arusakov > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of changesets: > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08 > From chien.yang at oracle.com Mon Jul 25 22:58:44 2016 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 25 Jul 2016 15:58:44 -0700 Subject: CFV: New OpenJFX Committer: Ankit Srivastava In-Reply-To: <578E2D26.1010806@Oracle.com> References: <578E2D26.1010806@Oracle.com> Message-ID: <579699A4.4090601@oracle.com> Vote: YES On 7/19/16 6:37 AM, David Hill wrote: > > I hereby nominate Ankit Srivastava to OpenJFX Committer. > > Ankit Srivastava is part of the JavaFX team focusing on Web. > > A list of Ankit's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivastava at oracle.com > > http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava > > Votes are due by August 3th, 2016. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From johan.vos at gluonhq.com Tue Jul 26 11:30:51 2016 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 26 Jul 2016 11:30:51 +0000 Subject: Scene graph performance In-Reply-To: References: <00eb01d1e379$3f312b70$bd938250$@eu> <7B5B39FA-C6B4-4648-B8FC-3554E3CBF418@oracle.com> <579112ED.7070600@oracle.com> <834ED0C8-2E4B-4E82-A394-94C1C2625335@gmail.com> <57911795.2060201@oracle.com> <12A10154-18C7-4CBF-9787-0FA000D1F045@gmail.com> <323f553d-c886-4aef-ee87-b027c93a123d@oracle.com> <4D2B7B2F-1D28-44AA-8BCE-B7DC8D7D129F@gmail.com> Message-ID: Hi, I agree with most that has been said here, but I want to add a few things. I've seen a number of "performance issues" with JavaFX in customer projects. Most of them are simply due to the application doing things on the FX App Thread that shouldn't be done there. Apart from these obvious things, it is indeed mainly the CSS and layout processing that consumes most of the time. I spent lots of time working on mobile performance, and in that context the CPU limitation is even more pronounced, as the GPU on modern mobile devices is pretty good. I don't have enough different devices, but to give an idea about numbers: when running a typical app, the GPU load on my desktop is about the same as the GPU load on my Nexus 5, but the CPU load on the Nexus is 5-10 times higher than on desktop. I measure this by comparing numbers in the pulseLogger. Hence, on mobile the limitation that only a single thread can do the CSS/layout phase AND the rasterisation is really a bottleneck. However, there are many tricks that can make it better. Contrary to e.g. Android and iOS, the JavaFX API's still allow for lots of flexibility that can be very helpful, but that also can easily kill performance. Caching is one of those things. If you cache the right Node, you'll gain a lot. But if you cache a Node that often becomes dirty, you screw performance. There is no general solution for this, I believe. The way to address this is to create components that work for specific usecases (e.g. cache the content of a pane while animating, and don't cache it once it might change again). This is what we do in the Gluon Mobile components. Complex CSS and layout changes are CPU hungry as well. About the latter: be careful about bounds that vary (e.g. start with a negative offset) without any visual consequence, as this will increase the dirty region. Profiling is the most important thing to do when your application is slow. Find the bottleneck, fix it, go to the next bottleneck. Each application has its own bottlenecks, but with enough time, I really believe all applications can at least be improved. One of the great things about JavaFX is the decoupling between the API and the rendering pipeline. If someone writes a renderer that works completely different from the existing ones, that is fine. All applications should be able to run with this. One of the things I'm thinking about is to see if/how Vulkan would be a good alternative to OpenGL. But that would not speed up the single-threaded bottleneck, so I applaud all initiatives in that area (e.g. do some parallel CSS processing/) - Johan On Fri, Jul 22, 2016 at 2:09 AM Scott Palmer wrote: > > > On Jul 21, 2016, at 6:18 PM, Richard Bair > wrote: > > > > Hi Steve, > > > > It could be a benchmark problem, although I wouldn?t be surprised at all > if the benchmark was exercising the platform in some way that was CPU > limited. Assuming it is CPU limited (and not going multi-core), I think the > problem really comes down to what Markus said: > > > >> The limiting factor is the single-thread architecture of rather all > parts of JavaFX. The only real difference you see between machines is not > correlating with neither number of CPU cores nor GPU cores, but only with > CPU frequency, roughly spoken. Short term fixes will only provide little > improvement, by optimizing the critical execution path (i. e. produce hot > spot histogram using a profiler), for example improvement clipping, > caching, etc. Huge performance optimizations need an architectural change > within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to > use parallel execution in lots of places. Typical design patterns would be > parallel iterations, work-stealing executors, fibers (a.k.a cooperative > multi-threading, a.k.a CompletableFuture), and last but not least > partitioned rendering (a.k.a tiled rendering). > >> > >> I am pretty sure you can add a lot more ideas to the list and produce > great performance, scaling linearly with number of CPU cores / GPU cores, > but this somes at a cost: Risk to introduce hard to track bugs, and needed > manpower. > >> > >> If somebody has at least a lot of free spare time, I am pretty sure > Kevin could easily provide a huge set of work items in this area. :-) > > > > > > JavaFX was setup to be multi-threaded ? in fact there are always at > least 2 threads ? the application / scene graph thread and the render > thread. Going way, way back the goal was for multi-core > computation/rasterizing on the NG side (Prism), but it didn?t get done for > a variety of reasons. I couldn?t even say what kind of performance win/loss > it would bring. I?m sure for some workloads it would be way better,but for > many others it probably wouldn?t make any difference. A lot of other more > pressing features had to be implemented first which would allow people to > build apps at all on top of FX (like controls and effects and animations > and so forth), and Prism has served us really well. > > > > There are a few places we could play with fork/join to see if we can get > performance boosts, all of which would be tricky and have to be done very > carefully because they are part of highly tuned code paths: > > Computing and applying CSS styles > > Computing bounds > > Computing layout > > > ^ That. Computing layout and CSS is the most time consuming aspect of my > application. > I get pauses of more than a second or two in some cases for only a few > thousand nodes. > > Recently JDK-8153329 was fixed which helped a little (e.g. 3-4 seconds to > add a panel full of controls to my UI down to 2-3 seconds)? but it lead me > to believe that these highly tuned code paths could use more tuning. > > Adding or remove nodes can be very expensive. I suspect changes in bounds > can be very expensive. And it seems that Path drawing is expensive. > > That?s what would help my application the most. > > Cheers, > > Scott > > From semyon.sadetsky at oracle.com Tue Jul 26 17:34:53 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 26 Jul 2016 20:34:53 +0300 Subject: [9] Review Request for 8162551: SwingNode scaling doesn't work Message-ID: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8162551 webrev: http://cr.openjdk.java.net/~ssadetsky/8162551/webrev.00/ Upscaling is not needed to send coordinates to sun.swing.JLightweightFrame. --Semyon From kevin.rushforth at oracle.com Tue Jul 26 18:28:45 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Jul 2016 11:28:45 -0700 Subject: HEADS-UP: Massive directory renaming in openjfx/9-dev/rt planned for Monday, August 1 Message-ID: <5797ABDD.8090204@oracle.com> TO: All developers who build openjfx/9-dev As a heads-up, we are preparing to rename all directories under rt/modules this coming Monday, August 1 to address JDK-8161705 [1]. This is a step along the path to compiling with a newer, Jigsaw-compatible JDK as described in JDK-8161704 [2]. Dave will send out a review in the next day or so. The 12 directories under "rt/modules", containing a total of 22,283 files, will be renamed; this will be a *very* large changeset. Developers need to be aware of the following: 1) The repo will remain locked on Monday after our weekly sanity testing; the changeset for this fix will be the first thing pushed after integration to 9 master, and then the repo will be unlocked. 2) Any patches that you have in flight will need to be redone using the new file locations. We will provide a script to help with this. 3) Backports from 9-dev to 8u-dev will no longer import cleanly without modification due to the location changes. We will provide a script to help with this. Please let Dave or me know if there are any questions. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8161705 [2] https://bugs.openjdk.java.net/browse/JDK-8161704 From snfuchs at gmx.de Tue Jul 26 19:30:54 2016 From: snfuchs at gmx.de (Stefan Fuchs) Date: Tue, 26 Jul 2016 21:30:54 +0200 Subject: JDK-8153350 - JavaFX webstart with javaws.exe selects wrong toolkit (unnecessary relaunch) Message-ID: Hi, it may be unrelated to these relaunches, but I have been wondering for awhile, what the toolkit parameter in the ant element is supposed to do. see: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIAGCAFH At least in my tests changing the parameter had no effect on the generated jnlp file. - Stefan From david.dehaven at oracle.com Tue Jul 26 22:47:27 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 26 Jul 2016 15:47:27 -0700 Subject: JDK-8153350 - JavaFX webstart with javaws.exe selects wrong toolkit (unnecessary relaunch) In-Reply-To: References: Message-ID: <59DF37AB-B96D-48E7-9587-46887C14787B@oracle.com> > Hi, > > it may be unrelated to these relaunches, but I have been wondering for awhile, what the toolkit parameter in the ant element is supposed to do. > > see: > > https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIAGCAFH > > At least in my tests changing the parameter had no effect on the generated jnlp file. Good question.. maybe Chris can answer? -DrD- From kevin.rushforth at oracle.com Tue Jul 26 23:15:48 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Jul 2016 16:15:48 -0700 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <578A773D.2020503@oracle.com> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> <578A773D.2020503@oracle.com> Message-ID: <5797EF24.1060509@oracle.com> Picking this back up again, I have just added my comments to JBS issue. https://bugs.openjdk.java.net/browse/JDK-8088147 The comments are minor in scope, so I suspect it will be ready for final review after one more iteration. It will need one other reviewer, since I am sponsoring the change. Could someone else review this as well (maybe Alexander Z or Sergey)? -- Kevin Kevin Rushforth wrote: > I'm back, and given that the review will take some time anyway, I will > sponsor this once the review is complete. I see that Guru uploaded the > patch for you (thanks, Guru) so I can test it next week. > > -- Kevin > > > Alexander Nyssen wrote: >> It seems I was unsuccessful again. If somebody would be willing to >> sponsor this contribution while Kevin is away (or at least update the >> patch provided for JDK-8088147), I could mail the patch privately. >> >> Regards, >> Alexander >> >> >>> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen : >>> >>> It seems my attachment has again been ?consumed? by the list. Trying >>> again with an archive containing the patch file. >>> >>> Regards, >>> Alexander >>> >>> >>> >>>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen >>>> : >>>> >>>> Hi Kevin, all, >>>> attached please find a revised patch, where I have added the >>>> required export to PlatformImpl and have fixed the build script, so >>>> it does no longer break when being executed in jigsaw mode. >>>> As swt is no named module yet, I have disabled the JUnit test in >>>> jigsaw mode for now. We would probably have to set up swt as a >>>> named module to enable this, and would further have to make >>>> swt-debug.jar available as an automated module on its module path. >>>> But this is a different problem. >>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>> >>>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen >>>>> : >>>>> >>>>> Hi Kevin, >>>>> >>>>> >>>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth >>>>>> : >>>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> I attached the patch to the bug: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>>> >>>>>> If I build it and run the manual test in "legacy" mode, meaning >>>>>> run everything with 9+109 and the legacy jfxrt.jar file, then it >>>>>> runs and the cursor now changes. So this looks like a good >>>>>> starting point for a fix. >>>>>> >>>>> Fine. >>>>> >>>>> >>>>>> I tried building and running this in Jigsaw mode (building with >>>>>> jdk-9+109, but running the tests with a more recent JDK that >>>>>> includes modularization support), and noticed two problems right >>>>>> away that must be addressed: >>>>>> >>>>>> 1. The unit tests for SWT are missing some of the jigsaw test >>>>>> tasks so the build fails right away with an exception from gradle: >>>>>> >>>>>> >>>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>>>>> >>>>>> Wiring up SWT-based tests to our unit test harness will take a >>>>>> bit more work than what you have provided (not even counting the >>>>>> Mac issue, which could be handled by excluding the test on Mac). >>>>>> In the short term, relying on manual tests for this fix might be >>>>>> best. >>>>>> >>>>>> >>>>> I did not execute the tests in jigsaw mode yet, because other >>>>> tests failed in this mode, too (as indicated in an earlier >>>>> discussion). I will try to set things up in a virtual machine with >>>>> Windows and/or Linux so I can work on the Gradle tests without >>>>> having to deal with the Mac issue. The test harness will IMHO also >>>>> be required for other contributions, and it would of course be >>>>> fine if the automated test, I included in this patch, could be >>>>> executed as well. >>>>> >>>>> >>>>>> 2. You have introduced a dependency on a new internal package, >>>>>> com.sun.javafx.tk. If this is required in order to implement the >>>>>> fix, then you will need to add this package to the list of >>>>>> packages exports to javafx.swt in PlatformImpl; otherwise the >>>>>> following exception is thrown at runtime: >>>>>> >>>>>> Exception in thread "JavaFX Application Thread" >>>>>> java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors >>>>>> (in module javafx.swt) cannot access class >>>>>> com.sun.javafx.tk.Toolkit (in module javafx.graphics) because >>>>>> module javafx.graphics does not export com.sun.javafx.tk to >>>>>> module javafx.swt >>>>>> >>>>> This dependency is required unless there is public API to convert >>>>> a platform image (which is provided by the image cursor frame) to >>>>> an image. To me, Image image = >>>>> Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>>>> >>>>> seemed to be the way to go. I will thus add the respective export >>>>> in a revised patch. >>>>> >>>>> >>>>>> I won't have time to sponsor this change until the second half of >>>>>> July, but if others have time, the review can proceed and I'll >>>>>> pick it back up then if it is in good enough shape to run. >>>>>> >>>>> Especially setting up the SWT test harness will be kind of a >>>>> blocker for succeeding contributions, so it would be nice if >>>>> somebody could step in. >>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Kevin Rushforth wrote: >>>>>> >>>>>>> Hi Alexander, >>>>>>> >>>>>>> It looks like your patch was stripped out by the mailing list >>>>>>> server. >>>>>>> >>>>>>> Can you please send me the patch offline, as a zip file (so line >>>>>>> endings are preserved across different systems), and I will >>>>>>> unzip it and attach it to the bug report. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Alexander Nyssen wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have worked on a first contribution related to JDK-8088147. >>>>>>>> Attached please find a patch (created in extended Git format) >>>>>>>> that comprises the related changes. I have augmented the >>>>>>>> implementation of javafx.embed.swt.SWTCursors to handle the >>>>>>>> image cursor case. I further adjusted javafx.scene.Scene to >>>>>>>> update the cursor frame (in addition to the cursor) within >>>>>>>> synchronizeSceneProperties, so the cursor is not cleared in the >>>>>>>> first pulse succeeding the cursor property change. >>>>>>>> I have added an automated JUnit test (SWTCursorsTest) to the >>>>>>>> swt module, as well as a manual test (SWTImageCursorTest) to >>>>>>>> the systemTests module, with which the proper behavior can be >>>>>>>> verified. As no tests for SWT existed so far, I updated the >>>>>>>> build.gradle and gradle.properties files to support an SWT_TEST >>>>>>>> option, which allows to handle them similar to Swing tests. I >>>>>>>> also added the respective SWT dependency to the systemTests >>>>>>>> module. Please note that the JUnit test can currently not be >>>>>>>> executed using Gradle on the Mac (where the manual test >>>>>>>> currently is the single option; the automated tests are >>>>>>>> disabled), because there SWT-based tests require the >>>>>>>> -XstartOnFirstThread option that is currently not supported by >>>>>>>> the Gradle test runner (see >>>>>>>> https://issues.gradle.org/browse/GRADLE-3290 for details). We >>>>>>>> would have to use an ant task as a workaround. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexander >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> >> From alexander at nyssen.org Wed Jul 27 06:39:29 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 27 Jul 2016 08:39:29 +0200 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <5797EF24.1060509@oracle.com> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> <578A773D.2020503@oracle.com> <5797EF24.1060509@oracle.com> Message-ID: <165D08D8-ADF3-42AB-910F-3C56E100B88C@nyssen.org> Hi Kevin, all, attached please find an updated patch and my replies to Kevin?s comments at https://bugs.openjdk.java.net/browse/JDK-8088147: > build.gradle > > 1. In the following: > > + if (IS_JIGSAW_TEST) { > + enabled = false // FIXME: JIGSAW -- support this with modules > + logger.info("JIGSAW Testing disabled for swt") > > I verified that it correctly skips this in JIGSAW mode. Can you look into implementing this, though? It should not be difficult, and once we switch to only supporting Jigsaw mode the tests will never be run until this is done. If it does turn out to be too much work, then we could consider it as a follow-on. > As already indicated in an earlier mail I would prefer to treat building up JIGSAW tests as a follow-on. I have not gained much experience with JIGSAW yet, but I would be willing to support this as far as I can. The problem I currently see is that SWT is still an automatic module, and JIGSAW-based SWT tests would have to access code from the swt-debug.jar, which is as well an automatic module. AFAIK, we would have to turn SWT into a named module first in order to make swt-debug.jar available on its module path. That seems to be out of scope here and should probably be investigated in an own issue. > 2. Platform logic: > > + if(IS_MAC){ > + enabled = false > ... > + } > + if(IS_LINUX){ > > Normally we would handle this in the test itself by using assumeTrue and platform checks. In this case, though, since it applies to all SWT tests run on Mac (or Linux in case of the warning), this seems fine. > > Please fix the spacing to match our coding conventions, though. There should be a space after the 'if' and a space before the '{'. So: > > if (IS_MAC) { Ok. fine. We could even try to get SWT tests working on Mac by falling back to ant-based test execution here, but I would propose to handle this in a different issue as well (after all, this issue is about SWT image cursors and not about building up an SWT test harness). > modules/swt/src/main/java/javafx/embed/swt/SWTCursors.java > > 3. Spacing issues: > > + if(display == null){ > > Please add a space after '(' and before '}' > > > -} > +} > \ No newline at end of file > > Please restore the newline after the last line. Done. > SWTCursorsTest.java > > 4. Need a blank line before the package declaration: > > + */ > +package test.javafx.embed.swt; > + Done. > 5. Can you sort the imports alphabetically? I organized the imports and removed unused ones. It seems they are pretty much consistent with those of the other SWT classes. > 6. Since the test loops waiting on a latch, please add a 10 second timeout for the test: > > @Test(timeout=10000) > public void testImageCursor() throws Throwable { Done. > SWTImageCursorTest.java > > 7. The following can use a lambda (as the setOnMouseEntered already did). > > + rect.setOnMouseExited(new EventHandler() { > + @Override > + public void handle(MouseEvent event) { > + scene.setCursor(null); > + } > + }); Done. Kevin, thanks for picking this up. Regards, Alexander > Am 27.07.2016 um 01:15 schrieb Kevin Rushforth : > > Picking this back up again, I have just added my comments to JBS issue. > > https://bugs.openjdk.java.net/browse/JDK-8088147 > > The comments are minor in scope, so I suspect it will be ready for final review after one more iteration. It will need one other reviewer, since I am sponsoring the change. > > Could someone else review this as well (maybe Alexander Z or Sergey)? > > -- Kevin > > > Kevin Rushforth wrote: >> I'm back, and given that the review will take some time anyway, I will sponsor this once the review is complete. I see that Guru uploaded the patch for you (thanks, Guru) so I can test it next week. >> >> -- Kevin >> >> >> Alexander Nyssen wrote: >>> It seems I was unsuccessful again. If somebody would be willing to sponsor this contribution while Kevin is away (or at least update the patch provided for JDK-8088147), I could mail the patch privately. >>> >>> Regards, >>> Alexander >>> >>> >>>> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen : >>>> >>>> It seems my attachment has again been ?consumed? by the list. Trying again with an archive containing the patch file. >>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>> >>>>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen : >>>>> >>>>> Hi Kevin, all, >>>>> attached please find a revised patch, where I have added the required export to PlatformImpl and have fixed the build script, so it does no longer break when being executed in jigsaw mode. >>>>> As swt is no named module yet, I have disabled the JUnit test in jigsaw mode for now. We would probably have to set up swt as a named module to enable this, and would further have to make swt-debug.jar available as an automated module on its module path. But this is a different problem. >>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>> >>>>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen : >>>>>> >>>>>> Hi Kevin, >>>>>> >>>>>> >>>>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth : >>>>>>> >>>>>>> Hi Alexander, >>>>>>> >>>>>>> I attached the patch to the bug: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>>>> >>>>>>> If I build it and run the manual test in "legacy" mode, meaning run everything with 9+109 and the legacy jfxrt.jar file, then it runs and the cursor now changes. So this looks like a good starting point for a fix. >>>>>>> >>>>>> Fine. >>>>>> >>>>>> >>>>>>> I tried building and running this in Jigsaw mode (building with jdk-9+109, but running the tests with a more recent JDK that includes modularization support), and noticed two problems right away that must be addressed: >>>>>>> >>>>>>> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the build fails right away with an exception from gradle: >>>>>>> >>>>>>> >>>>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>>>>>> >>>>>>> Wiring up SWT-based tests to our unit test harness will take a bit more work than what you have provided (not even counting the Mac issue, which could be handled by excluding the test on Mac). In the short term, relying on manual tests for this fix might be best. >>>>>>> >>>>>>> >>>>>> I did not execute the tests in jigsaw mode yet, because other tests failed in this mode, too (as indicated in an earlier discussion). I will try to set things up in a virtual machine with Windows and/or Linux so I can work on the Gradle tests without having to deal with the Mac issue. The test harness will IMHO also be required for other contributions, and it would of course be fine if the automated test, I included in this patch, could be executed as well. >>>>>> >>>>>> >>>>>>> 2. You have introduced a dependency on a new internal package, com.sun.javafx.tk. If this is required in order to implement the fix, then you will need to add this package to the list of packages exports to javafx.swt in PlatformImpl; otherwise the following exception is thrown at runtime: >>>>>>> >>>>>>> Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.tk to module javafx.swt >>>>>>> >>>>>> This dependency is required unless there is public API to convert a platform image (which is provided by the image cursor frame) to an image. To me, Image image = Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>>>>> seemed to be the way to go. I will thus add the respective export in a revised patch. >>>>>> >>>>>> >>>>>>> I won't have time to sponsor this change until the second half of July, but if others have time, the review can proceed and I'll pick it back up then if it is in good enough shape to run. >>>>>>> >>>>>> Especially setting up the SWT test harness will be kind of a blocker for succeeding contributions, so it would be nice if somebody could step in. >>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Kevin Rushforth wrote: >>>>>>> >>>>>>>> Hi Alexander, >>>>>>>> >>>>>>>> It looks like your patch was stripped out by the mailing list server. >>>>>>>> >>>>>>>> Can you please send me the patch offline, as a zip file (so line endings are preserved across different systems), and I will unzip it and attach it to the bug report. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Alexander Nyssen wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have worked on a first contribution related to JDK-8088147. Attached please find a patch (created in extended Git format) that comprises the related changes. I have augmented the implementation of javafx.embed.swt.SWTCursors to handle the image cursor case. I further adjusted javafx.scene.Scene to update the cursor frame (in addition to the cursor) within synchronizeSceneProperties, so the cursor is not cleared in the first pulse succeeding the cursor property change. >>>>>>>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, as well as a manual test (SWTImageCursorTest) to the systemTests module, with which the proper behavior can be verified. As no tests for SWT existed so far, I updated the build.gradle and gradle.properties files to support an SWT_TEST option, which allows to handle them similar to Swing tests. I also added the respective SWT dependency to the systemTests module. Please note that the JUnit test can currently not be executed using Gradle on the Mac (where the manual test currently is the single option; the automated tests are disabled), because there SWT-based tests require the -XstartOnFirstThread option that is currently not supported by the Gradle test runner (see https://issues.gradle.org/browse/GRADLE-3290 for details). We would have to use an ant task as a workaround. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexander >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> From vadim.pakhnushev at oracle.com Wed Jul 27 11:00:46 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 27 Jul 2016 14:00:46 +0300 Subject: [9] Review request for 8089755: AreaChart area color change when series is removed Message-ID: <61b7b8d9-1adb-8be1-db92-626a690de83e@oracle.com> Jonathan, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8089755 http://cr.openjdk.java.net/~vadim/8089755/webrev.00/ Thanks, Vadim From chafiq.sarie at gmail.com Wed Jul 27 07:47:25 2016 From: chafiq.sarie at gmail.com (Sarie Chafiq) Date: Wed, 27 Jul 2016 09:47:25 +0200 Subject: issue number JDK-8095131 or issue number JDK-8089225 Message-ID: I have resolved the problem doing this : In my fxml file: The tab that should contains my tableView In java ScrollPane scrollPane= (ScrollPane) lookup("#"+myScrollPane); TabPane tabPane=(TabPane)scrollPane.getContent(); return tabPane; the result is that i can see the table with no row and with a horizontal scroll bar From kevin.rushforth at oracle.com Wed Jul 27 16:51:35 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Jul 2016 09:51:35 -0700 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <165D08D8-ADF3-42AB-910F-3C56E100B88C@nyssen.org> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> <578A773D.2020503@oracle.com> <5797EF24.1060509@oracle.com> <165D08D8-ADF3-42AB-910F-3C56E100B88C@nyssen.org> Message-ID: <5798E697.9060505@oracle.com> I attached the patch to the JBS issue. You have introduced a bug in the SWTCursorsTest.java JUnit test -- it appears to be an almost-exact copy of the manual test (including the now-incorrect class name). Also, you have inadvertently included an unwanted modification to .idea/modules.xml that should be reverted. Please send a new patch with the above two fixed. The rest looks fine to me, but I will wait to verify until you provide an update to fix the unit test. As for the JIGSAW mode tests, I agree that can/should be a follow-on effort. -- Kevin Alexander Nyssen wrote: > Hi Kevin, all, > > attached please find an updated patch and my replies to Kevin?s > comments at https://bugs.openjdk.java.net/browse/JDK-8088147: > >> build.gradle >> >> 1. In the following: >> >> + if (IS_JIGSAW_TEST) { >> + enabled = false // FIXME: JIGSAW -- support this with modules >> + logger.info ("JIGSAW Testing disabled for swt") >> >> I verified that it correctly skips this in JIGSAW mode. Can you look >> into implementing this, though? It should not be difficult, and once >> we switch to only supporting Jigsaw mode the tests will never be run >> until this is done. If it does turn out to be too much work, then we >> could consider it as a follow-on. >> > > As already indicated in an earlier mail I would prefer to treat > building up JIGSAW tests as a follow-on. I have not gained much > experience with JIGSAW yet, but I would be willing to support this as > far as I can. The problem I currently see is that SWT is still an > automatic module, and JIGSAW-based SWT tests would have to access code > from the swt-debug.jar, which is as well an automatic module. AFAIK, > we would have to turn SWT into a named module first in order to make > swt-debug.jar available on its module path. That seems to be out of > scope here and should probably be investigated in an own issue. > >> 2. Platform logic: >> >> + if(IS_MAC){ >> + enabled = false >> ... >> + } >> + if(IS_LINUX){ >> >> Normally we would handle this in the test itself by using assumeTrue >> and platform checks. In this case, though, since it applies to all >> SWT tests run on Mac (or Linux in case of the warning), this seems fine. >> >> Please fix the spacing to match our coding conventions, though. There >> should be a space after the 'if' and a space before the '{'. So: >> >> if (IS_MAC) { > > Ok. fine. We could even try to get SWT tests working on Mac by falling > back to ant-based test execution here, but I would propose to handle > this in a different issue as well (after all, this issue is about SWT > image cursors and not about building up an SWT test harness). > >> modules/swt/src/main/java/javafx/embed/swt/SWTCursors.java >> >> 3. Spacing issues: >> >> + if(display == null){ >> >> Please add a space after '(' and before '}' >> >> >> -} >> +} >> \ No newline at end of file >> >> Please restore the newline after the last line. > > Done. > >> SWTCursorsTest.java >> >> 4. Need a blank line before the package declaration: >> >> + */ >> +package test.javafx.embed.swt; >> + > > Done. > >> 5. Can you sort the imports alphabetically? > > I organized the imports and removed unused ones. It seems they are > pretty much consistent with those of the other SWT classes. > > >> 6. Since the test loops waiting on a latch, please add a 10 second >> timeout for the test: >> >> @Test(timeout=10000) >> public void testImageCursor() throws Throwable { > > Done. > >> SWTImageCursorTest.java >> >> 7. The following can use a lambda (as the setOnMouseEntered already >> did). >> >> + rect.setOnMouseExited(new EventHandler() { >> + @Override >> + public void handle(MouseEvent event) { >> + scene.setCursor(null); >> + } >> + }); > > Done. > > Kevin, thanks for picking this up. > > Regards, > Alexander > > = > ------------------------------------------------------------------------ > > >> Am 27.07.2016 um 01:15 schrieb Kevin Rushforth >> >: >> >> Picking this back up again, I have just added my comments to JBS issue. >> >> https://bugs.openjdk.java.net/browse/JDK-8088147 >> >> The comments are minor in scope, so I suspect it will be ready for >> final review after one more iteration. It will need one other >> reviewer, since I am sponsoring the change. >> >> Could someone else review this as well (maybe Alexander Z or Sergey)? >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >>> I'm back, and given that the review will take some time anyway, I >>> will sponsor this once the review is complete. I see that Guru >>> uploaded the patch for you (thanks, Guru) so I can test it next week. >>> >>> -- Kevin >>> >>> >>> Alexander Nyssen wrote: >>>> It seems I was unsuccessful again. If somebody would be willing to >>>> sponsor this contribution while Kevin is away (or at least update >>>> the patch provided for JDK-8088147), I could mail the patch privately. >>>> >>>> Regards, >>>> Alexander >>>> >>>> >>>>> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen >>>>> : >>>>> >>>>> It seems my attachment has again been ?consumed? by the list. >>>>> Trying again with an archive containing the patch file. >>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>> >>>>>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen >>>>>> : >>>>>> >>>>>> Hi Kevin, all, >>>>>> attached please find a revised patch, where I have added the >>>>>> required export to PlatformImpl and have fixed the build script, >>>>>> so it does no longer break when being executed in jigsaw mode. >>>>>> As swt is no named module yet, I have disabled the JUnit test in >>>>>> jigsaw mode for now. We would probably have to set up swt as a >>>>>> named module to enable this, and would further have to make >>>>>> swt-debug.jar available as an automated module on its module >>>>>> path. But this is a different problem. >>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>> >>>>>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen >>>>>>> : >>>>>>> >>>>>>> Hi Kevin, >>>>>>> >>>>>>> >>>>>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth >>>>>>>> : >>>>>>>> >>>>>>>> Hi Alexander, >>>>>>>> >>>>>>>> I attached the patch to the bug: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>>>>> >>>>>>>> If I build it and run the manual test in "legacy" mode, meaning >>>>>>>> run everything with 9+109 and the legacy jfxrt.jar file, then >>>>>>>> it runs and the cursor now changes. So this looks like a good >>>>>>>> starting point for a fix. >>>>>>>> >>>>>>> Fine. >>>>>>> >>>>>>> >>>>>>>> I tried building and running this in Jigsaw mode (building with >>>>>>>> jdk-9+109, but running the tests with a more recent JDK that >>>>>>>> includes modularization support), and noticed two problems >>>>>>>> right away that must be addressed: >>>>>>>> >>>>>>>> 1. The unit tests for SWT are missing some of the jigsaw test >>>>>>>> tasks so the build fails right away with an exception from gradle: >>>>>>>> >>>>>>>> >>>>>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>>>>>>> >>>>>>>> Wiring up SWT-based tests to our unit test harness will take a >>>>>>>> bit more work than what you have provided (not even counting >>>>>>>> the Mac issue, which could be handled by excluding the test on >>>>>>>> Mac). In the short term, relying on manual tests for this fix >>>>>>>> might be best. >>>>>>>> >>>>>>>> >>>>>>> I did not execute the tests in jigsaw mode yet, because other >>>>>>> tests failed in this mode, too (as indicated in an earlier >>>>>>> discussion). I will try to set things up in a virtual machine >>>>>>> with Windows and/or Linux so I can work on the Gradle tests >>>>>>> without having to deal with the Mac issue. The test harness will >>>>>>> IMHO also be required for other contributions, and it would of >>>>>>> course be fine if the automated test, I included in this patch, >>>>>>> could be executed as well. >>>>>>> >>>>>>> >>>>>>>> 2. You have introduced a dependency on a new internal package, >>>>>>>> com.sun.javafx.tk. If this is required in order to implement >>>>>>>> the fix, then you will need to add this package to the list of >>>>>>>> packages exports to javafx.swt in PlatformImpl; otherwise the >>>>>>>> following exception is thrown at runtime: >>>>>>>> >>>>>>>> Exception in thread "JavaFX Application Thread" >>>>>>>> java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors >>>>>>>> (in module javafx.swt) cannot access class >>>>>>>> com.sun.javafx.tk.Toolkit (in module javafx.graphics) because >>>>>>>> module javafx.graphics does not export com.sun.javafx.tk to >>>>>>>> module javafx.swt >>>>>>>> >>>>>>> This dependency is required unless there is public API to >>>>>>> convert a platform image (which is provided by the image cursor >>>>>>> frame) to an image. To me, Image image = >>>>>>> Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>>>>>> >>>>>>> seemed to be the way to go. I will thus add the respective >>>>>>> export in a revised patch. >>>>>>> >>>>>>> >>>>>>>> I won't have time to sponsor this change until the second half >>>>>>>> of July, but if others have time, the review can proceed and >>>>>>>> I'll pick it back up then if it is in good enough shape to run. >>>>>>>> >>>>>>> Especially setting up the SWT test harness will be kind of a >>>>>>> blocker for succeeding contributions, so it would be nice if >>>>>>> somebody could step in. >>>>>>> >>>>>>> Regards, >>>>>>> Alexander >>>>>>> >>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Kevin Rushforth wrote: >>>>>>>> >>>>>>>>> Hi Alexander, >>>>>>>>> >>>>>>>>> It looks like your patch was stripped out by the mailing list >>>>>>>>> server. >>>>>>>>> >>>>>>>>> Can you please send me the patch offline, as a zip file (so >>>>>>>>> line endings are preserved across different systems), and I >>>>>>>>> will unzip it and attach it to the bug report. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Alexander Nyssen wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have worked on a first contribution related to JDK-8088147. >>>>>>>>>> Attached please find a patch (created in extended Git format) >>>>>>>>>> that comprises the related changes. I have augmented the >>>>>>>>>> implementation of javafx.embed.swt.SWTCursors to handle the >>>>>>>>>> image cursor case. I further adjusted javafx.scene.Scene to >>>>>>>>>> update the cursor frame (in addition to the cursor) within >>>>>>>>>> synchronizeSceneProperties, so the cursor is not cleared in >>>>>>>>>> the first pulse succeeding the cursor property change. >>>>>>>>>> I have added an automated JUnit test (SWTCursorsTest) to the >>>>>>>>>> swt module, as well as a manual test (SWTImageCursorTest) to >>>>>>>>>> the systemTests module, with which the proper behavior can be >>>>>>>>>> verified. As no tests for SWT existed so far, I updated the >>>>>>>>>> build.gradle and gradle.properties files to support an >>>>>>>>>> SWT_TEST option, which allows to handle them similar to Swing >>>>>>>>>> tests. I also added the respective SWT dependency to the >>>>>>>>>> systemTests module. Please note that the JUnit test can >>>>>>>>>> currently not be executed using Gradle on the Mac (where the >>>>>>>>>> manual test currently is the single option; the automated >>>>>>>>>> tests are disabled), because there SWT-based tests require >>>>>>>>>> the -XstartOnFirstThread option that is currently not >>>>>>>>>> supported by the Gradle test runner (see >>>>>>>>>> https://issues.gradle.org/browse/GRADLE-3290 for details). We >>>>>>>>>> would have to use an ant task as a workaround. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Alexander >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> >>>> > > = From alexander at nyssen.org Wed Jul 27 18:27:23 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Wed, 27 Jul 2016 20:27:23 +0200 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <5798E697.9060505@oracle.com> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> <578A773D.2020503@oracle.com> <5797EF24.1060509@oracle.com> <165D08D8-ADF3-42AB-910F-3C56E100B88C@nyssen.org> <5798E697.9060505@oracle.com> Message-ID: Hi Kevin, sorry for that (I?m a Git guy and don?t feel very comfortable with Mercurial yet). I have attached a revised patch that (hopefully) provides the correct changes. Regards, Alexander > Am 27.07.2016 um 18:51 schrieb Kevin Rushforth : > > I attached the patch to the JBS issue. You have introduced a bug in the SWTCursorsTest.java JUnit test -- it appears to be an almost-exact copy of the manual test (including the now-incorrect class name). Also, you have inadvertently included an unwanted modification to .idea/modules.xml that should be reverted. Please send a new patch with the above two fixed. > > The rest looks fine to me, but I will wait to verify until you provide an update to fix the unit test. > > As for the JIGSAW mode tests, I agree that can/should be a follow-on effort. > > -- Kevin > > > Alexander Nyssen wrote: >> >> Hi Kevin, all, >> >> attached please find an updated patch and my replies to Kevin?s comments at https://bugs.openjdk.java.net/browse/JDK-8088147: >> >>> build.gradle >>> >>> 1. In the following: >>> >>> + if (IS_JIGSAW_TEST) { >>> + enabled = false // FIXME: JIGSAW -- support this with modules >>> + logger.info ("JIGSAW Testing disabled for swt") >>> >>> I verified that it correctly skips this in JIGSAW mode. Can you look into implementing this, though? It should not be difficult, and once we switch to only supporting Jigsaw mode the tests will never be run until this is done. If it does turn out to be too much work, then we could consider it as a follow-on. >>> >> >> As already indicated in an earlier mail I would prefer to treat building up JIGSAW tests as a follow-on. I have not gained much experience with JIGSAW yet, but I would be willing to support this as far as I can. The problem I currently see is that SWT is still an automatic module, and JIGSAW-based SWT tests would have to access code from the swt-debug.jar, which is as well an automatic module. AFAIK, we would have to turn SWT into a named module first in order to make swt-debug.jar available on its module path. That seems to be out of scope here and should probably be investigated in an own issue. >> >>> 2. Platform logic: >>> >>> + if(IS_MAC){ >>> + enabled = false >>> ... >>> + } >>> + if(IS_LINUX){ >>> >>> Normally we would handle this in the test itself by using assumeTrue and platform checks. In this case, though, since it applies to all SWT tests run on Mac (or Linux in case of the warning), this seems fine. >>> >>> Please fix the spacing to match our coding conventions, though. There should be a space after the 'if' and a space before the '{'. So: >>> >>> if (IS_MAC) { >> >> Ok. fine. We could even try to get SWT tests working on Mac by falling back to ant-based test execution here, but I would propose to handle this in a different issue as well (after all, this issue is about SWT image cursors and not about building up an SWT test harness). >> >>> modules/swt/src/main/java/javafx/embed/swt/SWTCursors.java >>> >>> 3. Spacing issues: >>> >>> + if(display == null){ >>> >>> Please add a space after '(' and before '}' >>> >>> >>> -} >>> +} >>> \ No newline at end of file >>> >>> Please restore the newline after the last line. >> >> Done. >> >>> SWTCursorsTest.java >>> >>> 4. Need a blank line before the package declaration: >>> >>> + */ >>> +package test.javafx.embed.swt; >>> + >> >> Done. >> >>> 5. Can you sort the imports alphabetically? >> >> I organized the imports and removed unused ones. It seems they are pretty much consistent with those of the other SWT classes. >> >> >>> 6. Since the test loops waiting on a latch, please add a 10 second timeout for the test: >>> >>> @Test(timeout=10000) >>> public void testImageCursor() throws Throwable { >> >> Done. >> >>> SWTImageCursorTest.java >>> >>> 7. The following can use a lambda (as the setOnMouseEntered already did). >>> >>> + rect.setOnMouseExited(new EventHandler() { >>> + @Override >>> + public void handle(MouseEvent event) { >>> + scene.setCursor(null); >>> + } >>> + }); >> >> Done. >> >> Kevin, thanks for picking this up. >> >> Regards, >> Alexander >> >> = >> >> >>> Am 27.07.2016 um 01:15 schrieb Kevin Rushforth >: >>> >>> Picking this back up again, I have just added my comments to JBS issue. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>> >>> The comments are minor in scope, so I suspect it will be ready for final review after one more iteration. It will need one other reviewer, since I am sponsoring the change. >>> >>> Could someone else review this as well (maybe Alexander Z or Sergey)? >>> >>> -- Kevin >>> >>> >>> Kevin Rushforth wrote: >>>> I'm back, and given that the review will take some time anyway, I will sponsor this once the review is complete. I see that Guru uploaded the patch for you (thanks, Guru) so I can test it next week. >>>> >>>> -- Kevin >>>> >>>> >>>> Alexander Nyssen wrote: >>>>> It seems I was unsuccessful again. If somebody would be willing to sponsor this contribution while Kevin is away (or at least update the patch provided for JDK-8088147), I could mail the patch privately. >>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>>> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen : >>>>>> >>>>>> It seems my attachment has again been ?consumed? by the list. Trying again with an archive containing the patch file. >>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>> >>>>>>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen : >>>>>>> >>>>>>> Hi Kevin, all, >>>>>>> attached please find a revised patch, where I have added the required export to PlatformImpl and have fixed the build script, so it does no longer break when being executed in jigsaw mode. >>>>>>> As swt is no named module yet, I have disabled the JUnit test in jigsaw mode for now. We would probably have to set up swt as a named module to enable this, and would further have to make swt-debug.jar available as an automated module on its module path. But this is a different problem. >>>>>>> >>>>>>> Regards, >>>>>>> Alexander >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen : >>>>>>>> >>>>>>>> Hi Kevin, >>>>>>>> >>>>>>>> >>>>>>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth : >>>>>>>>> >>>>>>>>> Hi Alexander, >>>>>>>>> >>>>>>>>> I attached the patch to the bug: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>>>>>> >>>>>>>>> If I build it and run the manual test in "legacy" mode, meaning run everything with 9+109 and the legacy jfxrt.jar file, then it runs and the cursor now changes. So this looks like a good starting point for a fix. >>>>>>>>> >>>>>>>> Fine. >>>>>>>> >>>>>>>> >>>>>>>>> I tried building and running this in Jigsaw mode (building with jdk-9+109, but running the tests with a more recent JDK that includes modularization support), and noticed two problems right away that must be addressed: >>>>>>>>> >>>>>>>>> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the build fails right away with an exception from gradle: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>>>>>>>> >>>>>>>>> Wiring up SWT-based tests to our unit test harness will take a bit more work than what you have provided (not even counting the Mac issue, which could be handled by excluding the test on Mac). In the short term, relying on manual tests for this fix might be best. >>>>>>>>> >>>>>>>>> >>>>>>>> I did not execute the tests in jigsaw mode yet, because other tests failed in this mode, too (as indicated in an earlier discussion). I will try to set things up in a virtual machine with Windows and/or Linux so I can work on the Gradle tests without having to deal with the Mac issue. The test harness will IMHO also be required for other contributions, and it would of course be fine if the automated test, I included in this patch, could be executed as well. >>>>>>>> >>>>>>>> >>>>>>>>> 2. You have introduced a dependency on a new internal package, com.sun.javafx.tk. If this is required in order to implement the fix, then you will need to add this package to the list of packages exports to javafx.swt in PlatformImpl; otherwise the following exception is thrown at runtime: >>>>>>>>> >>>>>>>>> Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.tk to module javafx.swt >>>>>>>>> >>>>>>>> This dependency is required unless there is public API to convert a platform image (which is provided by the image cursor frame) to an image. To me, Image image = Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>>>>>>> seemed to be the way to go. I will thus add the respective export in a revised patch. >>>>>>>> >>>>>>>> >>>>>>>>> I won't have time to sponsor this change until the second half of July, but if others have time, the review can proceed and I'll pick it back up then if it is in good enough shape to run. >>>>>>>>> >>>>>>>> Especially setting up the SWT test harness will be kind of a blocker for succeeding contributions, so it would be nice if somebody could step in. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexander >>>>>>>> >>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Kevin Rushforth wrote: >>>>>>>>> >>>>>>>>>> Hi Alexander, >>>>>>>>>> >>>>>>>>>> It looks like your patch was stripped out by the mailing list server. >>>>>>>>>> >>>>>>>>>> Can you please send me the patch offline, as a zip file (so line endings are preserved across different systems), and I will unzip it and attach it to the bug report. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Alexander Nyssen wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have worked on a first contribution related to JDK-8088147. Attached please find a patch (created in extended Git format) that comprises the related changes. I have augmented the implementation of javafx.embed.swt.SWTCursors to handle the image cursor case. I further adjusted javafx.scene.Scene to update the cursor frame (in addition to the cursor) within synchronizeSceneProperties, so the cursor is not cleared in the first pulse succeeding the cursor property change. >>>>>>>>>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, as well as a manual test (SWTImageCursorTest) to the systemTests module, with which the proper behavior can be verified. As no tests for SWT existed so far, I updated the build.gradle and gradle.properties files to support an SWT_TEST option, which allows to handle them similar to Swing tests. I also added the respective SWT dependency to the systemTests module. Please note that the JUnit test can currently not be executed using Gradle on the Mac (where the manual test currently is the single option; the automated tests are disabled), because there SWT-based tests require the -XstartOnFirstThread option that is currently not supported by the Gradle test runner (see https://issues.gradle.org/browse/GRADLE-3290 for details). We would have to use an ant task as a workaround. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Alexander >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>>> >> >> = From kevin.rushforth at oracle.com Wed Jul 27 21:21:21 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Jul 2016 14:21:21 -0700 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> <578A773D.2020503@oracle.com> <5797EF24.1060509@oracle.com> <165D08D8-ADF3-42AB-910F-3C56E100B88C@nyssen.org> <5798E697.9060505@oracle.com> Message-ID: <579925D1.4040101@oracle.com> I have reviewed and tested the latest patch on Mac, Windows, Linux. I added my approval to the JIRA. Now we just one more reviewer. Alexander Z or Sergey: are either of you able to review? -- Kevin Alexander Nyssen wrote: > Hi Kevin, > > sorry for that (I?m a Git guy and don?t feel very comfortable with > Mercurial yet). I have attached a revised patch that (hopefully) > provides the correct changes. > > Regards, > Alexander > > > = > ------------------------------------------------------------------------ > > >> Am 27.07.2016 um 18:51 schrieb Kevin Rushforth >> >: >> >> I attached the patch to the JBS issue. You have introduced a bug in >> the SWTCursorsTest.java JUnit test -- it appears to be an >> almost-exact copy of the manual test (including the now-incorrect >> class name). Also, you have inadvertently included an unwanted >> modification to .idea/modules.xml that should be reverted. Please >> send a new patch with the above two fixed. >> >> The rest looks fine to me, but I will wait to verify until you >> provide an update to fix the unit test. >> >> As for the JIGSAW mode tests, I agree that can/should be a follow-on >> effort. >> >> -- Kevin >> >> >> Alexander Nyssen wrote: >>> Hi Kevin, all, >>> >>> attached please find an updated patch and my replies to Kevin?s >>> comments at https://bugs.openjdk.java.net/browse/JDK-8088147: >>> >>>> build.gradle >>>> >>>> 1. In the following: >>>> >>>> + if (IS_JIGSAW_TEST) { >>>> + enabled = false // FIXME: JIGSAW -- support this with modules >>>> + logger.info ("JIGSAW Testing disabled for swt") >>>> >>>> I verified that it correctly skips this in JIGSAW mode. Can you >>>> look into implementing this, though? It should not be difficult, >>>> and once we switch to only supporting Jigsaw mode the tests will >>>> never be run until this is done. If it does turn out to be too much >>>> work, then we could consider it as a follow-on. >>>> >>> >>> As already indicated in an earlier mail I would prefer to treat >>> building up JIGSAW tests as a follow-on. I have not gained much >>> experience with JIGSAW yet, but I would be willing to support this >>> as far as I can. The problem I currently see is that SWT is still an >>> automatic module, and JIGSAW-based SWT tests would have to access >>> code from the swt-debug.jar, which is as well an automatic module. >>> AFAIK, we would have to turn SWT into a named module first in order >>> to make swt-debug.jar available on its module path. That seems to be >>> out of scope here and should probably be investigated in an own issue. >>> >>>> 2. Platform logic: >>>> >>>> + if(IS_MAC){ >>>> + enabled = false >>>> ... >>>> + } >>>> + if(IS_LINUX){ >>>> >>>> Normally we would handle this in the test itself by using >>>> assumeTrue and platform checks. In this case, though, since it >>>> applies to all SWT tests run on Mac (or Linux in case of the >>>> warning), this seems fine. >>>> >>>> Please fix the spacing to match our coding conventions, though. >>>> There should be a space after the 'if' and a space before the '{'. So: >>>> >>>> if (IS_MAC) { >>> >>> Ok. fine. We could even try to get SWT tests working on Mac by >>> falling back to ant-based test execution here, but I would propose >>> to handle this in a different issue as well (after all, this issue >>> is about SWT image cursors and not about building up an SWT test >>> harness). >>> >>>> modules/swt/src/main/java/javafx/embed/swt/SWTCursors.java >>>> >>>> 3. Spacing issues: >>>> >>>> + if(display == null){ >>>> >>>> Please add a space after '(' and before '}' >>>> >>>> >>>> -} >>>> +} >>>> \ No newline at end of file >>>> >>>> Please restore the newline after the last line. >>> >>> Done. >>> >>>> SWTCursorsTest.java >>>> >>>> 4. Need a blank line before the package declaration: >>>> >>>> + */ >>>> +package test.javafx.embed.swt; >>>> + >>> >>> Done. >>> >>>> 5. Can you sort the imports alphabetically? >>> >>> I organized the imports and removed unused ones. It seems they are >>> pretty much consistent with those of the other SWT classes. >>> >>> >>>> 6. Since the test loops waiting on a latch, please add a 10 second >>>> timeout for the test: >>>> >>>> @Test(timeout=10000) >>>> public void testImageCursor() throws Throwable { >>> >>> Done. >>> >>>> SWTImageCursorTest.java >>>> >>>> 7. The following can use a lambda (as the setOnMouseEntered already >>>> did). >>>> >>>> + rect.setOnMouseExited(new EventHandler() { >>>> + @Override >>>> + public void handle(MouseEvent event) { >>>> + scene.setCursor(null); >>>> + } >>>> + }); >>> >>> Done. >>> >>> Kevin, thanks for picking this up. >>> >>> Regards, >>> Alexander >>> >>> = >>> ------------------------------------------------------------------------ >>> >>> >>>> Am 27.07.2016 um 01:15 schrieb Kevin Rushforth >>>> >: >>>> >>>> Picking this back up again, I have just added my comments to JBS issue. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>> >>>> The comments are minor in scope, so I suspect it will be ready for >>>> final review after one more iteration. It will need one other >>>> reviewer, since I am sponsoring the change. >>>> >>>> Could someone else review this as well (maybe Alexander Z or Sergey)? >>>> >>>> -- Kevin >>>> >>>> >>>> Kevin Rushforth wrote: >>>>> I'm back, and given that the review will take some time anyway, I >>>>> will sponsor this once the review is complete. I see that Guru >>>>> uploaded the patch for you (thanks, Guru) so I can test it next week. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Alexander Nyssen wrote: >>>>>> It seems I was unsuccessful again. If somebody would be willing >>>>>> to sponsor this contribution while Kevin is away (or at least >>>>>> update the patch provided for JDK-8088147), I could mail the >>>>>> patch privately. >>>>>> >>>>>> Regards, >>>>>> Alexander >>>>>> >>>>>> >>>>>>> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen >>>>>>> : >>>>>>> >>>>>>> It seems my attachment has again been ?consumed? by the list. >>>>>>> Trying again with an archive containing the patch file. >>>>>>> >>>>>>> Regards, >>>>>>> Alexander >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen >>>>>>>> : >>>>>>>> >>>>>>>> Hi Kevin, all, >>>>>>>> attached please find a revised patch, where I have added the >>>>>>>> required export to PlatformImpl and have fixed the build >>>>>>>> script, so it does no longer break when being executed in >>>>>>>> jigsaw mode. >>>>>>>> As swt is no named module yet, I have disabled the JUnit test >>>>>>>> in jigsaw mode for now. We would probably have to set up swt as >>>>>>>> a named module to enable this, and would further have to make >>>>>>>> swt-debug.jar available as an automated module on its module >>>>>>>> path. But this is a different problem. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexander >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen >>>>>>>>> : >>>>>>>>> >>>>>>>>> Hi Kevin, >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> Hi Alexander, >>>>>>>>>> >>>>>>>>>> I attached the patch to the bug: >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>>>>>>> >>>>>>>>>> If I build it and run the manual test in "legacy" mode, >>>>>>>>>> meaning run everything with 9+109 and the legacy jfxrt.jar >>>>>>>>>> file, then it runs and the cursor now changes. So this looks >>>>>>>>>> like a good starting point for a fix. >>>>>>>>>> >>>>>>>>> Fine. >>>>>>>>> >>>>>>>>> >>>>>>>>>> I tried building and running this in Jigsaw mode (building >>>>>>>>>> with jdk-9+109, but running the tests with a more recent JDK >>>>>>>>>> that includes modularization support), and noticed two >>>>>>>>>> problems right away that must be addressed: >>>>>>>>>> >>>>>>>>>> 1. The unit tests for SWT are missing some of the jigsaw test >>>>>>>>>> tasks so the build fails right away with an exception from >>>>>>>>>> gradle: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>>>>>>>>> >>>>>>>>>> Wiring up SWT-based tests to our unit test harness will take >>>>>>>>>> a bit more work than what you have provided (not even >>>>>>>>>> counting the Mac issue, which could be handled by excluding >>>>>>>>>> the test on Mac). In the short term, relying on manual tests >>>>>>>>>> for this fix might be best. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I did not execute the tests in jigsaw mode yet, because other >>>>>>>>> tests failed in this mode, too (as indicated in an earlier >>>>>>>>> discussion). I will try to set things up in a virtual machine >>>>>>>>> with Windows and/or Linux so I can work on the Gradle tests >>>>>>>>> without having to deal with the Mac issue. The test harness >>>>>>>>> will IMHO also be required for other contributions, and it >>>>>>>>> would of course be fine if the automated test, I included in >>>>>>>>> this patch, could be executed as well. >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2. You have introduced a dependency on a new internal >>>>>>>>>> package, com.sun.javafx.tk. If this is required in order to >>>>>>>>>> implement the fix, then you will need to add this package to >>>>>>>>>> the list of packages exports to javafx.swt in PlatformImpl; >>>>>>>>>> otherwise the following exception is thrown at runtime: >>>>>>>>>> >>>>>>>>>> Exception in thread "JavaFX Application Thread" >>>>>>>>>> java.lang.IllegalAccessError: class >>>>>>>>>> javafx.embed.swt.SWTCursors (in module javafx.swt) cannot >>>>>>>>>> access class com.sun.javafx.tk.Toolkit (in module >>>>>>>>>> javafx.graphics) because module javafx.graphics does not >>>>>>>>>> export com.sun.javafx.tk to module javafx.swt >>>>>>>>>> >>>>>>>>> This dependency is required unless there is public API to >>>>>>>>> convert a platform image (which is provided by the image >>>>>>>>> cursor frame) to an image. To me, Image image = >>>>>>>>> Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>>>>>>>> >>>>>>>>> seemed to be the way to go. I will thus add the respective >>>>>>>>> export in a revised patch. >>>>>>>>> >>>>>>>>> >>>>>>>>>> I won't have time to sponsor this change until the second >>>>>>>>>> half of July, but if others have time, the review can proceed >>>>>>>>>> and I'll pick it back up then if it is in good enough shape >>>>>>>>>> to run. >>>>>>>>>> >>>>>>>>> Especially setting up the SWT test harness will be kind of a >>>>>>>>> blocker for succeeding contributions, so it would be nice if >>>>>>>>> somebody could step in. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexander >>>>>>>>> >>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Kevin Rushforth wrote: >>>>>>>>>> >>>>>>>>>>> Hi Alexander, >>>>>>>>>>> >>>>>>>>>>> It looks like your patch was stripped out by the mailing >>>>>>>>>>> list server. >>>>>>>>>>> >>>>>>>>>>> Can you please send me the patch offline, as a zip file (so >>>>>>>>>>> line endings are preserved across different systems), and I >>>>>>>>>>> will unzip it and attach it to the bug report. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Alexander Nyssen wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I have worked on a first contribution related to >>>>>>>>>>>> JDK-8088147. Attached please find a patch (created in >>>>>>>>>>>> extended Git format) that comprises the related changes. I >>>>>>>>>>>> have augmented the implementation of >>>>>>>>>>>> javafx.embed.swt.SWTCursors to handle the image cursor >>>>>>>>>>>> case. I further adjusted javafx.scene.Scene to update the >>>>>>>>>>>> cursor frame (in addition to the cursor) within >>>>>>>>>>>> synchronizeSceneProperties, so the cursor is not cleared in >>>>>>>>>>>> the first pulse succeeding the cursor property change. >>>>>>>>>>>> I have added an automated JUnit test (SWTCursorsTest) to >>>>>>>>>>>> the swt module, as well as a manual test >>>>>>>>>>>> (SWTImageCursorTest) to the systemTests module, with which >>>>>>>>>>>> the proper behavior can be verified. As no tests for SWT >>>>>>>>>>>> existed so far, I updated the build.gradle and >>>>>>>>>>>> gradle.properties files to support an SWT_TEST option, >>>>>>>>>>>> which allows to handle them similar to Swing tests. I also >>>>>>>>>>>> added the respective SWT dependency to the systemTests >>>>>>>>>>>> module. Please note that the JUnit test can currently not >>>>>>>>>>>> be executed using Gradle on the Mac (where the manual test >>>>>>>>>>>> currently is the single option; the automated tests are >>>>>>>>>>>> disabled), because there SWT-based tests require the >>>>>>>>>>>> -XstartOnFirstThread option that is currently not supported >>>>>>>>>>>> by the Gradle test runner (see >>>>>>>>>>>> https://issues.gradle.org/browse/GRADLE-3290 for details). >>>>>>>>>>>> We would have to use an ant task as a workaround. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Alexander >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>>>> >>> >>> = > > = From alexander.zvegintsev at oracle.com Wed Jul 27 22:06:07 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 28 Jul 2016 01:06:07 +0300 Subject: [PATCH] 8088147: FXCanvas: implement custom cursors (revised) In-Reply-To: <579925D1.4040101@oracle.com> References: <576C0A67.4040402@oracle.com> <577457BF.3050206@oracle.com> <1FF51596-5F77-4679-A37D-FC1CC383DA11@nyssen.org> <865DB4BF-A4A1-49B4-9B4E-07C47EE719E2@nyssen.org> <8C1A93D6-8BAF-4635-B2A3-7C4532F357AD@nyssen.org> <578A773D.2020503@oracle.com> <5797EF24.1060509@oracle.com> <165D08D8-ADF3-42AB-910F-3C56E100B88C@nyssen.org> <5798E697.9060505@oracle.com> <579925D1.4040101@oracle.com> Message-ID: Looks good to me too. -- Thanks, Alexander. On 28.07.2016 0:21, Kevin Rushforth wrote: > I have reviewed and tested the latest patch on Mac, Windows, Linux. I > added my approval to the JIRA. > > Now we just one more reviewer. > > Alexander Z or Sergey: are either of you able to review? > > -- Kevin > > > Alexander Nyssen wrote: >> Hi Kevin, >> >> sorry for that (I?m a Git guy and don?t feel very comfortable with >> Mercurial yet). I have attached a revised patch that (hopefully) >> provides the correct changes. >> >> Regards, >> Alexander >> >> >> = >> ------------------------------------------------------------------------ >> >> >>> Am 27.07.2016 um 18:51 schrieb Kevin Rushforth >>> >: >>> >>> I attached the patch to the JBS issue. You have introduced a bug in >>> the SWTCursorsTest.java JUnit test -- it appears to be an >>> almost-exact copy of the manual test (including the now-incorrect >>> class name). Also, you have inadvertently included an unwanted >>> modification to .idea/modules.xml that should be reverted. Please >>> send a new patch with the above two fixed. >>> >>> The rest looks fine to me, but I will wait to verify until you >>> provide an update to fix the unit test. >>> >>> As for the JIGSAW mode tests, I agree that can/should be a follow-on >>> effort. >>> >>> -- Kevin >>> >>> >>> Alexander Nyssen wrote: >>>> Hi Kevin, all, >>>> >>>> attached please find an updated patch and my replies to Kevin?s >>>> comments at https://bugs.openjdk.java.net/browse/JDK-8088147: >>>> >>>>> build.gradle >>>>> >>>>> 1. In the following: >>>>> >>>>> + if (IS_JIGSAW_TEST) { >>>>> + enabled = false // FIXME: JIGSAW -- support this with modules >>>>> + logger.info ("JIGSAW Testing disabled for >>>>> swt") >>>>> >>>>> I verified that it correctly skips this in JIGSAW mode. Can you >>>>> look into implementing this, though? It should not be difficult, >>>>> and once we switch to only supporting Jigsaw mode the tests will >>>>> never be run until this is done. If it does turn out to be too >>>>> much work, then we could consider it as a follow-on. >>>>> >>>> >>>> As already indicated in an earlier mail I would prefer to treat >>>> building up JIGSAW tests as a follow-on. I have not gained much >>>> experience with JIGSAW yet, but I would be willing to support this >>>> as far as I can. The problem I currently see is that SWT is still >>>> an automatic module, and JIGSAW-based SWT tests would have to >>>> access code from the swt-debug.jar, which is as well an automatic >>>> module. AFAIK, we would have to turn SWT into a named module first >>>> in order to make swt-debug.jar available on its module path. That >>>> seems to be out of scope here and should probably be investigated >>>> in an own issue. >>>> >>>>> 2. Platform logic: >>>>> >>>>> + if(IS_MAC){ >>>>> + enabled = false >>>>> ... >>>>> + } >>>>> + if(IS_LINUX){ >>>>> >>>>> Normally we would handle this in the test itself by using >>>>> assumeTrue and platform checks. In this case, though, since it >>>>> applies to all SWT tests run on Mac (or Linux in case of the >>>>> warning), this seems fine. >>>>> >>>>> Please fix the spacing to match our coding conventions, though. >>>>> There should be a space after the 'if' and a space before the '{'. >>>>> So: >>>>> >>>>> if (IS_MAC) { >>>> >>>> Ok. fine. We could even try to get SWT tests working on Mac by >>>> falling back to ant-based test execution here, but I would propose >>>> to handle this in a different issue as well (after all, this issue >>>> is about SWT image cursors and not about building up an SWT test >>>> harness). >>>> >>>>> modules/swt/src/main/java/javafx/embed/swt/SWTCursors.java >>>>> >>>>> 3. Spacing issues: >>>>> >>>>> + if(display == null){ >>>>> >>>>> Please add a space after '(' and before '}' >>>>> >>>>> >>>>> -} >>>>> +} >>>>> \ No newline at end of file >>>>> >>>>> Please restore the newline after the last line. >>>> >>>> Done. >>>> >>>>> SWTCursorsTest.java >>>>> >>>>> 4. Need a blank line before the package declaration: >>>>> >>>>> + */ >>>>> +package test.javafx.embed.swt; >>>>> + >>>> >>>> Done. >>>> >>>>> 5. Can you sort the imports alphabetically? >>>> >>>> I organized the imports and removed unused ones. It seems they are >>>> pretty much consistent with those of the other SWT classes. >>>> >>>> >>>>> 6. Since the test loops waiting on a latch, please add a 10 second >>>>> timeout for the test: >>>>> >>>>> @Test(timeout=10000) >>>>> public void testImageCursor() throws Throwable { >>>> >>>> Done. >>>> >>>>> SWTImageCursorTest.java >>>>> >>>>> 7. The following can use a lambda (as the setOnMouseEntered >>>>> already did). >>>>> >>>>> + rect.setOnMouseExited(new EventHandler() { >>>>> + @Override >>>>> + public void handle(MouseEvent event) { >>>>> + scene.setCursor(null); >>>>> + } >>>>> + }); >>>> >>>> Done. >>>> >>>> Kevin, thanks for picking this up. >>>> >>>> Regards, >>>> Alexander >>>> >>>> = >>>> ------------------------------------------------------------------------ >>>> >>>> >>>>> Am 27.07.2016 um 01:15 schrieb Kevin Rushforth >>>>> >: >>>>> >>>>> Picking this back up again, I have just added my comments to JBS >>>>> issue. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>> >>>>> The comments are minor in scope, so I suspect it will be ready for >>>>> final review after one more iteration. It will need one other >>>>> reviewer, since I am sponsoring the change. >>>>> >>>>> Could someone else review this as well (maybe Alexander Z or Sergey)? >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Kevin Rushforth wrote: >>>>>> I'm back, and given that the review will take some time anyway, I >>>>>> will sponsor this once the review is complete. I see that Guru >>>>>> uploaded the patch for you (thanks, Guru) so I can test it next week. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Alexander Nyssen wrote: >>>>>>> It seems I was unsuccessful again. If somebody would be willing >>>>>>> to sponsor this contribution while Kevin is away (or at least >>>>>>> update the patch provided for JDK-8088147), I could mail the >>>>>>> patch privately. >>>>>>> >>>>>>> Regards, >>>>>>> Alexander >>>>>>> >>>>>>> >>>>>>>> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen >>>>>>>> : >>>>>>>> >>>>>>>> It seems my attachment has again been ?consumed? by the list. >>>>>>>> Trying again with an archive containing the patch file. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexander >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen >>>>>>>>> : >>>>>>>>> >>>>>>>>> Hi Kevin, all, >>>>>>>>> attached please find a revised patch, where I have added the >>>>>>>>> required export to PlatformImpl and have fixed the build >>>>>>>>> script, so it does no longer break when being executed in >>>>>>>>> jigsaw mode. >>>>>>>>> As swt is no named module yet, I have disabled the JUnit test >>>>>>>>> in jigsaw mode for now. We would probably have to set up swt >>>>>>>>> as a named module to enable this, and would further have to >>>>>>>>> make swt-debug.jar available as an automated module on its >>>>>>>>> module path. But this is a different problem. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexander >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> Hi Kevin, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> Hi Alexander, >>>>>>>>>>> >>>>>>>>>>> I attached the patch to the bug: >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>>>>>>>>>> >>>>>>>>>>> If I build it and run the manual test in "legacy" mode, >>>>>>>>>>> meaning run everything with 9+109 and the legacy jfxrt.jar >>>>>>>>>>> file, then it runs and the cursor now changes. So this looks >>>>>>>>>>> like a good starting point for a fix. >>>>>>>>>>> >>>>>>>>>> Fine. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I tried building and running this in Jigsaw mode (building >>>>>>>>>>> with jdk-9+109, but running the tests with a more recent JDK >>>>>>>>>>> that includes modularization support), and noticed two >>>>>>>>>>> problems right away that must be addressed: >>>>>>>>>>> >>>>>>>>>>> 1. The unit tests for SWT are missing some of the jigsaw >>>>>>>>>>> test tasks so the build fails right away with an exception >>>>>>>>>>> from gradle: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>>>>>>>>>>> >>>>>>>>>>> Wiring up SWT-based tests to our unit test harness will take >>>>>>>>>>> a bit more work than what you have provided (not even >>>>>>>>>>> counting the Mac issue, which could be handled by excluding >>>>>>>>>>> the test on Mac). In the short term, relying on manual tests >>>>>>>>>>> for this fix might be best. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I did not execute the tests in jigsaw mode yet, because other >>>>>>>>>> tests failed in this mode, too (as indicated in an earlier >>>>>>>>>> discussion). I will try to set things up in a virtual machine >>>>>>>>>> with Windows and/or Linux so I can work on the Gradle tests >>>>>>>>>> without having to deal with the Mac issue. The test harness >>>>>>>>>> will IMHO also be required for other contributions, and it >>>>>>>>>> would of course be fine if the automated test, I included in >>>>>>>>>> this patch, could be executed as well. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2. You have introduced a dependency on a new internal >>>>>>>>>>> package, com.sun.javafx.tk. If this is required in order to >>>>>>>>>>> implement the fix, then you will need to add this package to >>>>>>>>>>> the list of packages exports to javafx.swt in PlatformImpl; >>>>>>>>>>> otherwise the following exception is thrown at runtime: >>>>>>>>>>> >>>>>>>>>>> Exception in thread "JavaFX Application Thread" >>>>>>>>>>> java.lang.IllegalAccessError: class >>>>>>>>>>> javafx.embed.swt.SWTCursors (in module javafx.swt) cannot >>>>>>>>>>> access class com.sun.javafx.tk.Toolkit (in module >>>>>>>>>>> javafx.graphics) because module javafx.graphics does not >>>>>>>>>>> export com.sun.javafx.tk to module javafx.swt >>>>>>>>>>> >>>>>>>>>> This dependency is required unless there is public API to >>>>>>>>>> convert a platform image (which is provided by the image >>>>>>>>>> cursor frame) to an image. To me, Image image = >>>>>>>>>> Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >>>>>>>>>> >>>>>>>>>> seemed to be the way to go. I will thus add the respective >>>>>>>>>> export in a revised patch. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I won't have time to sponsor this change until the second >>>>>>>>>>> half of July, but if others have time, the review can >>>>>>>>>>> proceed and I'll pick it back up then if it is in good >>>>>>>>>>> enough shape to run. >>>>>>>>>>> >>>>>>>>>> Especially setting up the SWT test harness will be kind of a >>>>>>>>>> blocker for succeeding contributions, so it would be nice if >>>>>>>>>> somebody could step in. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Alexander >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Kevin Rushforth wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>> >>>>>>>>>>>> It looks like your patch was stripped out by the mailing >>>>>>>>>>>> list server. >>>>>>>>>>>> >>>>>>>>>>>> Can you please send me the patch offline, as a zip file (so >>>>>>>>>>>> line endings are preserved across different systems), and I >>>>>>>>>>>> will unzip it and attach it to the bug report. >>>>>>>>>>>> >>>>>>>>>>>> -- Kevin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Alexander Nyssen wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I have worked on a first contribution related to >>>>>>>>>>>>> JDK-8088147. Attached please find a patch (created in >>>>>>>>>>>>> extended Git format) that comprises the related changes. I >>>>>>>>>>>>> have augmented the implementation of >>>>>>>>>>>>> javafx.embed.swt.SWTCursors to handle the image cursor >>>>>>>>>>>>> case. I further adjusted javafx.scene.Scene to update the >>>>>>>>>>>>> cursor frame (in addition to the cursor) within >>>>>>>>>>>>> synchronizeSceneProperties, so the cursor is not cleared >>>>>>>>>>>>> in the first pulse succeeding the cursor property change. >>>>>>>>>>>>> I have added an automated JUnit test (SWTCursorsTest) to >>>>>>>>>>>>> the swt module, as well as a manual test >>>>>>>>>>>>> (SWTImageCursorTest) to the systemTests module, with which >>>>>>>>>>>>> the proper behavior can be verified. As no tests for SWT >>>>>>>>>>>>> existed so far, I updated the build.gradle and >>>>>>>>>>>>> gradle.properties files to support an SWT_TEST option, >>>>>>>>>>>>> which allows to handle them similar to Swing tests. I also >>>>>>>>>>>>> added the respective SWT dependency to the systemTests >>>>>>>>>>>>> module. Please note that the JUnit test can currently not >>>>>>>>>>>>> be executed using Gradle on the Mac (where the manual test >>>>>>>>>>>>> currently is the single option; the automated tests are >>>>>>>>>>>>> disabled), because there SWT-based tests require the >>>>>>>>>>>>> -XstartOnFirstThread option that is currently not >>>>>>>>>>>>> supported by the Gradle test runner (see >>>>>>>>>>>>> https://issues.gradle.org/browse/GRADLE-3290 for details). >>>>>>>>>>>>> We would have to use an ant task as a workaround. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Alexander >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>> >>>> >>>> = >> >> = From David.Hill at Oracle.com Wed Jul 27 23:00:14 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 27 Jul 2016 19:00:14 -0400 Subject: review: Rename directories under modules to exactly match the module names Message-ID: <57993CFE.30607@Oracle.com> This is a biggie.... and is presented a bit not traditionally. In short, we need to rename modules/*/ to match the new JDK9 module names - javafx.* (with a few exceptions). For your review - a webrev of the actual changes needed in files to support this change. And... the script that will be used to 'hg mv' the hierarchies. This operation generates a HUGE diff that is not very informative for reviewers. This rename operation has been tested by myself, Kevin, Vadim, Chien and our Hudson server in test builds. jbs: https://bugs.openjdk.java.net/browse/JDK-8161705 webrev: http://cr.openjdk.java.net/~ddhill/8161705 rename script: http://cr.openjdk.java.net/~ddhill/8161705/module_rename -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From alexander at nyssen.org Thu Jul 28 15:06:54 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Thu, 28 Jul 2016 17:06:54 +0200 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. Message-ID: Hi Kevin, all, attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. - Ensured SWT tests are executed using GTK2 on Linux. I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. Regards, Alexander From philip.race at oracle.com Thu Jul 28 15:13:24 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 Jul 2016 08:13:24 -0700 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: References: Message-ID: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> The mailing list rejects attachments so we got nothing. -phil. On 7/28/2016 8:06 AM, Alexander Nyssen wrote: > Hi Kevin, all, > > attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: > > - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. > - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. > - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). > - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. > - Ensured SWT tests are executed using GTK2 on Linux. > > I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. > > Regards, > Alexander > From kevin.rushforth at oracle.com Thu Jul 28 15:22:03 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 28 Jul 2016 08:22:03 -0700 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> Message-ID: <579A231B.8030009@oracle.com> I got the attachment, since Alexander also CCed me directly. I will attach it shortly. I do have two comments on this: 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html [2] http://openjdk.java.net/projects/jdk9/fc-extension-process [3] https://bugs.openjdk.java.net/browse/JDK-8145568 Phil Race wrote: > The mailing list rejects attachments so we got nothing. > > -phil. > > On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >> Hi Kevin, all, >> >> attached please find a patch that fixes JDK-8160325. The patch >> comprises the following changes: >> >> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the >> FXCanvas instance embedding the given Scene instance. >> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >> - Added FXCanvasTest with a test method to test correct behavior of >> FXCanvas#getFXCanvas(Scene). >> - Introduced SwtTest JUnit MethodRule to have more concise tests and >> ensure it is also used by SWTCursorsTest. >> - Ensured SWT tests are executed using GTK2 on Linux. >> >> I reworked the existing SWTCursorsTest while introducing FXCanvasTest >> to be more concise. >> >> Regards, >> Alexander >> > From alexander at nyssen.org Thu Jul 28 15:43:47 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Thu, 28 Jul 2016 17:43:47 +0200 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <579A231B.8030009@oracle.com> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> Message-ID: <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> Hi, I have added my comments below: > Am 28.07.2016 um 17:22 schrieb Kevin Rushforth : > > I got the attachment, since Alexander also CCed me directly. I will attach it shortly. Thanks! > > I do have two comments on this: > > 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. I was not aware about this, but I would of course appreciate if it could be included (due to Jigsaw). Thanks for considering it at least. > > 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. Well, the test case refactoring is somehow related, as I introduced the common SWT rule while introducing the second SWT test. However, I could provide it as a separate contribution if that was wished (and a JIRA issue was provided), but the rest of this contribution of course requires it as a prerequisite. If this enhancement could not be included in JDK 9, I would have to provide it as a separate contribution, as I would have to re-introduce FXCanvasTest in other succeeding bugfix contributions (JDK-8143596, JDK-8143596). The GTK2 flag I introduced just affects SWT. As the swt library that is bundled is rather old (3.7.2) that seemed to be safer (we have observed quite a few problems when running SWT on GTK3). We can of course remove it if tests are not affected by it. > > ? Kevin Regards, Alexander > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html > [2] http://openjdk.java.net/projects/jdk9/fc-extension-process > [3] https://bugs.openjdk.java.net/browse/JDK-8145568 > > > Phil Race wrote: >> The mailing list rejects attachments so we got nothing. >> >> -phil. >> >> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>> Hi Kevin, all, >>> >>> attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: >>> >>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. >>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>> - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). >>> - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. >>> - Ensured SWT tests are executed using GTK2 on Linux. >>> >>> I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. >>> >>> Regards, >>> Alexander >>> >> From kevin.rushforth at oracle.com Thu Jul 28 16:03:33 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 28 Jul 2016 09:03:33 -0700 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> Message-ID: <579A2CD5.5020600@oracle.com> Hi Alexander Nyssen wrote: > Hi, > > I have added my comments below: > > >> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >> >: >> >> I got the attachment, since Alexander also CCed me directly. I will >> attach it shortly. > > Thanks! Done. >> I do have two comments on this: >> >> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 >> R-team approval [1][2]. In this case, the justification can be >> internal API that is no longer accessible in JDK 9 due to Jigsaw (I >> would be very reluctant to consider any other Enhancement request >> this late in the process), but I will need to look at it and then >> take it through the approval process, provided that I feel it is in >> scope. > > I was not aware about this, but I would of course appreciate if it > could be included (due to Jigsaw). Thanks for considering it at least. I'll take a closer look tomorrow or Monday (no more time today). At first glance it seems like something reasonable to take forward. >> 2) Some of the changes you list seem unrelated to this enhancement >> and are better done as separate issues (e.g., the rework of the >> SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; >> in fact it seems at odds with the work we have done with JEP 283 [3]. > > Well, the test case refactoring is somehow related, as I introduced > the common SWT rule while introducing the second SWT test. However, I > could provide it as a separate contribution if that was wished (and a > JIRA issue was provided), but the rest of this contribution of course > requires it as a prerequisite. If this enhancement could not be > included in JDK 9, I would have to provide it as a separate > contribution, as I would have to re-introduce FXCanvasTest in other > succeeding bugfix contributions (JDK-8143596, JDK-8143596). I see. I did take a quick look at this and the test changes seem fine as part of this. I see you created the new test with 'hg cp' (or similar) which records it as a copy of the SWTCursorsTest.java file, which given the number of changes is not needed (and not really useful), but that's easy to fix. There are several white space changes in FXCanvas.java that should be reverted. Our policy is that we do not make unrelated changes, including white space changes, in portions of a file that aren't otherwise modified by a patch. > The GTK2 flag I introduced just affects SWT. As the swt library that > is bundled is rather old (3.7.2) that seemed to be safer (we have > observed quite a few problems when running SWT on GTK3). We can of > course remove it if tests are not affected by it. We don't actually bundle swt itself, although we do download an old copy to link against, and to run tests against. In any case, given that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might not have GTK2 installed by default. Please revert this change to build.gradle. If test issues arise on Linux we will deal with it at that time (possibly by moving to a newer version of swt to run tests). Thanks. -- Kevin > >> >> ? Kevin > > Regards, > Alexander > >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >> [2] http://openjdk.java.net/projects/jdk9/fc-extension-process >> [3] https://bugs.openjdk.java.net/browse/JDK-8145568 >> >> >> Phil Race wrote: >>> The mailing list rejects attachments so we got nothing. >>> >>> -phil. >>> >>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>> Hi Kevin, all, >>>> >>>> attached please find a patch that fixes JDK-8160325. The patch >>>> comprises the following changes: >>>> >>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the >>>> FXCanvas instance embedding the given Scene instance. >>>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>>> - Added FXCanvasTest with a test method to test correct behavior of >>>> FXCanvas#getFXCanvas(Scene). >>>> - Introduced SwtTest JUnit MethodRule to have more concise tests >>>> and ensure it is also used by SWTCursorsTest. >>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>> >>>> I reworked the existing SWTCursorsTest while introducing >>>> FXCanvasTest to be more concise. >>>> >>>> Regards, >>>> Alexander >>>> >>> > From david.dehaven at oracle.com Thu Jul 28 17:00:03 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 28 Jul 2016 10:00:03 -0700 Subject: JDK-8153350 - JavaFX webstart with javaws.exe selects wrong toolkit (unnecessary relaunch) In-Reply-To: <59DF37AB-B96D-48E7-9587-46887C14787B@oracle.com> References: <59DF37AB-B96D-48E7-9587-46887C14787B@oracle.com> Message-ID: <4CF4E91A-DB8E-412B-BA62-7C37730837C4@oracle.com> >> it may be unrelated to these relaunches, but I have been wondering for awhile, what the toolkit parameter in the ant element is supposed to do. >> >> see: >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIAGCAFH >> >> At least in my tests changing the parameter had no effect on the generated jnlp file. > > Good question.. maybe Chris can answer? Let me try that again... There are some properties passed to the VM (by dtjava.js) that change the default toolkit, but those would only be relevant for web deployment. Java Packager does produce html and JNLP files so it's possible that's what it's for. Actually, you can pass -J-Djnlp.tk=jfx to javaws and it will start with the FX toolkit and avoid the relaunch. -DrD- From alexander at nyssen.org Thu Jul 28 18:11:08 2016 From: alexander at nyssen.org (Alexander Nyssen) Date: Thu, 28 Jul 2016 20:11:08 +0200 Subject: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene. In-Reply-To: <579A2CD5.5020600@oracle.com> References: <8f6f91a9-0ea9-1769-d22d-ca3e19b8c5b7@oracle.com> <579A231B.8030009@oracle.com> <9C6E80F0-6826-43A5-8483-3C570B932D10@nyssen.org> <579A2CD5.5020600@oracle.com> Message-ID: Hi Kevin, attached please find a revised patch. My comments are inlined. > Am 28.07.2016 um 18:03 schrieb Kevin Rushforth : > > Hi > > Alexander Nyssen wrote: >> >> Hi, >> >> I have added my comments below: >> >> >>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth >: >>> >>> I got the attachment, since Alexander also CCed me directly. I will attach it shortly. >> >> Thanks! > > Done. > >>> I do have two comments on this: >>> >>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 R-team approval [1][2]. In this case, the justification can be internal API that is no longer accessible in JDK 9 due to Jigsaw (I would be very reluctant to consider any other Enhancement request this late in the process), but I will need to look at it and then take it through the approval process, provided that I feel it is in scope. >> >> I was not aware about this, but I would of course appreciate if it could be included (due to Jigsaw). Thanks for considering it at least. > > I'll take a closer look tomorrow or Monday (no more time today). At first glance it seems like something reasonable to take forward. That sounds promising. Thanks! > >>> 2) Some of the changes you list seem unrelated to this enhancement and are better done as separate issues (e.g., the rework of the SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in fact it seems at odds with the work we have done with JEP 283 [3]. >> >> Well, the test case refactoring is somehow related, as I introduced the common SWT rule while introducing the second SWT test. However, I could provide it as a separate contribution if that was wished (and a JIRA issue was provided), but the rest of this contribution of course requires it as a prerequisite. If this enhancement could not be included in JDK 9, I would have to provide it as a separate contribution, as I would have to re-introduce FXCanvasTest in other succeeding bugfix contributions (JDK-8143596, JDK-8143596). > > I see. I did take a quick look at this and the test changes seem fine as part of this. I see you created the new test with 'hg cp' (or similar) which records it as a copy of the SWTCursorsTest.java file, which given the number of changes is not needed (and not really useful), but that's easy to fix. Done (I copied it within IntelliJ and the IDE seems to have applied hg copy). > > There are several white space changes in FXCanvas.java that should be reverted. Our policy is that we do not make unrelated changes, including white space changes, in portions of a file that aren't otherwise modified by a patch. Done (I used the IntelliJ formatter). > >> The GTK2 flag I introduced just affects SWT. As the swt library that is bundled is rather old (3.7.2) that seemed to be safer (we have observed quite a few problems when running SWT on GTK3). We can of course remove it if tests are not affected by it. > > We don't actually bundle swt itself, although we do download an old copy to link against, and to run tests against. In any case, given that our minimum Linux platform for JDK 9 is Ubuntu 16.04, it might not have GTK2 installed by default. Please revert this change to build.gradle. If test issues arise on Linux we will deal with it at that time (possibly by moving to a newer version of swt to run tests). I removed the SWT option. However, the previous logger message is no longer valid and should be removed, so the patch still contains a change to build.gradle. > > Thanks. > > ? Kevin Regards, Alexander > > >> >>> >>> ? Kevin >> >> Regards, >> Alexander >> >>> >>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004485.html >>> [2] http://openjdk.java.net/projects/jdk9/fc-extension-process >>> [3] https://bugs.openjdk.java.net/browse/JDK-8145568 >>> >>> >>> Phil Race wrote: >>>> The mailing list rejects attachments so we got nothing. >>>> >>>> -phil. >>>> >>>> On 7/28/2016 8:06 AM, Alexander Nyssen wrote: >>>>> Hi Kevin, all, >>>>> >>>>> attached please find a patch that fixes JDK-8160325. The patch comprises the following changes: >>>>> >>>>> - Provided static FXCanvas#getFXCanvas(Scene) method to obtain the FXCanvas instance embedding the given Scene instance. >>>>> - Added EmbeddedWindow.getHost() so the HostInterface can be retrieved. >>>>> - Added FXCanvasTest with a test method to test correct behavior of FXCanvas#getFXCanvas(Scene). >>>>> - Introduced SwtTest JUnit MethodRule to have more concise tests and ensure it is also used by SWTCursorsTest. >>>>> - Ensured SWT tests are executed using GTK2 on Linux. >>>>> >>>>> I reworked the existing SWTCursorsTest while introducing FXCanvasTest to be more concise. >>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>> >> From chien.yang at oracle.com Thu Jul 28 21:47:26 2016 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 28 Jul 2016 14:47:26 -0700 Subject: [9] Code Review Request For 8154148: JavaFX crashes on startup when run on Mac in VMWare Message-ID: <579A7D6E.3040509@oracle.com> Hi Kevin and Dave, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8154148 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8154148/webrev.00/ Thanks, - Chien From guru.hb at oracle.com Fri Jul 29 12:23:38 2016 From: guru.hb at oracle.com (Guru Hb) Date: Fri, 29 Jul 2016 17:53:38 +0530 Subject: [9] Review request 8153681: WebView needs to resolve resources relative to "jrt:" URLs In-Reply-To: <5b0bb5ee-70c7-3e6d-35ef-1d57b6393c51@oracle.com> References: <42096db5-3686-f2fb-ce65-f74a3f607b86@oracle.com> <7ac9a346-2b91-fc15-60ad-5a0dd9be66a2@oracle.com> <5b0bb5ee-70c7-3e6d-35ef-1d57b6393c51@oracle.com> Message-ID: <1cac2cd1-9e13-fec7-e1d5-59998fe1b24f@oracle.com> Hi Kevin, Arun & Murali, Please review the fix for : https://bugs.openjdk.java.net/browse/JDK-8153681 Webrev : http://cr.openjdk.java.net/~ghb/8153681/webrev.00/ Solution updated in JBS. Thanks, Guru From vadim.pakhnushev at oracle.com Fri Jul 29 14:40:38 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 29 Jul 2016 17:40:38 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <58278b2c-b68d-f750-6c5c-9c8cb5a527f3@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri Jul 29 16:21:29 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 29 Jul 2016 09:21:29 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <58278b2c-b68d-f750-6c5c-9c8cb5a527f3@oracle.com> References: <58278b2c-b68d-f750-6c5c-9c8cb5a527f3@oracle.com> Message-ID: <579B8289.2070101@oracle.com> As a further reminder, we will remain locked after 1pm PST on Monday until the directory reorg changeset for https://bugs.openjdk.java.net/browse/JDK-8161705 is pushed. -- Kevin Vadim Pakhnushev wrote: > Reminder, Monday is our weekly sanity testing. > > You can find your testing assignment at: > https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing > > Also please remember that the repo will be locked from 1am PST until > 1pm PST. > > Happy testing! > > Thanks, > Vadim From philip.race at oracle.com Fri Jul 29 16:36:50 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Jul 2016 09:36:50 -0700 Subject: RFR: 8088718 : Printing of LinearGradient fails Message-ID: <579B8622.50502@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8088718 diff is in the bug report but it looks like this :- - if (x1 == x2 && y1 == y1) { + if (x1 == x2 && y1 == y2) { -phil. From kevin.rushforth at oracle.com Fri Jul 29 17:02:19 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 29 Jul 2016 10:02:19 -0700 Subject: RFR: 8088718 : Printing of LinearGradient fails In-Reply-To: <579B8622.50502@oracle.com> References: <579B8622.50502@oracle.com> Message-ID: <579B8C1B.5050306@oracle.com> Looks fine. +1 -- Kevin Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8088718 > > diff is in the bug report but it looks like this :- > > - if (x1 == x2 && y1 == y1) { > + if (x1 == x2 && y1 == y2) { > > -phil. From philip.race at oracle.com Fri Jul 29 20:02:20 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Jul 2016 13:02:20 -0700 Subject: RFR: 8088918: Illegal parameters when creating PageLayout Message-ID: <579BB64C.6040202@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8088918 I cannot reproduce this but I can change the code so that I fix the theoretical reasons it can occur with the provided code snippet. Basically eliminate that Math.abs() part of the check .. -phil. From arunprasad.rajkumar at oracle.com Sat Jul 30 06:42:16 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Sat, 30 Jul 2016 12:12:16 +0530 Subject: [webkit] [9] Review request for 8162715: Add regression test for JDK-8161258 In-Reply-To: References: Message-ID: <5d429381-0799-e757-c070-827af4746317@oracle.com> Hello Kevin, Guru, Murali, Please review the following fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162715 Webrev: http://cr.openjdk.java.net/~arajkumar/8162715/webrev.00 Regards, Arun