From tsayao at openjdk.java.net Wed Apr 1 00:47:06 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 00:47:06 GMT Subject: [Rev 34] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/3855e16f..b1222f85 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.34 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.33-34 Stats: 51 lines in 2 files changed: 13 ins; 18 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 01:09:07 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 01:09:07 GMT Subject: [Rev 35] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Better comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/b1222f85..381e8d14 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.35 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.34-35 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 01:18:44 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 01:18:44 GMT Subject: [Rev 36] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Fix Tab - JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/381e8d14..142073d1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.36 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.35-36 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 03:09:20 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 03:09:20 GMT Subject: [Rev 37] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Prefer content size over window size. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/142073d1..f367c9a3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.37 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.36-37 Stats: 24 lines in 1 file changed: 4 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 03:23:40 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 03:23:40 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Tue, 24 Mar 2020 13:33:33 GMT, Thiago Milczarek Sayao wrote: >> I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 >> and Scenebuilder. >> Will have to do some tests on 16.04. > > Ubuntu 20.04 Test Results > > Updated 31 march 2020. > > ![image](https://user-images.githubusercontent.com/30704286/78094606-5459e200-73ab-11ea-8de9-e6c1c569c318.png) > > Note: ColorPickerTest worked on a "solo" run, Test on 16.04 (without Webkit - it does not build on 16.04 anymore) ![image](https://user-images.githubusercontent.com/30704286/78095942-b9fb9d80-73ae-11ea-9dfa-108daa3479e5.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From guru.hb at oracle.com Wed Apr 1 03:46:16 2020 From: guru.hb at oracle.com (Guru) Date: Wed, 1 Apr 2020 09:16:16 +0530 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: <13839C1E-C790-4AF6-8263-5F45D785B91D@oracle.com> Vote: YES > On 26-Mar-2020, at 5:14 PM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Committer. > > Arun is a member of JavaFX team at Oracle, who has contributed 13 commits [2][3] to OpenJFX. > > Votes are due by April 9, 2020. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/commits?author=arun-Joseph > > [3] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From ajit.ghaisas at oracle.com Wed Apr 1 04:35:24 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 1 Apr 2020 10:05:24 +0530 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: Vote: YES Regards, Ajit > On 26-Mar-2020, at 5:14 PM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Committer. > > Arun is a member of JavaFX team at Oracle, who has contributed 13 commits [2][3] to OpenJFX. > > Votes are due by April 9, 2020. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/commits?author=arun-Joseph > > [3] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From prasanta.sadhukhan at oracle.com Wed Apr 1 04:47:32 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 1 Apr 2020 10:17:32 +0530 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: <8dc55f9b-f85a-afd3-74ab-7027a2c9e6c5@oracle.com> Vote: YES Regards Prasanta On 26-Mar-20 5:14 PM, Kevin Rushforth wrote: > I hereby nominate Arun Joseph [1] to OpenJFX Committer. > > Arun is a member of JavaFX team at Oracle, who has contributed 13 > commits [2][3] to OpenJFX. > > Votes are due by April 9, 2020. > > Only current OpenJFX Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/commits?author=arun-Joseph > > [3] > https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From aghaisas at openjdk.java.net Wed Apr 1 10:55:13 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 1 Apr 2020 10:55:13 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) Message-ID: Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 Root Cause : Turned out to be a simpler issue than thought. Atomicity check was missed while updating toolbar state (which in turn updates styles). Fix : Added the missed atomicity check at two places that handle text selection using keyboard keys. Testing : Added two system test cases. They fail without this fix and pass with it. ------------- Commit messages: - Fix_8230809 Changes: https://git.openjdk.java.net/jfx/pull/155/files Webrev: https://webrevs.openjdk.java.net/jfx/155/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230809 Stats: 115 lines in 2 files changed: 112 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/155.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/155/head:pull/155 PR: https://git.openjdk.java.net/jfx/pull/155 From mp at jugs.org Wed Apr 1 11:31:11 2020 From: mp at jugs.org (Michael Paus) Date: Wed, 1 Apr 2020 13:31:11 +0200 Subject: Strange window snapshots Message-ID: <74cf165f-9121-95cc-f838-da968591814a@jugs.org> Hi, I am just debugging a JavaFX application which behaves strangely. Occasionally I am getting strange error messages like this: 2020-03-29 17:43:34.485 java[6134:499599] -[NSPersistentUIWindowSnapshotter writeWindowSnapshot:length:width:height:bytesPerRow:toFile:inDirectory:encryptingWithKey:uuid:checksum:fd:]: 0 == ftruncate(fd, finalFileSize) failed on line 797: No such file or directory 2020-03-29 17:43:34.486 java[6134:499599] -[NSPersistentUIWindowSnapshotter writeWindowSnapshot:length:width:height:bytesPerRow:toFile:inDirectory:encryptingWithKey:uuid:checksum:fd:]: 0 == ftruncate(fd, fileLength) failed on line 868: No such file or directory I am wondering now who or what is trying to do window snapshots of my machine? It seems I am only seeing this because of some error. Otherwise I would not have even noticed this. Can anybody here provide me with some insight? I am on macOS 10.14.6 OpenJDK 15-ea+14-561 OpenJFX 15-ea+2 Michael From kcr at openjdk.java.net Wed Apr 1 13:46:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Apr 2020 13:46:42 GMT Subject: RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: On Tue, 31 Mar 2020 05:33:35 GMT, Ambarish Rapte wrote: > This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). > When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was > implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. > > Call to jpeg_read_header() may fail when the partial image data has incomplete header information. > > In the given case the jpeg_read_header() call fails and code execution flow enters the 'if > (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls > imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) > crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test > passes with fix and causes a native crash without the fix. The fix looks good. I can also confirm that the test fails (crashes) without your fix and passes with your fix. The new LoadCorruptJPEGTest.java test doesn't use Robot, so it should be moved to a package not underneath `test.robot`. For consistency with similar tests in `javafx.graphics`, I recommend `test.com.sun.javafx.iio`. I left a few other comments on the test. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 64: > 63: Util.runAndWait(() -> { > 64: URL resource = this.getClass().getResource("corrupt.jpg"); > 65: FileInputStream input = null; Minor: It's generally preferred to use `LoadCorruptJPEGTest.class` rather than the `getClass()` method call. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 69: > 68: } catch (FileNotFoundException e) { > 69: e.printStackTrace(); > 70: } The `FileNotFoundException` should cause the test to fail. Rather than doing a try / catch, I recommend adding `throws Exception` to the test method. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 88: > 87: }); > 88: stage.setAlwaysOnTop(true); > 89: stage.show(); This call is not needed. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 116: > 115: > 116: private static void waitForLatch(CountDownLatch latch, int seconds, String msg) { > 117: try { This method is unused and can be removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From kcr at openjdk.java.net Wed Apr 1 13:46:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Apr 2020 13:46:42 GMT Subject: RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: <1b81pvO1zucSM1lTAzmsMIRLZkdz_wlu__X8xpFgD_c=.dde1f658-3a01-40f8-a97c-76ad32c0cc31@github.com> On Wed, 1 Apr 2020 13:43:39 GMT, Kevin Rushforth wrote: >> This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). >> When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was >> implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. >> >> Call to jpeg_read_header() may fail when the partial image data has incomplete header information. >> >> In the given case the jpeg_read_header() call fails and code execution flow enters the 'if >> (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls >> imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) >> crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test >> passes with fix and causes a native crash without the fix. > > The fix looks good. I can also confirm that the test fails (crashes) without your fix and passes with your fix. > > The new LoadCorruptJPEGTest.java test doesn't use Robot, so it should be moved to a package not underneath > `test.robot`. For consistency with similar tests in `javafx.graphics`, I recommend `test.com.sun.javafx.iio`. > I left a few other comments on the test. @johanvos This is a simple enough fix that I don't think it needs a second reviewer. Feel free to review it if you like. ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From kcr at openjdk.java.net Wed Apr 1 13:52:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Apr 2020 13:52:25 GMT Subject: RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: <0H21P45OAGNizY072nIoDLs_XCo_Egdr2cUiY2xIg2c=.5d938008-3298-49fc-910a-09ea2e34692c@github.com> On Wed, 1 Apr 2020 13:39:35 GMT, Kevin Rushforth wrote: >> This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). >> When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was >> implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. >> >> Call to jpeg_read_header() may fail when the partial image data has incomplete header information. >> >> In the given case the jpeg_read_header() call fails and code execution flow enters the 'if >> (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls >> imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) >> crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test >> passes with fix and causes a native crash without the fix. > > tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 69: > >> 68: } catch (FileNotFoundException e) { >> 69: e.printStackTrace(); >> 70: } > > The `FileNotFoundException` should cause the test to fail. Rather than doing a try / catch, I recommend adding `throws > Exception` to the test method. Actually, I see that `Util.runAndWait` does not declare `throws Exception`, so you will need to keep the try/catch here. I recommend to fail the test with `Assert.fail` or `throw new AssertionFailedError(e)` ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From arapte at openjdk.java.net Wed Apr 1 19:45:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 1 Apr 2020 19:45:45 GMT Subject: [Rev 01] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: On Fri, 27 Mar 2020 11:46:30 GMT, Jeanette Winzenburg wrote: >> Several controls with selection/focusModels leave memory leaks on replacing the model. >> >> Added tests for all such, those for the misbehaving models fail before and pass after the fix. >> >> for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > widened issue/fix/test for all controls with selection/focus models Change looks good to me. Similar to Skin classes the listeners here are also not explicitly removed. But I don't see any problematic scenario even if the listeners of an old Model are executed before it gets GCed. Suggested minor changes in test. modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 203: > 202: ObservableList data = FXCollections.observableArrayList("Apple", "Orange", "Banana"); > 203: data.forEach(text -> control.getTabs().add(new Tab("text"))); > 204: WeakReference> weakRef = new WeakReference<>(control.getSelectionModel()); `new Tab("text")` -> `new Tab(text)` modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 200: > 199: // has its own issue https://bugs.openjdk.java.net/browse/JDK-8241737 > 200: if (showBeforeReplaceSM) return; > 201: TabPane control = new TabPane(); @Ignore is used to ignore the test that are known to fail, It also becomes easy to track the ignored test with the @Ignore tag. I think it will be good to tag this scenario with a commented @Ignore inside the if statement `//@Ignore("JDK-8241737")` modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 228: > 227: // will be fixed as side-effect of skin cleanup in https://bugs.openjdk.java.net/browse/JDK-8087555 > 228: if (showBeforeReplaceSM) return; > 229: ChoiceBox control = new ChoiceBox<>(FXCollections.observableArrayList("Apple", "Orange", > "Banana")); @Ignore inside the if statement, `//@Ignore("JDK-8087555")` modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 285: > 284: } > 285: root.getChildren().add(node); > 286: if (!stage.isShowing()) { Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Thu Apr 2 07:04:08 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 07:04:08 GMT Subject: [Rev 01] RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: <6pa3txKmKqDZg5F8-ZksTDOJzR9OT6CMgfD1aL0QK4k=.e636cc21-882f-4157-b919-b230219a32ff@github.com> > This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). > When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was > implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. > > Call to jpeg_read_header() may fail when the partial image data has incomplete header information. > > In the given case the jpeg_read_header() call fails and code execution flow enters the 'if > (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls > imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) > crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test > passes with fix and causes a native crash without the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Fixed reiew comments on test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/154/files - new: https://git.openjdk.java.net/jfx/pull/154/files/49cb0f36..a452cd62 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/154/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/154/webrev.00-01 Stats: 235 lines in 3 files changed: 110 ins; 125 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/154.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/154/head:pull/154 PR: https://git.openjdk.java.net/jfx/pull/154 From fastegal at openjdk.java.net Thu Apr 2 09:11:57 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Apr 2020 09:11:57 GMT Subject: [Rev 02] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: > Several controls with selection/focusModels leave memory leaks on replacing the model. > > Added tests for all such, those for the misbehaving models fail before and pass after the fix. > > for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: cleanup test as suggested in review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/148/files - new: https://git.openjdk.java.net/jfx/pull/148/files/d2918fb5..8bed244f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/148/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/148/webrev.01-02 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/148.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/148/head:pull/148 PR: https://git.openjdk.java.net/jfx/pull/148 From fastegal at openjdk.java.net Thu Apr 2 09:15:06 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Apr 2020 09:15:06 GMT Subject: [Rev 01] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: <006TLeKlbw4j6laP69DA94vGAHXsKHdEIfyTJBX8xO0=.a1dd2fd5-9429-4110-80a1-bd6b9276cbbc@github.com> On Wed, 1 Apr 2020 19:34:09 GMT, Ambarish Rapte wrote: > > Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? hmm .. don't think that it's necessary to clear out other children: the thing that actually matters is that the control goes active in the scenegraph and has a skin attached. Can you think of any context where any of the tests might get whacky if there are more than one nodes in the root? Actually, that's a pattern (*cough, read that's more or less c&p'ed) I use in other tests, where it sometimes is allowed and expected that there are more than one. ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Thu Apr 2 11:31:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 11:31:52 GMT Subject: [Rev 01] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: <006TLeKlbw4j6laP69DA94vGAHXsKHdEIfyTJBX8xO0=.a1dd2fd5-9429-4110-80a1-bd6b9276cbbc@github.com> References: <006TLeKlbw4j6laP69DA94vGAHXsKHdEIfyTJBX8xO0=.a1dd2fd5-9429-4110-80a1-bd6b9276cbbc@github.com> Message-ID: On Thu, 2 Apr 2020 09:12:55 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 285: >> >>> 284: } >>> 285: root.getChildren().add(node); >>> 286: if (!stage.isShowing()) { >> >> Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? > >> >> Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? > > hmm .. don't think that it's necessary to clear out other children: the thing that actually matters is that the control > goes active in the scenegraph and has a skin attached. Can you think of any context where any of the tests might get > whacky if there are more than one nodes in the root? Actually, that's a pattern (*cough, read that's more or less > c&p'ed) I use in other tests, where it sometimes is allowed and expected that there are more than one. Agree that It would not cause any problem in test execution. ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Thu Apr 2 11:31:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 11:31:52 GMT Subject: [Rev 02] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 09:11:57 GMT, Jeanette Winzenburg wrote: >> Several controls with selection/focusModels leave memory leaks on replacing the model. >> >> Added tests for all such, those for the misbehaving models fail before and pass after the fix. >> >> for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > cleanup test as suggested in review looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/148 From kcr at openjdk.java.net Thu Apr 2 12:24:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 12:24:53 GMT Subject: [Rev 01] RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: <6pa3txKmKqDZg5F8-ZksTDOJzR9OT6CMgfD1aL0QK4k=.e636cc21-882f-4157-b919-b230219a32ff@github.com> References: <6pa3txKmKqDZg5F8-ZksTDOJzR9OT6CMgfD1aL0QK4k=.e636cc21-882f-4157-b919-b230219a32ff@github.com> Message-ID: On Thu, 2 Apr 2020 07:04:08 GMT, Ambarish Rapte wrote: >> This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). >> When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was >> implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. >> >> Call to jpeg_read_header() may fail when the partial image data has incomplete header information. >> >> In the given case the jpeg_read_header() call fails and code execution flow enters the 'if >> (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls >> imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) >> crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test >> passes with fix and causes a native crash without the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Fixed reiew comments on test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From nlisker at openjdk.java.net Thu Apr 2 13:01:25 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 2 Apr 2020 13:01:25 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Fri, 3 Jan 2020 09:26:43 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Attenuation and range changed internally to floats from doubles > > I have added few comments, but have not run tests and sample yet. @arapte Can you please test the performance changes too? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Thu Apr 2 12:58:11 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 12:58:11 GMT Subject: [Rev 03] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: > ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when > the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves > the issue. > Please take a look. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Fixed review comment: cleanup the accelerator ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/147/files - new: https://git.openjdk.java.net/jfx/pull/147/files/e81f175a..bf974f6a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/147/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/147/webrev.02-03 Stats: 54 lines in 2 files changed: 46 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/147.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/147/head:pull/147 PR: https://git.openjdk.java.net/jfx/pull/147 From arapte at openjdk.java.net Thu Apr 2 13:21:43 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 13:21:43 GMT Subject: [Rev 01] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: <7LDkD9pey1uNcKAj6ajx-TbzKdhP6zzrfZUfy_5hwFM=.e7fb5c79-d981-45e1-b440-293057c38259@github.com> Message-ID: On Mon, 30 Mar 2020 10:36:13 GMT, Jeanette Winzenburg wrote: >> Thanks for the test case, I did minor changes to it and included in the next commit. >> The NPE can occur even without `button.setDefaultButton(true);`. >> Please take a look > > good catch! You are right, without explicit removal of the listener, the NPE happens always. > > Actually, I had been sloppy and got distracted by the NPE from my actual goal which was to dig into Kevin's "not > cleaning up after itself" and .. finally found a (concededly extreme corner-case :) where that's happening: when > setting the skin to null. Two failing tests: > @Test > public void testDefaultButtonNullSkinReleased() { > Button button = new Button(); > button.setDefaultButton(true); > Group root = new Group(button); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > stage.show(); > WeakReference defSkinRef = new WeakReference<>((ButtonSkin)button.getSkin()); > button.setSkin(null); > > attemptGC(defSkinRef); > assertNull("skin must be gc'ed", defSkinRef.get()); > } > > @Test > public void testDefaultButtonNullSkinAcceleratorRemoved() { > Button button = new Button(); > button.setDefaultButton(true); > Group root = new Group(button); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > stage.show(); > KeyCodeCombination key = new KeyCodeCombination(KeyCode.ENTER); > > assertNotNull(scene.getAccelerators().get(key)); > button.setSkin(null); > assertNull(scene.getAccelerators().get(key)); > > } > > An explicitly cleanup in dispose makes them pass: > > @Override > public void dispose() { > setDefaultButton(false); > setCancelButton(false); > getSkinnable().sceneProperty().removeListener(weakChangeListener); I have included this change and the test, with slight modification to include same test for Cancel button. ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From fastegal at openjdk.java.net Thu Apr 2 13:42:45 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Apr 2020 13:42:45 GMT Subject: [Rev 03] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 12:58:11 GMT, Ambarish Rapte wrote: >> ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when >> the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves >> the issue. >> Please take a look. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comment: cleanup the accelerator looks good :) ------------- Marked as reviewed by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/147 From Rony.Flatscher at wu.ac.at Thu Apr 2 16:47:54 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 2 Apr 2020 18:47:54 +0200 Subject: Seeking help with latest master ... In-Reply-To: References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> Message-ID: <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> Being stuck (tried the previous working gradle 5.6.4, could get "gradle clean", but not further) in the end I just tried Java 14 and that allowed me to run "gradle" successfully (currently building webkit to get going again). Just wanted to let interested readers know. (Would be great though, if it worked with the 11 LTS version as well.) ---rony On 31.03.2020 20:36, Rony G. Flatscher wrote: > On 31.03.2020 20:21, Scott Palmer wrote: >>> Could not resolve all dependencies for configuration ':apps:lucene'. >> ????? > Multiple build operations failed. >> ??????????? java.lang.ExceptionInInitializerError >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> ???????? > java.lang.ExceptionInInitializerError >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> >> >> This to me looks like it may be failing to make an https connection to a repository when >> attempting to download?dependencies. >> >> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running gradle builds, see:? >> https://github.com/gradle/gradle/issues/7842 >> >> Claims to be fixed, but maybe not? >> >> If it is related to Gradle?changing java.home while compiling, I wonder if using?--no-parallel >> might work around it? ?Of course try with --debug as well to see if it offers more clues. > Scott, thank you! > > Not having any knowledge about gradle I am unfortunately lost in this case. However, I used? "gradle > --no-parallel --debug" which did not succeed but created a 1.2 MB text file which I keep temporarily > in my DrobBox at: . > > Will have to leave in a few minutes for today so can only try other things tomorrow. > > ---rony From github.com+636962+ccavanaugh at openjdk.java.net Thu Apr 2 17:10:05 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Thu, 2 Apr 2020 17:10:05 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set Message-ID: This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. Also, I believe JDK-8196037 is a duplicate of this issue. I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. Thanks! ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jfx - Merge branch 'master' of https://github.com/openjdk/jfx - Fix for JDK-8129123 Changes: https://git.openjdk.java.net/jfx/pull/136/files Webrev: https://webrevs.openjdk.java.net/jfx/136/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8129123 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/136/head:pull/136 PR: https://git.openjdk.java.net/jfx/pull/136 From Rony.Flatscher at wu.ac.at Thu Apr 2 17:41:16 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 2 Apr 2020 19:41:16 +0200 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> Message-ID: <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> After merging master, applying some fixes and changing the title to reflect the change from WIP to a pull request I would kindly request a review of this pull request! Here the URL: , title changed to: "8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts". ---rony On 28.02.2020 19:22, Rony G. Flatscher wrote: > Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and > has an appropriate test unit going with it as well, please review. > > There should be no compatibility issue with this implementation. > > Discussion: another solution could be to not compile by default. Rather compile, if some new > information is present with the FXML file which cannot possibly be present in existing FXML files. > In this scenario one possible and probably simple solution would be to only compile scripts if the > language process instruction (e.g. ) contains an appropriate attribute with a value > indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with > PIs having this attribute set to true would be affected. If desired I could try to come up with a > respective solution as well. > > ---rony > > [1] "Implementation and test unit": > > [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile scripts": > > > [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": > > > > On 24.01.2020 16:26, Kevin Rushforth wrote: > >> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >> the concept). >> >> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >> issues, but it would be good to hear from application developers who heavily use FXML. >> >> -- Kevin >> >> >> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>> Just filed a RFE with the following information: >>> >>> ?? * Component: >>> ?????? o JavaFX >>> >>> ?? * Subcomponent: >>> ?????? o fxml: JavaFX FXML >>> >>> ?? * Synopsis: >>> ?????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>> >>> ?? * Descriptions: >>> ?????? o "FXMLLoader is able to execute scripts in Java script languages (javax.script.ScriptEngine >>> ???????? implementations) if such a Java script language gets defined as the controller language in >>> ???????? the FXML file. >>> >>> ???????? If a script engine implements the javax.script.Compilable interface, then such scripts >>> could >>> ???????? be compiled and the resulting javax.script.CompiledScript could be executed instead using >>> ???????? its eval() methods. >>> >>> ???????? Evaluating the CompiledScript objects may help speed up the execution of script >>> invocations, >>> ???????? especially for scripts defined for event attributes in FXML elements (e.g. like >>> onMouseMove) >>> ???????? which may be repetitevly invoked and evaluated." >>> >>> ?? * System /OS/Java Runtime Information: >>> ?????? o "All systems." >>> >>> Received the internal review ID: "9063426" >>> >>> ---rony From johan.vos at gluonhq.com Thu Apr 2 19:20:44 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 2 Apr 2020 21:20:44 +0200 Subject: Seeking help with latest master ... In-Reply-To: <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> Message-ID: I have no scientific evidence for this, but I remember issues related to SSL with some JDK's as well, which may or may not be related to the cacerts file that is bundled. - Johan On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher wrote: > Being stuck (tried the previous working gradle 5.6.4, could get "gradle > clean", but not further) in > the end I just tried Java 14 and that allowed me to run "gradle" > successfully (currently building > webkit to get going again). Just wanted to let interested readers know. > (Would be great though, if > it worked with the 11 LTS version as well.) > > ---rony > > > On 31.03.2020 20:36, Rony G. Flatscher wrote: > > On 31.03.2020 20:21, Scott Palmer wrote: > >>> Could not resolve all dependencies for configuration ':apps:lucene'. > >> > Multiple build operations failed. > >> java.lang.ExceptionInInitializerError > >> java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> > java.lang.ExceptionInInitializerError > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> > >> > >> This to me looks like it may be failing to make an https connection to > a repository when > >> attempting to download dependencies. > >> > >> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when > running gradle builds, see: > >> https://github.com/gradle/gradle/issues/7842 > >> > >> Claims to be fixed, but maybe not? > >> > >> If it is related to Gradle changing java.home while compiling, I wonder > if using --no-parallel > >> might work around it? Of course try with --debug as well to see if it > offers more clues. > > Scott, thank you! > > > > Not having any knowledge about gradle I am unfortunately lost in this > case. However, I used "gradle > > --no-parallel --debug" which did not succeed but created a 1.2 MB text > file which I keep temporarily > > in my DrobBox at: < > https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0 > >. > > > > Will have to leave in a few minutes for today so can only try other > things tomorrow. > > > > ---rony > > From tsayao at openjdk.java.net Thu Apr 2 20:11:54 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 2 Apr 2020 20:11:54 GMT Subject: [Rev 38] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fixes for ubuntu 16.04 (which delays frame extents) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/f367c9a3..547c3cb0 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.38 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.37-38 Stats: 28 lines in 2 files changed: 16 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Thu Apr 2 21:07:12 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 2 Apr 2020 21:07:12 GMT Subject: [Rev 39] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Just comment fixing ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/547c3cb0..e499a54d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.39 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.38-39 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Thu Apr 2 21:14:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 2 Apr 2020 21:14:02 GMT Subject: [Rev 40] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/e499a54d..031d2287 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.40 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.39-40 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Thu Apr 2 22:09:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:09:09 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events Message-ID: As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer guide: [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. ------------- Commit messages: - Revert "TEMPORARY: add debugging print statements (will be reverted before final review)" - TEMPORARY: add debugging print statements (will be reverted before final review) - 8236971: [macos] Gestures handled incorrectly due to missing events Changes: https://git.openjdk.java.net/jfx/pull/156/files Webrev: https://webrevs.openjdk.java.net/jfx/156/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236971 Stats: 117 lines in 4 files changed: 85 ins; 20 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/156/head:pull/156 PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Thu Apr 2 22:09:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:09:09 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. @arapte Can you be one of the reviewers? @mipastgt I ran it against your test application, but if you have other tests you could run, that would be helpful. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Thu Apr 2 22:23:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:23:10 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> On Wed, 4 Mar 2020 22:43:45 GMT, Craig Cavanaugh wrote: > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Can you please provide a unit test? One that fails before your fix and passes after your fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From kcr at openjdk.java.net Thu Apr 2 22:23:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:23:10 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Thu, 2 Apr 2020 22:20:18 GMT, Kevin Rushforth wrote: >> This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. >> Also, I believe JDK-8196037 is a duplicate of this issue. >> >> I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. >> >> Thanks! > > Can you please provide a unit test? One that fails before your fix and passes after your fix. @aghaisas can you be one of the reviewers? ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From github.com+60214806+ronyfla at openjdk.java.net Thu Apr 2 23:14:03 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Thu, 2 Apr 2020 23:14:03 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts Message-ID: TODO: ADD DESCRIPTION OF PROPOSED FIX HERE. ------------- Commit messages: - Correct error constant. - appease the jcheck script, such that that important trailing Whitespace error can be resolved (why would jcheck not do it automagically as well as expanding tabs?) - Merge master, correct ovesights. - Merge master - JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile scripts - corrected wrong test string - Removed executable bit from gradlew as this causes an error when - Merge branch 'scripttest' into script as requested by reviewer Kevin - Incorporating Kevin Rushfort's review comments to this WIP. - Incorporating Kevin Rushfort's review comments to this WIP. - Removed/replaced white space. - Removed/replaced white space. - test for JDK-8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV - fix for JDK-8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV Changes: https://git.openjdk.java.net/jfx/pull/129/files Webrev: https://webrevs.openjdk.java.net/jfx/129/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238080 Stats: 1003 lines in 17 files changed: 996 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/129.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/129/head:pull/129 PR: https://git.openjdk.java.net/jfx/pull/129 From kcr at openjdk.java.net Thu Apr 2 23:15:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 23:15:26 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts In-Reply-To: References: Message-ID: On Fri, 28 Feb 2020 17:46:58 GMT, Rony G. Flatscher wrote: > TODO: ADD DESCRIPTION OF PROPOSED FIX HERE. We will need to finish the discussion on this proposed new feature on the openjfx-dev mailing list. The PR can be used to illustrate what you want to do, but use [this email thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025623.html), rather than as a reply to the PR, for the discussion. Once we have agreement, then the next step will be to review the proposed spec change and implementation in this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/129 From kevin.rushforth at oracle.com Thu Apr 2 23:21:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Apr 2020 16:21:49 -0700 (PDT) Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> Message-ID: <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Hi Rony, I see that you updated the PR and sent it for review. Before we formally review it in the PR, let's finish the discussion as to whether this is a useful feature, and if so, what form this feature should take. From my point of view, this does seem like a useful feature. Would other users of FXML benefit from it? I'm not certain whether we want it to be implicit, compiling the script if the script engine in question implements Compilable, or via a new keyword or tag. What are the pros / cons? What do others think? In either case, we would need to make sure that this doesn't present any security concerns in the presence of a security manager. As long as a user-provided class is on the stack, it will be fine, but we would need to ensure that. -- Kevin On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: > After merging master, applying some fixes and changing the title to reflect the change from WIP to a > pull request I would kindly request a review of this pull request! > > Here the URL: , title changed to: "8238080: FXMLLoader: if > script engines implement javax.script.Compilable compile scripts". > > ---rony > > > On 28.02.2020 19:22, Rony G. Flatscher wrote: >> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >> has an appropriate test unit going with it as well, please review. >> >> There should be no compatibility issue with this implementation. >> >> Discussion: another solution could be to not compile by default. Rather compile, if some new >> information is present with the FXML file which cannot possibly be present in existing FXML files. >> In this scenario one possible and probably simple solution would be to only compile scripts if the >> language process instruction (e.g. ) contains an appropriate attribute with a value >> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >> PIs having this attribute set to true would be affected. If desired I could try to come up with a >> respective solution as well. >> >> ---rony >> >> [1] "Implementation and test unit": >> >> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile scripts": >> >> >> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >> >> >> >> On 24.01.2020 16:26, Kevin Rushforth wrote: >> >>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>> the concept). >>> >>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>> issues, but it would be good to hear from application developers who heavily use FXML. >>> >>> -- Kevin >>> >>> >>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>> Just filed a RFE with the following information: >>>> >>>> ?? * Component: >>>> ?????? o JavaFX >>>> >>>> ?? * Subcomponent: >>>> ?????? o fxml: JavaFX FXML >>>> >>>> ?? * Synopsis: >>>> ?????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>> >>>> ?? * Descriptions: >>>> ?????? o "FXMLLoader is able to execute scripts in Java script languages (javax.script.ScriptEngine >>>> ???????? implementations) if such a Java script language gets defined as the controller language in >>>> ???????? the FXML file. >>>> >>>> ???????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>> could >>>> ???????? be compiled and the resulting javax.script.CompiledScript could be executed instead using >>>> ???????? its eval() methods. >>>> >>>> ???????? Evaluating the CompiledScript objects may help speed up the execution of script >>>> invocations, >>>> ???????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>> onMouseMove) >>>> ???????? which may be repetitevly invoked and evaluated." >>>> >>>> ?? * System /OS/Java Runtime Information: >>>> ?????? o "All systems." >>>> >>>> Received the internal review ID: "9063426" >>>> >>>> ---rony From github.com+636962+ccavanaugh at openjdk.java.net Thu Apr 2 23:30:26 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Thu, 2 Apr 2020 23:30:26 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Thu, 2 Apr 2020 22:20:18 GMT, Kevin Rushforth wrote: > Can you please provide a unit test? One that fails before your fix and passes after your fix. I can provide a manual test the next couple of days that demonstrates it before and after, but I'm not sure how to create an automated unit test because the issue is visual. ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From tsayao at openjdk.java.net Fri Apr 3 00:48:19 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 00:48:19 GMT Subject: [Rev 41] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix unfullscreen bug on older gtk+ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/031d2287..11688aee Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.41 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.40-41 Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Fri Apr 3 01:59:08 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 01:59:08 GMT Subject: [Rev 42] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment Fix Tab Prefer content size over window size. Fixes for ubuntu 16.04 (which delays frame extents) Just comment fixing More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/11688aee..f52f63be Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.42 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.41-42 Stats: 45 lines in 2 files changed: 27 ins; 15 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Fri Apr 3 02:13:32 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 02:13:32 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Wed, 1 Apr 2020 03:21:31 GMT, Thiago Milczarek Sayao wrote: >> Ubuntu 20.04 Test Results >> >> Updated April 2nd. >> >> ![image](https://user-images.githubusercontent.com/30704286/78299385-28a23d80-750c-11ea-9edd-ac264f16c194.png) > > Test on 16.04 (without Webkit - it does not build on 16.04 anymore) > > Updated April 2nd. > > ![image](https://user-images.githubusercontent.com/30704286/78316727-c14db300-7536-11ea-86e9-4d5c56e4d92c.png) > > Note: DatePickerTest works when run alone. I will keep testing it, but I think it's looking good. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From aghaisas at openjdk.java.net Fri Apr 3 09:46:31 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 3 Apr 2020 09:46:31 GMT Subject: [Rev 02] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: <5rsifjfKxF8dd5GIcuTeHQiQMJDd9PikCg7bn8t9HtY=.1068d56f-3475-4d29-ab13-07303924694a@github.com> On Thu, 2 Apr 2020 09:11:57 GMT, Jeanette Winzenburg wrote: >> Several controls with selection/focusModels leave memory leaks on replacing the model. >> >> Added tests for all such, those for the misbehaving models fail before and pass after the fix. >> >> for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > cleanup test as suggested in review Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From craig.cavanaugh at gmail.com Fri Apr 3 10:26:39 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Fri, 3 Apr 2020 06:26:39 -0400 Subject: Stuck attempting to run/develop a manual unit test Message-ID: I am trying to create a manual unit test for RFR: 8129123 and I'm using the existing ButtonMnemonicPositionTest.java as a template to make sure everything is working correctly. I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 openjdk. openjfx is successfully compiling and passing tests following the wiki instructions I'm able to compile ButtonMnemonicPositionTest successfully as shown below. javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* ButtonMnemonicPositionTest.java But attempts to run are failing despite a successful compile: java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* ButtonMnemonicPositionTest Error: JavaFX runtime components are missing, and are required to run this application I've also tried running using the modular-sdk after a Gradle build and no luck either after finding a recommendation on the list that the module approach should be used for testing. java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules --add-modules=javafx.controls ButtonMnemonicPositionTest Error occurred during initialization of boot layer java.lang.module.FindException: Module javafx.controls not found I've been search through the list archive and haven't found a solution. I'm sure I'm doing something wrong. Some help please! Regards, Craig From ajit.ghaisas at oracle.com Fri Apr 3 10:52:01 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 3 Apr 2020 16:22:01 +0530 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: References: Message-ID: Hi Craig, Here is how I run the ButtonMnemonicPositionTest. $ export FX_LIB=/Users/AG/aaa/jfx/build/sdk/lib $ cd /Users/AG/aaa/jfx/tests/manual/UI $ javac --module-path $FX_LIB --add-modules javafx.controls ButtonMnemonicPositionTest.java $ java --module-path $FX_LIB --add-modules javafx.controls ButtonMnemonicPositionTest Hope this helps. We can discuss further on your PR. Regards, Ajit > On 03-Apr-2020, at 3:56 PM, Craig Cavanaugh wrote: > > I am trying to create a manual unit test for RFR: 8129123 and I'm using the > existing ButtonMnemonicPositionTest.java as a template to make sure > everything is working correctly. > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > openjdk. > openjfx is successfully compiling and passing tests following the wiki > instructions > > I'm able to compile ButtonMnemonicPositionTest successfully as shown below. > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest.java > > But attempts to run are failing despite a successful compile: > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest > Error: JavaFX runtime components are missing, and are required to run this > application > > I've also tried running using the modular-sdk after a Gradle build and no > luck either after finding a recommendation on the list that the module > approach should be used for testing. > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > --add-modules=javafx.controls ButtonMnemonicPositionTest > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.controls not found > > I've been search through the list archive and haven't found a solution. > I'm sure I'm doing something wrong. > > Some help please! > > Regards, > Craig From github.com+7517141+yososs at openjdk.java.net Fri Apr 3 10:55:39 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 3 Apr 2020 10:55:39 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow Message-ID: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> https://bugs.openjdk.java.net/browse/JDK-8197991 The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. This greatly improves the response when selecting multiple items in ListView and TableView. However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) ListView * selectAll: 400_000-> 10_000_000 * selectRange: 7_000-> 70_000 TableView * selectAll: 8_000-> 700_000 * selectRange: 7_000-> 50_000 You can see performance improvements in the following applications: SelectListViewTest.java import javafx.application.Application; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListView; import javafx.scene.control.SelectionMode; import javafx.scene.layout.BorderPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class SelectListViewTest extends Application { final int ROW_COUNT = 70_000; // final int ROW_COUNT = 400_000; // final int ROW_COUNT = 10_000_000; // final int ROW_COUNT = 7_000; @Override public void start(Stage stage) { ListView listView = new ListView<>(); listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); ObservableList items = listView.getItems(); for(int i=0; iselectAll(listView)); clearSelection.setOnAction((e)->clearSelection(listView)); selectToStart.setOnAction((e)->selectToStart(listView)); selectToEnd.setOnAction((e)->selectToLast(listView)); selectPrevious.setOnAction((e)->selectPrevious(listView)); selectNext.setOnAction((e)->selectNext(listView)); stage.show(); } private void selectAll(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectAll(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void clearSelection(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().clearSelection(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToStart(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToLast(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectPrevious(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectPrevious(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectNext(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectNext(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } public static void main(String[] args) { Application.launch(args); } } SelectTableViewTest.java import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.SelectionMode; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.layout.BorderPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class SelectTableViewTest extends Application { final int ROW_COUNT = 700_000; // final int ROW_COUNT = 80_000; // final int ROW_COUNT = 50_000; // final int ROW_COUNT = 8_000; final int COL_COUNT = 3; @Override public void start(Stage stage) { TableView tableView = new TableView<>(); tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); final ObservableList> columns = tableView.getColumns(); for(int i=0; i column = new TableColumn<>("Col"+i); final int colIndex=i; column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); column.setPrefWidth(150); columns.add(column); } ObservableList items = tableView.getItems(); for(int i=0; iselectAll(tableView)); clearSelection.setOnAction((e)->clearSelection(tableView)); selectToStart.setOnAction((e)->selectToStart(tableView)); selectToEnd.setOnAction((e)->selectToLast(tableView)); selectPrevious.setOnAction((e)->selectPrevious(tableView)); selectNext.setOnAction((e)->selectNext(tableView)); stage.show(); } private void selectAll(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectAll(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void clearSelection(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().clearSelection(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToStart(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToLast(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectPrevious(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectPrevious(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectNext(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectNext(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } public static void main(String[] args) { Application.launch(args); } } ------------- Commit messages: - 8197991: Fix multi-select performance issues Changes: https://git.openjdk.java.net/jfx/pull/127/files Webrev: https://webrevs.openjdk.java.net/jfx/127/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 54 lines in 2 files changed: 49 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/127/head:pull/127 PR: https://git.openjdk.java.net/jfx/pull/127 From robilad at openjdk.java.net Fri Apr 3 10:55:39 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Fri, 3 Apr 2020 10:55:39 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.88aea0b5-c8bd-459d-89a4-27be96af88b8@github.com> On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of > TreeUtil.getTreeItem (). > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), > tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } Hi, I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Fri Apr 3 10:58:01 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 3 Apr 2020 10:58:01 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView Message-ID: If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. `tableView.setFixedCellSize(height)` This proposal includes a fix because the current code does not correctly implement column virtualization. The improvement of this proposal can be seen in the following test program. Java import javafx.animation.AnimationTimer; import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class BigTableViewTest2 extends Application { private static final boolean USE_WIDTH_FIXED_SIZE = true; private static final boolean USE_HEIGHT_FIXED_SIZE = true; // private static final int COL_COUNT=300; private static final int COL_COUNT=600; // private static final int COL_COUNT=1000; private static final int ROW_COUNT=1000; @Override public void start(Stage primaryStage) throws Exception { final TableView tableView = new TableView<>(); final ObservableList> columns = tableView.getColumns(); for(int i=0; i column = new TableColumn<>("Col"+i); final int colIndex=i; column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); columns.add(column); if(USE_WIDTH_FIXED_SIZE) { column.setPrefWidth(60); column.setMaxWidth(60); column.setMinWidth(60); } } ObservableList items = tableView.getItems(); for(int i=0; i References: Message-ID: On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > > private static final boolean USE_WIDTH_FIXED_SIZE = true; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=300; > private static final int COL_COUNT=600; > // private static final int COL_COUNT=1000; > private static final int ROW_COUNT=1000; > > @Override > public void start(Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if(USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > if(USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > prepareTimeline(scene); > > } > > public static void main(String[] args) { > Application.launch(args); > } > > private void prepareTimeline(Scene scene) { > new AnimationTimer() { > @Override public void handle(long now) { > double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); > } > }.start(); > } > > } I'm signed to OCA and already a contributor. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From nlisker at openjdk.java.net Fri Apr 3 10:58:02 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 3 Apr 2020 10:58:02 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> On Thu, 27 Feb 2020 21:29:27 GMT, Martin Polakovic wrote: >> If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column >> virtualization. Virtualization mode is enabled when the row height is fixed by the following method. >> `tableView.setFixedCellSize(height)` >> >> This proposal includes a fix because the current code does not correctly implement column virtualization. >> >> The improvement of this proposal can be seen in the following test program. >> >> Java >> import javafx.animation.AnimationTimer; >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.TableColumn; >> import javafx.scene.control.TableView; >> import javafx.scene.layout.BorderPane; >> import javafx.stage.Stage; >> >> public class BigTableViewTest2 extends Application { >> >> private static final boolean USE_WIDTH_FIXED_SIZE = true; >> private static final boolean USE_HEIGHT_FIXED_SIZE = true; >> // private static final int COL_COUNT=300; >> private static final int COL_COUNT=600; >> // private static final int COL_COUNT=1000; >> private static final int ROW_COUNT=1000; >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> final TableView tableView = new TableView<>(); >> >> final ObservableList> columns = tableView.getColumns(); >> for(int i=0; i> TableColumn column = new TableColumn<>("Col"+i); >> final int colIndex=i; >> column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); >> columns.add(column); >> if(USE_WIDTH_FIXED_SIZE) { >> column.setPrefWidth(60); >> column.setMaxWidth(60); >> column.setMinWidth(60); >> } >> } >> >> ObservableList items = tableView.getItems(); >> for(int i=0; i> String[] rec = new String[COL_COUNT]; >> for(int j=0; j> rec[j] = i+":"+j; >> } >> items.add(rec); >> } >> BorderPane root = new BorderPane(tableView); >> if(USE_HEIGHT_FIXED_SIZE) { >> tableView.setFixedCellSize(24); >> } >> >> Scene scene = new Scene(root, 800, 800); >> primaryStage.setScene(scene); >> primaryStage.show(); >> prepareTimeline(scene); >> >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> >> private void prepareTimeline(Scene scene) { >> new AnimationTimer() { >> @Override public void handle(long now) { >> double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); >> ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); >> } >> }.start(); >> } >> >> } > > I took the liberty of pointing out some formatting errors The title of your PR should match the title of the JBS issue. Moreover, #108 already tackles this issue with a different approach and 2 PRs on the same issue can't be intetgrated. Since I'm not familiar with this code, I can't advise on who's solution is more suitable. I suggest you discuss both of the approaches on the mailing list. I saw many JBS issues around this performance issue, probably one of them fits (or a new one can be created). ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From robilad at openjdk.java.net Fri Apr 3 10:58:03 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Fri, 3 Apr 2020 10:58:03 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Mon, 9 Mar 2020 17:00:06 GMT, Nir Lisker wrote: >> I took the liberty of pointing out some formatting errors > > The title of your PR should match the title of the JBS issue. Moreover, #108 already tackles this issue with a > different approach and 2 PRs on the same issue can't be intetgrated. Since I'm not familiar with this code, I can't > advise on who's solution is more suitable. I suggest you discuss both of the approaches on the mailing list. I saw many > JBS issues around this performance issue, probably one of them fits (or a new one can be created). Hi, I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+7517141+yososs at openjdk.java.net Fri Apr 3 10:58:03 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 3 Apr 2020 10:58:03 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Thu, 2 Apr 2020 17:38:00 GMT, Dalibor Topic wrote: >> The title of your PR should match the title of the JBS issue. Moreover, #108 already tackles this issue with a >> different approach and 2 PRs on the same issue can't be intetgrated. Since I'm not familiar with this code, I can't >> advise on who's solution is more suitable. I suggest you discuss both of the approaches on the mailing list. I saw many >> JBS issues around this performance issue, probably one of them fits (or a new one can be created). > > Hi, > I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail > at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. My name is "Naohiro Yoshimoto" I have received an approved email on 2019-8-3. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+5527071+sghpjuikit at openjdk.java.net Fri Apr 3 10:58:02 2020 From: github.com+5527071+sghpjuikit at openjdk.java.net (Martin Polakovic) Date: Fri, 3 Apr 2020 10:58:02 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > > private static final boolean USE_WIDTH_FIXED_SIZE = true; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=300; > private static final int COL_COUNT=600; > // private static final int COL_COUNT=1000; > private static final int ROW_COUNT=1000; > > @Override > public void start(Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if(USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > if(USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > prepareTimeline(scene); > > } > > public static void main(String[] args) { > Application.launch(args); > } > > private void prepareTimeline(Scene scene) { > new AnimationTimer() { > @Override public void handle(long now) { > double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); > } > }.start(); > } > > } I took the liberty of pointing out some formatting errors modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 492: > 491: tableCell.requestLayout(); > 492: }else if(fixedCellSizeEnabled && lastVisibleColumnIndex 493: break; `}else` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 387: > 386: } > 387: }else{ > 388: // we only add/remove to the scenegraph if the fixed cell `}else` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 373: > 372: lastVisibleColumnIndex = column; > 373: }else if( firstVisibleColumnIndex != -1 ) { > 374: break; `}else` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 347: > 346: final Insets padding = getSkinnable().getPadding(); > 347: final double vfWidth = virtualFlow == null ? 0.0:virtualFlow.getWidth(); > 348: final double headerWidth = vfWidth - (padding.getLeft() + padding.getRight()); `0.0:` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 414: > 413: width = snapSizeX(tableColumn.getWidth()); > 414: if (isVisible || isOverlap(tableCell.getLayoutX(), tableCell.getLayoutX()+width, scrollX, headerWidth > + scrollX)) { 415: // if the style origin is null then the property has not been `)+w` formatting ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From mpaus at openjdk.java.net Fri Apr 3 11:34:21 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Fri, 3 Apr 2020 11:34:21 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 22:04:55 GMT, Kevin Rushforth wrote: >> As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case >> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, >> `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile >> time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer >> guide: >> [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) >> Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification >> works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to >> link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK >> or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information >> from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the >> `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new >> local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, >> `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and >> the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the >> problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have >> since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. > > @arapte Can you be one of the reviewers? > > @mipastgt I ran it against your test application, but if you have other tests you could run, that would be helpful. I've built a fresh JFX, with your changes applied to master, this morning. I can confirm that the primary bug seems to be fixed with these changes but I have observed some behaviour where I am not sure whether it is correct or whether my expectation is just wrong. 1. The total delta values are now accumulated correctly for the regualar scroll events but not for the following generated inertia events. They are still equal to the delta values. Is that according to the specification? From a practical point of view a programmer who relies on the total delta values is probably much surprised if the total delta is reset by the inertia events. 2. Is the touch-count field only valid for touch-events or why is it always zero? 3. The mouse-wheel behaviour is still wrong because the total-deltas for mouse-wheel generated scroll-events is still not 0 but this has probably another root cause. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From fastegal at swingempire.de Fri Apr 3 11:47:47 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 03 Apr 2020 13:47:47 +0200 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: References: Message-ID: <20200403134747.Horde.uzvz028f4rZMXjJvWfnCEQ1@webmail.df.eu> Hi Craig, no manual test needed - you can implement a normal (unit) test with the help or VirtualFlowTestUtils: grab the flow, get its first/last visible cell and check whether their range includes to cell we want to see, something like: @Test public void testScrollInSkin() { int index = 50; comboBox.getSelectionModel().select(index); comboBox.show(); VirtualFlow> virtualFlow = getFlow(); int first = virtualFlow.getFirstVisibleCell().getIndex(); int last = virtualFlow.getLastVisibleCell().getIndex(); assertTrue(" visible range [" + first + ", " + last + "] must include " + index, first <= index && index <= last); } protected VirtualFlow> getFlow() { VirtualFlow> virtualFlow = (VirtualFlow>) VirtualFlowTestUtils.getVirtualFlow(comboBox); return virtualFlow; } Have a look at the tests in test.xx.controls to understand how to setup the test context. And have fun :) Zitat von Craig Cavanaugh : > I am trying to create a manual unit test for RFR: 8129123 and I'm using the > existing ButtonMnemonicPositionTest.java as a template to make sure > everything is working correctly. > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > openjdk. > openjfx is successfully compiling and passing tests following the wiki > instructions > > I'm able to compile ButtonMnemonicPositionTest successfully as shown below. > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest.java > > But attempts to run are failing despite a successful compile: > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest > Error: JavaFX runtime components are missing, and are required to run this > application > > I've also tried running using the modular-sdk after a Gradle build and no > luck either after finding a recommendation on the list that the module > approach should be used for testing. > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > --add-modules=javafx.controls ButtonMnemonicPositionTest > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.controls not found > > I've been search through the list archive and haven't found a solution. > I'm sure I'm doing something wrong. > > Some help please! > > Regards, > Craig From fastegal at openjdk.java.net Fri Apr 3 12:06:51 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 3 Apr 2020 12:06:51 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Thu, 2 Apr 2020 23:28:19 GMT, Craig Cavanaugh wrote: >> Can you please provide a unit test? One that fails before your fix and passes after your fix. > >> Can you please provide a unit test? One that fails before your fix and passes after your fix. > > I can provide a manual test the next couple of days that demonstrates it before and after, but I'm not sure how to > create an automated unit test because the issue is visual. A quick snippet of how-to write a unit test (for setup see other tests in controls) that will fail before and pass after the change: @Test public void testScrollInSkin() { int index = 50; comboBox.getSelectionModel().select(index); comboBox.show(); VirtualFlow> virtualFlow = getFlow(); int first = virtualFlow.getFirstVisibleCell().getIndex(); int last = virtualFlow.getLastVisibleCell().getIndex(); assertTrue(" visible range [" + first + ", " + last + "] must include " + index, first <= index && index <= last); } protected VirtualFlow> getFlow() { VirtualFlow> virtualFlow = (VirtualFlow>) VirtualFlowTestUtils.getVirtualFlow(comboBox); return virtualFlow; } ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From fastegal at openjdk.java.net Fri Apr 3 12:18:43 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 3 Apr 2020 12:18:43 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Fri, 3 Apr 2020 12:03:33 GMT, Jeanette Winzenburg wrote: >>> Can you please provide a unit test? One that fails before your fix and passes after your fix. >> >> I can provide a manual test the next couple of days that demonstrates it before and after, but I'm not sure how to >> create an automated unit test because the issue is visual. > > A quick snippet of how-to write a unit test (for setup see other tests in controls) that will fail before and pass > after the change: > @Test > public void testScrollInSkin() { > int index = 50; > comboBox.getSelectionModel().select(index); > comboBox.show(); > VirtualFlow> virtualFlow = getFlow(); > int first = virtualFlow.getFirstVisibleCell().getIndex(); > int last = virtualFlow.getLastVisibleCell().getIndex(); > assertTrue(" visible range [" + first + ", " + last + "] must include " + index, > first <= index && index <= last); > } > > protected VirtualFlow> getFlow() { > VirtualFlow> virtualFlow = (VirtualFlow>) > VirtualFlowTestUtils.getVirtualFlow(comboBox); > return virtualFlow; > } A couple of comments to the bug (and fix) itself: - is it really a bug or a nice-to-have enhancement? couldn't find an example in win, didn't try too hard and nowadays, such plain combos are not a really frequent - while none of the virtualized controls (nor ChoiceBox) combines selection with scrolling to the selected item. For combo and choice, I see no reason not make it the default behavior. We need to make certain it behaves "naturally" when navigating in the open popup. instead of catching every list.select (and not forget the unselect) we might consider doing it in a showing handler alternatively, we might consider to go deeper and support it directly in the listView ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From kcr at openjdk.java.net Fri Apr 3 12:37:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Apr 2020 12:37:51 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> On Fri, 3 Apr 2020 11:32:12 GMT, Michael Paus wrote: >> @arapte Can you be one of the reviewers? >> >> @mipastgt I ran it against your test application, but if you have other tests you could run, that would be helpful. > > I've built a fresh JFX, with your changes applied to master, this morning. I can confirm that the primary bug seems to > be fixed with these changes but I have observed some behaviour where I am not sure whether it is correct or whether my > expectation is just wrong. 1. The total delta values are now accumulated correctly for the regualar scroll events but > not for the following generated inertia events. They are still equal to the delta values. Is that according to the > specification? From a practical point of view a programmer who relies on the total delta values is probably much > surprised if the total delta is reset by the inertia events. 2. Is the touch-count field only valid for touch-events > or why is it always zero? 3. The mouse-wheel behaviour is still wrong because the total-deltas for mouse-wheel > generated scroll-events is still not 0 but this has probably another root cause. These are all separate issues that could be explored with follow-on bugs. I'm not sure what the right behavior is for these or whether there is enough information from the OS to do anything about them (e.g., I suspect there is no way to get the touch count for these trackpad-generated gestures on macOS, nor do I really think it would be useful). You might file a follow-on issue for 1 and 3. Would you be able to review this? If not I'll ask @johanvos or @pankaj-bansal to be the second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From mpaus at openjdk.java.net Fri Apr 3 14:16:44 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Fri, 3 Apr 2020 14:16:44 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> References: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> Message-ID: On Fri, 3 Apr 2020 12:35:35 GMT, Kevin Rushforth wrote: >> I've built a fresh JFX, with your changes applied to master, this morning. I can confirm that the primary bug seems to >> be fixed with these changes but I have observed some behaviour where I am not sure whether it is correct or whether my >> expectation is just wrong. 1. The total delta values are now accumulated correctly for the regualar scroll events but >> not for the following generated inertia events. They are still equal to the delta values. Is that according to the >> specification? From a practical point of view a programmer who relies on the total delta values is probably much >> surprised if the total delta is reset by the inertia events. 2. Is the touch-count field only valid for touch-events >> or why is it always zero? 3. The mouse-wheel behaviour is still wrong because the total-deltas for mouse-wheel >> generated scroll-events is still not 0 but this has probably another root cause. > > These are all separate issues that could be explored with follow-on bugs. I'm not sure what the right behavior is for > these or whether there is enough information from the OS to do anything about them (e.g., I suspect there is no way to > get the touch count for these trackpad-generated gestures on macOS, nor do I really think it would be useful). You > might file a follow-on issue for 1 and 3. > Would you be able to review this? If not I'll ask @johanvos or @pankaj-bansal to be the second reviewer. I think 1. is more a point for discussion and I am also not sure what is right or wrong but 3. is IMHO a bug, especially because the documentation is so explicit about this behaviour. I'll file a new issue for that. What would I have to do to formally review this? I haven't done that before. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Fri Apr 3 14:34:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Apr 2020 14:34:32 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> Message-ID: On Fri, 3 Apr 2020 14:14:36 GMT, Michael Paus wrote: >> These are all separate issues that could be explored with follow-on bugs. I'm not sure what the right behavior is for >> these or whether there is enough information from the OS to do anything about them (e.g., I suspect there is no way to >> get the touch count for these trackpad-generated gestures on macOS, nor do I really think it would be useful). You >> might file a follow-on issue for 1 and 3. >> Would you be able to review this? If not I'll ask @johanvos or @pankaj-bansal to be the second reviewer. > > I think 1. is more a point for discussion and I am also not sure what is right or wrong but 3. is IMHO a bug, > especially because the documentation is so explicit about this behaviour. I'll file a new issue for that. > What would I have to do to formally review this? I haven't done that before. I agree about 1 being a point of discussion. Please do file a bug for 3. As for formally reviewing it, you would press the `Files changed` tab near the top of the PR, add any inline comments you might have, and then press the `Review changes` pull down. You would add any overall review comments that you have, then select one of `Comment` (to add comments or questions before approving), `Approve` (this means you have reviewed it and are OK with the changes; you will be listed as a reviewer), or `Request changes` (to indicate a bug or other serious problem), and then press `Submit Review`. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From mpaus at openjdk.java.net Fri Apr 3 15:10:39 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Fri, 3 Apr 2020 15:10:39 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. Marked as reviewed by mpaus (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Fri Apr 3 15:23:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Apr 2020 15:23:39 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Fri, 3 Apr 2020 02:11:12 GMT, Thiago Milczarek Sayao wrote: >> Test on 16.04 (without Webkit - it does not build on 16.04 anymore) >> >> Updated April 2nd. >> >> ![image](https://user-images.githubusercontent.com/30704286/78316727-c14db300-7536-11ea-86e9-4d5c56e4d92c.png) >> >> Note: DatePickerTest works when run alone. > > I will keep testing it, but I think it's looking good. I see a lot of work going into this. In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the RFR thread and not a comment in the PR. @tsayao When you are ready, please send a short email (not a reply to any existing message) to openjfx-dev at openjdk.java.net with the following: 1. A short summary of the proposed enhancement 2. The goals of the proposed enhancement 3. A description of the proposed changes (basically, the bullet items from the description of this PR) 4. A pointer to this PR for reference I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; review comments in the PR aren't the best way to have that discussion. We aren't following the formal JEP process for JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. Finally, I note that this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther along in the review process. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From Rony.Flatscher at wu.ac.at Fri Apr 3 16:57:29 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Fri, 3 Apr 2020 18:57:29 +0200 Subject: Question ad CSR (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Message-ID: <25a21904-3fed-a089-6387-f8daeb524447@wu.ac.at> Hi Kevin, thank you for your feedback and actions! Ad "please create a CSR request and add link to it in JDK-8238080": preliminarily researching [CSR FAQ] (https://wiki.openjdk.java.net/display/csr/CSR+FAQs) the question "Q: How do I create a CSR ?" gets answered with: > "A: _Do not directly create a CSR from the Create Menu._ JIRA will let you do this right up until _the moment you try to save it and find your typing was in vain._ Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.". Looking at [JDK-8238080] (https://bugs.openjdk.java.net/browse/JDK-8238080) there is no possibility for me to follow the above advice as I have no "More" button/link to select! The reason probably being that I cannot log on. Once I have the CSR text formulated (may take a little while) what should I do with it? ---rony On 03.04.2020 01:21, Kevin Rushforth wrote: > Hi Rony, > > I see that you updated the PR and sent it for review. > > Before we formally review it in the PR, let's finish the discussion as to whether this is a useful > feature, and if so, what form this feature should take. > > From my point of view, this does seem like a useful feature. Would other users of FXML benefit > from it? > > I'm not certain whether we want it to be implicit, compiling the script if the script engine in > question implements Compilable, or via a new keyword or tag. What are the pros / cons? > > What do others think? > > In either case, we would need to make sure that this doesn't present any security concerns in the > presence of a security manager. As long as a user-provided class is on the stack, it will be fine, > but we would need to ensure that. > > -- Kevin > > > On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >> pull request I would kindly request a review of this pull request! >> >> Here the URL: , title changed to: "8238080: FXMLLoader: if >> script engines implement javax.script.Compilable compile scripts". >> >> ---rony >> >> >> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>> has an appropriate test unit going with it as well, please review. >>> >>> There should be no compatibility issue with this implementation. >>> >>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>> language process instruction (e.g. ) contains an appropriate attribute with a >>> value >>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>> respective solution as well. >>> >>> ---rony >>> >>> [1] "Implementation and test unit": >>> >>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>> scripts": >>> >>> >>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>> >>> >>> >>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>> >>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>> the concept). >>>> >>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>> >>>> -- Kevin >>>> >>>> >>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>> Just filed a RFE with the following information: >>>>> >>>>> ??? * Component: >>>>> ??????? o JavaFX >>>>> >>>>> ??? * Subcomponent: >>>>> ??????? o fxml: JavaFX FXML >>>>> >>>>> ??? * Synopsis: >>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>> >>>>> ??? * Descriptions: >>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>> (javax.script.ScriptEngine >>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>> language in >>>>> ????????? the FXML file. >>>>> >>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>> could >>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>> using >>>>> ????????? its eval() methods. >>>>> >>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>> invocations, >>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>> onMouseMove) >>>>> ????????? which may be repetitevly invoked and evaluated." >>>>> >>>>> ??? * System /OS/Java Runtime Information: >>>>> ??????? o "All systems." >>>>> >>>>> Received the internal review ID: "9063426" >>>>> >>>>> ---rony From kevin.rushforth at oracle.com Fri Apr 3 17:33:33 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Apr 2020 10:33:33 -0700 Subject: Question ad CSR (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <25a21904-3fed-a089-6387-f8daeb524447@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <25a21904-3fed-a089-6387-f8daeb524447@wu.ac.at> Message-ID: <72d541da-7418-1c4b-2b0c-a6b00fc72b30@oracle.com> Regarding the CSR, that's usually done after the enhancement is agreed upon in principle, and the review is far enough along that you are ready to write up the spec changes, new API, and/or new interfaces. Since you don't have direct JBS access you will need a sponsor to do that part for you, in which case, creating a comment in the PR with the contents of the CSR is the way to go (once we get to that point). Unless there ends up being new public API, this will be mainly the spec changes in FXMLLoader and the "Introduction to FXML" guide. -- Kevin On 4/3/2020 9:57 AM, Rony G. Flatscher wrote: > Hi Kevin, > > thank you for your feedback and actions! > > Ad "please create a CSR request and add link to it in JDK-8238080": preliminarily researching [CSR > FAQ] (https://wiki.openjdk.java.net/display/csr/CSR+FAQs) the question "Q: How do I create a CSR ?" > gets answered with: > >> "A: _Do not directly create a CSR from the Create Menu._ JIRA will let you do this right up until > _the moment you try to save it and find your typing was in vain._ Instead you should go to the > target bug, select "More", and from the drop down menu select "Create CSR". This is required to > properly associate the CSR with the main bug, just as is done for backports.". > > Looking at [JDK-8238080] (https://bugs.openjdk.java.net/browse/JDK-8238080) there is no possibility > for me to follow the above advice as I have no "More" button/link to select! The reason probably > being that I cannot log on. > > Once I have the CSR text formulated (may take a little while) what should I do with it? > > ---rony > > > On 03.04.2020 01:21, Kevin Rushforth wrote: >> Hi Rony, >> >> I see that you updated the PR and sent it for review. >> >> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >> feature, and if so, what form this feature should take. >> >> From my point of view, this does seem like a useful feature. Would other users of FXML benefit >> from it? >> >> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >> >> What do others think? >> >> In either case, we would need to make sure that this doesn't present any security concerns in the >> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >> but we would need to ensure that. >> >> -- Kevin >> >> >> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >>> pull request I would kindly request a review of this pull request! >>> >>> Here the URL: , title changed to: "8238080: FXMLLoader: if >>> script engines implement javax.script.Compilable compile scripts". >>> >>> ---rony >>> >>> >>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>>> has an appropriate test unit going with it as well, please review. >>>> >>>> There should be no compatibility issue with this implementation. >>>> >>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>> value >>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>>> respective solution as well. >>>> >>>> ---rony >>>> >>>> [1] "Implementation and test unit": >>>> >>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>> scripts": >>>> >>>> >>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>> >>>> >>>> >>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>> >>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>>> the concept). >>>>> >>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>> Just filed a RFE with the following information: >>>>>> >>>>>> ??? * Component: >>>>>> ??????? o JavaFX >>>>>> >>>>>> ??? * Subcomponent: >>>>>> ??????? o fxml: JavaFX FXML >>>>>> >>>>>> ??? * Synopsis: >>>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>> >>>>>> ??? * Descriptions: >>>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>> (javax.script.ScriptEngine >>>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>>> language in >>>>>> ????????? the FXML file. >>>>>> >>>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>>> could >>>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>> using >>>>>> ????????? its eval() methods. >>>>>> >>>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>> invocations, >>>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>> onMouseMove) >>>>>> ????????? which may be repetitevly invoked and evaluated." >>>>>> >>>>>> ??? * System /OS/Java Runtime Information: >>>>>> ??????? o "All systems." >>>>>> >>>>>> Received the internal review ID: "9063426" >>>>>> >>>>>> ---rony From kevin.rushforth at oracle.com Fri Apr 3 18:15:15 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Apr 2020 11:15:15 -0700 Subject: Alternatives for JDK-8185886: Improve scrolling performance of TableView and TreeTableView Message-ID: We now have two pull requests under review that propose to solve the poor scrolling performance of TableView and TreeTableView, as tracked by JDK-8185886 [1] The first one, PR #108 [2], proposes a change in the bindings ExpressionHelper code relating to the cleaning up of listeners (changing the array-based implementation to a Map). It is a change in javafx.base to make the existing operations that TableView / TreeTableView do less expensive. The second one, PR #125 [3], proposes to address the problem by eliminating the need for cleaning up a large numbers of bindings. This approach changes the javafx.controls code used by TableView, and doesn't touch the binding code. It would be helpful to discuss which approach to take on this list, so we aren't independently reviewing both PRs. I don't yet have an opinion on which way to go, but I will note a couple pros / cons of each approach. PR #108 is both a more fundamental change and a simpler change. It changes the characteristics (memory footprint, performance) of a class that is used by far more that just TableView and TreeTableView. This is both a potential benefit and risk. If done in such a way that there are no regressions (functional, memory, or performance), it could benefit more than just the scrolling issue in question. By contrast, it has the potential to impact other use cases negatively, mainly from a performance or memory point of view, since the logic changes are relatively simple, and should be largely "behavior neutral". PR #125 is a more targeted change, impacting only the two controls in question, but is a more complicated change from a logic point of view. I am concerned primarily with any unintended behavioral changes. Both of them will need to be very well tested to ensure that there are no regressions. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8185886 [2] https://github.com/openjdk/jfx/pull/108 [3] https://github.com/openjdk/jfx/pull/125 From swpalmer at gmail.com Fri Apr 3 19:15:37 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 3 Apr 2020 15:15:37 -0400 Subject: Alternatives for JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: <0DF6AB39-810A-4E6C-960A-D30778E66B63@gmail.com> Assuming testing and performance/memory analysis leads to the conclusion that the risks are worth it, would it make sense to do both? Would we get a greater benefit from the combined effects? Or is the incremental improvement of including the second fix (whichever it may be) no longer significant enough to bother with? Scott > On Apr 3, 2020, at 2:15 PM, Kevin Rushforth wrote: > > ?We now have two pull requests under review that propose to solve the poor scrolling performance of TableView and TreeTableView, as tracked by JDK-8185886 [1] > > The first one, PR #108 [2], proposes a change in the bindings ExpressionHelper code relating to the cleaning up of listeners (changing the array-based implementation to a Map). It is a change in javafx.base to make the existing operations that TableView / TreeTableView do less expensive. > > The second one, PR #125 [3], proposes to address the problem by eliminating the need for cleaning up a large numbers of bindings. This approach changes the javafx.controls code used by TableView, and doesn't touch the binding code. > > It would be helpful to discuss which approach to take on this list, so we aren't independently reviewing both PRs. > > I don't yet have an opinion on which way to go, but I will note a couple pros / cons of each approach. > > PR #108 is both a more fundamental change and a simpler change. It changes the characteristics (memory footprint, performance) of a class that is used by far more that just TableView and TreeTableView. This is both a potential benefit and risk. If done in such a way that there are no regressions (functional, memory, or performance), it could benefit more than just the scrolling issue in question. By contrast, it has the potential to impact other use cases negatively, mainly from a performance or memory point of view, since the logic changes are relatively simple, and should be largely "behavior neutral". > > PR #125 is a more targeted change, impacting only the two controls in question, but is a more complicated change from a logic point of view. I am concerned primarily with any unintended behavioral changes. > > Both of them will need to be very well tested to ensure that there are no regressions. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8185886 > [2] https://github.com/openjdk/jfx/pull/108 > [3] https://github.com/openjdk/jfx/pull/125 > From kevin.rushforth at oracle.com Fri Apr 3 19:22:04 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Apr 2020 12:22:04 -0700 Subject: Alternatives for JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <0DF6AB39-810A-4E6C-960A-D30778E66B63@gmail.com> References: <0DF6AB39-810A-4E6C-960A-D30778E66B63@gmail.com> Message-ID: <72cfbf06-9c6b-5b16-82ea-10cca915918c@oracle.com> That's a fair question. Hard to say, but my guess is that if we do the first, the incremental improvements of the second might not be worth the effort or risk. And if we go with the second, we would need another test case that hits the slow iteration problem when removing a listener from a large array. -- Kevin On 4/3/2020 12:15 PM, Scott Palmer wrote: > Assuming testing and performance/memory analysis leads to the conclusion that the risks are worth it, would it make sense to do both? Would we get a greater benefit from the combined effects? Or is the incremental improvement of including the second fix (whichever it may be) no longer significant enough to bother with? > > > Scott > >> On Apr 3, 2020, at 2:15 PM, Kevin Rushforth wrote: >> >> ?We now have two pull requests under review that propose to solve the poor scrolling performance of TableView and TreeTableView, as tracked by JDK-8185886 [1] >> >> The first one, PR #108 [2], proposes a change in the bindings ExpressionHelper code relating to the cleaning up of listeners (changing the array-based implementation to a Map). It is a change in javafx.base to make the existing operations that TableView / TreeTableView do less expensive. >> >> The second one, PR #125 [3], proposes to address the problem by eliminating the need for cleaning up a large numbers of bindings. This approach changes the javafx.controls code used by TableView, and doesn't touch the binding code. >> >> It would be helpful to discuss which approach to take on this list, so we aren't independently reviewing both PRs. >> >> I don't yet have an opinion on which way to go, but I will note a couple pros / cons of each approach. >> >> PR #108 is both a more fundamental change and a simpler change. It changes the characteristics (memory footprint, performance) of a class that is used by far more that just TableView and TreeTableView. This is both a potential benefit and risk. If done in such a way that there are no regressions (functional, memory, or performance), it could benefit more than just the scrolling issue in question. By contrast, it has the potential to impact other use cases negatively, mainly from a performance or memory point of view, since the logic changes are relatively simple, and should be largely "behavior neutral". >> >> PR #125 is a more targeted change, impacting only the two controls in question, but is a more complicated change from a logic point of view. I am concerned primarily with any unintended behavioral changes. >> >> Both of them will need to be very well tested to ensure that there are no regressions. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8185886 >> [2] https://github.com/openjdk/jfx/pull/108 >> [3] https://github.com/openjdk/jfx/pull/125 >> From craig.cavanaugh at gmail.com Fri Apr 3 22:52:31 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Fri, 3 Apr 2020 18:52:31 -0400 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: References: Message-ID: Thanks! That was the trick! On Fri, Apr 3, 2020 at 6:52 AM Ajit Ghaisas wrote: > Hi Craig, > > Here is how I run the ButtonMnemonicPositionTest. > > $ export FX_LIB=/Users/AG/aaa/jfx/build/sdk/lib > $ cd /Users/AG/aaa/jfx/tests/manual/UI > $ javac --module-path $FX_LIB --add-modules javafx.controls > ButtonMnemonicPositionTest.java > $ java --module-path $FX_LIB --add-modules javafx.controls > ButtonMnemonicPositionTest > > Hope this helps. > > We can discuss further on your PR. > > Regards, > Ajit > > > > On 03-Apr-2020, at 3:56 PM, Craig Cavanaugh > wrote: > > > > I am trying to create a manual unit test for RFR: 8129123 and I'm using > the > > existing ButtonMnemonicPositionTest.java as a template to make sure > > everything is working correctly. > > > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > > openjdk. > > openjfx is successfully compiling and passing tests following the wiki > > instructions > > > > I'm able to compile ButtonMnemonicPositionTest successfully as shown > below. > > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest.java > > > > But attempts to run are failing despite a successful compile: > > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest > > Error: JavaFX runtime components are missing, and are required to run > this > > application > > > > I've also tried running using the modular-sdk after a Gradle build and no > > luck either after finding a recommendation on the list that the module > > approach should be used for testing. > > > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > > --add-modules=javafx.controls ButtonMnemonicPositionTest > > Error occurred during initialization of boot layer > > java.lang.module.FindException: Module javafx.controls not found > > > > I've been search through the list archive and haven't found a solution. > > I'm sure I'm doing something wrong. > > > > Some help please! > > > > Regards, > > Craig > > From tsayao at openjdk.java.net Fri Apr 3 23:44:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 23:44:02 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Fri, 3 Apr 2020 15:21:29 GMT, Kevin Rushforth wrote: >> I will keep testing it, but I think it's looking good. > > I see a lot of work going into this. > > In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the > openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the > RFR thread and not a comment in the PR. @tsayao When you are ready, please send a short email (not a reply to any > existing message) to openjfx-dev at openjdk.java.net with the following: > 1. A short summary of the proposed enhancement > 2. The goals of the proposed enhancement > 3. A description of the proposed changes (basically, the bullet items from the description of this PR) > 4. A pointer to this PR for reference > > I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the > details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; > review comments in the PR aren't the best way to have that discussion. We aren't following the formal JEP process for > JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large > or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. Finally, I note that > this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther > along in the review process. @kevinrushforth Ok, will do as the instructions. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From craig.cavanaugh at gmail.com Sat Apr 4 00:05:15 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Fri, 3 Apr 2020 20:05:15 -0400 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: <20200403134747.Horde.uzvz028f4rZMXjJvWfnCEQ1@webmail.df.eu> References: <20200403134747.Horde.uzvz028f4rZMXjJvWfnCEQ1@webmail.df.eu> Message-ID: Jeanette, Thank you! Much appreciated and a much better approach than a manual test. Well on my way now! Thanks, Craig On Fri, Apr 3, 2020 at 7:48 AM Jeanette Winzenburg wrote: > > Hi Craig, > > no manual test needed - you can implement a normal (unit) test with > the help or VirtualFlowTestUtils: grab the flow, get its first/last > visible cell and check whether their range includes to cell we want to > see, something like: > > @Test > public void testScrollInSkin() { > int index = 50; > comboBox.getSelectionModel().select(index); > comboBox.show(); > VirtualFlow> virtualFlow = getFlow(); > int first = virtualFlow.getFirstVisibleCell().getIndex(); > int last = virtualFlow.getLastVisibleCell().getIndex(); > assertTrue(" visible range [" + first + ", " + last + "] must > include " + index, > first <= index && index <= last); > } > > protected VirtualFlow> getFlow() { > VirtualFlow> virtualFlow = > (VirtualFlow>) > VirtualFlowTestUtils.getVirtualFlow(comboBox); > return virtualFlow; > } > > Have a look at the tests in test.xx.controls to understand how to > setup the test context. And have fun :) > > Zitat von Craig Cavanaugh : > > > I am trying to create a manual unit test for RFR: 8129123 and I'm using > the > > existing ButtonMnemonicPositionTest.java as a template to make sure > > everything is working correctly. > > > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > > openjdk. > > openjfx is successfully compiling and passing tests following the wiki > > instructions > > > > I'm able to compile ButtonMnemonicPositionTest successfully as shown > below. > > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest.java > > > > But attempts to run are failing despite a successful compile: > > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest > > Error: JavaFX runtime components are missing, and are required to run > this > > application > > > > I've also tried running using the modular-sdk after a Gradle build and no > > luck either after finding a recommendation on the list that the module > > approach should be used for testing. > > > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > > --add-modules=javafx.controls ButtonMnemonicPositionTest > > Error occurred during initialization of boot layer > > java.lang.module.FindException: Module javafx.controls not found > > > > I've been search through the list archive and haven't found a solution. > > I'm sure I'm doing something wrong. > > > > Some help please! > > > > Regards, > > Craig > > > > From tsayao at openjdk.java.net Sat Apr 4 00:55:58 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sat, 4 Apr 2020 00:55:58 GMT Subject: [Rev 43] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Only work-around Unity bug if Unity is the Window Manager (Ubuntu 16.04). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/f52f63be..acd54962 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.43 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.42-43 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From ebresie at gmail.com Sat Apr 4 01:25:15 2020 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 3 Apr 2020 20:25:15 -0500 Subject: Seeking help with latest master ... In-Reply-To: CABxFH2Fjkk2sNBq8524a_MK5vqbbxzsFxnpbzRez1v9Huh9J=g@mail.gmail.com References: b47033ae-9404-c870-98ab-fbd3a5687c4a@wu.ac.at 82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com 7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at e1c5f995-0d29-599b-0d19-f46308bc9182@wu.ac.at 104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com 76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at B3D01019-5F4C-47A3-AD38-79D6DF52EF8B@gmail.com cf87bdba-04f1-df69-b83d-5bb7c83dbcd6@wu.ac.at 364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at 364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at Message-ID: <029c38e1-83dd-4d08-ab13-b14cceeefa33@Erics-iPhone-X> Are you behind a proxy? I had problems with another application which required registering certificates and related credentials keys to be added for java. Eric Bresie Ebresie at gmail.com > On April 2, 2020 at 2:20:44 PM CDT, Johan Vos wrote: > I have no scientific evidence for this, but I remember issues related to > SSL with some JDK's as well, which may or may not be related to the cacerts > file that is bundled. > > - Johan > > On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher > wrote: > > > Being stuck (tried the previous working gradle 5.6.4, could get "gradle > > clean", but not further) in > > the end I just tried Java 14 and that allowed me to run "gradle" > > successfully (currently building > > webkit to get going again). Just wanted to let interested readers know. > > (Would be great though, if > > it worked with the 11 LTS version as well.) > > > > ---rony > > > > > > On 31.03.2020 20:36, Rony G. Flatscher wrote: > > > On 31.03.2020 20:21, Scott Palmer wrote: > > > > > Could not resolve all dependencies for configuration ':apps:lucene'. > > > > > Multiple build operations failed. > > > > java.lang.ExceptionInInitializerError > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > java.lang.ExceptionInInitializerError > > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > > > > > > > > This to me looks like it may be failing to make an https connection to > > a repository when > > > > attempting to download dependencies. > > > > > > > > There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when > > running gradle builds, see: > > > > https://github.com/gradle/gradle/issues/7842 > > > > > > > > Claims to be fixed, but maybe not? > > > > > > > > If it is related to Gradle changing java.home while compiling, I wonder > > if using --no-parallel > > > > might work around it? Of course try with --debug as well to see if it > > offers more clues. > > > Scott, thank you! > > > > > > Not having any knowledge about gradle I am unfortunately lost in this > > case. However, I used "gradle > > > --no-parallel --debug" which did not succeed but created a 1.2 MB text > > file which I keep temporarily > > > in my DrobBox at: < > > https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0 > > > . > > > > > > Will have to leave in a few minutes for today so can only try other > > things tomorrow. > > > > > > ---rony > > > > From github.com+636962+ccavanaugh at openjdk.java.net Sat Apr 4 07:36:47 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sat, 4 Apr 2020 07:36:47 GMT Subject: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: <6zE9O-VX_9Xpoxv73bbW9DKjwE4LzhRXnWF_PmHyiVo=.a8cbcc0c-3000-452c-8a0f-106e155b1050@github.com> > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Craig Cavanaugh has updated the pull request incrementally with one additional commit since the last revision: Unit test for JDK_8129123 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/136/files - new: https://git.openjdk.java.net/jfx/pull/136/files/8e06c9e1..229a7fd2 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/136/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/136/webrev.00-01 Stats: 47 lines in 1 file changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/136/head:pull/136 PR: https://git.openjdk.java.net/jfx/pull/136 From craig.cavanaugh at gmail.com Sat Apr 4 07:59:10 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Sat, 4 Apr 2020 03:59:10 -0400 Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: My use case which is driving the fix for this bug is user expectation in an open source application (https://github.com/ccavanaugh/jgnash). When a user makes an edit to an existing transaction, the expectation is the prior selected ComboBox value is visible when the list is displayed, otherwise it gives the impression they made an error or something is wrong. I think the root cause of the poor experience is seeing the correct value when collapsed, and then not seeing it or it's selection when expanded. Also, scrolling automatically was the default behavior for Swing. My current work around is an extended ComboBox that listens for a mouse click or key events and then scrolls the list view. On Fri, Apr 3, 2020 at 8:19 AM Jeanette Winzenburg < fastegal at openjdk.java.net> wrote: > On Fri, 3 Apr 2020 12:03:33 GMT, Jeanette Winzenburg > wrote: > > >>> Can you please provide a unit test? One that fails before your fix and > passes after your fix. > >> > >> I can provide a manual test the next couple of days that demonstrates > it before and after, but I'm not sure how to > >> create an automated unit test because the issue is visual. > > > > A quick snippet of how-to write a unit test (for setup see other tests > in controls) that will fail before and pass > > after the change: > > @Test > > public void testScrollInSkin() { > > int index = 50; > > comboBox.getSelectionModel().select(index); > > comboBox.show(); > > VirtualFlow> virtualFlow = getFlow(); > > int first = virtualFlow.getFirstVisibleCell().getIndex(); > > int last = virtualFlow.getLastVisibleCell().getIndex(); > > assertTrue(" visible range [" + first + ", " + last + "] must > include " + index, > > first <= index && index <= last); > > } > > > > protected VirtualFlow> getFlow() { > > VirtualFlow> virtualFlow = > (VirtualFlow>) > > VirtualFlowTestUtils.getVirtualFlow(comboBox); > > return virtualFlow; > > } > > A couple of comments to the bug (and fix) itself: > > - is it really a bug or a nice-to-have enhancement? couldn't find an > example in win, didn't try too hard and nowadays, > such plain combos are not a really frequent > - while none of the virtualized controls (nor ChoiceBox) combines > selection with scrolling to the selected item. For > combo and choice, I see no reason not make it the default behavior. We > need to make certain it behaves "naturally" when > navigating in the open popup. instead of catching every list.select (and > not forget the unselect) we might consider > doing it in a showing handler alternatively, we might consider to go > deeper and support it directly in the listView > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/136 > From fastegal at swingempire.de Sat Apr 4 10:21:21 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 04 Apr 2020 12:21:21 +0200 Subject: Where to discuss options/scope of an issue (and its pull request)? Message-ID: <20200404122121.Horde.wU3DIRPGeKDh63C8wt3MZg1@webmail.df.eu> as an example take f.i. https://bugs.openjdk.java.net/browse/JDK-8129123 (and its pull request https://github.com/openjdk/jfx/pull/136 with a good starter to a solution) has open questions - for me, at least :) Places to discuss: the pull request? the mailing list? the issue? Where would such a debate - assuming there's some lasting value in it - be best done such that it wouldn't be lost? -- Jeanette From kevin.rushforth at oracle.com Sat Apr 4 13:10:21 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 4 Apr 2020 06:10:21 -0700 Subject: Where to discuss options/scope of an issue (and its pull request)? In-Reply-To: <20200404122121.Horde.wU3DIRPGeKDh63C8wt3MZg1@webmail.df.eu> References: <20200404122121.Horde.wU3DIRPGeKDh63C8wt3MZg1@webmail.df.eu> Message-ID: In general a discussion like this can happen in the pull request as part of the review. All PR comments are forwarded to the mailing list anyway. -- Kevin On 4/4/2020 3:21 AM, Jeanette Winzenburg wrote: > > as an example take f.i. > https://bugs.openjdk.java.net/browse/JDK-8129123 (and its pull request > https://github.com/openjdk/jfx/pull/136 with a good starter to a > solution) has open questions - for me, at least :) > > Places to discuss: the pull request? the mailing list? the issue? > Where would such a debate - assuming there's some lasting value in it > - be best done such that it wouldn't be lost? > > -- Jeanette > From Rony.Flatscher at wu.ac.at Sat Apr 4 13:58:27 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sat, 4 Apr 2020 15:58:27 +0200 Subject: Seeking help with latest master ... In-Reply-To: References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> Message-ID: On 02.04.2020 21:20, Johan Vos wrote: > I have no scientific evidence for this, but I remember issues related to SSL with some JDK's as > well, which may or may not be related to the cacerts file that is bundled. When hitting this problem the JDK was the same that has worked flawlessly with the previous versions of OpenFX. It looks as if Java 14 is needed for the latest OpenFX master, at least for my installation. ---rony > > On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher > wrote: > > Being stuck (tried the previous working gradle 5.6.4, could get "gradle clean", but not > further) in > the end I just tried Java 14 and that allowed me to run "gradle" successfully (currently building > webkit to get going again). Just wanted to let interested readers know. (Would be great though, if > it worked with the 11 LTS version as well.) > > ---rony > > > On 31.03.2020 20:36, Rony G. Flatscher wrote: > > On 31.03.2020 20:21, Scott Palmer wrote: > >>> Could not resolve all dependencies for configuration ':apps:lucene'. > >> ????? > Multiple build operations failed. > >> ??????????? java.lang.ExceptionInInitializerError > >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> ???????? > java.lang.ExceptionInInitializerError > >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> > >> > >> This to me looks like it may be failing to make an https connection to a repository when > >> attempting to download?dependencies. > >> > >> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running gradle builds, > see:? > >> https://github.com/gradle/gradle/issues/7842 > >> > >> Claims to be fixed, but maybe not? > >> > >> If it is related to Gradle?changing java.home while compiling, I wonder if using?--no-parallel > >> might work around it?? Of course try with --debug as well to see if it offers more clues. > > Scott, thank you! > > > > Not having any knowledge about gradle I am unfortunately lost in this case. However, I used? > "gradle > > --no-parallel --debug" which did not succeed but created a 1.2 MB text file which I keep > temporarily > > in my DrobBox at: . > > > > Will have to leave in a few minutes for today so can only try other things tomorrow. > > > > ---rony > From Rony.Flatscher at wu.ac.at Sat Apr 4 13:59:50 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sat, 4 Apr 2020 15:59:50 +0200 Subject: Seeking help with latest master ... In-Reply-To: <029c38e1-83dd-4d08-ab13-b14cceeefa33@Erics-iPhone-X> References: <029c38e1-83dd-4d08-ab13-b14cceeefa33@Erics-iPhone-X> Message-ID: On 04.04.2020 03:25, Eric Bresie wrote: > Are you behind a proxy? I had problems with another application which required registering certificates and related credentials keys to be added for java. No, no proxy server (my setup has direct access). ---rony > On April 2, 2020 at 2:20:44 PM CDT, Johan Vos wrote: > I have no scientific evidence for this, but I remember issues related to > SSL with some JDK's as well, which may or may not be related to the cacerts > file that is bundled. > > - Johan > > On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher > wrote: > >>> Being stuck (tried the previous working gradle 5.6.4, could get "gradle >>> clean", but not further) in >>> the end I just tried Java 14 and that allowed me to run "gradle" >>> successfully (currently building >>> webkit to get going again). Just wanted to let interested readers know. >>> (Would be great though, if >>> it worked with the 11 LTS version as well.) >>> >>> ---rony >>> >>> >>> On 31.03.2020 20:36, Rony G. Flatscher wrote: >>>> On 31.03.2020 20:21, Scott Palmer wrote: >>>>>> Could not resolve all dependencies for configuration ':apps:lucene'. >>>>>> Multiple build operations failed. >>>>> java.lang.ExceptionInInitializerError >>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>>> java.lang.ExceptionInInitializerError >>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>> >>>>> >>>>> This to me looks like it may be failing to make an https connection to >>> a repository when >>>>> attempting to download dependencies. >>>>> >>>>> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when >>> running gradle builds, see: >>>>> https://github.com/gradle/gradle/issues/7842 >>>>> >>>>> Claims to be fixed, but maybe not? >>>>> >>>>> If it is related to Gradle changing java.home while compiling, I wonder >>> if using --no-parallel >>>>> might work around it? Of course try with --debug as well to see if it >>> offers more clues. >>>> Scott, thank you! >>>> >>>> Not having any knowledge about gradle I am unfortunately lost in this >>> case. However, I used "gradle >>>> --no-parallel --debug" which did not succeed but created a 1.2 MB text >>> file which I keep temporarily >>>> in my DrobBox at: < >>> https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0 >>>> . >>>> >>>> Will have to leave in a few minutes for today so can only try other >>> things tomorrow. >>>> ---rony From Rony.Flatscher at wu.ac.at Sat Apr 4 16:03:37 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sat, 4 Apr 2020 18:03:37 +0200 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Message-ID: Hi Kevin, On 03.04.2020 01:21, Kevin Rushforth wrote: > I see that you updated the PR and sent it for review. > > Before we formally review it in the PR, let's finish the discussion as to whether this is a useful > feature, and if so, what form this feature should take. > > From my point of view, this does seem like a useful feature. Would other users of FXML benefit > from it? Script code should be executed faster after compilation, so any FXML page that hosts script code may benefit. The benefits depend on the type of script (and maybe its size and its complexity) and also on the types of event handlers the scripts serve, e.g. move or drag event handlers may benefit significantly. This is because repeated invocation of compiled script event handlers do not cause the reparsing of that script's source and interpreting it on each invocation, which may be expensive depending on the script engine, but rather allows the immediate evaluation/execution of the compiled script by the script engine. > I'm not certain whether we want it to be implicit, compiling the script if the script engine in > question implements Compilable, or via a new keyword or tag. What are the pros / cons? In principle there are three possibilities: 1) If a script engine implements javax.script.Compilable, compile the script and execute the compiled version. In the case of event handlers compile and buffer the compiled script and execute the compiled script each time its registered event fires. o Pro: immediately benefits all existing FXML pages that host scripts o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail compiling but have been employed successfully in interpreted mode 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML language PI that switches on compilation of scripts hosted in FXML definitions if the script engine implements the javax.script.Compilable interface. If missing it would default to "false". (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the script engine supports it. It would be an error if the "compile" PI was present, but the "language" PI was not.) o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the language PI gets changed o Con: benefit not made available automatically to existing FXML pages that host scripts 3) Another possibility would be to define a boolean attribute/property "compile" for script and node elements and only compile the scripts, if the property is set to true o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed accordingly o Con: potential benefit not made available automatically to existing FXML pages that host scripts 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be overruled individually by 3. The question would be whether 2 or/and 3 are really necessary as it can be expected that compilation of scripts by the script engines would find the same errors as while interpreting the very same scripts (if not, the script engine is badly broken and it could be argued that then the interpretation part of the script engine might be expected to be broken as well which would be quite dangerous from an integrity POV; the same consideration applies as well if the execution of the compiled script would behave differently to interpreting the very same script by the same script engine). The current WIP implements 1 above and includes an appropriate test unit. > What do others think? > In either case, we would need to make sure that this doesn't present any security concerns in the > presence of a security manager. As long as a user-provided class is on the stack, it will be fine, > but we would need to ensure that. The compilation of scripts needs to be done by the Java script engines (implementing both, javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled scripts ([javax.script.CompiledScript] (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). ---rony > On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >> pull request I would kindly request a review of this pull request! >> >> Here the URL: , title changed to: "8238080: FXMLLoader: if >> script engines implement javax.script.Compilable compile scripts". >> >> ---rony >> >> >> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>> has an appropriate test unit going with it as well, please review. >>> >>> There should be no compatibility issue with this implementation. >>> >>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>> language process instruction (e.g. ) contains an appropriate attribute with a >>> value >>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>> respective solution as well. >>> >>> ---rony >>> >>> [1] "Implementation and test unit": >>> >>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>> scripts": >>> >>> >>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>> >>> >>> >>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>> >>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>> the concept). >>>> >>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>> >>>> -- Kevin >>>> >>>> >>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>> Just filed a RFE with the following information: >>>>> >>>>> ??? * Component: >>>>> ??????? o JavaFX >>>>> >>>>> ??? * Subcomponent: >>>>> ??????? o fxml: JavaFX FXML >>>>> >>>>> ??? * Synopsis: >>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>> >>>>> ??? * Descriptions: >>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>> (javax.script.ScriptEngine >>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>> language in >>>>> ????????? the FXML file. >>>>> >>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>> could >>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>> using >>>>> ????????? its eval() methods. >>>>> >>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>> invocations, >>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>> onMouseMove) >>>>> ????????? which may be repetitevly invoked and evaluated." >>>>> >>>>> ??? * System /OS/Java Runtime Information: >>>>> ??????? o "All systems." >>>>> >>>>> Received the internal review ID: "9063426" >>>>> >>>>> ---rony From tsayao at openjdk.java.net Sun Apr 5 00:05:43 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 00:05:43 GMT Subject: [Rev 44] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Separate the new gtk glass impl ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/acd54962..748d81bd Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.44 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.43-44 Stats: 4073 lines in 40 files changed: 2479 ins; 831 del; 763 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From thiago.sayao at clamed.com.br Sun Apr 5 00:13:58 2020 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 00:13:58 +0000 Subject: Discussion on adding a new gtk glass backend Message-ID: Summary ------- * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. PR: https://github.com/openjdk/jfx/pull/77 Goals ----- * Make Linux a first-class OpenJFX platform (see Motivation); * Simplify the code and reduce it's size; * Update to gtk3 (it was originally a port from gtk2); * Remove unused code (such as applets and web start); * Prepare the ground for a possible future Wayland support. Non-Goals --------- * Make Wayland work now. Success Metrics --------------- * Reduced code size (999 lines removed); * Pass robot tests on Ubuntu 16.04, 18.04 and 20.04, except some of them that always fails; * Pass manual testing using the Drag and Drop app (java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls) with gtk2 and gtk3 backends; * Pass manual testing using Ensemble 8 with either gtk2 and gtk3 backends. Motivation ---------- While working with OpenJFX on Linux, I have fixed some of it's bugs: * Wrong stage gets focused after modal stage creation: https://bugs.openjdk.java.net/browse/JDK-8227366 * Multi-level Stage::initOwner can crash gnome-shell or X.org server: https://bugs.openjdk.java.net/browse/JDK-8226537 * DragAndDrop no longer works with GTK3: https://bugs.openjdk.java.net/browse/JDK-8211302 * [Linux] Dialog height switches between correct and too small when showing and hiding a Dialog repeatedly: https://bugs.openjdk.java.net/browse/JDK-8193502 * Focus goes to wrong Window when dismissing an Alert: https://bugs.openjdk.java.net/browse/JDK-8210973 * [GTK3] Stage sometimes shown at top-left before moving to correct position: https://bugs.openjdk.java.net/browse/JDK-8212060 * Window order is not correct when Modality.WINDOW_MODAL: https://bugs.openjdk.java.net/browse/JDK-8220272 * Port Linux glass drag source (DND) to use gtk instead of gdk: https://bugs.openjdk.java.net/browse/JDK-8225571 * Dialog's preferred size no longer accommodates multi-line strings: https://bugs.openjdk.java.net/browse/JDK-8232811 While fixing those bugs I got familiar with the code and saw many opportunities to make it better (as the goal lists). One special case is that X.org needs a window manager to decorate windows (such as Unity, Metacity, Mutter, and many others), so the toolkit does not know about decoration sizes - it must ask to the window manager trough an extension (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html). OpenJFX can set sizes by content size and window size - so there is a complexity on the "window size" option - it must know decoration sizes. I could not fully understand the current code because it had a high cyclomatic complexity - this was the main motivation to make it simplier (see JBS https://bugs.openjdk.java.net/browse/JDK-8232811 - it fixes the bug, but it's not very "clean"). I refer to "make Linux a first-class platform" on the goal because the PR makes room for more improvements (such as easier to fix bugs). Description ----------- This glass gtk replacement will be active if passing -Djdk.gtk.new=true to the jvm. The proposal is to have this side by side with current Linux glass so people can test and eventually it may become the default glass implementation on Linux. * Note: No public API was modified; * Specific Code Changes * glass_window.cpp / glass_window.h - Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore); - Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; - Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); - Frame Extents: Removed the code to request extents and gtk already does it by default; - Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJFX uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. - Other Size calculation changes: - Use gtk_window_set_default_size() for initial size which is the appropriate function; - Gravity is now ignored as it is on Windows glass impl; - Avoid sending same sizes to Java (duplicated events); - Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); - Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on apply_geometry(). - Mouse grab: Reworked it to use to correct functions according to gtk+ version; - Draw: Reworked it to use the correct calls accord to gtk+ version changes; - Fixed JDK-8237491; - Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; - Reorganized function order on glass_window.cpp to match glass_window.h - Only work-around Unity bug if window manager is Unity * GlassCursor.cpp - Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; - Reworked Gtk+2 to use a function instead of manual calls to find the cursor; * GtkWindow.java - Moved the extents special case to native glass; * GlassApplication.cpp - Removed Gdk events where possible (it's now on glass_window as signals); - Removed applet/web start code; * GlassView.cpp - Changes to reflect frame extents rework on glass_window * GlassWindow.cpp - WindowContextTop -> WindowContext - Removed applet / web start code; - Removed frame extents (which is not called anymore due to GtkWindow.java change); * glass_general.cpp - Removed functions that became unused; - Added is_grab_disabled() that is used on glass_window * glass_window_ime.cpp - WindowContextTop -> WindowContext; * glass_dnd.cpp / glass_dnd.h - Ported to Gtk signals; - Use all possible image formats (supported by GdkPixbuf / OpenJFX) - .gif is now possible (for ex.); - Allow COMPOUND_TEXT; - Do not request content while dragging; - Reduce overall code size. Testing ------- While fixing the bugs listed on "Motivation" I have developed some robot tests that must pass along with the previosly existing ones. Note: Non-robot tests do not apply since the changes are glass specific. Note2: Must pass -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' to gradle. Risks and Assumptions --------------------- * Testing were done since Ubuntu 16.04 (released 4 years ago) on x64 machines; * Tested with Mutter (default gnome) and Unity (default on 16.04) - should work on other window managers that follows the specs; * It's a big change - well tested but might still break something. Dependencies ----------- * Simplify and update glass gtk backend: https://bugs.openjdk.java.net/browse/JDK-8236651 * Maximized undecorated stage behaves inconsistently on different platforms : https://bugs.openjdk.java.net/browse/JDK-8237491 From jvos at openjdk.java.net Sun Apr 5 10:24:17 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 5 Apr 2020 10:24:17 GMT Subject: RFR: 8242163: Android keyboard integration fails Message-ID: Fix the code that integrates TextField/TextArea with the android keyboard Fix for #8242163 ------------- Commit messages: - Fix the code that integrates TextField/TextArea with the android keyboard Changes: https://git.openjdk.java.net/jfx/pull/157/files Webrev: https://webrevs.openjdk.java.net/jfx/157/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242163 Stats: 267 lines in 9 files changed: 148 ins; 108 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/157.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/157/head:pull/157 PR: https://git.openjdk.java.net/jfx/pull/157 From jvos at openjdk.java.net Sun Apr 5 14:16:21 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 5 Apr 2020 14:16:21 GMT Subject: RFR: 8242167: ios keyboard handling Message-ID: Use JavaFX controls for TextField and TextArea instead of the native iOS ones This fixes JDK-8242167 ------------- Commit messages: - Use JavaFX controls for TextField and TextArea instead of the native iOS ones Changes: https://git.openjdk.java.net/jfx/pull/158/files Webrev: https://webrevs.openjdk.java.net/jfx/158/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242167 Stats: 367 lines in 12 files changed: 288 ins; 76 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/158.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/158/head:pull/158 PR: https://git.openjdk.java.net/jfx/pull/158 From tsayao at openjdk.java.net Sun Apr 5 18:21:24 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 18:21:24 GMT Subject: [Rev 45] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: <9y6JPJ1hSwoodob6hNybRf9FbnXioKlVSiK2nCUZT2Q=.dc9b8be8-5701-405d-be15-54b750ba4c52@github.com> > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with five additional commits since the last revision: - Merge branch 'test2' into jdk_8236651 - Merge remote-tracking branch 'origin/test2' into test2 - Make gtk3 compile without deprecations - Make gtk3 compile without deprecations - Make gtk3 compile without deprecations ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/748d81bd..91d98466 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.45 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.44-45 Stats: 114 lines in 9 files changed: 77 ins; 4 del; 33 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Sun Apr 5 18:44:20 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 18:44:20 GMT Subject: [Rev 46] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment Fix Tab Prefer content size over window size. Fixes for ubuntu 16.04 (which delays frame extents) Just comment fixing More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Only work-around Unity bug if Unity is the Window Manager (Ubuntu 16.04). Separate the new gtk glass impl Make gtk3 compile without deprecations Make gtk3 compile without deprecations Make gtk3 compile without deprecations ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/91d98466..8973d385 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.46 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.45-46 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Sun Apr 5 20:24:13 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 20:24:13 GMT Subject: [Rev 47] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Smooth scrolling only possible with impl on java side ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/8973d385..2f83ce7b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.47 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.46-47 Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From ajoseph at openjdk.java.net Mon Apr 6 12:03:32 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 6 Apr 2020 12:03:32 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode Message-ID: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native threads for x86 to 1 MB. ------------- Commit messages: - 8242209: Increase web native thread stack size for x86 mode Changes: https://git.openjdk.java.net/jfx/pull/159/files Webrev: https://webrevs.openjdk.java.net/jfx/159/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242209 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/159.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/159/head:pull/159 PR: https://git.openjdk.java.net/jfx/pull/159 From arapte at openjdk.java.net Mon Apr 6 12:30:32 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 12:30:32 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 868: > 867: } > 868: gesturesBeganMask |= theMask; > 869: } Rotate and Magnify gestures can be started and performed together. If Rotate is already in progress then `gesturesBeganMask` would be set to `4`. and If we start a Magnify gesture while the Rotate is not ended then `sendJavaGestureBeginEvent` will not be executed for Magnify gesture. However the application currently receives the synthetic `ZOOM_STARTED` event, which is generated as a result of call to `sendJavaGestureEvent` and not an event generated from here, A change in inner `if` statement as below can fix the issue, if ((gesturesBeganMask & theMask) == 0) { gesturesBeganMask |= theMask; [self sendJavaGestureBeginEvent:theEvent] } ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From arapte at openjdk.java.net Mon Apr 6 12:34:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 12:34:52 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 888: > 887: } > 888: } > 889: } In continuation to the change in `maybeBeginGestureWithEvent`, we would need to remove the inner `if` condition change here, if ((gesturesBeganMask & theMask) != 0) { gesturesBeganMask &= ~theMask; [self sendJavaGestureEndEvent:theEvent]; } ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Mon Apr 6 14:19:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 14:19:11 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Mon, 6 Apr 2020 12:28:21 GMT, Ambarish Rapte wrote: >> As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case >> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, >> `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile >> time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer >> guide: >> [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) >> Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification >> works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to >> link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK >> or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information >> from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the >> `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new >> local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, >> `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and >> the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the >> problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have >> since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. > > modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 868: > >> 867: } >> 868: gesturesBeganMask |= theMask; >> 869: } > > Rotate and Magnify gestures can be started and performed together. > If Rotate is already in progress then `gesturesBeganMask` would be set to `4`. > and If we start a Magnify gesture while the Rotate is not ended then `sendJavaGestureBeginEvent` will not be executed > for Magnify gesture. However the application currently receives the synthetic `ZOOM_STARTED` event, which is generated > as a result of call to `sendJavaGestureEvent` and not an event generated from here, > A change in inner `if` statement as below can fix the issue, > > if ((gesturesBeganMask & theMask) == 0) { > gesturesBeganMask |= theMask; > [self sendJavaGestureBeginEvent:theEvent] > } This is a good thought, and one I had initially considered, but didn't do for two related reasons: 1. The macOS NSEvent code that sends `beginGestureWithEvent` and `endGestureWithEvent` when the JDK is compiled with an older SDK doesn't send a begin call when starting a rotate gesture if a zoom gesture is already active, or vice versa. One goal of this change is to match the previous behavior to minimize risk. 2. More importantly, the existing logic is not expecting nested `sendJavaGestureBeginEvent` / `sendJavaGestureEndEvent` calls, and will not track the state correctly if they are nested. I did a quick test implementing your suggestion and confirmed that it misbehaves. Worth noting, the logic that synthesizes the begin and end gesture notifications that are sent by the Java gesture code already takes care of the case of switching from zoom to rotate and sends the correct sequence to the event listener. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From arapte at openjdk.java.net Mon Apr 6 15:02:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 15:02:55 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: <9rz1FQY9Jo0QLVHr_K6uQ2S9CZMqyHFIxdCXEgV-7rc=.1beb7dd7-cc05-4ab7-bf7f-0e1e79cf8630@github.com> On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/156 From arapte at openjdk.java.net Mon Apr 6 16:20:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 16:20:45 GMT Subject: RFR: 8241249: NPE in TabPaneSkin.perfromDrag Message-ID: This is a simple fix similar to [JDK-8237372](https://bugs.openjdk.java.net/browse/JDK-8237372). The NPE can occur if a MOUSE_DRAGGED is received by tab header without receiving MOUSE_PRESSED. The fix also corrects a typo error. `perfromDrag()` to `performDrag()` ------------- Commit messages: - 8241249: NPE in TabPaneSkin.perfromDrag Changes: https://git.openjdk.java.net/jfx/pull/160/files Webrev: https://webrevs.openjdk.java.net/jfx/160/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241249 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/160/head:pull/160 PR: https://git.openjdk.java.net/jfx/pull/160 From jskov at zoftcorp.dk Mon Apr 6 17:42:05 2020 From: jskov at zoftcorp.dk (Jesper Skov) Date: Mon, 6 Apr 2020 19:42:05 +0200 Subject: Fixing ToggleGroup synchronization Message-ID: Hi, I happened to fall over this issue: https://bugs.openjdk.java.net/browse/JDK-8198402 while reading another jfx PR. I have a shot at a fix: https://github.com/openjdk/jfx/compare/master...jskov:toggleGroupSync-JDK-8198402 But I was not entirely sure if just submitting a PR without saying hello first was OK? :) The OCA has been sent. Should I await some feedback from oracle-ca_us before I submit the PR? Cheers, Jesper From kevin.rushforth at oracle.com Mon Apr 6 18:42:30 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 6 Apr 2020 11:42:30 -0700 Subject: Fixing ToggleGroup synchronization In-Reply-To: References: Message-ID: <57514f7c-11c0-9f11-dcc9-71c24de15233@oracle.com> Hi Jesper, Welcome to OpenJFX. Yes, it's a fine idea to say hello, so that 's taken care of. I presume you have read the CONTRIBUTING guidelines (since you sent the OCA you probably have)? [1] Since your OCA has been sent, you can file a PR any time. It won't be marked as ready for review until your OCA is processed, though. When you do file it, choose "/signed" as the option to respond to the automated message. -- Kevin [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md On 4/6/2020 10:42 AM, Jesper Skov wrote: > Hi, > > I happened to fall over this issue: > > https://bugs.openjdk.java.net/browse/JDK-8198402 > > while reading another jfx PR. > > > I have a shot at a fix: > > https://github.com/openjdk/jfx/compare/master...jskov:toggleGroupSync-JDK-8198402 > > But I was not entirely sure if just submitting a PR without saying hello > first was OK? :) > > > The OCA has been sent. Should I await some feedback from oracle-ca_us > before I submit the PR? > > Cheers, > Jesper From kevin.rushforth at oracle.com Mon Apr 6 21:34:03 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 6 Apr 2020 14:34:03 -0700 Subject: Discussion on adding a new gtk glass backend In-Reply-To: References: Message-ID: Hi Thiago, Nice summary! As I mentioned offline, I am generally supportive of this, since I know how fragile the existing Linux Glass implementation is. Unsurprisingly, this has effectively turned into a rewrite of the Linux GTK glass port. It's going to need a very thorough review, including a security review, and that will take some time. Thank you for adding my offline suggestion of making this new implementation an optional library where the old and new versions of the glass library for Linux can coexist. This will allow making separate decisions about when it is ready to go in versus when it is ready to become the default; this is the only way it even has a chance of getting in for JavaFX 15 (and even then it's not a given). Since this is JavaFX only, the command line option should probably be "javafx.gtk..." rather than "jdk.gtk....", or at least something with "javafx" in the name, but that's a detail that can be worked out later. I have a couple high-level questions: 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? 2. How much of the reliance on GDK were you able to eliminate? I'd like to also hear from Johan and others -- especially other Linux app developers. -- Kevin On 4/4/2020 5:13 PM, Thiago Milczarek Sayao wrote: > Summary > ------- > > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > PR: https://github.com/openjdk/jfx/pull/77 > > Goals > ----- > > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > > Non-Goals > --------- > > * Make Wayland work now. > > > Success Metrics > --------------- > > * Reduced code size (999 lines removed); > * Pass robot tests on Ubuntu 16.04, 18.04 and 20.04, except some of them that always fails; > * Pass manual testing using the Drag and Drop app (java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls) with gtk2 and gtk3 backends; > * Pass manual testing using Ensemble 8 with either gtk2 and gtk3 backends. > > Motivation > ---------- > > While working with OpenJFX on Linux, I have fixed some of it's bugs: > > * Wrong stage gets focused after modal stage creation: https://bugs.openjdk.java.net/browse/JDK-8227366 > * Multi-level Stage::initOwner can crash gnome-shell or X.org server: https://bugs.openjdk.java.net/browse/JDK-8226537 > * DragAndDrop no longer works with GTK3: https://bugs.openjdk.java.net/browse/JDK-8211302 > * [Linux] Dialog height switches between correct and too small when showing and hiding a Dialog repeatedly: https://bugs.openjdk.java.net/browse/JDK-8193502 > * Focus goes to wrong Window when dismissing an Alert: https://bugs.openjdk.java.net/browse/JDK-8210973 > * [GTK3] Stage sometimes shown at top-left before moving to correct position: https://bugs.openjdk.java.net/browse/JDK-8212060 > * Window order is not correct when Modality.WINDOW_MODAL: https://bugs.openjdk.java.net/browse/JDK-8220272 > * Port Linux glass drag source (DND) to use gtk instead of gdk: https://bugs.openjdk.java.net/browse/JDK-8225571 > * Dialog's preferred size no longer accommodates multi-line strings: https://bugs.openjdk.java.net/browse/JDK-8232811 > > While fixing those bugs I got familiar with the code and saw many opportunities to make it better (as the goal lists). > > One special case is that X.org needs a window manager to decorate windows (such as Unity, Metacity, Mutter, and many others), so the toolkit does not know about decoration sizes - it must ask to the window manager trough an extension (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html). OpenJFX can set sizes by content size and window size - so there is a complexity on the "window size" option - it must know decoration sizes. I could not fully understand the current code because it had a high cyclomatic complexity - this was the main motivation to make it simplier (see JBS https://bugs.openjdk.java.net/browse/JDK-8232811 - it fixes the bug, but it's not very "clean"). > > I refer to "make Linux a first-class platform" on the goal because the PR makes room for more improvements (such as easier to fix bugs). > > > Description > ----------- > > This glass gtk replacement will be active if passing -Djdk.gtk.new=true to the jvm. The proposal is to have this side by side with current Linux glass so people can test and eventually it may become the default glass implementation on Linux. > > * Note: No public API was modified; > > * Specific Code Changes > > * glass_window.cpp / glass_window.h > > - Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore); > - Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; > - Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); > - Frame Extents: Removed the code to request extents and gtk already does it by default; > - Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJFX uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. > - Other Size calculation changes: > - Use gtk_window_set_default_size() for initial size which is the appropriate function; > - Gravity is now ignored as it is on Windows glass impl; > - Avoid sending same sizes to Java (duplicated events); > - Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); > - Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on > apply_geometry(). > - Mouse grab: Reworked it to use to correct functions according to gtk+ version; > - Draw: Reworked it to use the correct calls accord to gtk+ version changes; > - Fixed JDK-8237491; > - Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; > - Reorganized function order on glass_window.cpp to match glass_window.h > - Only work-around Unity bug if window manager is Unity > > * GlassCursor.cpp > > - Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; > - Reworked Gtk+2 to use a function instead of manual calls to find the cursor; > > * GtkWindow.java > > - Moved the extents special case to native glass; > > * GlassApplication.cpp > > - Removed Gdk events where possible (it's now on glass_window as signals); > - Removed applet/web start code; > > * GlassView.cpp > > - Changes to reflect frame extents rework on glass_window > > * GlassWindow.cpp > > - WindowContextTop -> WindowContext > - Removed applet / web start code; > - Removed frame extents (which is not called anymore due to GtkWindow.java change); > > * glass_general.cpp > > - Removed functions that became unused; > - Added is_grab_disabled() that is used on glass_window > > * glass_window_ime.cpp > > - WindowContextTop -> WindowContext; > > * glass_dnd.cpp / glass_dnd.h > > - Ported to Gtk signals; > - Use all possible image formats (supported by GdkPixbuf / OpenJFX) - .gif is now possible (for ex.); > - Allow COMPOUND_TEXT; > - Do not request content while dragging; > - Reduce overall code size. > > > Testing > ------- > > While fixing the bugs listed on "Motivation" I have developed some robot tests that must pass along with the previosly existing ones. > > Note: Non-robot tests do not apply since the changes are glass specific. > > Note2: Must pass -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' to gradle. > > > Risks and Assumptions > --------------------- > > * Testing were done since Ubuntu 16.04 (released 4 years ago) on x64 machines; > * Tested with Mutter (default gnome) and Unity (default on 16.04) - should work on other window managers that follows the specs; > * It's a big change - well tested but might still break something. > > Dependencies > ----------- > > * Simplify and update glass gtk backend: https://bugs.openjdk.java.net/browse/JDK-8236651 > * Maximized undecorated stage behaves inconsistently on different platforms > : https://bugs.openjdk.java.net/browse/JDK-8237491 > From kcr at openjdk.java.net Mon Apr 6 23:23:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:23:30 GMT Subject: RFR: 8242167: ios keyboard handling In-Reply-To: References: Message-ID: <6xxdGVdLnJGbMQKXoggN_A_CkpK7v2_ns6U5dPYavj0=.9223af92-775a-470d-bc03-8c5f5d148524@github.com> On Sun, 5 Apr 2020 14:09:32 GMT, Johan Vos wrote: > Use JavaFX controls for TextField and TextArea instead of the native iOS ones > This fixes JDK-8242167 The new `TextAreaSkinIos` and `TextFieldSkinIos ` classes will become part of the public API for IOS, since they are in the `javafx.scene.control.skin` package. Is this intended, or might they be able to live somewhere under `com.sun.javafx`? ------------- PR: https://git.openjdk.java.net/jfx/pull/158 From kcr at openjdk.java.net Mon Apr 6 23:28:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:28:27 GMT Subject: RFR: 8242163: Android keyboard integration fails In-Reply-To: References: Message-ID: On Sun, 5 Apr 2020 10:19:07 GMT, Johan Vos wrote: > Fix the code that integrates TextField/TextArea with the android keyboard > > Fix for #8242163 Similar question as for the IOS keyboard issue: The newly moved `TextAreaSkinAndroid ` and `TextFieldSkinAndroid` classes will become part of the public API for Android, since they are in the `javafx.scene.control.skin` package. Is this intended, or might they still be able to live somewhere under `com.sun.javafx`? ------------- PR: https://git.openjdk.java.net/jfx/pull/157 From kcr at openjdk.java.net Mon Apr 6 23:39:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:39:12 GMT Subject: RFR: 8241249: NPE in TabPaneSkin.perfromDrag In-Reply-To: References: Message-ID: On Mon, 6 Apr 2020 16:14:41 GMT, Ambarish Rapte wrote: > This is a simple fix similar to [JDK-8237372](https://bugs.openjdk.java.net/browse/JDK-8237372). > The NPE can occur if a MOUSE_DRAGGED is received by tab header without receiving MOUSE_PRESSED. > The fix also corrects a typo error. `perfromDrag()` to `performDrag()` Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/160 From kcr at openjdk.java.net Mon Apr 6 23:43:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:43:40 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) In-Reply-To: References: Message-ID: <1xFGE5fJaMpANiWA_Be0C9uFUwwlhyVgKa_kTk8ksb0=.70f34efe-7c40-4f25-9d2c-88bec0e45f96@github.com> On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 > > Root Cause : > Turned out to be a simpler issue than thought. > Atomicity check was missed while updating toolbar state (which in turn updates styles). > > Fix : > Added the missed atomicity check at two places that handle text selection using keyboard keys. > > Testing : > Added two system test cases. They fail without this fix and pass with it. @guruhb can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/155 From kcr at openjdk.java.net Mon Apr 6 23:57:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:57:18 GMT Subject: [Rev 03] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 12:58:11 GMT, Ambarish Rapte wrote: >> ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when >> the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves >> the issue. >> Please take a look. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comment: cleanup the accelerator Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From thiago.sayao at clamed.com.br Tue Apr 7 00:13:00 2020 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Tue, 7 Apr 2020 00:13:00 +0000 Subject: Discussion on adding a new gtk glass backend In-Reply-To: References: , Message-ID: Hi Kevin, 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? Yes it works and was tested with gtk2. It has version checks for each API that changed since version 2. One thing that I may have to double-check is if it works with the minimum required gtk2 version. 2. How much of the reliance on GDK were you able to eliminate? It is unlikely to eliminate all of gdk because gtk itself requires gdk structures. I mostly reduced it on Drag and Drop (previously with https://github.com/openjdk/jfx/pull/4 and now with the drag dest part). The thought was "if gtk has it, use gtk". The goal was not to remove gdk but use existing gtk functionality if it fits. One example was to use gtk_widget_set_sensitive to make parent windows "insensitive" when on WINDOW_MODAL instead of custom implementation. Other example is in DND - gtk does the handling, just needed to translate it from glass to gtk. About the flag to enable the implementation, what about "javafx.gtk.experimental=true/false" ? ________________________________ De: openjfx-dev em nome de Kevin Rushforth Enviado: segunda-feira, 6 de abril de 2020 18:34 Para: openjfx-dev at openjdk.java.net Assunto: Re: Discussion on adding a new gtk glass backend Hi Thiago, Nice summary! As I mentioned offline, I am generally supportive of this, since I know how fragile the existing Linux Glass implementation is. Unsurprisingly, this has effectively turned into a rewrite of the Linux GTK glass port. It's going to need a very thorough review, including a security review, and that will take some time. Thank you for adding my offline suggestion of making this new implementation an optional library where the old and new versions of the glass library for Linux can coexist. This will allow making separate decisions about when it is ready to go in versus when it is ready to become the default; this is the only way it even has a chance of getting in for JavaFX 15 (and even then it's not a given). Since this is JavaFX only, the command line option should probably be "javafx.gtk..." rather than "jdk.gtk....", or at least something with "javafx" in the name, but that's a detail that can be worked out later. I have a couple high-level questions: 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? 2. How much of the reliance on GDK were you able to eliminate? I'd like to also hear from Johan and others -- especially other Linux app developers. -- Kevin On 4/4/2020 5:13 PM, Thiago Milczarek Sayao wrote: > Summary > ------- > > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > PR: https://github.com/openjdk/jfx/pull/77 > > Goals > ----- > > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > > Non-Goals > --------- > > * Make Wayland work now. > > > Success Metrics > --------------- > > * Reduced code size (999 lines removed); > * Pass robot tests on Ubuntu 16.04, 18.04 and 20.04, except some of them that always fails; > * Pass manual testing using the Drag and Drop app (java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls) with gtk2 and gtk3 backends; > * Pass manual testing using Ensemble 8 with either gtk2 and gtk3 backends. > > Motivation > ---------- > > While working with OpenJFX on Linux, I have fixed some of it's bugs: > > * Wrong stage gets focused after modal stage creation: https://bugs.openjdk.java.net/browse/JDK-8227366 > * Multi-level Stage::initOwner can crash gnome-shell or X.org server: https://bugs.openjdk.java.net/browse/JDK-8226537 > * DragAndDrop no longer works with GTK3: https://bugs.openjdk.java.net/browse/JDK-8211302 > * [Linux] Dialog height switches between correct and too small when showing and hiding a Dialog repeatedly: https://bugs.openjdk.java.net/browse/JDK-8193502 > * Focus goes to wrong Window when dismissing an Alert: https://bugs.openjdk.java.net/browse/JDK-8210973 > * [GTK3] Stage sometimes shown at top-left before moving to correct position: https://bugs.openjdk.java.net/browse/JDK-8212060 > * Window order is not correct when Modality.WINDOW_MODAL: https://bugs.openjdk.java.net/browse/JDK-8220272 > * Port Linux glass drag source (DND) to use gtk instead of gdk: https://bugs.openjdk.java.net/browse/JDK-8225571 > * Dialog's preferred size no longer accommodates multi-line strings: https://bugs.openjdk.java.net/browse/JDK-8232811 > > While fixing those bugs I got familiar with the code and saw many opportunities to make it better (as the goal lists). > > One special case is that X.org needs a window manager to decorate windows (such as Unity, Metacity, Mutter, and many others), so the toolkit does not know about decoration sizes - it must ask to the window manager trough an extension (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html). OpenJFX can set sizes by content size and window size - so there is a complexity on the "window size" option - it must know decoration sizes. I could not fully understand the current code because it had a high cyclomatic complexity - this was the main motivation to make it simplier (see JBS https://bugs.openjdk.java.net/browse/JDK-8232811 - it fixes the bug, but it's not very "clean"). > > I refer to "make Linux a first-class platform" on the goal because the PR makes room for more improvements (such as easier to fix bugs). > > > Description > ----------- > > This glass gtk replacement will be active if passing -Djdk.gtk.new=true to the jvm. The proposal is to have this side by side with current Linux glass so people can test and eventually it may become the default glass implementation on Linux. > > * Note: No public API was modified; > > * Specific Code Changes > > * glass_window.cpp / glass_window.h > > - Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore); > - Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; > - Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); > - Frame Extents: Removed the code to request extents and gtk already does it by default; > - Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJFX uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. > - Other Size calculation changes: > - Use gtk_window_set_default_size() for initial size which is the appropriate function; > - Gravity is now ignored as it is on Windows glass impl; > - Avoid sending same sizes to Java (duplicated events); > - Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); > - Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on > apply_geometry(). > - Mouse grab: Reworked it to use to correct functions according to gtk+ version; > - Draw: Reworked it to use the correct calls accord to gtk+ version changes; > - Fixed JDK-8237491; > - Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; > - Reorganized function order on glass_window.cpp to match glass_window.h > - Only work-around Unity bug if window manager is Unity > > * GlassCursor.cpp > > - Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; > - Reworked Gtk+2 to use a function instead of manual calls to find the cursor; > > * GtkWindow.java > > - Moved the extents special case to native glass; > > * GlassApplication.cpp > > - Removed Gdk events where possible (it's now on glass_window as signals); > - Removed applet/web start code; > > * GlassView.cpp > > - Changes to reflect frame extents rework on glass_window > > * GlassWindow.cpp > > - WindowContextTop -> WindowContext > - Removed applet / web start code; > - Removed frame extents (which is not called anymore due to GtkWindow.java change); > > * glass_general.cpp > > - Removed functions that became unused; > - Added is_grab_disabled() that is used on glass_window > > * glass_window_ime.cpp > > - WindowContextTop -> WindowContext; > > * glass_dnd.cpp / glass_dnd.h > > - Ported to Gtk signals; > - Use all possible image formats (supported by GdkPixbuf / OpenJFX) - .gif is now possible (for ex.); > - Allow COMPOUND_TEXT; > - Do not request content while dragging; > - Reduce overall code size. > > > Testing > ------- > > While fixing the bugs listed on "Motivation" I have developed some robot tests that must pass along with the previosly existing ones. > > Note: Non-robot tests do not apply since the changes are glass specific. > > Note2: Must pass -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' to gradle. > > > Risks and Assumptions > --------------------- > > * Testing were done since Ubuntu 16.04 (released 4 years ago) on x64 machines; > * Tested with Mutter (default gnome) and Unity (default on 16.04) - should work on other window managers that follows the specs; > * It's a big change - well tested but might still break something. > > Dependencies > ----------- > > * Simplify and update glass gtk backend: https://bugs.openjdk.java.net/browse/JDK-8236651 > * Maximized undecorated stage behaves inconsistently on different platforms > : https://bugs.openjdk.java.net/browse/JDK-8237491 > From hohonuuli at icloud.com Tue Apr 7 00:36:42 2020 From: hohonuuli at icloud.com (hohonuuli at icloud.com) Date: Mon, 6 Apr 2020 17:36:42 -0700 Subject: Shared buffer in PixelBuffer References: <8ecabcf1-0781-4dbb-9388-0be3653237d7@Spark> Message-ID: Hi All, I just wanted to send a "thank you!" to all the JavaFX devs for your work on JavaFX and most especially, adding shared memory to JavaFX?s PixelBuffer. (https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html) The ?tl;dr? is that I now have a JavaFX-based video player tool, thanks to Caprica Software, that can play a wide variety of video formats well and can be easily modified to support my organization's science requirements. I?ve linked a YouTube video of the video player app, playing a ProRes 422 encoded QuickTime video and communicating with another annotation application. Thanks to the shared buffer the video playback is smoooooooth.?https://youtu.be/FKeuG8-UYC0 Again thanks for your work. Stay well! Brian Schlining Software Engineer P (831) 775-1855 ? F (831) 775-1620 Monterey Bay Aquarium Research Institute 7700 Sandholdt Road, Moss Landing CA 95039 www.mbari.org Advancing marine science and engineering to understand our changing ocean. From ajoseph at openjdk.java.net Tue Apr 7 05:41:09 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 7 Apr 2020 05:41:09 GMT Subject: RFR: WIP: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: <5sc2TcVxXD92jtPsDF4L5BvUSDrPDI-_Uwv_DRdonDo=.6ad0a745-e683-4ade-8080-644718a47fca@github.com> <807NKhSRXjlLn18IXMMGrlk72xPhRDvky1Q5t6ctc28=.ee2a0009-ba40-4232-b9ba-0c0fc9e81c46@github.com> Message-ID: On Wed, 12 Feb 2020 20:34:55 GMT, Kevin Rushforth wrote: >> I have indeed let this bug on the side. I would like to investigate but my time is limited these days. Especially that >> my patch is apparently creating another issue. I will try to give it another shot in the upcoming week. But if anyone >> has some ideas or is willing to carry the issue, feel free > > No hurry. I was just going through PRs that hadn't been updated in a while. The second issue regarding selecting texts with multiple fonts will be fixed when https://github.com/openjdk/jfx/pull/155 is merged. ------------- PR: https://git.openjdk.java.net/jfx/pull/12 From aghaisas at openjdk.java.net Tue Apr 7 07:41:48 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 07:41:48 GMT Subject: RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" Message-ID: Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT array key. Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. ------------- Commit messages: - Fix NPE Changes: https://git.openjdk.java.net/jfx/pull/161/files Webrev: https://webrevs.openjdk.java.net/jfx/161/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241710 Stats: 29 lines in 2 files changed: 20 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/161/head:pull/161 PR: https://git.openjdk.java.net/jfx/pull/161 From jvos at openjdk.java.net Tue Apr 7 08:09:30 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Apr 2020 08:09:30 GMT Subject: RFR: 8242167: ios keyboard handling In-Reply-To: <6xxdGVdLnJGbMQKXoggN_A_CkpK7v2_ns6U5dPYavj0=.9223af92-775a-470d-bc03-8c5f5d148524@github.com> References: <6xxdGVdLnJGbMQKXoggN_A_CkpK7v2_ns6U5dPYavj0=.9223af92-775a-470d-bc03-8c5f5d148524@github.com> Message-ID: On Mon, 6 Apr 2020 23:21:17 GMT, Kevin Rushforth wrote: > The new `TextAreaSkinIos` and `TextFieldSkinIos ` classes will become part of the public API for IOS, since they are in > the `javafx.scene.control.skin` package. Is this intended, or might they be able to live somewhere under > `com.sun.javafx`? That is intentional indeed, as libraries may want to change behavior. The Android classes used to be in com.sun.javafx, at the same level as the desktop classes. But the desktop classes (`TextAreaSkin` and `TextFieldSkin`) are moved to `javafx.scene.control.skin` hence it seems logic to move the Android classes to the same level, and the iOS classes as well then. Alternatively, we could completely get rid of the ios/android specific classes, and add the logic to show/hide the keyboard in the desktop classes. But that is much more intrusive, so I think it's safer to keep them separated for now. ------------- PR: https://git.openjdk.java.net/jfx/pull/158 From jvos at openjdk.java.net Tue Apr 7 08:21:09 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Apr 2020 08:21:09 GMT Subject: RFR: 8242163: Android keyboard integration fails In-Reply-To: References: Message-ID: <6gESkzr5u5TiveZFkshIioukCPug1-jC4cxxv_6forw=.1f2959d8-f4c8-4dac-a83e-09fc85572e20@github.com> On Mon, 6 Apr 2020 23:26:12 GMT, Kevin Rushforth wrote: >> Fix the code that integrates TextField/TextArea with the android keyboard >> >> Fix for #8242163 > > Similar question as for the IOS keyboard issue: The newly moved `TextAreaSkinAndroid ` and `TextFieldSkinAndroid` > classes will become part of the public API for Android, since they are in the `javafx.scene.control.skin` package. Is > this intended, or might they still be able to live somewhere under `com.sun.javafx`? Same reason as in the iOS case. The `TextFieldSkinAndroid` was in `com.sun.javafx` at the same level as `TextFieldSkin`. Since `TextFieldSkin` was moved to `javafx`, I moved `TextFieldSkinAndroid` as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/157 From mp at jugs.org Tue Apr 7 08:39:00 2020 From: mp at jugs.org (Michael Paus) Date: Tue, 7 Apr 2020 10:39:00 +0200 Subject: Shared buffer in PixelBuffer In-Reply-To: References: <8ecabcf1-0781-4dbb-9388-0be3653237d7@Spark> Message-ID: <9e20e5b0-fd73-b289-6ba2-0ca1bec1a126@jugs.org> Hi, it is nice to hear that you could make some good use of this work. Michael (mipastgt) Am 07.04.20 um 02:36 schrieb hohonuuli at icloud.com: > Hi All, > > I just wanted to send a "thank you!" to all the JavaFX devs for your work on JavaFX and most especially, adding shared memory to JavaFX?s PixelBuffer. (https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html) > > The ?tl;dr? is that I now have a JavaFX-based video player tool, thanks to Caprica Software, that can play a wide variety of video formats well and can be easily modified to support my organization's science requirements. I?ve linked a YouTube video of the video player app, playing a ProRes 422 encoded QuickTime video and communicating with another annotation application. Thanks to the shared buffer the video playback is smoooooooth.?https://youtu.be/FKeuG8-UYC0 > > Again thanks for your work. Stay well! > > Brian Schlining > Software Engineer > P (831) 775-1855 ? F (831) 775-1620 > > > Monterey Bay Aquarium Research Institute > 7700 Sandholdt Road, Moss Landing CA 95039 > www.mbari.org > Advancing marine science and engineering to understand our changing ocean. From arapte at openjdk.java.net Tue Apr 7 10:27:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 7 Apr 2020 10:27:09 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Mon, 30 Mar 2020 13:37:51 GMT, Florian Kirmaier wrote: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Suggested some changes and query. I still need to verify the fix in detail. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 77: > 76: Platform.runLater(() -> stage.close()); > 77: } > 78: Looks like the primary `stage` is not required for actual test, and this block is only used to initialize JavaFX runtime. Please check if it can be replaced by below block ``` @BeforeClass public static void initFX() throws Exception { startupLatch = new CountDownLatch(1); Platform.startup(startupLatch::countDown); Assert.assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.MILLISECONDS)); } tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 133: > 132: > 133: Assert.assertNull(weakReference.get()); > 134: } This assert check call should be added to the @Test method. I would recommend to refer [this method](https://github.com/openjdk/jfx/blob/364c64a2e55b561df4ca1afc85c91054b339eea8/modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java#L1998) from ListViewTest. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 113: > 112: }); > 113: > 114: Assert.assertTrue("Timeout, waiting for runLater. ", leakLatch.await(15, TimeUnit.SECONDS)); Is it really required to nest the `Platform.runLater()` calls ? Can you please check if this code can be simplified by making the calls sequential, Consider using `Util.runAndWait()` tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 84: > 83: counter += 1; > 84: testLeakOnce(); > 85: } If the test has constant behavior on every run, then only one run should be done. modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 354: > 353: } > 354: if(Window.focusedWindow == this) { > 355: Window.focusedWindow = null; Please correct format by adding space after `if`. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 53: > 52: System.setProperty("monocle.platform","Headless"); > 53: } > 54: The test will always run with Monocle. I see that if this static block is removed then the test fails on Windows 10. Can you please verify all the platforms and change the test such that it runs on all platforms/ combinations. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/153 From fastegal at openjdk.java.net Tue Apr 7 10:30:08 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 7 Apr 2020 10:30:08 GMT Subject: RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 07:36:00 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 > > Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. > > Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. Verified the fix: test is failing before and passing after. See one inline comment (just noting my personal pref :). And again me fighting the system (can't seem to review code parts that are not near a change, so doing here: - copyright year doesn't seem to be updated - there's another fishy looking code line in MenuItemContainer actionHandler: actionEventHandler = e -> { if (item instanceof Menu) { final Menu menu = (Menu) item; if (openSubmenu == menu && submenu.isShowing()) return; don't know when/if that's ever reached (could get there - an action handler on the region itself?), anyway, at other places with a similar pattern (f.i processRightKey) there's an explicit guard against a null submenu, don't know if the latter is over-caution - logic and code is rather .. well .. inter-twined ;) modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ContextMenuContent.java line 658: > 657: ContextMenuContent cmContent = (ContextMenuContent)submenu.getSkin().getNode(); > 658: if (cmContent != null) { > 659: if (cmContent.itemsContainer.getChildren().size() > 0) { just a mini-note: personally, I prefer early-return on no-match (vs. wrapping nearly the whole method inside an if match if (submenu == null) return; ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From lior.yaffe at jelurida.com Tue Apr 7 11:14:39 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Tue, 7 Apr 2020 14:14:39 +0300 Subject: Support "trust all" SSL context in OpenJFX 14 Message-ID: Some background information on why we are facing the issue. The internal implementation of WebView changed in OpenJFX 14 to use HttpClient instead of Http(s)URLConnection. Therefore, it is no longer possible to use the following methods to set a custom SSL context before instantiation of a HttpsURLConnection object: HttpsURLConnection#setDefaultSSLSocketFactory HttpsURLConnection#setDefaultHostnameVerifier The only way to set a custom SSLContext to a HttpClient is to use the method HttpClientBuilder#sslContext unfortunately this method is not accessible for the Webview code. Since there is no static method on the HttpClient to set a custom SSLContext, we hereby request to introduce a public method on WebView (or WebEngine) for the purpose of passing a custom SSL context. Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From webczat_200 at poczta.onet.pl Tue Apr 7 11:28:16 2020 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Tue, 7 Apr 2020 13:28:16 +0200 Subject: Support "trust all" SSL context in OpenJFX 14 In-Reply-To: References: Message-ID: What about global SSLContext.setDefault()? maybe it doesn't apply of course. W dniu 07.04.2020 o?13:14, Lior Yaffe pisze: > Some background information on why we are facing the issue. > The internal implementation of WebView changed in OpenJFX 14 to use > HttpClient instead of Http(s)URLConnection. Therefore, it is no longer > possible to use the following methods to set a custom SSL context before > instantiation of a HttpsURLConnection object: > > HttpsURLConnection#setDefaultSSLSocketFactory > HttpsURLConnection#setDefaultHostnameVerifier > > The only way to set a custom SSLContext to a HttpClient is to use the > method HttpClientBuilder#sslContext unfortunately this method is not > accessible for the Webview code. > > Since there is no static method on the HttpClient to set a custom > SSLContext, we hereby request to introduce a public method on WebView (or > WebEngine) for the purpose of passing a custom SSL context. > > > Virus-free. > www.avg.com > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > From aghaisas at openjdk.java.net Tue Apr 7 11:40:20 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 11:40:20 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: <_r51eqAgNcgCLGJg-Lmzza7lNvSFDVniddpZruEx8l8=.123306bc-cb83-42c3-9303-aa0d4e2bbf52@github.com> On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 >> >> Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. >> >> Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Minor review fixes > Verified the fix: test is failing before and passing after. Thanks for the quick test. > See one inline comment (just noting my personal pref :). > > And again me fighting the system (can't seem to review code parts that are not near a change, so doing here: Well, you are part of the system :) > * copyright year doesn't seem to be updated I have updated this now. > * there's another fishy looking code line in MenuItemContainer actionHandler: > ``` > actionEventHandler = e -> { > if (item instanceof Menu) { > final Menu menu = (Menu) item; > if (openSubmenu == menu && submenu.isShowing()) return; > ``` > > > don't know when/if that's ever reached (could get there - an action handler on the region itself?), anyway, at other > places with a similar pattern (f.i processRightKey) there's an explicit guard against a null submenu, don't know if the > latter is over-caution - logic and code is rather .. well .. inter-twined ;) Yes. This code does not seem to be ideal, but, it has evolved and a lot of fixes have gone in. So rewriting is ruled out. ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From aghaisas at openjdk.java.net Tue Apr 7 11:40:09 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 11:40:09 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: > Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 > > Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. > > Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Minor review fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/161/files - new: https://git.openjdk.java.net/jfx/pull/161/files/dbb56031..aecc69c3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/161/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/161/webrev.00-01 Stats: 15 lines in 2 files changed: 1 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/161/head:pull/161 PR: https://git.openjdk.java.net/jfx/pull/161 From aghaisas at openjdk.java.net Tue Apr 7 11:40:21 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 11:40:21 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: <4bvZiyumGdQMDYTJ4KCVYewj-Z1mU0tAY4AkwkxjXTw=.a1f4b412-36e8-4c7c-82ef-d7641f2ced44@github.com> On Tue, 7 Apr 2020 10:13:39 GMT, Jeanette Winzenburg wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor review fixes > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ContextMenuContent.java line 658: > >> 657: ContextMenuContent cmContent = (ContextMenuContent)submenu.getSkin().getNode(); >> 658: if (cmContent != null) { >> 659: if (cmContent.itemsContainer.getChildren().size() > 0) { > > just a mini-note: personally, I prefer early-return on no-match (vs. wrapping nearly the whole method inside an if match > > if (submenu == null) return; I prefer a single point of return for small methods. Anyway, this file has lot of early returns. Hence, I am modifying as per your suggestion. ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From fastegal at openjdk.java.net Tue Apr 7 11:42:46 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 7 Apr 2020 11:42:46 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 >> >> Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. >> >> Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Minor review fixes okay, thanks for the quicks changes :) ------------- Marked as reviewed by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/161 From kcr at openjdk.java.net Tue Apr 7 12:12:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 12:12:43 GMT Subject: RFR: 8242163: Android keyboard integration fails In-Reply-To: References: Message-ID: On Sun, 5 Apr 2020 10:19:07 GMT, Johan Vos wrote: > Fix the code that integrates TextField/TextArea with the android keyboard > > Fix for #8242163 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/157 From kcr at openjdk.java.net Tue Apr 7 12:12:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 12:12:33 GMT Subject: RFR: 8242167: ios keyboard handling In-Reply-To: References: Message-ID: On Sun, 5 Apr 2020 14:09:32 GMT, Johan Vos wrote: > Use JavaFX controls for TextField and TextArea instead of the native iOS ones > This fixes JDK-8242167 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/158 From kevin.rushforth at oracle.com Tue Apr 7 12:16:40 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Apr 2020 05:16:40 -0700 Subject: Shared buffer in PixelBuffer In-Reply-To: <9e20e5b0-fd73-b289-6ba2-0ca1bec1a126@jugs.org> References: <8ecabcf1-0781-4dbb-9388-0be3653237d7@Spark> <9e20e5b0-fd73-b289-6ba2-0ca1bec1a126@jugs.org> Message-ID: Thanks for sharing. -- Kevin On 4/7/2020 1:39 AM, Michael Paus wrote: > Hi, > it is nice to hear that you could make some good use of this work. > Michael > (mipastgt) > > > Am 07.04.20 um 02:36 schrieb hohonuuli at icloud.com: >> Hi All, >> >> I just wanted to send a "thank you!" to all the JavaFX devs for your >> work on JavaFX and most especially, adding shared memory to JavaFX?s >> PixelBuffer. >> (https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html) >> >> The ?tl;dr? is that I now have a JavaFX-based video player tool, >> thanks to Caprica Software, that can play a wide variety of video >> formats well and can be easily modified to support my organization's >> science requirements. I?ve linked a YouTube video of the video player >> app, playing a ProRes 422 encoded QuickTime video and communicating >> with another annotation application. Thanks to the shared buffer the >> video playback is smoooooooth.?https://youtu.be/FKeuG8-UYC0 >> >> Again thanks for your work. Stay well! >> >> Brian Schlining >> Software Engineer >> P (831) 775-1855 ? F (831) 775-1620 >> >> >> Monterey Bay Aquarium Research Institute >> 7700 Sandholdt Road, Moss Landing CA 95039 >> www.mbari.org >> Advancing marine science and engineering to understand our changing >> ocean. > > From lior.yaffe at jelurida.com Tue Apr 7 13:30:08 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Tue, 7 Apr 2020 16:30:08 +0300 Subject: Support "trust all" SSL context in OpenJFX 14 In-Reply-To: References: Message-ID: I'm not sure why but it doesn't work. The only workaround I found is: System.setProperty("com.sun.webkit.useHTTP2Loader", "false"); // Workaround to support test certificate with OpenJFX 14 Webview Then use the old code which works in OpenJFX 13 and earlier. HttpsURLConnection.setDefaultSSLSocketFactory(TrustAllSSLProvider.getSslSocketFactory()); HttpsURLConnection.setDefaultHostnameVerifier(TrustAllSSLProvider.getHostNameVerifier()); On Tue, Apr 7, 2020 at 2:28 PM Micha? Zegan wrote: > What about global SSLContext.setDefault()? maybe it doesn't apply of > course. > > W dniu 07.04.2020 o 13:14, Lior Yaffe pisze: > > Some background information on why we are facing the issue. > > The internal implementation of WebView changed in OpenJFX 14 to use > > HttpClient instead of Http(s)URLConnection. Therefore, it is no longer > > possible to use the following methods to set a custom SSL context before > > instantiation of a HttpsURLConnection object: > > > > HttpsURLConnection#setDefaultSSLSocketFactory > > HttpsURLConnection#setDefaultHostnameVerifier > > > > The only way to set a custom SSLContext to a HttpClient is to use the > > method HttpClientBuilder#sslContext unfortunately this method is not > > accessible for the Webview code. > > > > Since there is no static method on the HttpClient to set a custom > > SSLContext, we hereby request to introduce a public method on WebView (or > > WebEngine) for the purpose of passing a custom SSL context. > > > > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > Virus-free. > > www.avg.com > > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > From kcr at openjdk.java.net Tue Apr 7 14:01:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 14:01:04 GMT Subject: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class Message-ID: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> This is a simple fix to remove some obsolete code. As noted in the JBS description, GlassView2D was made obsolete back in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is dead code, as there are no references to that class. ------------- Commit messages: - 8242106: [macos] Remove obsolete GlassView2D.m class Changes: https://git.openjdk.java.net/jfx/pull/162/files Webrev: https://webrevs.openjdk.java.net/jfx/162/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242106 Stats: 460 lines in 3 files changed: 0 ins; 460 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/162.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/162/head:pull/162 PR: https://git.openjdk.java.net/jfx/pull/162 From kcr at openjdk.java.net Tue Apr 7 14:01:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 14:01:05 GMT Subject: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class In-Reply-To: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> References: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> Message-ID: On Tue, 7 Apr 2020 13:54:43 GMT, Kevin Rushforth wrote: > This is a simple fix to remove some obsolete code. As noted in the JBS description, GlassView2D was made obsolete back > in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is dead code, as there are no references to > that class. @arapte can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/162 From ajoseph at openjdk.java.net Tue Apr 7 14:15:26 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 7 Apr 2020 14:15:26 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) In-Reply-To: References: Message-ID: On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 > > Root Cause : > Turned out to be a simpler issue than thought. > Atomicity check was missed while updating toolbar state (which in turn updates styles). > > Fix : > Added the missed atomicity check at two places that handle text selection using keyboard keys. > > Testing : > Added two system test cases. They fail without this fix and pass with it. Marked as reviewed by ajoseph (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/155 From kcr at openjdk.java.net Tue Apr 7 20:31:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 20:31:11 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode In-Reply-To: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> References: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> Message-ID: On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph wrote: > CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native > threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() > function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native > threads for x86 to 1 MB. @guruhb please also review this. ------------- PR: https://git.openjdk.java.net/jfx/pull/159 From kcr at openjdk.java.net Tue Apr 7 21:16:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 21:16:15 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) In-Reply-To: References: Message-ID: <1T7UNspBPJ0EjXROKBBCtlWJZb_BeILL4J197lSSO7g=.79c463eb-26aa-4322-8e5c-4d649e8c82c5@github.com> On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 > > Root Cause : > Turned out to be a simpler issue than thought. > Atomicity check was missed while updating toolbar state (which in turn updates styles). > > Fix : > Added the missed atomicity check at two places that handle text selection using keyboard keys. > > Testing : > Added two system test cases. They fail without this fix and pass with it. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/155 From kcr at openjdk.java.net Tue Apr 7 21:45:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 21:45:53 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode In-Reply-To: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> References: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> Message-ID: On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph wrote: > CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native > threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() > function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native > threads for x86 to 1 MB. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/159 From tsayao at openjdk.java.net Tue Apr 7 22:37:14 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 7 Apr 2020 22:37:14 GMT Subject: [Rev 48] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Restore comment position - Restore deleted idea file ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/2f83ce7b..d18b5be4 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.48 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.47-48 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Tue Apr 7 22:58:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 22:58:56 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 >> >> Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. >> >> Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Minor review fixes Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From kcr at openjdk.java.net Tue Apr 7 23:05:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 23:05:42 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 12:59:11 GMT, Nir Lisker wrote: >> I have added few comments, but have not run tests and sample yet. > > @arapte Can you please test the performance changes too? I think @arapte has a similar MacBookPro model to mine. I think @prrace might be able to test it (I'll sync with him offline). ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Tue Apr 7 23:18:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 23:18:17 GMT Subject: [Rev 02] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: <2c5f1R0WcHlKzFyQKLflFMwWOZK9Ks5aVBtqCxiCtgw=.c5ed7209-28f0-44ce-9755-7595dd62cb18@github.com> On Tue, 31 Mar 2020 20:45:44 GMT, Thiago Milczarek Sayao wrote: >> I took a look yesterday and came to the same conclusion that what we really want are separate C and C++ flags. For now, >> the only difference would be the presence or absence of `-Werror=implicit-function-declaration`, but it would allow for >> other differences in the future if needed. > > Please, let me know if this is the desired way to do it. If not, I will rework it. Thanks. This is roughly what I had in mind. I want to test it, and also take a look at the WebKit and media builds as well. WebKit uses the flags from `linux.gradle`, and is mostly C++, so I think it needs no changes. Media does not use any flags from `linux.gradle` -- only the jfxmedia project has C++ files on Linux. I guess it should be fine, too, but I'll see. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From almatvee at openjdk.java.net Tue Apr 7 23:49:22 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 7 Apr 2020 23:49:22 GMT Subject: RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina Message-ID: https://bugs.openjdk.java.net/browse/JDK-8240694 - Original fix JDK-8236832 was reverted. - Timestamp will be queried on event loop thread when spectrum event is received by event loop. - FIx only enabled for macOS when using OSXPlatform. ------------- Commit messages: - 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina Changes: https://git.openjdk.java.net/jfx/pull/163/files Webrev: https://webrevs.openjdk.java.net/jfx/163/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240694 Stats: 62 lines in 11 files changed: 29 ins; 13 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/163/head:pull/163 PR: https://git.openjdk.java.net/jfx/pull/163 From arapte at openjdk.java.net Wed Apr 8 04:23:31 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 8 Apr 2020 04:23:31 GMT Subject: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class In-Reply-To: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> References: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> Message-ID: On Tue, 7 Apr 2020 13:54:43 GMT, Kevin Rushforth wrote: > This is a simple fix to remove some obsolete code. As noted in the JBS description, GlassView2D was made obsolete back > in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is dead code, as there are no references to > that class. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/162 From ajoseph at openjdk.java.net Wed Apr 8 07:35:48 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 8 Apr 2020 07:35:48 GMT Subject: RFR: 8223298: SVG patterns are drawn wrong Message-ID: Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. Fix: Override scale() method in WCBufferedContext class to call init() before scaling. ------------- Commit messages: - 8223298: SVG patterns are drawn wrong Changes: https://git.openjdk.java.net/jfx/pull/164/files Webrev: https://webrevs.openjdk.java.net/jfx/164/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223298 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164 PR: https://git.openjdk.java.net/jfx/pull/164 From jpereda at openjdk.java.net Wed Apr 8 08:43:34 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 8 Apr 2020 08:43:34 GMT Subject: RFR: 8240264: Comment out verbose logging Message-ID: This PR comments out too verbose console logging, as it has been done with some other fprintf calls. As a follow up of this PR, a custom directive that enables this output if needed can be considered. ------------- Commit messages: - Comment out verbose logging Changes: https://git.openjdk.java.net/jfx/pull/165/files Webrev: https://webrevs.openjdk.java.net/jfx/165/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240264 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/165/head:pull/165 PR: https://git.openjdk.java.net/jfx/pull/165 From ajoseph at openjdk.java.net Wed Apr 8 11:55:03 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 8 Apr 2020 11:55:03 GMT Subject: [Rev 01] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: > Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java > side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. > Fix: Override scale() method in WCBufferedContext class to call init() before scaling. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/164/files - new: https://git.openjdk.java.net/jfx/pull/164/files/ea66bca2..fb1c3934 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/164/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/164/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164 PR: https://git.openjdk.java.net/jfx/pull/164 From kcr at openjdk.java.net Wed Apr 8 12:44:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 12:44:14 GMT Subject: RFR: 8240264: Comment out verbose logging In-Reply-To: References: Message-ID: On Wed, 8 Apr 2020 08:37:27 GMT, Jose Pereda wrote: > This PR comments out too verbose console logging, as it has been done with some other fprintf calls. > As a follow up of this PR, a custom directive that enables this output if needed can be considered. @jperedadnr Please change the title of this PR to exactly match the title of the JBS bug. So: 8240264: iOS: Unnecessary logging on every pulse when GL context changes ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From nlisker at gmail.com Wed Apr 8 16:02:29 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 8 Apr 2020 19:02:29 +0300 Subject: JavaFX Swipe Events Glitch On Mobile In-Reply-To: References: Message-ID: Is this a bug caused by JavaFX or Gluon? On Fri, Mar 20, 2020 at 9:24 PM Debayan Sutradhar < debayansutradhar3 at gmail.com> wrote: > Swipe Events like swipeup and swipedown don't get registered and their > related set methods don't get called. OnTouch works rarely. > > JavaFX Version : 14 > Gluon Client Plugin : 0.0.18 > > Regards, > Debayan > From powers.anirvan at gmail.com Wed Apr 8 16:10:31 2020 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Thu, 9 Apr 2020 01:10:31 +0900 Subject: Support "trust all" SSL context in OpenJFX 14 In-Reply-To: References: Message-ID: Maybe it doesn't work due to JDK-8239595. It seems that HttpClient implementation does not use the default SSL context for its configuration [1]. There is an RFR mail to fix this [2][3]. [1] : https://bugs.openjdk.java.net/browse/JDK-8239595 [2] : https://mail.openjdk.java.net/pipermail/net-dev/2020-March/013705.html [3] : https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013785.html On Tue, 7 Apr 2020 at 22:33, Lior Yaffe wrote: > I'm not sure why but it doesn't work. > > The only workaround I found is: > System.setProperty("com.sun.webkit.useHTTP2Loader", "false"); // Workaround > to support test certificate with OpenJFX 14 Webview > > Then use the old code which works in OpenJFX 13 and earlier. > > HttpsURLConnection.setDefaultSSLSocketFactory(TrustAllSSLProvider.getSslSocketFactory()); > > HttpsURLConnection.setDefaultHostnameVerifier(TrustAllSSLProvider.getHostNameVerifier()); > > On Tue, Apr 7, 2020 at 2:28 PM Micha? Zegan > wrote: > > > What about global SSLContext.setDefault()? maybe it doesn't apply of > > course. > > > > W dniu 07.04.2020 o 13:14, Lior Yaffe pisze: > > > Some background information on why we are facing the issue. > > > The internal implementation of WebView changed in OpenJFX 14 to use > > > HttpClient instead of Http(s)URLConnection. Therefore, it is no longer > > > possible to use the following methods to set a custom SSL context > before > > > instantiation of a HttpsURLConnection object: > > > > > > HttpsURLConnection#setDefaultSSLSocketFactory > > > HttpsURLConnection#setDefaultHostnameVerifier > > > > > > The only way to set a custom SSLContext to a HttpClient is to use the > > > method HttpClientBuilder#sslContext unfortunately this method is not > > > accessible for the Webview code. > > > > > > Since there is no static method on the HttpClient to set a custom > > > SSLContext, we hereby request to introduce a public method on WebView > (or > > > WebEngine) for the purpose of passing a custom SSL context. > > > > > > < > > > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > Virus-free. > > > www.avg.com > > > < > > > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > > > -- Anirvan From nlisker at gmail.com Wed Apr 8 16:16:14 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 8 Apr 2020 19:16:14 +0300 Subject: Monocle as a replacement In-Reply-To: References: Message-ID: I added a note about removing Dprism.order=sw. On Wed, Mar 25, 2020 at 7:27 PM Tres Finocchiaro wrote: > With the help from a paid fx support channel, we're making headway with > this. The main help was disabling the recommended software option. At > time of writing this, I recommend this warning/detail is added to the wiki: > https://wiki.openjdk.java.net/display/OpenJFX/Monocle > > Quoting: > > > > *If you are running the desktop build of JavaFX or OpenJFX then your only > > monocle option is Headless. Desktop JavaFX does not support the > > javafx.platform system property, but you can select Monocle > > with:-Dglass.platform=Monocle -Dmonocle.platform=Headless > -Dprism.order=sw* > > > In or case, removing "*-Dprism.order=sw"* was critical to prevent crashes > on MacOS and Windows. We've yet to test on Linux. > > Last, since Monocle introduces a virtual desktop size (and we're using this > desktop for screen captures), we'll be tweaking the > "*-Dheadless.geometry=*" > parameter depending on available heap size. These details are best tracked > downstream for those interested https://github.com/qzind/tray/pull/586. > > Unless there are immediate questions, this will be the last update I > provide to the mailing list, all further updates will be specific to the > downstream implementation. > > As an aside, we may decide to sponsor the fixing of the underlying crashes > as well (for example, d2d may not be available on Windows 2016 Core?) but > at the time of writing this, we're adopting workarounds to make it viable > on a standard Desktop. > > - Tres.Finocchiaro at gmail.com > > > On Fri, Feb 21, 2020 at 5:13 PM Tres Finocchiaro < > tres.finocchiaro at gmail.com> > wrote: > > > Danny, > > > > Thanks this information is very valuable. > > > > By using the provided patch, I too am able to re-use the Monocle > framework > > without suffering this bug. > > > > For those visiting this thread (e.g. through archive) at a later time, > > it's being tracked downstream here: > > https://github.com/qzind/tray/issues/576 > > > > So applying it I was able to discover I was running into two separate > > issues... > > > > - The first was the unpredictable buffer behavior you've shared, which > > seems to be resolved that problem. I used the recommended code, just > in a > > copy of the JavaFX 11 class instead. Thanks! > > > > - The second is a nuance of reusing the WebView and Stage using > > Monocle, the stage/webview height calculation starts to grow out of > control > > (watching the DOM height -- we calculate the natural height and then > use > > that for snapshot). In my case it was growing 300, 900, 2900, 8600 > > eventually crashing somewhere in buffer allocation. Hard-coding the > sizing > > didn't suffer the same fate because it bypasses our attempts to > calculate > > the height using JavaScript. Oddly, creating a fresh WebView each > time > > didn't correct the issue either. I believe the underlying issue stems > > somewhere from the stage height never resetting back, but attempts to > do so > > manually cause other issues, so I'll see if there's a viable > workaround by > > doing more renders using Monocle. > > > > We already have an open item with Gluon regarding WebView stage sizing, > so > > this may be a race condition rearing its ugly head through a different > > symptom. We'll continue to work on it separately. > > > > Danny, thanks again for the link to the patch. We'll continue our > testing. > > > > - Tres.Finocchiaro at gmail.com > > > > > > On Wed, Feb 19, 2020 at 2:46 AM Danny Gonzalez < > > danny.gonzalez at screamingfrog.co.uk> wrote: > > > >> Hi Tres, > >> > >> We also are suffering from this crash when running our TestFX unit > tests, > >> particularly on Java 11. > >> It is due to a concurrency issue between the JavaFX thread and the > >> QuantumRenderer thread and there is an OpenJDK bug here: > >> https://bugs.openjdk.java.net/browse/JDK-8201567 > >> > >> Quoting from this bug report: > >> ?The QuantumRenderer calls the getPixels() method while trying to find a > >> buffer that's not in use, yet in doing so it can inadvertently modify a > >> buffer that's in use." > >> > >> There is also a related TestFX Bug: > >> https://github.com/TestFX/Monocle/issues/56 > >> > >> There is a fix for this issue In the first comment of the JDK-8201567, > in > >> a link to GitLab: https://gitlab.com/openjfxepd/jfxpatch/commit/ > >> < > https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258e790a049f3fdce4a956ef665c7 > > > >> > >> We have used this patch in our local OpenJFX build. > >> > >> This has never been made into a pull request however but I believe it > >> should. > >> > >> Danny > >> > >> On 17 Feb 2020, at 19:12, Tres Finocchiaro > >> wrote: > >> > >> Hi, > >> > >> I'm the developer of a printing plugin which leverages JavaFX for a few > >> HTML functions. > >> > >> One of our functions would greatly benefit from being "headless (or more > >> accurately, "silent") mode that Monocle offers and I'm evaluating the > use > >> of Monocle on (non-headless) Desktops for this. I'm currently testing a > >> monocle build by the TestFX team for MacOS. > >> > >> Although first test was positive, when invoking multiple times, I'm > >> getting > >> some internal errors similar to this: > >> https://stackoverflow.com/questions/49388497 and the framework grows > >> slower > >> and slower as it nears its final capture. (I'm using > WebView.capture(...)) > >> > >> Is this the right place for such as discussion? Where's the best place > to > >> ask about issues with Monocle? > >> > >> > >> - Tres.Finocchiaro at gmail.com > >> > >> > >> > From kcr at openjdk.java.net Wed Apr 8 18:37:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 18:37:11 GMT Subject: [Rev 02] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: On Sun, 29 Mar 2020 00:38:20 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to remove annoying warnings. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Sep cppFlags and cFlags The build changes in `linux.gradle` look good. I tested it, and all warnings are gone (including those in WebKit) except for the ones in the jfxmedia sub-project of javafx.media. Two comments: 1. I changed the bug title in JBS to refer to gcc 9 rather than Ubuntu to reflect the actual cause of the additional warnings. Can you update the title of this PR to match? 8241476: Linux build warnings issued on gcc 9 2. Can you add the following change to your PR as well? This will fix the remaining warnings in jfxmedia: --- a/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile +++ b/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile @@ -41,7 +41,6 @@ ifdef HOST_COMPILE -Wextra \ -Wformat-security \ -fstack-protector \ - -Werror=implicit-function-declaration \ -Werror=trampolines \ -msse2 \ -DGSTREAMER_LITE ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From kcr at openjdk.java.net Wed Apr 8 21:28:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 21:28:53 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: Message-ID: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> On Wed, 8 Apr 2020 08:37:27 GMT, Jose Pereda wrote: > This PR comments out too verbose console logging, as it has been done with some other fprintf calls. > As a follow up of this PR, a custom directive that enables this output if needed can be considered. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From kcr at openjdk.java.net Wed Apr 8 22:54:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 22:54:43 GMT Subject: RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 23:44:17 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is received by event loop. > - FIx only enabled for macOS when using OSXPlatform. Can you add a root cause / evaluation either in JBS or to this PR? I also noted a few places where it might be helpful to add a comment in the code, so anyone looking at it later will know why you are querying the timestamp later from the event thread. I'll finish my testing in parallel with your addressing those comments and adding the evaluation. modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaPlayer.java line 722: > 721: if (listener != null) { > 722: if (evt.queryTimestamp()) { > 723: double timestamp = playerGetPresentationTime(); A short (one-line) comment would be useful here. modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.cpp line 194: > 193: double duration = (double) mSamplesPerInterval / (double) 44100; > 194: // Timestamp is ignored and it will be queried from event loop > 195: mSpectrumCallbackProc(mSpectrumCallbackContext, duration, -1.0); You might also note that the reason it is ignored is because it will deadlock if you read it from the media thread. modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 656: > 655: if (eventHandler) { > 656: // Always true for queryTimestamp do to JDK-8240694 > 657: eventHandler->SendAudioSpectrumEvent(timestamp, duration, true); that should be "due" to... you might also mention that we need to query on the event thread to avoid a deadlock. ------------- PR: https://git.openjdk.java.net/jfx/pull/163 From almatvee at openjdk.java.net Thu Apr 9 01:45:27 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 9 Apr 2020 01:45:27 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is received by event loop. > - FIx only enabled for macOS when using OSXPlatform. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8240694: Improved comments per reviewers request ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/163/files - new: https://git.openjdk.java.net/jfx/pull/163/files/b43ace5c..0ea46c79 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/163/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/163/webrev.00-01 Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/163/head:pull/163 PR: https://git.openjdk.java.net/jfx/pull/163 From almatvee at openjdk.java.net Thu Apr 9 01:45:28 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 9 Apr 2020 01:45:28 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Wed, 8 Apr 2020 22:52:27 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8240694: Improved comments per reviewers request > > Can you add a root cause / evaluation either in JBS or to this PR? > > I also noted a few places where it might be helpful to add a comment in the code, so anyone looking at it later will > know why you are querying the timestamp later from the event thread. > I'll finish my testing in parallel with your addressing those comments and adding the evaluation. I updated comments in code and added a root cause / evaluation to JBS. ------------- PR: https://git.openjdk.java.net/jfx/pull/163 From github.com+636962+ccavanaugh at openjdk.java.net Thu Apr 9 09:37:50 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Thu, 9 Apr 2020 09:37:50 GMT Subject: [Rev 02] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Craig Cavanaugh has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. This pull request has been closed without being integrated. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/136/files - new: https://git.openjdk.java.net/jfx/pull/136/files/229a7fd2..159f6516 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/136/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/136/webrev.01-02 Stats: 51 lines in 2 files changed: 0 ins; 49 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/136/head:pull/136 PR: https://git.openjdk.java.net/jfx/pull/136 From kevin.rushforth at oracle.com Thu Apr 9 14:07:37 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 9 Apr 2020 07:07:37 -0700 Subject: Result: New OpenJFX Committer: Arun Joseph Message-ID: Voting for Arun Joseph [1] to to OpenJFX Committer [2] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#ajoseph [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-March/025542.html From kcr at openjdk.java.net Thu Apr 9 16:59:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Apr 2020 16:59:40 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Thu, 9 Apr 2020 01:45:27 GMT, Alexander Matveev wrote: >> https://bugs.openjdk.java.net/browse/JDK-8240694 >> >> - Original fix JDK-8236832 was reverted. >> - Timestamp will be queried on event loop thread when spectrum event is received by event loop. >> - FIx only enabled for macOS when using OSXPlatform. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8240694: Improved comments per reviewers request Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/163 From ghb at openjdk.java.net Thu Apr 9 17:22:38 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 9 Apr 2020 17:22:38 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Thu, 9 Apr 2020 01:45:27 GMT, Alexander Matveev wrote: >> https://bugs.openjdk.java.net/browse/JDK-8240694 >> >> - Original fix JDK-8236832 was reverted. >> - Timestamp will be queried on event loop thread when spectrum event is received by event loop. >> - FIx only enabled for macOS when using OSXPlatform. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8240694: Improved comments per reviewers request Looks good to me, Tested on MacOS 10.12.6 (Sierra) with the use case provided in JBS). ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/163 From almatvee at openjdk.java.net Thu Apr 9 21:19:47 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 9 Apr 2020 21:19:47 GMT Subject: [Closed] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 23:44:17 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is received by event loop. > - FIx only enabled for macOS when using OSXPlatform. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/163 From nlisker at openjdk.java.net Fri Apr 10 06:39:40 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 10 Apr 2020 06:39:40 GMT Subject: RFR: 8241582: Infinite animation does not start from the end when started with a negative rate Message-ID: ### Cause `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly. This causes `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start the animation not from the end, depending on the modulo calculation. ### Fix For infinite cycles, use the `cycleDuration` as the destination since that is the effective end point. ### Tests * Added an `testJumpTo_IndefiniteCycles` test that fails without the patch and passes after it. * Added a `testJumpTo_IndefiniteCycleDuration` that passes both before and after, just to make sure that this type of infinite duration is correct. * Removed a test in `SequentialTransition` that fails with this patch, but it passed before it only because the modulo value happened to land in the right place. Changing the duration of one of the child animation can cause it to fail, so the test is faulty anyway at this stage. ### Future work Playing backwards will still not work correctly, but at least now it start from the correct value. This is the first of a series of fixes under the umbrella issue [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238). ------------- Commit messages: - Comment out erroneous test - Fix IndefiniteCycleDuration test - Fixed single loop test - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/169/files Webrev: https://webrevs.openjdk.java.net/jfx/169/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241582 Stats: 28 lines in 3 files changed: 19 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/169.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/169/head:pull/169 PR: https://git.openjdk.java.net/jfx/pull/169 From ghb at openjdk.java.net Fri Apr 10 16:08:45 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 10 Apr 2020 16:08:45 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode In-Reply-To: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> References: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> Message-ID: On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph wrote: > CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native > threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() > function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native > threads for x86 to 1 MB. Looks good to me, Tested on Windows with test case added in JBS. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/159 From ghb at openjdk.java.net Fri Apr 10 16:32:08 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 10 Apr 2020 16:32:08 GMT Subject: [Rev 01] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: <5YmcHntf1Eh0B834KOCZKJQPRp54JcokstInXVx-oAM=.17a1eacd-256f-46a0-a70a-e5481458fbb1@github.com> On Wed, 8 Apr 2020 11:55:03 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java >> side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Looks good to me. Tested on Windows and mac OS X. If feasible can we have Unit test for this. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/164 From tsayao at openjdk.java.net Fri Apr 10 19:00:25 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 10 Apr 2020 19:00:25 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: > Simple fix to remove annoying warnings. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Gstreamer build ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/150/files - new: https://git.openjdk.java.net/jfx/pull/150/files/67adeaee..92f1b9ab Webrevs: - full: https://webrevs.openjdk.java.net/jfx/150/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/150/webrev.02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/150.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/150/head:pull/150 PR: https://git.openjdk.java.net/jfx/pull/150 From tsayao at openjdk.java.net Fri Apr 10 19:00:26 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 10 Apr 2020 19:00:26 GMT Subject: [Rev 02] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Wed, 8 Apr 2020 18:34:56 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Sep cppFlags and cFlags > > The build changes in `linux.gradle` look good. I tested it, and all warnings are gone (including those in WebKit) > except for the ones in the jfxmedia sub-project of javafx.media. > Two comments: > > 1. I changed the bug title in JBS to refer to gcc 9 rather than Ubuntu to reflect the actual cause of the additional > warnings. Can you update the title of this PR to match? 8241476: Linux build warnings issued on gcc 9 > > 2. Can you add the following change to your PR as well? This will fix the remaining warnings in jfxmedia: > > --- a/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > +++ b/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > @@ -41,7 +41,6 @@ ifdef HOST_COMPILE > -Wextra \ > -Wformat-security \ > -fstack-protector \ > - -Werror=implicit-function-declaration \ > -Werror=trampolines \ > -msse2 \ > -DGSTREAMER_LITE Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From tsayao at openjdk.java.net Fri Apr 10 19:20:34 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 10 Apr 2020 19:20:34 GMT Subject: [Rev 49] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: <2y07dBE6cmyoIk4oGlgU3_sxEnXivy3jgPQeNMMcHTE=.8d48545c-3336-4607-abf1-abfba76f1a2a@github.com> > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Rename flag to javafx.gtk.experimental - Rename flag to javafx.gtk.experimental ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/d18b5be4..85defa52 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.49 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.48-49 Stats: 27 lines in 29 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Fri Apr 10 21:59:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Apr 2020 21:59:57 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Fri, 10 Apr 2020 19:00:25 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to remove annoying warnings. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Gstreamer build Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/150 From jvos at openjdk.java.net Sat Apr 11 08:21:28 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 11 Apr 2020 08:21:28 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> References: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> Message-ID: On Wed, 8 Apr 2020 21:26:40 GMT, Kevin Rushforth wrote: >> This PR comments out too verbose console logging, as it has been done with some other fprintf calls. >> As a follow up of this PR, a custom directive that enables this output if needed can be considered. > > Marked as reviewed by kcr (Lead). The root cause for this issue is not the unnecessary logging, but the fact that the Quantum Renderer keeps running when the app is not in the foreground (causing a long list of debug lines). I'll create a separate issue for that. ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From arapte at openjdk.java.net Sat Apr 11 10:17:24 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 11 Apr 2020 10:17:24 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing Message-ID: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. Fix: 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. Change unrelated to fix: `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed for the fix. But this seems to be dead code. Verification: Added new unit tests to verify the change. Also verified that the behavior ListView behaves same before and after this change. ------------- Commit messages: - 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing Changes: https://git.openjdk.java.net/jfx/pull/172/files Webrev: https://webrevs.openjdk.java.net/jfx/172/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209788 Stats: 211 lines in 6 files changed: 151 ins; 49 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From aghaisas at openjdk.java.net Mon Apr 13 07:08:01 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 13 Apr 2020 07:08:01 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly Message-ID: Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 Root Cause : Incorrect implementation. Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. Fix : Added a method for IntegerSpinnerValueFactory with separate implementation. Testing : Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed separately. ------------- Commit messages: - IntegerSpinner_wrapAround Changes: https://git.openjdk.java.net/jfx/pull/174/files Webrev: https://webrevs.openjdk.java.net/jfx/174/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193286 Stats: 202 lines in 3 files changed: 195 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/174/head:pull/174 PR: https://git.openjdk.java.net/jfx/pull/174 From arapte at openjdk.java.net Mon Apr 13 08:25:39 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 13 Apr 2020 08:25:39 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel Message-ID: `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member `selectionModel`. The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). ------------- Commit messages: - 8241737: TabPaneSkin memory leak on replacing selectionModel Changes: https://git.openjdk.java.net/jfx/pull/175/files Webrev: https://webrevs.openjdk.java.net/jfx/175/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241737 Stats: 36 lines in 2 files changed: 26 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/175/head:pull/175 PR: https://git.openjdk.java.net/jfx/pull/175 From fastegal at swingempire.de Mon Apr 13 10:48:16 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 13 Apr 2020 12:48:16 +0200 Subject: Automate copyright year? Message-ID: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> Seeing that missing to update of copyright year in the header is rather common (in my own pull requests as well as in others :) is there any means to do so automatically or some source tool (for me that would be for Eclipse) that would do on request? -- Jeanette From fastegal at openjdk.java.net Mon Apr 13 11:00:20 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 13 Apr 2020 11:00:20 GMT Subject: RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection Message-ID: Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else block when updating toggle selection state (see report for details). Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the incorrect selection state - removed listener to selected item - removed toggle selection update in showing listener The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel is null initially. Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the informally ignored test part for memory leak. ------------- Commit messages: - 8242489: ChoiceBox: initially toggle not sync'ed to selection Changes: https://git.openjdk.java.net/jfx/pull/177/files Webrev: https://webrevs.openjdk.java.net/jfx/177/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242489 Stats: 375 lines in 5 files changed: 347 ins; 25 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177 PR: https://git.openjdk.java.net/jfx/pull/177 From kevin.rushforth at oracle.com Mon Apr 13 12:33:42 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Apr 2020 05:33:42 -0700 Subject: Automate copyright year? In-Reply-To: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> References: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> Message-ID: <5cbbcdc4-913f-df30-df9d-6204c23da6da@oracle.com> Not that I know of. FWIW, I'm not too bothered by this, since I run a script 2-3 times a year to update the copyright years for those files fixed in the current year. -- Kevin On 4/13/2020 3:48 AM, Jeanette Winzenburg wrote: > > Seeing that missing to update of copyright year in the header is > rather common (in my own pull requests as well as in others :) is > there any means to do so automatically or some source tool (for me > that would be for Eclipse) that would do on request? > > -- Jeanette > From kcr at openjdk.java.net Mon Apr 13 14:35:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 14:35:04 GMT Subject: RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 10:36:51 GMT, Jeanette Winzenburg wrote: > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. @aghaisas can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From kcr at openjdk.java.net Mon Apr 13 14:49:50 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 14:49:50 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Fri, 10 Apr 2020 21:57:43 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Gstreamer build > > Looks good. @johanvos or @arapte Can one of you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From fastegal at openjdk.java.net Mon Apr 13 16:04:18 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 13 Apr 2020 16:04:18 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 08:03:09 GMT, Ambarish Rapte wrote: > `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being > GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. > If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member > `selectionModel`. > The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for > [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). Changes requested by fastegal (Author). modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 270: > 269: } > 270: > 271: super.dispose(); wondering if the removal is really needed? The memory leak seems to be fixed without explicit removing. Did you experience any side-effects if not? If so, a unit test covering that would be cool. There are other (mostly) skins that have a weak "path listener" which is not removed on dispose, they need a re-visit to see if the side-effect applies to them as well. Or the other way round: without a detectable side-effect, not doing it might be okay. Whatever the outcome, this looks like a pattern to remember when skins are listening weakly :) ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From kcr at openjdk.java.net Mon Apr 13 16:37:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:37:28 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth wrote: > This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done > for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). > On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by > [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. > I have run a full build and test using this new compiler. /reviewers 2 ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From kcr at openjdk.java.net Mon Apr 13 16:37:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:37:28 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux Message-ID: This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. I have run a full build and test using this new compiler. ------------- Commit messages: - 8242490: Upgrade to gcc 9.2 on Linux Changes: https://git.openjdk.java.net/jfx/pull/178/files Webrev: https://webrevs.openjdk.java.net/jfx/178/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242490 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/178.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/178/head:pull/178 PR: https://git.openjdk.java.net/jfx/pull/178 From kcr at openjdk.java.net Mon Apr 13 16:37:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:37:28 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 16:13:42 GMT, Kevin Rushforth wrote: >> This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done >> for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). >> On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by >> [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. >> I have run a full build and test using this new compiler. > > /reviewers 2 @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From jvos at openjdk.java.net Mon Apr 13 18:58:48 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 13 Apr 2020 18:58:48 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> Message-ID: On Sat, 11 Apr 2020 08:19:16 GMT, Johan Vos wrote: >> Marked as reviewed by kcr (Lead). > > The root cause for this issue is not the unnecessary logging, but the fact that the Quantum Renderer keeps running when > the app is not in the foreground (causing a long list of debug lines). I'll create a separate issue for that. It would be nice to show this debug info when javafx.pulseLogger is true, and hide it when that property is false. It shows interesting information about the rendering phase, so when that info is requested (by enabling pulseLogger), it is useful. ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From nlisker at gmail.com Mon Apr 13 20:49:59 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 13 Apr 2020 23:49:59 +0300 Subject: Testing JavaFX with Java14 preview features Message-ID: Hi, I would like to test the preview features in Java 14 on JavaFX. What changes should I make in the build files to get it working? - Nir From kevin.rushforth at oracle.com Mon Apr 13 22:59:57 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Apr 2020 15:59:57 -0700 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: Message-ID: I guess you mean modifying the FX build in your local repo so that you can test the use of JDK 14 preview features in FX itself? (if you were just trying to use it from your app you wouldn't need any build changes in FX). At a minimum you would need to add the "--enable-preview" flag to compile.options.compilerArgs, and change "sourceCompatibility" from "11" to "14". Not sure if anything more is needed. I've never tried it. -- Kevin On 4/13/2020 1:49 PM, Nir Lisker wrote: > Hi, > > I would like to test the preview features in Java 14 on JavaFX. What > changes should I make in the build files to get it working? > > - Nir From nlisker at gmail.com Mon Apr 13 23:10:50 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 14 Apr 2020 02:10:50 +0300 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: Message-ID: Thanks, yes, testing on JavaFX itself. I made these changes. I'm getting "error: invalid source release: 14" when trying to build. These are the settings that are output during the task: Gradle Distribution: Gradle wrapper from target build Gradle Version: 6.3 Java Home: C:\Program Files\Java\jdk-14 JVM Arguments: None Program Arguments: None Build Scans Enabled: false Offline Mode Enabled: false Gradle Tasks: build This is the full error message: error: invalid source release: 14 Usage: javac use --help for a list of possible options FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':base:compileJava'. > Compilation failed with exit code 2; see the compiler error output for details. On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth wrote: > I guess you mean modifying the FX build in your local repo so that you > can test the use of JDK 14 preview features in FX itself? (if you were > just trying to use it from your app you wouldn't need any build changes > in FX). At a minimum you would need to add the "--enable-preview" flag > to compile.options.compilerArgs, and change "sourceCompatibility" from > "11" to "14". Not sure if anything more is needed. I've never tried it. > > -- Kevin > > > On 4/13/2020 1:49 PM, Nir Lisker wrote: > > Hi, > > > > I would like to test the preview features in Java 14 on JavaFX. What > > changes should I make in the build files to get it working? > > > > - Nir > > From kevin.rushforth at oracle.com Mon Apr 13 23:38:23 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:38:23 -0700 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: Message-ID: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> Not sure, but you might check here: modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt That's the list of args that gradle generates to pass to javac (using @.../java-compiler-args.txt) -- Kevin On 4/13/2020 4:10 PM, Nir Lisker wrote: > Thanks, yes, testing on JavaFX itself. > I made these changes. I'm getting "error: invalid source release: 14" > when trying to build. These are the settings that are output during > the task: > > Gradle Distribution: Gradle wrapper from target build > Gradle Version: 6.3 > Java Home: C:\Program Files\Java\jdk-14 > JVM Arguments: None > Program Arguments: None > Build Scans Enabled: false > Offline Mode Enabled: false > Gradle Tasks: build > > This is the full error message: > > error: invalid source release: 14 > Usage: javac > use --help for a list of possible options > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':base:compileJava'. > > Compilation failed with exit code 2; see the compiler error output > for details. > > On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth > > wrote: > > I guess you mean modifying the FX build in your local repo so that > you > can test the use of JDK 14 preview features in FX itself? (if you > were > just trying to use it from your app you wouldn't need any build > changes > in FX). At a minimum you would need to add the "--enable-preview" > flag > to compile.options.compilerArgs, and change "sourceCompatibility" > from > "11" to "14". Not sure if anything more is needed. I've never > tried it. > > -- Kevin > > > On 4/13/2020 1:49 PM, Nir Lisker wrote: > > Hi, > > > > I would like to test the preview features in Java 14 on JavaFX. What > > changes should I make in the build files to get it working? > > > > - Nir > From almatvee at openjdk.java.net Tue Apr 14 00:09:26 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 14 Apr 2020 00:09:26 GMT Subject: RFR: 8241629: [macos10.15] Long startup delay playing media over https on Catalina Message-ID: https://bugs.openjdk.java.net/browse/JDK-8241629 We used to link with system provided libffi (due to a bug in Makefile) and for some reason GLib signals did not work correctly and thus we did not able to build dynamic pipelines. We did not switch to AVFoundation until timeout is reached while waiting for GStreamer to start playing or report us an error. Fixed by linking GLib with libffi which we build, like we do for other platforms. ------------- Commit messages: - 8241629: [macos10.15] Long startup delay playing media over https on Catalina Changes: https://git.openjdk.java.net/jfx/pull/179/files Webrev: https://webrevs.openjdk.java.net/jfx/179/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241629 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/179.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/179/head:pull/179 PR: https://git.openjdk.java.net/jfx/pull/179 From kcr at openjdk.java.net Tue Apr 14 00:16:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 00:16:27 GMT Subject: RFR: 8241629: [macos10.15] Long startup delay playing media over https on Catalina In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 23:07:12 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8241629 > > We used to link with system provided libffi (due to a bug in Makefile) and for some reason GLib signals did not work > correctly and thus we did not able to build dynamic pipelines. We did not switch to AVFoundation until timeout is > reached while waiting for GStreamer to start playing or report us an error. Fixed by linking GLib with libffi which we > build, like we do for other platforms. Looks good. I tested it on both 10.15.x (Catalina) and 10.13.x (High Sierra). I confirm that there is no more dependency on the system libffi. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/179 From nlisker at gmail.com Tue Apr 14 01:35:58 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 14 Apr 2020 04:35:58 +0300 Subject: Testing JavaFX with Java14 preview features In-Reply-To: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> References: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> Message-ID: It contains: -source 14 -target 14 Looks like I'll have to do some digging. Thanks On Tue, Apr 14, 2020 at 2:38 AM Kevin Rushforth wrote: > Not sure, but you might check here: > > modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt > > That's the list of args that gradle generates to pass to javac (using > @.../java-compiler-args.txt) > > -- Kevin > > On 4/13/2020 4:10 PM, Nir Lisker wrote: > > Thanks, yes, testing on JavaFX itself. > I made these changes. I'm getting "error: invalid source release: 14" when > trying to build. These are the settings that are output during the task: > > Gradle Distribution: Gradle wrapper from target build > Gradle Version: 6.3 > Java Home: C:\Program Files\Java\jdk-14 > JVM Arguments: None > Program Arguments: None > Build Scans Enabled: false > Offline Mode Enabled: false > Gradle Tasks: build > > This is the full error message: > > error: invalid source release: 14 > Usage: javac > use --help for a list of possible options > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':base:compileJava'. > > Compilation failed with exit code 2; see the compiler error output for > details. > > On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I guess you mean modifying the FX build in your local repo so that you >> can test the use of JDK 14 preview features in FX itself? (if you were >> just trying to use it from your app you wouldn't need any build changes >> in FX). At a minimum you would need to add the "--enable-preview" flag >> to compile.options.compilerArgs, and change "sourceCompatibility" from >> "11" to "14". Not sure if anything more is needed. I've never tried it. >> >> -- Kevin >> >> >> On 4/13/2020 1:49 PM, Nir Lisker wrote: >> > Hi, >> > >> > I would like to test the preview features in Java 14 on JavaFX. What >> > changes should I make in the build files to get it working? >> > >> > - Nir >> >> > From tschindl at openjdk.java.net Tue Apr 14 04:48:31 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Tue, 14 Apr 2020 04:48:31 GMT Subject: RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Message-ID: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Extract keystate and add to the existing modifier mask, to support eg multi-select https://bugs.openjdk.java.net/browse/JDK-8202296 ------------- Commit messages: - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Changes: https://git.openjdk.java.net/jfx/pull/170/files Webrev: https://webrevs.openjdk.java.net/jfx/170/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202296 Stats: 20 lines in 1 file changed: 14 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From jhendrikx at openjdk.java.net Tue Apr 14 04:54:27 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 14 Apr 2020 04:54:27 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation Message-ID: This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. ------------- Commit messages: - 8242548: Honor line spacing in Labeled reflow calculation Changes: https://git.openjdk.java.net/jfx/pull/173/files Webrev: https://webrevs.openjdk.java.net/jfx/173/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242548 Stats: 44 lines in 4 files changed: 40 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/173/head:pull/173 PR: https://git.openjdk.java.net/jfx/pull/173 From arapte at openjdk.java.net Tue Apr 14 08:43:38 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 08:43:38 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: <171xckDtVxAoZqEUFk59iUrKnGM14RfL0K-d19a9pls=.469bf2e5-809b-4369-bb19-0e6f8cfc03f9@github.com> On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth wrote: > This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done > for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). > On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by > [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. > I have run a full build and test using this new compiler. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From florian.kirmaier at gmail.com Tue Apr 14 10:15:49 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Tue, 14 Apr 2020 12:15:49 +0200 Subject: Mac: Supported MacOS JDKs Message-ID: Hi everyone, it seems to me, that the newest JDK for Mac (MacOSX10.15.sdk) doesn't work to build JavaFX. It works for me with 10.14 but not with 10.15. Can anyone confirm this? It would be great to mention this in the build instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX Greetings Florian Kirmaier From jpereda at openjdk.java.net Tue Apr 14 10:40:43 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 14 Apr 2020 10:40:43 GMT Subject: RFR: 8242577: Cell selection fails on iOS most of the times Message-ID: There are cases when iOS sends one or more NSTouchPhaseMoved for a given touch event, in between NSTouchPhaseBegan and NSTouchPhaseEnded , even if the initial event location didn't change. By default, all these events are emulated as mouse enter/down, drag and up/exit events. However, when the user taps quickly or even holds steady on a cell, if these touch moved events are generated and sent as mouse drag events, the cell selection fails, as the flag `latePress` used in [CellBehaviorBase](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java#L191) is set to false, preventing the cell selection that should happen upon touch release event. This PR prevents emulating mouse drag events when the touch event doesn't change its location. ------------- Commit messages: - Don?t emulate as mouse drag events touch moved events if location didn?t change Changes: https://git.openjdk.java.net/jfx/pull/181/files Webrev: https://webrevs.openjdk.java.net/jfx/181/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242577 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/181.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/181/head:pull/181 PR: https://git.openjdk.java.net/jfx/pull/181 From fkirmaier at openjdk.java.net Tue Apr 14 10:50:13 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 14 Apr 2020 10:50:13 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 09:44:34 GMT, Ambarish Rapte wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 77: > >> 76: Platform.runLater(() -> stage.close()); >> 77: } >> 78: > > Looks like the primary `stage` is not required for actual test, and this block is only used to initialize JavaFX > runtime. Please check if it can be replaced by below block > ``` > @BeforeClass > public static void initFX() throws Exception { > startupLatch = new CountDownLatch(1); > Platform.startup(startupLatch::countDown); > Assert.assertTrue("Timeout waiting for FX runtime to start", > startupLatch.await(15, TimeUnit.MILLISECONDS)); > } This version doesn't work for me. With this change, I get the following error: test.javafx.stage.FocusedWindowTest > testLeak FAILED junit.framework.AssertionFailedError: Exceeded timeout limit of 10000 msec at test.util.Util.runAndWait(Util.java:163) at test.util.Util.runAndWait(Util.java:134) at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:82) ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Tue Apr 14 11:15:32 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 14 Apr 2020 11:15:32 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8241840 Some code cleanups ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/153/files - new: https://git.openjdk.java.net/jfx/pull/153/files/991d3ffa..20865db8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/153/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/153/webrev.00-01 Stats: 41 lines in 2 files changed: 9 ins; 24 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Tue Apr 14 11:15:35 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 14 Apr 2020 11:15:35 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 09:51:18 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> Some code cleanups > > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 133: > >> 132: >> 133: Assert.assertNull(weakReference.get()); >> 134: } > > This assert check call should be added to the @Test method. > I would recommend to refer [this > method](https://github.com/openjdk/jfx/blob/364c64a2e55b561df4ca1afc85c91054b339eea8/modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java#L1998) > from ListViewTest. Unifying memory-tests is something I discussed in my last PR. This code is based on my previous pull request: https://github.com/openjdk/jfx/pull/71 I would like to keep this version which I've used there. But it really has to be a library/utility-class which is used across the project instead of reinventing it on every test. > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 84: > >> 83: counter += 1; >> 84: testLeakOnce(); >> 85: } > > If the test has constant behavior on every run, then only one run should be done. done > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 354: > >> 353: } >> 354: if(Window.focusedWindow == this) { >> 355: Window.focusedWindow = null; > > Please correct format by adding space after `if`. done > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 113: > >> 112: }); >> 113: >> 114: Assert.assertTrue("Timeout, waiting for runLater. ", leakLatch.await(15, TimeUnit.SECONDS)); > > Is it really required to nest the `Platform.runLater()` calls ? Can you please check if this code can be simplified by > making the calls sequential, Consider using `Util.runAndWait()` done > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 53: > >> 52: System.setProperty("monocle.platform","Headless"); >> 53: } >> 54: > > The test will always run with Monocle. I see that if this static block is removed then the test fails on Windows 10. > Can you please verify all the platforms and change the test such that it runs on all platforms/ combinations. I wasn't able to reproduce the Problem on Window10 with VirtualBox. How should I do it? Add a second test class without the static code? Do you have a good recommendation on how to add it? ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Tue Apr 14 11:43:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:43:32 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Sun, 12 Apr 2020 21:21:07 GMT, John Hendrikx wrote: > This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. @aghaisas can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From kcr at openjdk.java.net Tue Apr 14 11:44:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:44:45 GMT Subject: RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: On Fri, 10 Apr 2020 10:26:06 GMT, Tom Schindl wrote: > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 The fix looks simple enough. Can you add a unit test? ------------- PR: https://git.openjdk.java.net/jfx/pull/170 From kcr at openjdk.java.net Tue Apr 14 11:49:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:49:32 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> Message-ID: On Sun, 9 Feb 2020 14:40:25 GMT, Jeanette Winzenburg wrote: >> I left comments inline. This will need changes. Also, you will need to provide a test that fails without the fix and >> passes with the fix. > > Just a comment on how to add a failing test: we can replace the actual typing (in the TestFx context) by > programmatically replacing the selection, actually, it doesn't even need the skin (so no scene nor parent) because all > collaborators are in TextInputControl: > /** > * Test for JDK-8176270: register changeListener on selectedText, select at > * end of text and replace selection throws. > */ > @Test > public void addingChangeListenerNoSkin() { > TextField textField = new TextField(); > textField.setText("1234 5678"); > textField.selectedTextProperty() > .addListener((o, ov, nv) -> {}); > > textField.positionCaret(5); > textField.selectEnd(); > textField.replaceSelection("d"); > } > > Similarly, an invalidationListener that access the selectedText throws, while an invalidationListener not accessing the > selected is fine. ~~So it looks like a one-off when evaluating the actual selection during the process, somehow it's > not yet ready~~ That was my wrong assumption, the culprit is really the incorrect clamping of a no-longer valid end > index when adjusting the selectedText binding (as @Kevin noted above). It shows only if the selectedText must be > re-evaluated before the selectionRange is updated, f.i. forced by a changeListener (or direct access). To make the > error show up on the test thread, replace the uncaughtExceptionHandler before (and cleanup after): > @Before public void setup() throws Exception { > Thread.currentThread().setUncaughtExceptionHandler((thread, throwable) -> { > if (throwable instanceof RuntimeException) { > throw (RuntimeException)throwable; > } else { > Thread.currentThread().getThreadGroup().uncaughtException(thread, throwable); > } > }); > textInput = (TextInputControl) type.newInstance(); > } > > > @After public void cleanup() { > Thread.currentThread().setUncaughtExceptionHandler(null); > } @koppor are you planning to resume work on this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/73 From kcr at openjdk.java.net Tue Apr 14 11:54:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:54:19 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Thu, 27 Feb 2020 00:01:28 GMT, Kevin Rushforth wrote: >> Allow to override buildDate with `SOURCE_DATE_EPOCH` >> in order to make builds reproducible. >> See https://reproducible-builds.org/ for why this is good >> and https://reproducible-builds.org/specs/source-date-epoch/ >> for the definition of this variable. >> >> This PR was done while working on reproducible builds for openSUSE. > > Finally getting to this (sorry for the delay). This seems OK to me, as it is not an intrusive change. I do not think > that actually setting this property for production builds is a good idea, so I recommend against that (ultimately that > will be up to Gluon or whoever produces builds). I'll test it once you change it from an env variable to a gradle > property. @bmwiedemann are you planning to pursue this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Tue Apr 14 12:00:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 12:00:02 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Fri, 13 Mar 2020 13:05:29 GMT, Tobias Diez wrote: >> You must have some use case that fails without this proposed fix (else why are you proposing it), right? > > Yes, we had this exception in our application which was (temporarily) fixed with > https://github.com/JabRef/jabref/pull/5497. But JabRef is 100k lines of code, so I doubt this counts as a unit test. @tobiasdiez are you planning to pursue this? The review is pending a simple test case. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From jhendrikx at openjdk.java.net Tue Apr 14 12:22:22 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 14 Apr 2020 12:22:22 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: On Tue, 10 Mar 2020 06:08:25 GMT, yosbits wrote: >>> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time >>> (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, >>> we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing >>> it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin >>> has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal >>> code does it .. >> >> So we can choose to specify it as ordered. >> >> These are the 2 options I mentioned: >> 1. Not specify the behavior and change the implementation in favor of performance. This could break applications as >> you've mentioned. 2. Specify that the order is preserved and keep the ordered implementation behavior. This will allow >> applications to rely on the behavior safely. >> Right now we're losing on both sides. We keep a promise and we don't tell anyone about it. The only reason for this is >> if we intend to change the behavior in the future, in which case we should add a doc comment saying that the order is >> unspecified and is planned to change in the future, so there will be at least some warning. Once we choose what to do >> here it will make sense to continue to review the code with that decision in mind. > > In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce > the performance improvement. I have attached a test program in my PR(#125) @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow.". Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when the listeners are spread out over dozens of properties, and although high in total number, the total listeners per property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Tue Apr 14 12:23:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 12:23:09 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 15:47:00 GMT, Jeanette Winzenburg wrote: >> `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being >> GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. >> If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member >> `selectionModel`. >> The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for >> [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 270: > >> 269: } >> 270: >> 271: super.dispose(); > > wondering if the removal is really needed? The memory leak seems to be fixed without explicit removing. Did you > experience any side-effects if not? > If so, a unit test covering that would be cool. There are other (mostly) skins that have a weak "path listener" which > is not removed on dispose, they need a re-visit to see if the side-effect applies to them as well. Or the other way > round: without a detectable side-effect, not doing it might be okay. Whatever the outcome, this looks like a pattern > to remember when skins are listening weakly :) This is needed to future safe the code from an NPE from scenarios as in below test case, class TabPaneSkin1 extends TabPaneSkin { TabPaneSkin1(TabPane tabPane) { super(tabPane); } } @Test public void testNPEOnSwitchSkinAndRemoveTabPane() { TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); Group root = new Group(testPane); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); stage.show(); tk.firePulse(); testPane.setSkin(new TabPaneSkin1(testPane)); tk.firePulse(); testPane.getSelectionModel().select(1); tk.firePulse(); } But currently this throws an NPE at different code, java.lang.NullPointerException at javafx.controls/javafx.scene.control.skin.TabPaneSkin.isHorizontal(TabPaneSkin.java:699) at javafx.controls/javafx.scene.control.skin.TabPaneSkin$TabHeaderArea.layoutChildren(TabPaneSkin.java:1134) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1207) This is part of an another problem that skins should remove all listeners when switched. So I think we can not add this test with this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From johan.vos at gluonhq.com Tue Apr 14 12:53:41 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Apr 2020 14:53:41 +0200 Subject: RFR: backport fixes for JavaFX 14.0.1 Message-ID: Hi Kevin, I request permission to backport the following fixes into JavaFX 14.0.1 (in the jfx14 branch). https://bugs.openjdk.java.net/browse/JDK-8233942 JDK-8233942 -- Update to 609.1 version of WebKit https://bugs.openjdk.java.net/browse/JDK-8237003 JDK-8237003 -- Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree https://bugs.openjdk.java.net/browse/JDK-8238256 JDK-8238526 -- Cherry pick GTK WebKit 2.26.3 changes https://bugs.openjdk.java.net/browse/JDK-8239454 JDK-8239454 -- LLIntData : invalid opcode returned for 16 and 32 bit wide instructions https://bugs.openjdk.java.net/browse/JDK-8239109 JDK-8239109 -- Update SQLite to version 3.31.1 https://bugs.openjdk.java.net/browse/JDK-8240211 JDK-8240211 -- Stack overflow on Windows 32-bit can lead to crash https://bugs.openjdk.java.net/browse/JDK-8240832 JDK-8240832 -- Remove unused applecoreaudio.md third-party legal file The following diff would bring those fixes into JavaFX 14.0.1: https://github.com/openjdk/jfx/compare/jfx14...johanvos:jfx14 Those patches would be integrated directly, and not via a PR. Thanks, - Johan From fastegal at openjdk.java.net Tue Apr 14 13:03:36 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 14 Apr 2020 13:03:36 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 12:20:16 GMT, Ambarish Rapte wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 270: >> >>> 269: } >>> 270: >>> 271: super.dispose(); >> >> wondering if the removal is really needed? The memory leak seems to be fixed without explicit removing. Did you >> experience any side-effects if not? >> If so, a unit test covering that would be cool. There are other (mostly) skins that have a weak "path listener" which >> is not removed on dispose, they need a re-visit to see if the side-effect applies to them as well. Or the other way >> round: without a detectable side-effect, not doing it might be okay. Whatever the outcome, this looks like a pattern >> to remember when skins are listening weakly :) > > This is needed to future safe the code from an NPE from scenarios as in below test case, > > class TabPaneSkin1 extends TabPaneSkin { > TabPaneSkin1(TabPane tabPane) { > super(tabPane); > } > } > > @Test > public void testNPEOnSwitchSkinAndRemoveTabPane() { > TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); > Group root = new Group(testPane); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > stage.show(); > tk.firePulse(); > > testPane.setSkin(new TabPaneSkin1(testPane)); > tk.firePulse(); > testPane.getSelectionModel().select(1); > tk.firePulse(); > } > > But currently this throws an NPE at different code, > java.lang.NullPointerException > at javafx.controls/javafx.scene.control.skin.TabPaneSkin.isHorizontal(TabPaneSkin.java:699) > at javafx.controls/javafx.scene.control.skin.TabPaneSkin$TabHeaderArea.layoutChildren(TabPaneSkin.java:1134) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1207) > > This is part of an another problem that skins should remove all listeners when switched. > So I think we can not add this test with this fix. thanks for the test :) Good catch, and I can reproduce it, though with a twist: - with firing the pulse I see the error you cited - without firing the pulse, I see the error in the selected item listener (because the skinnable is null) which to me appears to be "nearer" the real reason Whatever the error, though, we learned that we must be extremely careful with (even weak) listeners - at least when they fall into some categories. So far we had - listeners to path properties - listeners that change global state (like in the button skin issue) - ?? maybe all Personally, I would tend to keep and ignore that test with doc: the ignore could point to https://bugs.openjdk.java.net/browse/JDK-8242621 (memory leak on switching tab, which might or not be related), the removing code could have a code comment explaining why it is needed. What do you think? ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From github.com+5037600+tobiasdiez at openjdk.java.net Tue Apr 14 13:18:54 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Tue, 14 Apr 2020 13:18:54 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Tue, 14 Apr 2020 11:49:50 GMT, Kevin Rushforth wrote: >> Yes, we had this exception in our application which was (temporarily) fixed with >> https://github.com/JabRef/jabref/pull/5497. But JabRef is 100k lines of code, so I doubt this counts as a unit test. > > @tobiasdiez are you planning to pursue this? The review is pending a simple test case. @kevinrushforth I've now added a test. Hope it's ok like this. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Tue Apr 14 13:18:54 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Tue, 14 Apr 2020 13:18:54 GMT Subject: [Rev 01] RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: Message-ID: > Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url > start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/22/files - new: https://git.openjdk.java.net/jfx/pull/22/files/391c4fa5..f58ddfca Webrevs: - full: https://webrevs.openjdk.java.net/jfx/22/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/22/webrev.00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/22/head:pull/22 PR: https://git.openjdk.java.net/jfx/pull/22 From fastegal at openjdk.java.net Tue Apr 14 13:29:02 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 14 Apr 2020 13:29:02 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 13:01:18 GMT, Jeanette Winzenburg wrote: >> This is needed to future safe the code from an NPE from scenarios as in below test case, >> >> class TabPaneSkin1 extends TabPaneSkin { >> TabPaneSkin1(TabPane tabPane) { >> super(tabPane); >> } >> } >> >> @Test >> public void testNPEOnSwitchSkinAndRemoveTabPane() { >> TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); >> Group root = new Group(testPane); >> Scene scene = new Scene(root); >> Stage stage = new Stage(); >> stage.setScene(scene); >> stage.show(); >> tk.firePulse(); >> >> testPane.setSkin(new TabPaneSkin1(testPane)); >> tk.firePulse(); >> testPane.getSelectionModel().select(1); >> tk.firePulse(); >> } >> >> But currently this throws an NPE at different code, >> java.lang.NullPointerException >> at javafx.controls/javafx.scene.control.skin.TabPaneSkin.isHorizontal(TabPaneSkin.java:699) >> at javafx.controls/javafx.scene.control.skin.TabPaneSkin$TabHeaderArea.layoutChildren(TabPaneSkin.java:1134) >> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1207) >> >> This is part of an another problem that skins should remove all listeners when switched. >> So I think we can not add this test with this fix. > > thanks for the test :) > > Good catch, and I can reproduce it, though with a twist: > > - with firing the pulse I see the error you cited > - without firing the pulse, I see the error in the selected item listener (because the skinnable is null) which to me > appears to be "nearer" the real reason > > Whatever the error, though, we learned that we must be extremely careful with (even weak) listeners - at least when > they fall into some categories. So far we had > - listeners to path properties > - listeners that change global state (like in the button skin issue) > - ?? maybe all > > Personally, I would tend to keep and ignore that test with doc: the ignore could point to > https://bugs.openjdk.java.net/browse/JDK-8242621 (memory leak on switching tab, which might or not be related), the > removing code could have a code comment explaining why it is needed. What do you think? Looked again, and actually seeing two different issues ;) A) your test - that is with firing the pulse: fails for both not/removing the listener B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener So I think we should include B as it is directly related to this fix (and verifies the need to remove the listener). As to A: we should keep it somewhere to not forget, but where? Test code B: @Test public void testNPEOnSwitchSkinAndSelect() { // want to replace the skin - test doesn't make sense without if (!showBeforeReplaceSM) return; TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); Group root = new Group(testPane); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); stage.show(); testPane.setSkin(new TabPaneSkin1(testPane)); testPane.getSelectionModel().select(1); } The exception (seen on the test stack when rewiring the uncaughthandler as usual, else on sysout): Exception in thread "main" java.lang.NullPointerException at javafx.controls/javafx.scene.control.skin.TabPaneSkin.lambda$0(TabPaneSkin.java:447) at javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:83) at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) at javafx.base/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:74) at javafx.base/javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102) at javafx.base/javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:113) at javafx.base/javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:147) at javafx.controls/javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:105) at javafx.controls/javafx.scene.control.TabPane$TabPaneSelectionModel.select(TabPane.java:736) at javafx.controls/test.javafx.scene.control.SelectionFocusModelMemoryTest.testNPEOnSwitchSkinAndRemoveTabPaneFirePulse(SelectionFocusModelMemoryTest.java:261) ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From kevin.rushforth at oracle.com Tue Apr 14 14:04:34 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 07:04:34 -0700 Subject: RFR: backport fixes for JavaFX 14.0.1 In-Reply-To: References: Message-ID: +1 Looks good. -- Kevin On 4/14/2020 5:53 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following fixes into JavaFX 14.0.1 (in > the jfx14 branch). > > > https://bugs.openjdk.java.net/browse/JDK-8233942 > JDK-8233942 -- Update to > 609.1 version of WebKit > > https://bugs.openjdk.java.net/browse/JDK-8237003 > JDK-8237003 -- Remove > hardcoded WebAnimationsCSSIntegrationEnabled flag > in DumpRenderTree > > https://bugs.openjdk.java.net/browse/JDK-8238256 > JDK-8238526 -- Cherry > pick GTK WebKit 2.26.3 changes > > https://bugs.openjdk.java.net/browse/JDK-8239454 > JDK-8239454 -- LLIntData > : invalid opcode returned for 16 and 32 bit > wide instructions > > https://bugs.openjdk.java.net/browse/JDK-8239109 > JDK-8239109 -- Update > SQLite to version 3.31.1 > > https://bugs.openjdk.java.net/browse/JDK-8240211 JDK-8240211 -- Stack > overflow on Windows 32-bit can lead to crash > > > https://bugs.openjdk.java.net/browse/JDK-8240832 > JDK-8240832 -- Remove > unused applecoreaudio.md third-party legal file > > The following diff would bring those fixes into JavaFX 14.0.1: > https://github.com/openjdk/jfx/compare/jfx14...johanvos:jfx14 > > Those patches would be integrated directly, and not via a PR. > > Thanks, > > - Johan From ajit.ghaisas at oracle.com Tue Apr 14 14:04:16 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 14 Apr 2020 19:34:16 +0530 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 Message-ID: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> Hi, Once I fix JDK-8193286, I would like to take up JDK-8242553 (IntegerSpinner does not wrap around values correctly if amountToStepBy is larger than total numbers between Max and Min) The current implementation is not as per what is documented. Refer : https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty I propose to fix the current buggy behavior of IntegerSpinner. Although it is a corner case, I would like to know if anybody relies on this buggy behavior? Regards, Ajit From fastegal at swingempire.de Tue Apr 14 14:31:45 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 14 Apr 2020 16:31:45 +0200 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> Message-ID: <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> Hi Ajit, thought the doc was simply bad (in specifying the behavior for amountPerStep = 1 and not thinking of larger amounts) - my expection is a calculated wrap, that is the target as you suggest via modulo the difference from current value. Don't know if anybody took the doc literally .. -- Jeanette Zitat von Ajit Ghaisas : > Hi, > > Once I fix JDK-8193286, I would like to take up JDK-8242553 > (IntegerSpinner does not wrap around values correctly if > amountToStepBy is larger than total numbers between Max and Min) > > The current implementation is not as per what is documented. > Refer : > https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty > > I propose to fix the current buggy behavior of IntegerSpinner. > Although it is a corner case, I would like to know if anybody > relies on this buggy behavior? > > Regards, > Ajit From jvos at openjdk.java.net Tue Apr 14 14:38:58 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Apr 2020 14:38:58 GMT Subject: [jfx14] RFR: 8242637: Change JavaFX release version in jfx14 branch to 14.0.1 Message-ID: Fix for JDK-8242637 ------------- Commit messages: - Increase release version for JavaFX 14.0.1 Changes: https://git.openjdk.java.net/jfx/pull/183/files Webrev: https://webrevs.openjdk.java.net/jfx/183/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242637 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/183/head:pull/183 PR: https://git.openjdk.java.net/jfx/pull/183 From kcr at openjdk.java.net Tue Apr 14 14:53:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 14:53:39 GMT Subject: [jfx14] RFR: 8242637: Change JavaFX release version in jfx14 branch to 14.0.1 In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 14:33:53 GMT, Johan Vos wrote: > Fix for JDK-8242637 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/183 From kevin.rushforth at oracle.com Tue Apr 14 15:58:40 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 08:58:40 -0700 Subject: RFR: Request to sync April 2020 CPU changes into jfx Message-ID: Johan and Phil, I request approval to sync changes from to the just-released April 2020 CPU release into the 'master' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/4d69a0d...cpu-2004-sync NOTE: Since this is an integration of already-reviewed fixes into the jfx repo, I will push it directly into the master branch rather than via a pull request. -- Kevin From kevin.rushforth at oracle.com Tue Apr 14 16:08:13 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 09:08:13 -0700 Subject: [11][14] RFR: Request to backport April 2020 CPU changes Message-ID: Hi Johan, I request approval to backport the changes from the just-released April 2020 CPU to 11-dev (for 11.0.7) and the jfx14 branch of jfx (for 14.0.1). https://cr.openjdk.java.net/~kcr/cpu-2004-sync/11-dev/webrev/ https://github.com/kevinrushforth/jfx/compare/f8c235b...14-cpu-2004-sync Each is a straight backport (patch applies cleanly) of the one FX fix that went into the April CPU. NOTE: For the 14.0.1 backport, since this is an integration of already-reviewed fixes into the jfx repo, I will push it directly into the jfx14 branch rather than via a pull request. The 11.0.7 backport will be pushed to the HG 11-dev repo. Thanks. -- Kevin From Rony.Flatscher at wu.ac.at Tue Apr 14 16:48:54 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 14 Apr 2020 18:48:54 +0200 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Message-ID: <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> Hi there, as there was probably enough time that has passed by I would intend to create a CSR in the next days with the PR as per Kevin's suggestion. (For the case that this feature should not be active by default, the CSR will suggest to define a new "compile" PI in the form (default, if no PI data given: true), which is independent of the existence of a language PI (this way it becomes also possible to allow compilation of external scripts denoted with the script-element, which do not need a page language to be set as the file's extension allows the appropriate script engine to be loaded and used for execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI or ? to FXML files (and to turn off), which seems to be simple and self-documentary. In general employing such compile PIs allows for setting compilation of scripts on and off throughout an FXML file.) ---rony On 04.04.2020 18:03, Rony G. Flatscher wrote: > Hi Kevin, > > On 03.04.2020 01:21, Kevin Rushforth wrote: >> I see that you updated the PR and sent it for review. >> >> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >> feature, and if so, what form this feature should take. >> >> From my point of view, this does seem like a useful feature. Would other users of FXML benefit >> from it? > Script code should be executed faster after compilation, so any FXML page that hosts script code may > benefit. > > The benefits depend on the type of script (and maybe its size and its complexity) and also on the > types of event handlers the scripts serve, e.g. move or drag event handlers may benefit > significantly. This is because repeated invocation of compiled script event handlers do not cause > the reparsing of that script's source and interpreting it on each invocation, which may be expensive > depending on the script engine, but rather allows the immediate evaluation/execution of the compiled > script by the script engine. > >> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >> question implements Compilable, or via a new keyword or tag. What are the pros / cons? > In principle there are three possibilities: > > 1) If a script engine implements javax.script.Compilable, compile the script and execute the > compiled version. In the case of event handlers compile and buffer the compiled script and > execute the compiled script each time its registered event fires. > > o Pro: immediately benefits all existing FXML pages that host scripts > o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail > compiling but have been employed successfully in interpreted mode > > 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML > language PI that switches on compilation of scripts hosted in FXML definitions if the script > engine implements the javax.script.Compilable interface. If missing it would default to "false". > (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the > script engine supports it. It would be an error if the "compile" PI was present, but the > "language" PI was not.) > > o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the language > PI gets changed > o Con: benefit not made available automatically to existing FXML pages that host scripts > > 3) Another possibility would be to define a boolean attribute/property "compile" for script and > node elements and only compile the scripts, if the property is set to true > > o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed > accordingly > o Con: potential benefit not made available automatically to existing FXML pages that host scripts > > 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be > overruled individually by 3. > > The question would be whether 2 or/and 3 are really necessary as it can be expected that compilation > of scripts by the script engines would find the same errors as while interpreting the very same > scripts (if not, the script engine is badly broken and it could be argued that then the > interpretation part of the script engine might be expected to be broken as well which would be quite > dangerous from an integrity POV; the same consideration applies as well if the execution of the > compiled script would behave differently to interpreting the very same script by the same script > engine). > > The current WIP implements 1 above and includes an appropriate test unit. > >> What do others think? > > >> In either case, we would need to make sure that this doesn't present any security concerns in the >> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >> but we would need to ensure that. > The compilation of scripts needs to be done by the Java script engines (implementing both, > javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled > scripts ([javax.script.CompiledScript] > (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). > > ---rony > > > >> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >>> pull request I would kindly request a review of this pull request! >>> >>> Here the URL: , title changed to: "8238080: FXMLLoader: if >>> script engines implement javax.script.Compilable compile scripts". >>> >>> ---rony >>> >>> >>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>>> has an appropriate test unit going with it as well, please review. >>>> >>>> There should be no compatibility issue with this implementation. >>>> >>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>> value >>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>>> respective solution as well. >>>> >>>> ---rony >>>> >>>> [1] "Implementation and test unit": >>>> >>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>> scripts": >>>> >>>> >>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>> >>>> >>>> >>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>> >>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>>> the concept). >>>>> >>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>> Just filed a RFE with the following information: >>>>>> >>>>>> ??? * Component: >>>>>> ??????? o JavaFX >>>>>> >>>>>> ??? * Subcomponent: >>>>>> ??????? o fxml: JavaFX FXML >>>>>> >>>>>> ??? * Synopsis: >>>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>> >>>>>> ??? * Descriptions: >>>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>> (javax.script.ScriptEngine >>>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>>> language in >>>>>> ????????? the FXML file. >>>>>> >>>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>>> could >>>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>> using >>>>>> ????????? its eval() methods. >>>>>> >>>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>> invocations, >>>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>> onMouseMove) >>>>>> ????????? which may be repetitevly invoked and evaluated." >>>>>> >>>>>> ??? * System /OS/Java Runtime Information: >>>>>> ??????? o "All systems." >>>>>> >>>>>> Received the internal review ID: "9063426" >>>>>> >>>>>> ---rony > From arapte at openjdk.java.net Tue Apr 14 17:19:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 17:19:48 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: <4z-EPq_6p7kA_4V83BNCGwSUIkyIa26vElssWJSeMPk=.3d7a78c8-a999-4a47-8a3e-c603f0a0a077@github.com> On Fri, 10 Apr 2020 19:00:25 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to remove annoying warnings. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Gstreamer build Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From arapte at openjdk.java.net Tue Apr 14 17:19:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 17:19:48 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 14:47:35 GMT, Kevin Rushforth wrote: >> Looks good. > > @johanvos or @arapte Can one of you be the second reviewer on this? After this change below c files would be compiled without `-Werror=implicit-function-declaration` option. modules/javafx.media/src/main/native/jfxmedia/Utils/ColorConverter.c modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c modules/javafx.graphics/src/main/native-glass/gtk/launcher.c This can be addressed in follow on issue. Recording the files here for track. Looks good to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From kevin.rushforth at oracle.com Tue Apr 14 17:52:44 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 10:52:44 -0700 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> Message-ID: Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to create the CSR until the review is far enough along to know which direction we intend to go. Unless there is a real concern about possible regressions if scripts are compiled by default, I think "enabled by default" is the way to go. Your argument that such script engines are broken seems reasonable, since this only applies to script engines that implement javax.script.Compilable in the first place. We still might want to add way to turn compilation off for individual scripts. One other thing to consider is that if compilation fails, it might make sense to log a warning and fall back to the existing interpreted mode. Does anyone else have any concerns with this? -- Kevin On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: > Hi there, > > as there was probably enough time that has passed by I would intend to create a CSR in the next days > with the PR as per Kevin's suggestion. > > (For the case that this feature should not be active by default, the CSR will suggest to define a > new "compile" PI in the form (default, if no PI data given: true), which > is independent of the existence of a language PI (this way it becomes also possible to allow > compilation of external scripts denoted with the script-element, which do not need a page language > to be set as the file's extension allows the appropriate script engine to be loaded and used for > execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI > or ? to FXML files (and to turn off), which seems to > be simple and self-documentary. In general employing such compile PIs allows for setting compilation > of scripts on and off throughout an FXML file.) > > ---rony > > > On 04.04.2020 18:03, Rony G. Flatscher wrote: > >> Hi Kevin, >> >> On 03.04.2020 01:21, Kevin Rushforth wrote: >>> I see that you updated the PR and sent it for review. >>> >>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>> feature, and if so, what form this feature should take. >>> >>> From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>> from it? >> Script code should be executed faster after compilation, so any FXML page that hosts script code may >> benefit. >> >> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >> significantly. This is because repeated invocation of compiled script event handlers do not cause >> the reparsing of that script's source and interpreting it on each invocation, which may be expensive >> depending on the script engine, but rather allows the immediate evaluation/execution of the compiled >> script by the script engine. >> >>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >> In principle there are three possibilities: >> >> 1) If a script engine implements javax.script.Compilable, compile the script and execute the >> compiled version. In the case of event handlers compile and buffer the compiled script and >> execute the compiled script each time its registered event fires. >> >> o Pro: immediately benefits all existing FXML pages that host scripts >> o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >> compiling but have been employed successfully in interpreted mode >> >> 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >> language PI that switches on compilation of scripts hosted in FXML definitions if the script >> engine implements the javax.script.Compilable interface. If missing it would default to "false". >> (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >> script engine supports it. It would be an error if the "compile" PI was present, but the >> "language" PI was not.) >> >> o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the language >> PI gets changed >> o Con: benefit not made available automatically to existing FXML pages that host scripts >> >> 3) Another possibility would be to define a boolean attribute/property "compile" for script and >> node elements and only compile the scripts, if the property is set to true >> >> o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >> accordingly >> o Con: potential benefit not made available automatically to existing FXML pages that host scripts >> >> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >> overruled individually by 3. >> >> The question would be whether 2 or/and 3 are really necessary as it can be expected that compilation >> of scripts by the script engines would find the same errors as while interpreting the very same >> scripts (if not, the script engine is badly broken and it could be argued that then the >> interpretation part of the script engine might be expected to be broken as well which would be quite >> dangerous from an integrity POV; the same consideration applies as well if the execution of the >> compiled script would behave differently to interpreting the very same script by the same script >> engine). >> >> The current WIP implements 1 above and includes an appropriate test unit. >> >>> What do others think? >> >>> In either case, we would need to make sure that this doesn't present any security concerns in the >>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>> but we would need to ensure that. >> The compilation of scripts needs to be done by the Java script engines (implementing both, >> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >> scripts ([javax.script.CompiledScript] >> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >> >> ---rony >> >> >> >>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >>>> pull request I would kindly request a review of this pull request! >>>> >>>> Here the URL: , title changed to: "8238080: FXMLLoader: if >>>> script engines implement javax.script.Compilable compile scripts". >>>> >>>> ---rony >>>> >>>> >>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>>>> has an appropriate test unit going with it as well, please review. >>>>> >>>>> There should be no compatibility issue with this implementation. >>>>> >>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>>>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>> value >>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>>>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>>>> respective solution as well. >>>>> >>>>> ---rony >>>>> >>>>> [1] "Implementation and test unit": >>>>> >>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>> scripts": >>>>> >>>>> >>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>> >>>>> >>>>> >>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>> >>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>>>> the concept). >>>>>> >>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>> Just filed a RFE with the following information: >>>>>>> >>>>>>> ??? * Component: >>>>>>> ??????? o JavaFX >>>>>>> >>>>>>> ??? * Subcomponent: >>>>>>> ??????? o fxml: JavaFX FXML >>>>>>> >>>>>>> ??? * Synopsis: >>>>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>> >>>>>>> ??? * Descriptions: >>>>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>> (javax.script.ScriptEngine >>>>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>>>> language in >>>>>>> ????????? the FXML file. >>>>>>> >>>>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>>>> could >>>>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>> using >>>>>>> ????????? its eval() methods. >>>>>>> >>>>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>> invocations, >>>>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>> onMouseMove) >>>>>>> ????????? which may be repetitevly invoked and evaluated." >>>>>>> >>>>>>> ??? * System /OS/Java Runtime Information: >>>>>>> ??????? o "All systems." >>>>>>> >>>>>>> Received the internal review ID: "9063426" >>>>>>> >>>>>>> ---rony From johan.vos at gluonhq.com Tue Apr 14 18:03:28 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Apr 2020 20:03:28 +0200 Subject: [11][14] RFR: Request to backport April 2020 CPU changes In-Reply-To: References: Message-ID: Approved, looks good. - Johan On Tue, Apr 14, 2020 at 6:10 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released April > 2020 CPU to 11-dev (for 11.0.7) and the jfx14 branch of jfx (for 14.0.1). > > https://cr.openjdk.java.net/~kcr/cpu-2004-sync/11-dev/webrev/ > https://github.com/kevinrushforth/jfx/compare/f8c235b...14-cpu-2004-sync > > Each is a straight backport (patch applies cleanly) of the one FX fix > that went into the April CPU. > > NOTE: For the 14.0.1 backport, since this is an integration of > already-reviewed fixes into the jfx repo, I will push it directly into > the jfx14 branch rather than via a pull request. The 11.0.7 backport > will be pushed to the HG 11-dev repo. > > Thanks. > > -- Kevin > > From johan.vos at gluonhq.com Tue Apr 14 19:56:53 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Apr 2020 21:56:53 +0200 Subject: RFR: Request to sync April 2020 CPU changes into jfx In-Reply-To: References: Message-ID: Approved. On Tue, Apr 14, 2020 at 5:58 PM Kevin Rushforth wrote: > Johan and Phil, > > I request approval to sync changes from to the just-released April 2020 > CPU release into the 'master' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/4d69a0d...cpu-2004-sync > > NOTE: Since this is an integration of already-reviewed fixes into the > jfx repo, I will push it directly into the master branch rather than via > a pull request. > > -- Kevin > > From github.com+637990+bmwiedemann at openjdk.java.net Wed Apr 15 02:38:00 2020 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Wed, 15 Apr 2020 02:38:00 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 11:48:55 GMT, Kevin Rushforth wrote: >> Finally getting to this (sorry for the delay). This seems OK to me, as it is not an intrusive change. I do not think >> that actually setting this property for production builds is a good idea, so I recommend against that (ultimately that >> will be up to Gluon or whoever produces builds). I'll test it once you change it from an env variable to a gradle >> property. > > @bmwiedemann are you planning to pursue this PR? Long term, yes. I am currently low on time and my Java-foo is not that great, so I was hoping that someone would pick it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From ajit.ghaisas at oracle.com Wed Apr 15 04:25:29 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 15 Apr 2020 09:55:29 +0530 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> Message-ID: <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> Hi Jeanette, The doc never assumes amountPerStep = 1. I am quoting it here - ?The wrapAround property is used to specify whether the value factory should be circular. For example, should an integer-based value model increment from the maximum value back to the minimum value (and vice versa).? The word ?circular? clarifies that once we exceed maximum value, we should start from minimum. I think, the doc is OK in it?s current form, but implementation needs to be corrected. Regards, Ajit > On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg wrote: > > > Hi Ajit, > > thought the doc was simply bad (in specifying the behavior for amountPerStep = 1 and not thinking of larger amounts) - my expection is a calculated wrap, that is the target as you suggest via modulo the difference from current value. Don't know if anybody took the doc literally .. > > -- Jeanette > > Zitat von Ajit Ghaisas : > >> Hi, >> >> Once I fix JDK-8193286, I would like to take up JDK-8242553 (IntegerSpinner does not wrap around values correctly if amountToStepBy is larger than total numbers between Max and Min) >> >> The current implementation is not as per what is documented. >> Refer : https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >> >> I propose to fix the current buggy behavior of IntegerSpinner. >> Although it is a corner case, I would like to know if anybody relies on this buggy behavior? >> >> Regards, >> Ajit > > > From github.com+6702882+dannygonzalez at openjdk.java.net Wed Apr 15 07:13:44 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Wed, 15 Apr 2020 07:13:44 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: On Tue, 14 Apr 2020 12:20:10 GMT, John Hendrikx wrote: >> In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce >> the performance improvement. I have attached a test program in my PR(#125) > > @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the > number of nodes in a TableView this is going to be a problem if the unregistering is slow.". > Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands > of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a > single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the > problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when > the listeners are spread out over dozens of properties, and although high in total number, the total listeners per > property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost > unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. @hjohn I haven't quantified exactly where all the listeners are coming from but the Node class for example has various listeners on it. The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly (although it was still bad before this change in my previous tests): > commit e21606d3a1b73cd4b44383babc750a4b4721edfd > Author: Florian Kirmaier > > Date: Tue Jan 22 09:08:36 2019 -0800 > > 8216377: Fix memoryleak for initial nodes of Window > 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window > > Add or remove the windowShowingChangedListener when the scene changes As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant performance hit on the JavaFX thread. I don't have the time or knowledge to investigate why these listeners are all needed especially around the Node class. I went directly to the source of the problem which was the linear search to deregister each listener. I have been running my proposed fix in our JavaFX application for the past few months and it has saved it from being unusable due to the JavaFx thread being swamped. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From tschindl at openjdk.java.net Wed Apr 15 08:19:38 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Wed, 15 Apr 2020 08:19:38 GMT Subject: [Rev 01] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with one additional commit since the last revision: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Added Test for keyboard modifiers ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/79fe0fd7..2ca1c88a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.00-01 Stats: 54 lines in 1 file changed: 54 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From tschindl at openjdk.java.net Wed Apr 15 08:22:47 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Wed, 15 Apr 2020 08:22:47 GMT Subject: [Rev 02] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: <-4V47sYdQyB-P5YA13ipdq5smDDHqI1218Y_-7EBHEk=.5c1ee2fc-0733-4815-aaee-b6d2bb9dc24d@github.com> > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with two additional commits since the last revision: - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/2ca1c88a..64a802ca Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.01-02 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From tschindl at openjdk.java.net Wed Apr 15 08:28:22 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Wed, 15 Apr 2020 08:28:22 GMT Subject: [Rev 03] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with one additional commit since the last revision: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/64a802ca..8fe96a90 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.02-03 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From fastegal at swingempire.de Wed Apr 15 09:23:10 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 11:23:10 +0200 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> Message-ID: <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> Hi Ajit, yes, I read the doc, probably a bit differently - could well be my misunderstanding and misunderstandable wording :) Trying again: - I read your suggestion (in https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. that being at value and incrementing a full-cycle (that is max -min +1), I will land on value again - for me the doc seemed to imply that in such a case I would land on min. Though, given the "circular" as you pointed out correctly, was my misunderstanding - the current implementation is buggy (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating the remainder (which is what the first bullet amounts to) incorrectly for min != 0 Where do I err? -- Jeanette Zitat von Ajit Ghaisas : > Hi Jeanette, > > The doc never assumes amountPerStep = 1. I am quoting it here - > ?The wrapAround property is used to specify whether the value > factory should be circular. For example, should an integer-based > value model increment from the maximum value back to the minimum > value (and vice versa).? > > The word ?circular? clarifies that once we exceed maximum value, we > should start from minimum. > I think, the doc is OK in it?s current form, but implementation > needs to be corrected. > > Regards, > Ajit > > >> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg >> wrote: >> >> >> Hi Ajit, >> >> thought the doc was simply bad (in specifying the behavior for >> amountPerStep = 1 and not thinking of larger amounts) - my >> expection is a calculated wrap, that is the target as you suggest >> via modulo the difference from current value. Don't know if anybody >> took the doc literally .. >> >> -- Jeanette >> >> Zitat von Ajit Ghaisas : >> >>> Hi, >>> >>> Once I fix JDK-8193286, I would like to take up JDK-8242553 >>> (IntegerSpinner does not wrap around values correctly if >>> amountToStepBy is larger than total numbers between Max and Min) >>> >>> The current implementation is not as per what is documented. >>> Refer : >>> https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>> >>> I propose to fix the current buggy behavior of IntegerSpinner. >>> Although it is a corner case, I would like to know if anybody >>> relies on this buggy behavior? >>> >>> Regards, >>> Ajit >> >> >> From aghaisas at openjdk.java.net Wed Apr 15 09:41:39 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 15 Apr 2020 09:41:39 GMT Subject: RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 10:36:51 GMT, Jeanette Winzenburg wrote: > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. Code changes and test look OK to me. I have a minor comment that I have listed separately. modules/javafx.controls/src/main/java/javafx/scene/control/ChoiceBox.java line 185: > 184: sm.selectedItemProperty().addListener(selectedItemListener); > 185: // unfixed part of JDK-8090015 - why exclude null? > 186: if (sm.getSelectedItem() != null && ! valueProperty().isBound()) { Add a TODO: or FIXME: if you intend to work on it. Also, it will be better to create a JBS issue. If not - please remove the comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Wed Apr 15 10:02:47 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 10:02:47 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: ChoiceBox: added FIXME with reference to issue ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/177/files - new: https://git.openjdk.java.net/jfx/pull/177/files/017be222..0d3ce123 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/177/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/177/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177 PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Wed Apr 15 10:02:59 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 10:02:59 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 14:09:13 GMT, Ajit Ghaisas wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> ChoiceBox: added FIXME with reference to issue > > modules/javafx.controls/src/main/java/javafx/scene/control/ChoiceBox.java line 185: > >> 184: sm.selectedItemProperty().addListener(selectedItemListener); >> 185: // unfixed part of JDK-8090015 - why exclude null? >> 186: if (sm.getSelectedItem() != null && ! valueProperty().isBound()) { > > Add a TODO: or FIXME: if you intend to work on it. Also, it will be better to create a JBS issue. > > If not - please remove the comment. Actually forgot that comment, already filed and took the issue JDK-8242001 thanks, eagle eye :) ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From arapte at openjdk.java.net Wed Apr 15 10:19:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Apr 2020 10:19:52 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 13:26:51 GMT, Jeanette Winzenburg wrote: > B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener Seems like this test randomly crashes (not always) any other test from `TabPaneTest`. It might be crashing the test executed just after this one OR the next test which does `tk.firePulse()`. Also not including `tk.firePulse()` would make the test incomplete/ unreliable. > Personally, I would tend to keep and ignore that test with doc: That is better to include the test now, else very doubtful of adding it in future. Including the test in next commit with @Ignore("JDK-8242621"). ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From arapte at openjdk.java.net Wed Apr 15 10:52:26 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Apr 2020 10:52:26 GMT Subject: [Rev 01] RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: > `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being > GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. > If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member > `selectionModel`. > The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for > [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Add tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/175/files - new: https://git.openjdk.java.net/jfx/pull/175/files/c3e2cbf9..e4293c75 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/175/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/175/webrev.00-01 Stats: 44 lines in 1 file changed: 39 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/175/head:pull/175 PR: https://git.openjdk.java.net/jfx/pull/175 From aghaisas at openjdk.java.net Wed Apr 15 10:59:52 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 15 Apr 2020 10:59:52 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:02:47 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox: added FIXME with reference to issue Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From florian.kirmaier at gmail.com Wed Apr 15 11:14:26 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Wed, 15 Apr 2020 13:14:26 +0200 Subject: No tags for releases at github openjdk/jfx? Message-ID: Hi everyone, I can't see any tags in the GitHub project for the various releases of JavaFX. I would like to know which commit is the base for various releases. Specifically, I'm interested in the version 14 and 15-ea3. Is there a place where I can look it up? Thanks, Florian Kirmaier From fastegal at openjdk.java.net Wed Apr 15 11:17:03 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 11:17:03 GMT Subject: [Rev 01] RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:52:26 GMT, Ambarish Rapte wrote: >> `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being >> GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. >> If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member >> `selectionModel`. >> The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for >> [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Add tests Marked as reviewed by fastegal (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From fastegal at openjdk.java.net Wed Apr 15 11:17:03 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 11:17:03 GMT Subject: [Rev 01] RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:17:41 GMT, Ambarish Rapte wrote: >> Looked again, and actually seeing two different issues ;) >> >> A) your test - that is with firing the pulse: fails for both not/removing the listener >> B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener >> >> So I think we should include B as it is directly related to this fix (and verifies the need to remove the listener). As >> to A: we should keep it somewhere to not forget, but where? >> Test code B: >> >> @Test >> public void testNPEOnSwitchSkinAndSelect() { >> TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); >> Group root = new Group(testPane); >> Scene scene = new Scene(root); >> Stage stage = new Stage(); >> stage.setScene(scene); >> stage.show(); >> >> testPane.setSkin(new TabPaneSkin1(testPane)); >> testPane.getSelectionModel().select(1); >> } >> >> >> The exception (seen on the test stack when rewiring the uncaughthandler as usual, else on sysout): >> >> Exception in thread "main" java.lang.NullPointerException >> at javafx.controls/javafx.scene.control.skin.TabPaneSkin.lambda$0(TabPaneSkin.java:447) >> at javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:83) >> at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348) >> at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) >> at >> javafx.base/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:74) >> at javafx.base/javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102) at >> javafx.base/javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:113) at >> javafx.base/javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:147) at >> javafx.controls/javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:105) at >> javafx.controls/javafx.scene.control.TabPane$TabPaneSelectionModel.select(TabPane.java:736) at >> javafx.controls/test.javafx.scene.control.SelectionFocusModelMemoryTest.testNPEOnSwitchSkinAndRemoveTabPaneFirePulse(SelectionFocusModelMemoryTest.java:261) > >> B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener > > Seems like this test randomly crashes (not always) any other test from `TabPaneTest`. It might be crashing the test > executed just after this one OR the next test which does `tk.firePulse()`. Also not including `tk.firePulse()` would > make the test incomplete/ unreliable. >> Personally, I would tend to keep and ignore that test with doc: > > That is better to include the test now, else very doubtful of adding it in future. Including the test in next commit > with @Ignore("JDK-8242621"). can't reproduce the random crashing (but then, it's random :) And don't quite understand why you think the test being incomplete/unreliable without a firePulse (there are tons of tests without) - as long as we don't want to test the result of a layout pass, we should be fine. anyway, that's a different story, to me your fix and tests look fine ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From joeri.sykora at gluonhq.com Wed Apr 15 13:21:35 2020 From: joeri.sykora at gluonhq.com (Joeri Sykora) Date: Wed, 15 Apr 2020 15:21:35 +0200 Subject: No tags for releases at github openjdk/jfx? In-Reply-To: References: Message-ID: You can find all tags for each release at https://github.com/openjdk/jfx/tags For OpenJFX versions 11, 12 and 13, you can find them in the previous repository: https://github.com/javafxports/openjdk-jfx/tags Greetings, Joeri On Wed, Apr 15, 2020 at 1:18 PM Florian Kirmaier wrote: > Hi everyone, > > I can't see any tags in the GitHub project for the various releases of > JavaFX. > I would like to know which commit is the base for various releases. > Specifically, I'm interested in the version 14 and 15-ea3. > Is there a place where I can look it up? > > Thanks, > Florian Kirmaier > -- Joeri Sykora *Gluon*E: joeri.sykora at gluonhq.com From kcr at openjdk.java.net Wed Apr 15 13:37:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 13:37:24 GMT Subject: [Rev 01] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: <5YmcHntf1Eh0B834KOCZKJQPRp54JcokstInXVx-oAM=.17a1eacd-256f-46a0-a70a-e5481458fbb1@github.com> References: <5YmcHntf1Eh0B834KOCZKJQPRp54JcokstInXVx-oAM=.17a1eacd-256f-46a0-a70a-e5481458fbb1@github.com> Message-ID: On Fri, 10 Apr 2020 16:29:57 GMT, Guru Hb wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > Looks good to me. Tested on Windows and mac OS X. > If feasible can we have Unit test for this. As discussed offline, please add a test for this. ------------- PR: https://git.openjdk.java.net/jfx/pull/164 From ajoseph at openjdk.java.net Wed Apr 15 15:14:49 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 15 Apr 2020 15:14:49 GMT Subject: [Rev 02] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: > Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java > side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. > Fix: Override scale() method in WCBufferedContext class to call init() before scaling. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Added SVGTest ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/164/files - new: https://git.openjdk.java.net/jfx/pull/164/files/fb1c3934..86674653 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/164/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/164/webrev.01-02 Stats: 132 lines in 1 file changed: 132 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164 PR: https://git.openjdk.java.net/jfx/pull/164 From arapte at openjdk.java.net Wed Apr 15 16:09:24 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Apr 2020 16:09:24 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:02:47 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox: added FIXME with reference to issue The change looks good to me, however I have minor concern about selecting Separator, which should be taken in a follow on issue. It may need a change in `Separator` selection test here. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 416: > 415: } else { > 416: toggleGroup.selectToggle(null); > 417: } The `else` part here means that user programmatically has selected a `Separator` or `SeparatorMenuItem`. The behavior in such scenario is not defined in doc but the methods, `select()`, `selectNext()`, `selectPrevious()` of `ChoiceBox.ChoiceBoxSelectionModel` imply that if index points to a `Separator` then a valid item should be selected. However these method do handle this correctly. If these methods are implemented such that no Separator is allowed to be selected then this `else` part would not be needed and we might be able to remove the `instanceof` checks. The fix in this PR looks good to me. But we should also decide the behavior in above scenario and may be file a JBS. If we decide that when a `Separator` is chosen for selection then the current selection should not be changed or a valid item should be selected, then the test related to Separator selection need to be changed. Or all of it can be handled in a follow on issue. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 347: > 346: // Test only purpose > 347: ContextMenu getChoiceBoxPopup() { > 348: return popup; I would recommend to prefix the method name with `test_.` It is not followed across, only `TabPaneSkin` has `test_` prefixed method. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From github.com+7450507+fthevenet at openjdk.java.net Wed Apr 15 17:23:15 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 15 Apr 2020 17:23:15 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: <3KFaFGV14nY90FsyOZ0VTySsogloizqfaV5FIU_iX88=.a44be05b-c0c5-43b1-b90d-0dcb793746c3@github.com> References: <3KFaFGV14nY90FsyOZ0VTySsogloizqfaV5FIU_iX88=.a44be05b-c0c5-43b1-b90d-0dcb793746c3@github.com> Message-ID: On Tue, 17 Mar 2020 15:31:20 GMT, Frederic Thevenet wrote: >>> >>> >>> Now that the tiling is done in the `QuantumRenderer` level, I'll bring back >>> [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this tiling be used to fix that? >> >> It won't help with things in their current state, as the `RenderToImage` method that is modified in this PR is >> currently called only by the snapshot feature in `Scene` But of course I suspect the same technique could also be used >> to solve [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) and now is indeed a good time to investigate >> it further. I'll have a look to see if it is possible to factorize the tiling implementation for both classes of >> issues, in which case it would make sense to do prior to merging this PR. If it is different enough that the >> implementation cannot be shared but only the general idea, then I suggest we address it in a different PR. What do you >> all think ? > > At first glance, the NPE in [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) occurs in the Prism layer, > which is one level _below_ Quantum where the tiling is currently implemented, so I'm not sure tit is reachable from > there; if we want the code to be shared, it looks like it would need to be moved even further down (maybe in the > `ResourceFactory`?) Also, while reusing code is generally the way to go, in such lower layers, very closely > intertwined with the actual rendering, I'm afraid that insisting on having a "one-size-fits-all" implementation might > get in the way of necessary case-by-case optimizations, so I'd like to have someone with a deeper knowledge of the > code base to weight in before starting work in that direction. Maybe @kevinrushforth could advise? Hi everyone, This PR hasn't seen much activity in a while, so I though I would give it a gentle kick to hopefully get it moving again ;) As explained above, I feel a little stalled at the moment, as we need to decide whether or not it is a good idea to try and address all or part of JDK-8189082 within the scope of this PR, and I don't feel like I can settle that on my own. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Wed Apr 15 20:30:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 20:30:17 GMT Subject: [Rev 02] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:14:49 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java >> side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Added SVGTest Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/164 From kcr at openjdk.java.net Wed Apr 15 21:01:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 21:01:59 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> On Wed, 15 Apr 2020 20:59:29 GMT, Kevin Rushforth wrote: >> I think @arapte has a similar MacBookPro model to mine. >> >> I think @prrace might be able to test it (I'll sync with him offline). > > Here are the results on Phil's machine, which is a Mac Book Pro with a graphics accelerator (Nvidia, I think). > > Without the patch: > 2000 quads average 8.805 fps > > With the patch: > 2000 quads average 4.719 fps > > Almost a 2x performance hit. Conclusion: The new shaders that support attenuation don't seem to have much of a performance impact on machines with an Intel HD, but on systems with a graphics accelerator, it is a significant slowdown. So we are left with the two choices of doubling the number of shaders (that is, a set of shaders with attenuation and a set without) or living with the performance hit (which will only be a problem on machines with a dedicated graphics accelerator for highly fill-limited scenes). The only way we can justify a 2x drop in performance is if we are fairly certain that this is a corner case, and thus unlikely to hit real applications. If we do end up deciding to replicate the shaders, I don't think it is all that much work. I'm more worried about how well it would scale to subsequent improvements, although we could easily decide that for, say, spotlights attenuation is so common that you wouldn't create a version that doesn't do that. In the D3D HLSL shaders, ifdefs are used, so the work would be to restore the original code and add the new code under an ifdef. Then double the number of lines of gradle (at that point, I'd do it in a for-each loop), then modify the logic that loads the shaders to pick the right one. For GLSL, the different parts of the shader are in different files, so it's a matter of creating new versions of each of the three lighting shaders that handle attenuation and choosing the right one at runtime. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Wed Apr 15 21:01:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 21:01:59 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 23:03:21 GMT, Kevin Rushforth wrote: >> @arapte Can you please test the performance changes too? > > I think @arapte has a similar MacBookPro model to mine. > > I think @prrace might be able to test it (I'll sync with him offline). Here are the results on Phil's machine, which is a Mac Book Pro with a graphics accelerator (Nvidia, I think). Without the patch: 2000 quads average 8.805 fps With the patch: 2000 quads average 4.719 fps Almost a 2x performance hit. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Wed Apr 15 21:46:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 21:46:18 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <3KFaFGV14nY90FsyOZ0VTySsogloizqfaV5FIU_iX88=.a44be05b-c0c5-43b1-b90d-0dcb793746c3@github.com> Message-ID: <5ukOjx9H6os3yhP7oj2lqZVpgr5_tpxmCTORBq8r1Xo=.8e9ed593-2362-49f7-9ffb-ad5ba677f671@github.com> On Wed, 15 Apr 2020 17:20:55 GMT, Frederic Thevenet wrote: >> At first glance, the NPE in [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) occurs in the Prism layer, >> which is one level _below_ Quantum where the tiling is currently implemented, so I'm not sure tit is reachable from >> there; if we want the code to be shared, it looks like it would need to be moved even further down (maybe in the >> `ResourceFactory`?) Also, while reusing code is generally the way to go, in such lower layers, very closely >> intertwined with the actual rendering, I'm afraid that insisting on having a "one-size-fits-all" implementation might >> get in the way of necessary case-by-case optimizations, so I'd like to have someone with a deeper knowledge of the >> code base to weight in before starting work in that direction. Maybe @kevinrushforth could advise? > > Hi everyone, > > This PR hasn't seen much activity in a while, so I though I would give it a gentle kick to hopefully get it moving > again ;) As explained above, I feel a little stalled at the moment, as we need to decide whether or not it is a good > idea to try and address all or part of JDK-8189082 within the scope of this PR, and I don't feel like I can settle > that on my own. Thanks. Sorry for the delay. This is on my review queue, which has been growing of late. I'll take a look at it soon. To answer one of your questions: > we need to decide whether or not it is a good idea to try and address all or part of JDK-8189082 within the scope of > this PR I think your idea of addressing the other similar cases (Canvas and SubScene in particular) in a follow-up PR seems fine. If, at that time, you find you can refactor this to share some of the implementation, that would be good. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kevin.rushforth at oracle.com Wed Apr 15 22:42:03 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 15 Apr 2020 15:42:03 -0700 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> Message-ID: <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> I just took another look at the SpinnerValueFactory API docs. The use of the term "circular" heavily implies modulo arithmetic as the expected behavior if wrapAround is true. That the usual meaning of "wrap" versus "clamp" when you have a range bounded on both ends. Maybe the confusion comes from the fact that it isn't stated as clearly as it might be, coupled with a single example of a step by one going from max to min (if incrementing). I note that example doesn't say what the amountToStepBy is, but it wasn't trying to be prescriptive. Since the current behavior of "wrap around unless you happen to wrap a bit too much and then we'll clamp" doesn't make sense in any universe that I can think of, it is fine to treat this as a bug. I'm not worried about "bug compatibility" here. Clarifying the spec at the same time seems like a good idea to me. A related issue is that the default value of wrapAround is not specified (the default is `false`, but you wouldn't know that from reading the docs). This should also be addressed at the same time. You mentioned that this is specific to IntegerValueFactory, but it looks like DoubleValueFactory (and maybe ListValueFactory) have the same bug. Or am I missing something? On an unrelated note, I just noticed that the SpinnerValueFactory constructor has no documentation. This is because it is an implicitly added constructor, which is an anti-pattern for public API. I'll file a separate issue for that. -- Kevin On 4/15/2020 2:23 AM, Jeanette Winzenburg wrote: > Hi Ajit, > > yes, I read the doc, probably a bit differently - could well be my > misunderstanding and misunderstandable wording :) > > Trying again: > > - I read your suggestion (in > https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. that > being at value and incrementing a full-cycle (that is max -min +1), I > will land on value again > - for me the doc seemed to imply that in such a case I would land on > min. Though, given the "circular" as you pointed out correctly, was my > misunderstanding > - the current implementation is buggy > (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating the > remainder (which is what the first bullet amounts to) incorrectly for > min != 0 > > Where do I err? > > -- Jeanette > > > Zitat von Ajit Ghaisas : > >> Hi Jeanette, >> >> The doc never assumes amountPerStep = 1. I am quoting it here - >> ?The wrapAround property is used to specify whether the value factory >> should be circular. For example, should an integer-based value model >> increment from the maximum value back to the minimum value (and vice >> versa).? >> >> The word ?circular? clarifies that once we exceed maximum value, we >> should start from minimum. >> I think, the doc is OK in it?s current form, but implementation needs >> to be corrected. >> >> Regards, >> Ajit >> >> >>> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg >>> wrote: >>> >>> >>> Hi Ajit, >>> >>> thought the doc was simply bad (in specifying the behavior for >>> amountPerStep = 1 and not thinking of larger amounts) - my expection >>> is a calculated wrap, that is the target as you suggest via modulo >>> the difference from current value. Don't know if anybody took the >>> doc literally .. >>> >>> -- Jeanette >>> >>> Zitat von Ajit Ghaisas : >>> >>>> Hi, >>>> >>>> ? Once I fix JDK-8193286, I would like to take up JDK-8242553 >>>> (IntegerSpinner does not wrap around values correctly if >>>> amountToStepBy is larger than total numbers between Max and Min) >>>> >>>> ? The current implementation is not as per what is documented. >>>> ? Refer : >>>> https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>>> >>>> ? I propose to fix the current buggy behavior of IntegerSpinner. >>>> ? Although it is a corner case, I would like to know if anybody >>>> relies on this buggy behavior? >>>> >>>> Regards, >>>> Ajit >>> >>> >>> > > > From kcr at openjdk.java.net Wed Apr 15 23:20:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 23:20:58 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 06:59:08 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 > > Root Cause : > Incorrect implementation. > Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. > Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. > > Fix : > Added a method for IntegerSpinnerValueFactory with separate implementation. > > Testing : > Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. > > Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed > separately. I'm not sure this is quite right, but I need to look at it more closely. It should fix the bug in question for well-behaved values, but might make it possible to return a value outside the range of [min, max]. I also want to think about it in light of [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). While a partial fix seems OK, we need to avoid the situation where some values cause a change from one buggy behavior to a different buggy behavior on the way to fixing it right. ------------- PR: https://git.openjdk.java.net/jfx/pull/174 From almatvee at openjdk.java.net Wed Apr 15 23:25:06 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 15 Apr 2020 23:25:06 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first Message-ID: https://bugs.openjdk.java.net/browse/JDK-8242530 - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing separate callback to send messages to AVFoundation. ------------- Commit messages: - 8242530: [macos] Some audio files miss spectrum data when another audio file plays first Changes: https://git.openjdk.java.net/jfx/pull/184/files Webrev: https://webrevs.openjdk.java.net/jfx/184/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242530 Stats: 23 lines in 3 files changed: 19 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/184.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/184/head:pull/184 PR: https://git.openjdk.java.net/jfx/pull/184 From kcr at openjdk.java.net Wed Apr 15 23:38:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 23:38:29 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:17:56 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8242530 > > - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is > same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This > issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing > separate callback to send messages to AVFoundation. @arapte Can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/184 From kcr at openjdk.java.net Wed Apr 15 23:54:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 23:54:02 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:17:56 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8242530 > > - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is > same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This > issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing > separate callback to send messages to AVFoundation. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/184 From github.com+7517141+yososs at openjdk.java.net Thu Apr 16 06:36:54 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 16 Apr 2020 06:36:54 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> On Wed, 15 Apr 2020 07:11:27 GMT, dannygonzalez wrote: >> @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the >> number of nodes in a TableView this is going to be a problem if the unregistering is slow.". >> Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands >> of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a >> single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the >> problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when >> the listeners are spread out over dozens of properties, and although high in total number, the total listeners per >> property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost >> unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. > > @hjohn > I haven't quantified exactly where all the listeners are coming from but the Node class for example has various > listeners on it. > The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly > (although it was still bad before this change in my previous tests): >> commit e21606d3a1b73cd4b44383babc750a4b4721edfd >> Author: Florian Kirmaier > >> Date: Tue Jan 22 09:08:36 2019 -0800 >> >> 8216377: Fix memoryleak for initial nodes of Window >> 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window >> >> Add or remove the windowShowingChangedListener when the scene changes > > As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having > multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant > performance hit on the JavaFX thread. I don't have the time or knowledge to investigate why these listeners are all > needed especially around the Node class. I went directly to the source of the problem which was the linear search to > deregister each listener. I have been running my proposed fix in our JavaFX application for the past few months and it > has saved it from being unusable due to the JavaFx thread being swamped. If the lifespan of a large number of registered listeners is biased, It seems like the next simple change can improve delete performance without changing the data structure. * Change the search from the front of the list to the search from the back. This will reduce the number of long-life listeners matching. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Thu Apr 16 07:14:08 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 07:14:08 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> Message-ID: <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> On Thu, 16 Apr 2020 06:34:39 GMT, yosbits wrote: >> @hjohn >> I haven't quantified exactly where all the listeners are coming from but the Node class for example has various >> listeners on it. >> The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly >> (although it was still bad before this change in my previous tests): >>> commit e21606d3a1b73cd4b44383babc750a4b4721edfd >>> Author: Florian Kirmaier > >>> Date: Tue Jan 22 09:08:36 2019 -0800 >>> >>> 8216377: Fix memoryleak for initial nodes of Window >>> 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window >>> >>> Add or remove the windowShowingChangedListener when the scene changes >> >> As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having >> multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant >> performance hit on the JavaFX thread. I don't have the time or knowledge to investigate why these listeners are all >> needed especially around the Node class. I went directly to the source of the problem which was the linear search to >> deregister each listener. I have been running my proposed fix in our JavaFX application for the past few months and it >> has saved it from being unusable due to the JavaFx thread being swamped. > > The patch proposed here does not share the case where the listener deletion performance becomes a bottleneck. > > I think that it is necessary to reproduce it by testing first, but > > If you just focus on improving listener removal performance, > > If the lifespan of a large number of registered listeners is biased, > It seems like the next simple change can improve delete performance without changing the data structure. > > * Change the search from the front of the list to the search from the back. > > This will reduce the number of long-life listeners matching. Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the number of nodes. A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us an idea how many Nodes we're talking about? 1000? 10.000? It also means there might be other options, do Nodes really need to add these listeners and for which functionality and are there alternatives? It would also be possible to target only these specific properties with an optimized listener list to reduce the impact of this change. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Thu Apr 16 07:38:45 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 07:38:45 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> Message-ID: On Thu, 16 Apr 2020 07:11:58 GMT, John Hendrikx wrote: >> The patch proposed here does not share the case where the listener deletion performance becomes a bottleneck. >> >> I think that it is necessary to reproduce it by testing first, but >> >> If you just focus on improving listener removal performance, >> >> If the lifespan of a large number of registered listeners is biased, >> It seems like the next simple change can improve delete performance without changing the data structure. >> >> * Change the search from the front of the list to the search from the back. >> >> This will reduce the number of long-life listeners matching. > > Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd > it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` > property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the > number of nodes. > > A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but > I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us > an idea how many Nodes we're talking about? 1000? 10.000? It also means there might be other options, do Nodes really > need to add these listeners and for which functionality and are there alternatives? It would also be possible to > target only these specific properties with an optimized listener list to reduce the impact of this change. The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). A lot of the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / showing status from there. No need for so many listeners. The other classes mentioned might register their own listener, instead of having `Node` do it for them (and thus impacting *every* node). Alternatively, `Node` may lazily register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty specific classes only, not classes that you'd see a lot in a TableView...) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Thu Apr 16 08:26:35 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Thu, 16 Apr 2020 08:26:35 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> Message-ID: On Thu, 16 Apr 2020 07:34:40 GMT, John Hendrikx wrote: >> Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd >> it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` >> property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the >> number of nodes. >> >> A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but >> I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us >> an idea how many Nodes we're talking about? 1000? 10.000? It also means there might be other options, do Nodes really >> need to add these listeners and for which functionality and are there alternatives? It would also be possible to >> target only these specific properties with an optimized listener list to reduce the impact of this change. > > The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and > `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of > listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). A lot of > the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / > showing status from there. No need for so many listeners. The other classes mentioned might register their own > listener, instead of having `Node` do it for them (and thus impacting *every* node). Alternatively, `Node` may lazily > register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty > specific classes only, not classes that you'd see a lot in a TableView...) If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using 61% of the JavaFX thread whilst running our application. [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to see which classes are calling the removeListener function. ![Screenshot 2020-04-16 at 09 16 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Thu Apr 16 08:48:31 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 08:48:31 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:17:56 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8242530 > > - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is > same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This > issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing > separate callback to send messages to AVFoundation. looks good to me... ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/184 From jhendrikx at openjdk.java.net Thu Apr 16 08:50:25 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 08:50:25 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> Message-ID: <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> On Thu, 16 Apr 2020 08:24:16 GMT, dannygonzalez wrote: >> The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and >> `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of >> listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). A lot of >> the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / >> showing status from there. No need for so many listeners. The other classes mentioned might register their own >> listener, instead of having `Node` do it for them (and thus impacting *every* node). Alternatively, `Node` may lazily >> register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty >> specific classes only, not classes that you'd see a lot in a TableView...) > > If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using > 61% of the JavaFX thread whilst running our application. > [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) > > If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to > see which classes are calling the removeListener function. > ![Screenshot 2020-04-16 at 09 16 > 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw about 20000 change listeners registered on this single Scene Window property. However, this custom control is not creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going on, scrolling was still smooth >30 fps. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Thu Apr 16 09:07:32 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 09:07:32 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:46:16 GMT, Ambarish Rapte wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> ChoiceBox: added FIXME with reference to issue > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 416: > >> 415: } else { >> 416: toggleGroup.selectToggle(null); >> 417: } > > The `else` part here means that user programmatically has selected a `Separator` or `SeparatorMenuItem`. The behavior > in such scenario is not defined in doc but the methods, `select()`, `selectNext()`, `selectPrevious()` of > `ChoiceBox.ChoiceBoxSelectionModel` imply that if index points to a `Separator` then a valid item should be selected. > However these method do handle this correctly. If these methods are implemented such that no Separator is allowed to > be selected then this `else` part would not be needed and we might be able to remove the `instanceof` checks. The fix > in this PR looks good to me. But we should also decide the behavior in above scenario and may be file a JBS. If we > decide that when a `Separator` is chosen for selection then the current selection should not be changed or a valid item > should be selected, then the test related to Separator selection need to be changed. Or all of it can be handled in a > follow on issue. yeah, you are right: a) the implementation of ChoiceBoxSelectionModel is broken when it comes to handling of unselectable items (such as Separator): next/previous try to move on, the others simply select. The implementation changed in fix of [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261) - before select(index) tried to handle it, after this was moved into next/previous. Arguably, the model can do what it wants without specification ;) b) the skin is responsible to sync the selection state of its toggles with the state of model: if the selectedIndex/Item does not have a corresponding toggle (f.i. if it's a separator), all toggles must be unselected. c) my test related to the Separator is broken - as you correctly noted, it will fail if a future implementation decides to select a really selectable item :) My plan: 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I think) 2. fix the test to be resistant against implementation changes of selectionModel Thanks for the extensive review, very much appreciated :) ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Thu Apr 16 09:12:24 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 09:12:24 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:52:13 GMT, Ambarish Rapte wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> ChoiceBox: added FIXME with reference to issue > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 347: > >> 346: // Test only purpose >> 347: ContextMenu getChoiceBoxPopup() { >> 348: return popup; > > I would recommend to prefix the method name with `test_.` It is not followed across, only `TabPaneSkin` has `test_` > prefixed method. well, as TabPaneSkin is a singularity in controls (in graphics such a pattern seems to be wider-spread), I would prefer not to do it here - also because ChoiceBoxSkin has another test-only accessor (for label text) which doesn't. Might be a candidate for a general cleanup task - if we decide to really introduce such a naming convention (which I personally wouldn't like :) ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Thu Apr 16 09:19:30 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 09:19:30 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 09:05:12 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 416: >> >>> 415: } else { >>> 416: toggleGroup.selectToggle(null); >>> 417: } >> >> The `else` part here means that user programmatically has selected a `Separator` or `SeparatorMenuItem`. The behavior >> in such scenario is not defined in doc but the methods, `select()`, `selectNext()`, `selectPrevious()` of >> `ChoiceBox.ChoiceBoxSelectionModel` imply that if index points to a `Separator` then a valid item should be selected. >> However these method do handle this correctly. If these methods are implemented such that no Separator is allowed to >> be selected then this `else` part would not be needed and we might be able to remove the `instanceof` checks. The fix >> in this PR looks good to me. But we should also decide the behavior in above scenario and may be file a JBS. If we >> decide that when a `Separator` is chosen for selection then the current selection should not be changed or a valid item >> should be selected, then the test related to Separator selection need to be changed. Or all of it can be handled in a >> follow on issue. > > yeah, you are right: > > a) the implementation of ChoiceBoxSelectionModel is broken when it comes to handling of unselectable items (such as > Separator): next/previous try to move on, the others simply select. The implementation changed in fix of > [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261) - before select(index) tried to handle it, after this > was moved into next/previous. Arguably, the model can do what it wants without specification ;) b) the skin is > responsible to sync the selection state of its toggles with the state of model: if the selectedIndex/Item does not have > a corresponding toggle (f.i. if it's a separator), all toggles must be unselected. c) my test related to the > Separator is broken - as you correctly noted, it will fail if a future implementation decides to select a really > selectable item :) My plan: > 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I > think) 2. fix the test to be resistant against implementation changes of selectionModel > > Thanks for the extensive review, very much appreciated :) btw: just noticed that there are methods in ChoiceBoxSkin testing the fix for next/prev @Test public void test_jdk_8988261_selectNext() { @Test public void test_jdk_8988261_selectPrevious() { the name look like they want to point to the corresponding issue .. but the id is incorrect: that id doesn't exist, should be 8088261 (spelling error, I think) - is it okay to change them to the right id? ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From github.com+6702882+dannygonzalez at openjdk.java.net Thu Apr 16 09:47:37 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Thu, 16 Apr 2020 09:47:37 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> Message-ID: <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> On Thu, 16 Apr 2020 08:46:26 GMT, John Hendrikx wrote: >> If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using >> 61% of the JavaFX thread whilst running our application. >> [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) >> >> If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to >> see which classes are calling the removeListener function. >> ![Screenshot 2020-04-16 at 09 16 >> 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) > > @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random > node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with > a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw > about 20000 change listeners registered on this single Scene Window property. However, this custom control is not > creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going > on, scrolling was still smooth >30 fps. @hjohn I have 12136 change listeners when debugging our application as you suggested. Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I do not see the issue. It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Thu Apr 16 11:21:07 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 11:21:07 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> On Thu, 16 Apr 2020 09:17:19 GMT, Jeanette Winzenburg wrote: >> yeah, you are right: >> >> a) the implementation of ChoiceBoxSelectionModel is broken when it comes to handling of unselectable items (such as >> Separator): next/previous try to move on, the others simply select. The implementation changed in fix of >> [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261) - before select(index) tried to handle it, after this >> was moved into next/previous. Arguably, the model can do what it wants without specification ;) b) the skin is >> responsible to sync the selection state of its toggles with the state of model: if the selectedIndex/Item does not have >> a corresponding toggle (f.i. if it's a separator), all toggles must be unselected. c) my test related to the >> Separator is broken - as you correctly noted, it will fail if a future implementation decides to select a really >> selectable item :) My plan: >> 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I >> think) 2. fix the test to be resistant against implementation changes of selectionModel >> >> Thanks for the extensive review, very much appreciated :) > > btw: just noticed that there are methods in ChoiceBoxSkin testing the fix for next/prev > > @Test public void test_jdk_8988261_selectNext() { > @Test public void test_jdk_8988261_selectPrevious() { > > the name look like they want to point to the corresponding issue .. but the id is incorrect: that id doesn't exist, > should be 8088261 (spelling error, I think) - is it okay to change them to the right id? > 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I > think) I am good with this. Though I will file a JBS for the correction in ChoiceBoxSelectionModel. `seletPrevious()`, `selectNext()` need one more check `value instanceof SeparatorMenuItem`. and similarly `selectFirst()` and `selectLast()` should be overridden correctly. and I can't think of why `select()` was changed so may be rethink about it :). We can discuss it again whenever we start fixing it. > 2. fix the test to be resistant against implementation changes of selectionModel Thanks for link to [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261), As mentioned in this bug description, "Culprit is an incorrect override of select(int): it may reject the new index if that would select a separator, but it must not select an arbitrary index instead", So It is not sure to me what should `select()` do in such scenario. So I think the test can also go as is, in case we change the behavior then test can be changed with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From arapte at openjdk.java.net Thu Apr 16 11:25:31 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 11:25:31 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> References: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> Message-ID: On Thu, 16 Apr 2020 11:18:55 GMT, Ambarish Rapte wrote: >> btw: just noticed that there are methods in ChoiceBoxSkin testing the fix for next/prev >> >> @Test public void test_jdk_8988261_selectNext() { >> @Test public void test_jdk_8988261_selectPrevious() { >> >> the name look like they want to point to the corresponding issue .. but the id is incorrect: that id doesn't exist, >> should be 8088261 (spelling error, I think) - is it okay to change them to the right id? > >> 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I >> think) > > I am good with this. Though I will file a JBS for the correction in ChoiceBoxSelectionModel. > `seletPrevious()`, `selectNext()` need one more check `value instanceof SeparatorMenuItem`. > and similarly `selectFirst()` and `selectLast()` should be overridden correctly. > and I can't think of why `select()` was changed so may be rethink about it :). > We can discuss it again whenever we start fixing it. > > >> 2. fix the test to be resistant against implementation changes of selectionModel > > Thanks for link to [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261), As mentioned in this bug > description, "Culprit is an incorrect override of select(int): it may reject the new index if that would select a > separator, but it must not select an arbitrary index instead", So It is not sure to me what should `select()` do in > such scenario. So I think the test can also go as is, in case we change the behavior then test can be changed with it. > should be 8088261 (spelling error, I think) - is it okay to change them to the right id? That will be good to change, but not sure if as part of this bug. It will be unrelated to fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From aghaisas at openjdk.java.net Thu Apr 16 11:38:17 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 16 Apr 2020 11:38:17 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:18:46 GMT, Kevin Rushforth wrote: >> Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 >> >> Root Cause : >> Incorrect implementation. >> Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. >> Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. >> >> Fix : >> Added a method for IntegerSpinnerValueFactory with separate implementation. >> >> Testing : >> Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. >> >> Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed >> separately. > > I'm not sure this is quite right, but I need to look at it more closely. It should fix the bug in question for > well-behaved values, but might make it possible to return a value outside the range of [min, max]. > I also want to think about it in light of [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). While a > partial fix seems OK, we need to avoid the situation where some values cause a change from one buggy behavior to a > different buggy behavior on the way to fixing it right. The fix works for well behaved values - and - maintains buggy behavior (to be addressed in JDK-8242553) if (amountToStepBy * no of steps) is greater than the total numbers between min and max. The Spinner.wrapValue() does return value outside min-max range if (amountToStepBy * steps) is greater than total numbers between min and max. It gets clamped to either min or max based on condition in IntegerSpinnerValueFactory valueProperty() listener. I am planning to change Spinner.wrapValue() to use modulo as part of JDK-8242553. This fix is restricted to addressing the issue of stepping through of valid (amountToStepBy * no of steps) which was reported as bug. ------------- PR: https://git.openjdk.java.net/jfx/pull/174 From github.com+2720909+jskov at openjdk.java.net Thu Apr 16 13:48:35 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Thu, 16 Apr 2020 13:48:35 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() Message-ID: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 ------------- Commit messages: - 8198402: Fix ToggleButton leak in ToggleGroup Changes: https://git.openjdk.java.net/jfx/pull/167/files Webrev: https://webrevs.openjdk.java.net/jfx/167/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8198402 Stats: 117 lines in 3 files changed: 102 ins; 10 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/167.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/167/head:pull/167 PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Thu Apr 16 13:48:35 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Thu, 16 Apr 2020 13:48:35 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: On Thu, 9 Apr 2020 09:58:27 GMT, Jesper Skov wrote: > Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. > > This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 /signed ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From fastegal at openjdk.java.net Thu Apr 16 15:04:53 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 15:04:53 GMT Subject: [Rev 02] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: ChoiceBox/-Skin/-SelectionTest - added code comments to clarify test/implemenation intention ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/177/files - new: https://git.openjdk.java.net/jfx/pull/177/files/0d3ce123..01aa7901 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/177/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/177/webrev.01-02 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177 PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Thu Apr 16 15:05:04 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 15:05:04 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> Message-ID: On Thu, 16 Apr 2020 11:23:24 GMT, Ambarish Rapte wrote: >>> 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I >>> think) >> >> I am good with this. Though I will file a JBS for the correction in ChoiceBoxSelectionModel. >> `seletPrevious()`, `selectNext()` need one more check `value instanceof SeparatorMenuItem`. >> and similarly `selectFirst()` and `selectLast()` should be overridden correctly. >> and I can't think of why `select()` was changed so may be rethink about it :). >> We can discuss it again whenever we start fixing it. >> >> >>> 2. fix the test to be resistant against implementation changes of selectionModel >> >> Thanks for link to [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261), As mentioned in this bug >> description, "Culprit is an incorrect override of select(int): it may reject the new index if that would select a >> separator, but it must not select an arbitrary index instead", So It is not sure to me what should `select()` do in >> such scenario. So I think the test can also go as is, in case we change the behavior then test can be changed with it. > >> should be 8088261 (spelling error, I think) - is it okay to change them to the right id? > > That will be good to change, but not sure if as part of this bug. It will be unrelated to fix. At the end and following your latest comments I did nothing Except adding code comments to the separator test and the else (toggle nulling) branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From arapte at openjdk.java.net Thu Apr 16 16:09:42 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 16:09:42 GMT Subject: [Rev 02] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> References: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> Message-ID: On Thu, 16 Apr 2020 15:04:53 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox/-Skin/-SelectionTest > > - added code comments to clarify test/implemenation intention Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From jhendrikx at openjdk.java.net Thu Apr 16 16:17:43 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 16:17:43 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Thu, 16 Apr 2020 09:45:20 GMT, dannygonzalez wrote: >> @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random >> node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with >> a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw >> about 20000 change listeners registered on this single Scene Window property. However, this custom control is not >> creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going >> on, scrolling was still smooth >30 fps. > > @hjohn I have 12136 change listeners when debugging our application as you suggested. > > Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I > do not see the issue. > It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. > The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with 20.000 nested stack panes resulted in these average times: - Add all 51 ms - Remove all 25 ms Versus the unmodified code: - Add all 34 ms - Remove all 135 ms However, there are some significant functional changes as well that might impact current users: 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to check whether an iteration was in progress. 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). The last point is not easily solved and could potentially cause problems. Finally I think this solution, although it performs well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window and have Scene provide a new combined status property that Node could use for its purposes. Even better however would be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener lists much shorter, which should scale a lot better. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Thu Apr 16 16:28:38 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 16:28:38 GMT Subject: RFR: 8241582: Infinite animation does not start from the end when started with a negative rate In-Reply-To: References: Message-ID: On Fri, 10 Apr 2020 06:31:39 GMT, Nir Lisker wrote: > ### Cause > > `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly. This causes > `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start the animation not from the end, depending > on the modulo calculation. ### Fix > > For infinite cycles, use the `cycleDuration` as the destination since that is the effective end point. > > ### Tests > > * Added an `testJumpTo_IndefiniteCycles` test that fails without the patch and passes after it. > * Added a `testJumpTo_IndefiniteCycleDuration` that passes both before and after, just to make sure that this type of > infinite duration is correct. > * Removed a test in `SequentialTransition` that fails with this patch, but it passed before it only because the modulo > value happened to land in the right place. Changing the duration of one of the child animation can cause it to fail, so > the test is faulty anyway at this stage. > > ### Future work > > Playing backwards will still not work correctly, but at least now it start from the correct value. This is the first of > a series of fixes under the umbrella issue [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238). looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/169 From github.com+1413266+jgneff at openjdk.java.net Thu Apr 16 19:31:22 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 16 Apr 2020 19:31:22 GMT Subject: [Rev 01] RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: > This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements > [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* > repository. Some of the changes were made to support the new device models, while others are minor changes to the > existing support in JavaFX 13. The following changes were made to support the new device models. > * Work around problems on the Kobo Glo HD Model N437. > > Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is > ignored by the driver on the Kobo Glo HD where the error occurs, anyway. > > Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of > the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame > buffer device driver can be an incorrect value. > > * Work around problems on the Kobo Clara HD Model N249. > > The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the > normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The > work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. > > The following changes were made to the existing code that supports e-paper displays in JavaFX 13. > > * Use the correct constant for the number of bytes per pixel. > > Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when > calculating the capacity of the 32-bit off-screen byte buffer. > > * Do not round the luma value to the nearest integer. > > Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of > rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 > percent and doesn't seem worth it for a display with just 16 levels of gray. > > * Change camel case of system property *y8inverted*. > > Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it > is consistent with the other system properties containing Y1, Y4, and Y8 in their names. > > * Improve error handling when mapping the frame buffer. > > Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a > `null` return value from `EPDFrameBuffer.getMappedBuffer`. > > * Replace non-ASCII characters with their ASCII equivalent. > > Replace non-ASCII characters in comments and log messages as follows: > > * "?" with "x" for display resolution and color depth, > * "?" with "*" for multiplication, > * "?" with "to" for transition, and > * "?C" with "degrees Celsius" for temperature. > > * Add descriptions to Monocle EPD system properties. > > Add Javadoc comments to each constant that defines a Monocle EPD system property. > > * Rename `IntStructure.getInteger` to `IntStructure.get`. > > Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method > `Integer.getInteger`, which gets the integer value of a system property. > > Below are some of the more interesting test results. > > * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray > values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. > > * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black > for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that > displays black for values `0x7F` or less and white for values `0x80` or greater. > > * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the > tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame > buffer. I plan to investigate the cause of the performance difference. > > * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold > increase in the number of pixels in their displays. The table below shows the animation speed of each model in > milliseconds per frame and frames per second. > > | Product Name | Speed (ms) | Rate (fps) | > | ------------- |:----------:|:----------:| > | Kobo Touch B | 125 | 8.0 | > | Kobo Touch C | 130 | 7.7 | > | Kobo Glo HD | 140 | 7.1 | > | Kobo Clara HD | 145 | 6.9 | John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into monocle-epd-imx6 - 8227425: Add support for e-paper displays on i.MX6 devices ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/60/files - new: https://git.openjdk.java.net/jfx/pull/60/files/aa335246..f7028e89 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/60/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/60/webrev.00-01 Stats: 322794 lines in 6225 files changed: 185606 ins; 92697 del; 44491 mod Patch: https://git.openjdk.java.net/jfx/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60 PR: https://git.openjdk.java.net/jfx/pull/60 From github.com+1413266+jgneff at openjdk.java.net Thu Apr 16 20:47:26 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 16 Apr 2020 20:47:26 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: On Thu, 5 Dec 2019 00:14:34 GMT, John Neffenger wrote: >> This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements >> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* >> repository. Some of the changes were made to support the new device models, while others are minor changes to the >> existing support in JavaFX 13. The following changes were made to support the new device models. >> * Work around problems on the Kobo Glo HD Model N437. >> >> Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is >> ignored by the driver on the Kobo Glo HD where the error occurs, anyway. >> >> Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of >> the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame >> buffer device driver can be an incorrect value. >> >> * Work around problems on the Kobo Clara HD Model N249. >> >> The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the >> normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The >> work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. >> >> The following changes were made to the existing code that supports e-paper displays in JavaFX 13. >> >> * Use the correct constant for the number of bytes per pixel. >> >> Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when >> calculating the capacity of the 32-bit off-screen byte buffer. >> >> * Do not round the luma value to the nearest integer. >> >> Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of >> rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 >> percent and doesn't seem worth it for a display with just 16 levels of gray. >> >> * Change camel case of system property *y8inverted*. >> >> Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it >> is consistent with the other system properties containing Y1, Y4, and Y8 in their names. >> >> * Improve error handling when mapping the frame buffer. >> >> Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a >> `null` return value from `EPDFrameBuffer.getMappedBuffer`. >> >> * Replace non-ASCII characters with their ASCII equivalent. >> >> Replace non-ASCII characters in comments and log messages as follows: >> >> * "?" with "x" for display resolution and color depth, >> * "?" with "*" for multiplication, >> * "?" with "to" for transition, and >> * "?C" with "degrees Celsius" for temperature. >> >> * Add descriptions to Monocle EPD system properties. >> >> Add Javadoc comments to each constant that defines a Monocle EPD system property. >> >> * Rename `IntStructure.getInteger` to `IntStructure.get`. >> >> Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method >> `Integer.getInteger`, which gets the integer value of a system property. >> >> Below are some of the more interesting test results. >> >> * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray >> values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. >> >> * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black >> for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that >> displays black for values `0x7F` or less and white for values `0x80` or greater. >> >> * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the >> tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame >> buffer. I plan to investigate the cause of the performance difference. >> >> * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold >> increase in the number of pixels in their displays. The table below shows the animation speed of each model in >> milliseconds per frame and frames per second. >> >> | Product Name | Speed (ms) | Rate (fps) | >> | ------------- |:----------:|:----------:| >> | Kobo Touch B | 125 | 8.0 | >> | Kobo Touch C | 130 | 7.7 | >> | Kobo Glo HD | 140 | 7.1 | >> | Kobo Clara HD | 145 | 6.9 | > > /signed @kevinrushforth Did I merge the upstream master branch correctly? The [last time I did this](https://github.com/javafxports/openjdk-jfx/pull/522/commits) on the old *openjdk-jfx* repository, the pull request showed only the single merge commit. This time all 87 commits from the upstream master branch are shown as part of this pull request, even though the code I propose has not changed since the pull request was created on December 4, 2019. Let me know if you would like me to rebase my changes and *force push* a cleaner update. While I have your attention ... would you be able to be my second reviewer? This pull request is a small update that completes the large project begun by [JDK-8217605](https://github.com/javafxports/openjdk-jfx/pull/369) over a year ago. Your comments on that first part were very helpful, so I'm hoping you can bring that experience to this second and final part of the project. ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From jvos at openjdk.java.net Thu Apr 16 21:16:23 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 16 Apr 2020 21:16:23 GMT Subject: RFR: 8242577: Cell selection fails on iOS most of the times In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 10:31:18 GMT, Jose Pereda wrote: > There are cases when iOS sends one or more NSTouchPhaseMoved for a given touch event, in between NSTouchPhaseBegan and > NSTouchPhaseEnded , even if the initial event location didn't change. > By default, all these events are emulated as mouse enter/down, drag and up/exit events. > > However, when the user taps quickly or even holds steady on a cell, if these touch moved events are generated and sent > as mouse drag events, the cell selection fails, as the flag `latePress` used in > [CellBehaviorBase](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java#L191) > is set to false, preventing the cell selection that should happen upon touch release event. This PR prevents emulating > mouse drag events when the touch event doesn't change its location. looks good. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/181 From aghaisas at openjdk.java.net Fri Apr 17 06:08:54 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 06:08:54 GMT Subject: [Rev 02] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> References: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> Message-ID: On Thu, 16 Apr 2020 15:04:53 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox/-Skin/-SelectionTest > > - added code comments to clarify test/implemenation intention Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 07:10:24 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 07:10:24 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Thu, 16 Apr 2020 16:15:20 GMT, John Hendrikx wrote: >> @hjohn I have 12136 change listeners when debugging our application as you suggested. >> >> Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I >> do not see the issue. >> It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. >> The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. > > I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with > 20.000 nested stack panes resulted in these average times: > - Add all 51 ms > - Remove all 25 ms > > Versus the unmodified code: > > - Add all 34 ms > - Remove all 135 ms > > However, there are some significant functional changes as well that might impact current users: > > 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making > a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This > can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to > check whether an iteration was in progress. 2. There is a significant increase in memory use. Where before each > listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per > entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still > well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener > implementation hierarchy (singleton -> array -> map). 3. Even though the current version of this pull request takes > care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with > respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). The last > point is not easily solved and could potentially cause problems. Finally I think this solution, although it performs > well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think > this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced > another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window > and have Scene provide a new combined status property that Node could use for its purposes. Even better however would > be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen > to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single > property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener > lists much shorter, which should scale a lot better. @hjon > 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of > times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, > a) the notification order will be (a, a, b). Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as registration which was the case when I used a HashMap. See here: https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 07:24:35 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 07:24:35 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 07:08:01 GMT, dannygonzalez wrote: >> I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with >> 20.000 nested stack panes resulted in these average times: >> - Add all 51 ms >> - Remove all 25 ms >> >> Versus the unmodified code: >> >> - Add all 34 ms >> - Remove all 135 ms >> >> However, there are some significant functional changes as well that might impact current users: >> >> 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making >> a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This >> can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to >> check whether an iteration was in progress. 2. There is a significant increase in memory use. Where before each >> listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per >> entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still >> well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener >> implementation hierarchy (singleton -> array -> map). 3. Even though the current version of this pull request takes >> care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with >> respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). The last >> point is not easily solved and could potentially cause problems. Finally I think this solution, although it performs >> well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think >> this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced >> another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window >> and have Scene provide a new combined status property that Node could use for its purposes. Even better however would >> be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen >> to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single >> property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener >> lists much shorter, which should scale a lot better. > > @hjon > >> 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of >> times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, >> a) the notification order will be (a, a, b). > > Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of > notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as > registration which was the case when I used a HashMap. See here: > https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 @hjohn > 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each > listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more > heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a > further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to the hierarchy as you mentioned). This was mentioned here also: https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Apr 17 07:55:31 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 17 Apr 2020 07:55:31 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 07:22:20 GMT, dannygonzalez wrote: >> @hjon >> >>> 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of >>> times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, >>> a) the notification order will be (a, a, b). >> >> Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of >> notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as >> registration which was the case when I used a HashMap. See here: >> https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 > > @hjohn > >> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each >> listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more >> heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a >> further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). > > There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where > we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to > the hierarchy as you mentioned). This was mentioned here also: > https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 I've implemented an alternative solution: Removing the listeners on `Window.showingProperty` and `Scene.windowProperty` completely. They are in fact only used in two places: `PopupWindow` in order to remove itself if the `Window` is no longer showing, and `ProgressIndicatorSkin`. These two can be easily replaced with their own listeners for these properties instead of burdening **all** nodes with these listeners only to support these two classes. I left the `isTreeShowing` method in, and implemented it simply as `isTreeVisible() && isWindowShowing()` as that's really the only difference between "visible" and "showing" apparently. Here is the test result with 20.000 nested StackPanes with only this change in: - Add all 45 ms - Remove all 25 ms I think this might be a good solution as it completely avoids these listeners. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Apr 17 08:09:26 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 17 Apr 2020 08:09:26 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 07:22:20 GMT, dannygonzalez wrote: >> @hjon >> >>> 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of >>> times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, >>> a) the notification order will be (a, a, b). >> >> Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of >> notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as >> registration which was the case when I used a HashMap. See here: >> https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 > > @hjohn > >> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each >> listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more >> heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a >> further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). > > There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where > we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to > the hierarchy as you mentioned). This was mentioned here also: > https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 08:50:52 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 08:50:52 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 08:07:08 GMT, John Hendrikx wrote: >> @hjohn >> >>> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each >>> listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more >>> heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a >>> further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). >> >> There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where >> we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to >> the hierarchy as you mentioned). This was mentioned here also: >> https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 > > @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped off the hotspots in the same way it did with my pull request. I wasn't fully confident of making changes to the Node hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck which was the listener de-registration slowness. I do worry however that any changes down the road which add listeners to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. I feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I know my changes may be more fundamental and hence risky. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:33 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Tue, 14 Apr 2020 09:04:40 GMT, Ajit Ghaisas wrote: >> was: https://github.com/openjdk/jfx/pull/136 > > I am taking a look at your changes now. > @ccavanaugh can you make jcheck pass while I review. Please see the details of the failing jcheck. Thank you. I've updated the pull request comments with what I thought was the necessary changes, but jcheck is still failing with "the commits in this PR have inconsistent user names and/or email addresses. Please amend the commits." I'm not sure what to do with this error. Thanks, Craig On Tue, Apr 14, 2020 at 5:04 AM Ajit Ghaisas wrote: > I am taking a look at your changes now. > @ccavanaugh can you make jcheck pass > while I review. Please see the details of the failing jcheck. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From fastegal at openjdk.java.net Fri Apr 17 09:26:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> On Thu, 9 Apr 2020 09:37:30 GMT, Craig Cavanaugh wrote: > https://bugs.openjdk.java.net/browse/JDK-8129123 > > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! was: https://github.com/openjdk/jfx/pull/136 ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From kcr at openjdk.java.net Fri Apr 17 09:26:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Tue, 14 Apr 2020 10:43:30 GMT, Craig Cavanaugh wrote: >> I am taking a look at your changes now. >> @ccavanaugh can you make jcheck pass while I review. Please see the details of the failing jcheck. > > Thank you. I've updated the pull request comments with what I thought was > the necessary changes, but jcheck is still failing with > > "the commits in this PR have inconsistent user names and/or email > addresses. Please amend the commits." > > I'm not sure what to do with this error. > > Thanks, > Craig > > On Tue, Apr 14, 2020 at 5:04 AM Ajit Ghaisas > wrote: > >> I am taking a look at your changes now. >> @ccavanaugh can you make jcheck pass >> while I review. Please see the details of the failing jcheck. >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> >> . >> I think you will need to rebase and force push your branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From aghaisas at openjdk.java.net Fri Apr 17 09:26:33 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Fri, 10 Apr 2020 10:22:29 GMT, Jeanette Winzenburg wrote: >> https://bugs.openjdk.java.net/browse/JDK-8129123 >> >> This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. >> Also, I believe JDK-8196037 is a duplicate of this issue. >> >> I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. >> >> Thanks! > > was: https://github.com/openjdk/jfx/pull/136 I am taking a look at your changes now. @ccavanaugh can you make jcheck pass while I review. Please see the details of the failing jcheck. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From kcr at openjdk.java.net Fri Apr 17 09:26:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 09:26:34 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> On Thu, 16 Apr 2020 10:01:14 GMT, Craig Cavanaugh wrote: >> I think you will need to rebase and force push your branch. > > Seems I've made a further mess attempting to rebase. I apologize as I know > the list is not intended to be tech support for git usage, but I'm at a > loss and don't want to make it worse. > > Below is the log after an interactive rebase and forced push. > > "" > Merge branch '8129123' of https://github.com/ccavanaugh/jfx into 8129123 > > branches 8129123, origin/8129123 > "" > > Thanks, > Craig > > On Tue, Apr 14, 2020 at 7:11 AM Kevin Rushforth > wrote: > >> I think you will need to rebase and force push your branch. >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> >> . >> The following should work: $ git rebase -i master If the rebase is successful, it will pop you into your EDITOR. You then select "pick" for the first commit (which is already selected by default) and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good to you, do the following: $ git push --force origin 8129123 ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:34 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:34 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> Message-ID: On Thu, 16 Apr 2020 12:30:20 GMT, Kevin Rushforth wrote: >> Seems I've made a further mess attempting to rebase. I apologize as I know >> the list is not intended to be tech support for git usage, but I'm at a >> loss and don't want to make it worse. >> >> Below is the log after an interactive rebase and forced push. >> >> "" >> Merge branch '8129123' of https://github.com/ccavanaugh/jfx into 8129123 >> >> branches 8129123, origin/8129123 >> "" >> >> Thanks, >> Craig >> >> On Tue, Apr 14, 2020 at 7:11 AM Kevin Rushforth >> wrote: >> >>> I think you will need to rebase and force push your branch. >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> > > The following should work: > > $ git rebase -i master > > If the rebase is successful, it will pop you into your EDITOR. You then select "pick" for the first commit (which is > already selected by default) and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good to you, do the > following: $ git push --force origin 8129123 That did it! Thanks! On Thu, Apr 16, 2020 at 8:30 AM Kevin Rushforth wrote: > The following should work: > > $ git rebase -i master > > If the rebase is successful, it will pop you into your EDITOR. You then > select "pick" for the first commit (which is already selected by default) > and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good > to you, do the following: > > $ git push --force origin 8129123 > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:34 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:34 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Tue, 14 Apr 2020 11:11:13 GMT, Kevin Rushforth wrote: >> Thank you. I've updated the pull request comments with what I thought was >> the necessary changes, but jcheck is still failing with >> >> "the commits in this PR have inconsistent user names and/or email >> addresses. Please amend the commits." >> >> I'm not sure what to do with this error. >> >> Thanks, >> Craig >> >> On Tue, Apr 14, 2020 at 5:04 AM Ajit Ghaisas >> wrote: >> >>> I am taking a look at your changes now. >>> @ccavanaugh can you make jcheck pass >>> while I review. Please see the details of the failing jcheck. >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> > > I think you will need to rebase and force push your branch. Seems I've made a further mess attempting to rebase. I apologize as I know the list is not intended to be tech support for git usage, but I'm at a loss and don't want to make it worse. Below is the log after an interactive rebase and forced push. "" Merge branch '8129123' of https://github.com/ccavanaugh/jfx into 8129123 branches 8129123, origin/8129123 "" Thanks, Craig On Tue, Apr 14, 2020 at 7:11 AM Kevin Rushforth wrote: > I think you will need to rebase and force push your branch. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:33 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set Message-ID: https://bugs.openjdk.java.net/browse/JDK-8129123 This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. Also, I believe JDK-8196037 is a duplicate of this issue. I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. Thanks! ------------- Commit messages: - Fix for JDK-8129123 Changes: https://git.openjdk.java.net/jfx/pull/166/files Webrev: https://webrevs.openjdk.java.net/jfx/166/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8129123 Stats: 51 lines in 2 files changed: 49 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/166.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/166/head:pull/166 PR: https://git.openjdk.java.net/jfx/pull/166 From jhendrikx at openjdk.java.net Fri Apr 17 10:24:37 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 17 Apr 2020 10:24:37 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 08:48:35 GMT, dannygonzalez wrote: >> @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 > > @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being > swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped > off the hotspots in the same way it did with my pull request. I wasn't fully confident of making changes to the Node > hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck > which was the listener de-registration slowness. I do worry however that any changes down the road which add listeners > to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now > where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. I > feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I > know my changes may be more fundamental and hence risky. The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very limited cases, and its addition in the past may have slipped through the cracks. Adding a performance unit test that specifically checks add/remove performance of nodes may prevent such future regressions. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From aghaisas at openjdk.java.net Fri Apr 17 10:37:21 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 10:37:21 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> Message-ID: <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> On Fri, 17 Apr 2020 09:21:25 GMT, Craig Cavanaugh wrote: >> The following should work: >> >> $ git rebase -i master >> >> If the rebase is successful, it will pop you into your EDITOR. You then select "pick" for the first commit (which is >> already selected by default) and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good to you, do the >> following: $ git push --force origin 8129123 > > That did it! > > Thanks! > > On Thu, Apr 16, 2020 at 8:30 AM Kevin Rushforth > wrote: > >> The following should work: >> >> $ git rebase -i master >> >> If the rebase is successful, it will pop you into your EDITOR. You then >> select "pick" for the first commit (which is already selected by default) >> and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good >> to you, do the following: >> >> $ git push --force origin 8129123 >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> >> . >> I think, selection and scrolling are two separate operations. Here we use these two operations to achieve the desired result for ComboBox. It is nice to have behavior and I am OK with the fix. > Also, I believe JDK-8196037 is a duplicate of this issue. Please Note that - JDK-8196037 is not a duplicate of this issue as described in PR description. I have a minor comment regarding test. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From aghaisas at openjdk.java.net Fri Apr 17 10:40:58 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 10:40:58 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: On Thu, 9 Apr 2020 09:37:30 GMT, Craig Cavanaugh wrote: > https://bugs.openjdk.java.net/browse/JDK-8129123 > > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 2097: > 2096: first <= index && index <= last); > 2097: > 2098: index = LIST_SIZE - 1; You have tested first and last index selection. It will be nice to have a case where we select index = LIST_SIZE/2 ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From fastegal at openjdk.java.net Fri Apr 17 10:46:45 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 17 Apr 2020 10:46:45 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Fri, 17 Apr 2020 10:34:54 GMT, Ajit Ghaisas wrote: >> That did it! >> >> Thanks! >> >> On Thu, Apr 16, 2020 at 8:30 AM Kevin Rushforth >> wrote: >> >>> The following should work: >>> >>> $ git rebase -i master >>> >>> If the rebase is successful, it will pop you into your EDITOR. You then >>> select "pick" for the first commit (which is already selected by default) >>> and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good >>> to you, do the following: >>> >>> $ git push --force origin 8129123 >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> > > I think, selection and scrolling are two separate operations. Here we use these two operations to achieve the desired > result for ComboBox. It is nice to have behavior and I am OK with the fix. >> Also, I believe JDK-8196037 is a duplicate of this issue. > > Please Note that - JDK-8196037 is not a duplicate of this issue as described in PR description. > > I have a minor comment regarding test. repeating my comment from the [previous pull request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered :) ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 10:49:10 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 10:49:10 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 10:22:15 GMT, John Hendrikx wrote: >> @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being >> swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped >> off the hotspots in the same way it did with my pull request. I wasn't fully confident of making changes to the Node >> hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck >> which was the listener de-registration slowness. I do worry however that any changes down the road which add listeners >> to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now >> where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. I >> feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I >> know my changes may be more fundamental and hence risky. > > The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for > each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change > would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very > limited cases, and its addition in the past may have slipped through the cracks. Adding a performance unit test that > specifically checks add/remove performance of nodes may prevent such future regressions. @hjohn, agreed regards the issues of adding a listener to each node. Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own listeners to make this a pull request that can be reviewed officially? I await any further comments from @kevinrushforth et al. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Fri Apr 17 13:00:19 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 17 Apr 2020 13:00:19 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> On Tue, 14 Apr 2020 11:15:32 GMT, Florian Kirmaier wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8241840 > Some code cleanups Changes requested by arapte (Reviewer). modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindowManager.java line 124: > 123: int index = getWindowIndex(window); > 124: if (index != -1 && window.isVisible()) { > 125: focusedWindow = window; This change is sufficient for the test to pass, are there any other scenarios for which the changes in Window.java are needed. If so could you please add the relevant tests. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 103: > 102: assertCollectable(closedFocusedStageWeak); > 103: } > 104: The current test does not assure that stage is shown when `close()` is called or it is closed when `requestFocus()` is called, I would recommend the test to be as, @Test public void testClosedFocusedStageLeak() throws Exception { CountDownLatch latch = new CountDownLatch(1); Util.runAndWait(() -> { closedFocusedStage = new Stage(); closedFocusedStage.setTitle("Focused Stage"); closedFocusedStageWeak = new WeakReference<>(closedFocusedStage); TextField textField = new TextField(); closedFocusedStage.setScene(new Scene(textField)); closedFocusedStage.setOnShown(l -> { latch.countDown(); }); closedFocusedStage.show(); }); Assert.assertTrue("Timeout waiting for closedFocusedStage to show`", latch.await(15, TimeUnit.MILLISECONDS)); CountDownLatch hideLatch = new CountDownLatch(1); closedFocusedStage.setOnHidden(a -> { hideLatch.countDown(); }); Util.runAndWait(() -> closedFocusedStage.close()); Assert.assertTrue("Timeout waiting for closedFocusedStage to hide`", hideLatch.await(15, TimeUnit.MILLISECONDS)); closedFocusedStage.requestFocus(); closedFocusedStage = null; assertCollectable(closedFocusedStageWeak); } ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From arapte at openjdk.java.net Fri Apr 17 13:00:20 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 17 Apr 2020 13:00:20 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 10:47:55 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 77: >> >>> 76: Platform.runLater(() -> stage.close()); >>> 77: } >>> 78: >> >> Looks like the primary `stage` is not required for actual test, and this block is only used to initialize JavaFX >> runtime. Please check if it can be replaced by below block >> ``` >> @BeforeClass >> public static void initFX() throws Exception { >> startupLatch = new CountDownLatch(1); >> Platform.startup(startupLatch::countDown); >> Assert.assertTrue("Timeout waiting for FX runtime to start", >> startupLatch.await(15, TimeUnit.MILLISECONDS)); >> } > > This version doesn't work for me. > With this change, I get the following error: > test.javafx.stage.FocusedWindowTest > testLeak FAILED > junit.framework.AssertionFailedError: Exceeded timeout limit of 10000 msec > at test.util.Util.runAndWait(Util.java:163) > at test.util.Util.runAndWait(Util.java:134) > at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:82) This is happening because after the last stage is closed JavaFX runtime shuts down implicitly unless specified otherwise using `Platform.setImplicitExit(false);`. So `initFX()` should look as, ``` @BeforeClass public static void initFX() throws Exception { startupLatch = new CountDownLatch(1); Platform.startup(startupLatch::countDown); Platform.setImplicitExit(false); Assert.assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.MILLISECONDS)); } >> tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 53: >> >>> 52: System.setProperty("monocle.platform","Headless"); >>> 53: } >>> 54: >> >> The test will always run with Monocle. I see that if this static block is removed then the test fails on Windows 10. >> Can you please verify all the platforms and change the test such that it runs on all platforms/ combinations. > > I wasn't able to reproduce the Problem on Window10 with VirtualBox. > > How should I do it? Add a second test class without the static code? Do you have a good recommendation on how to add it? The previous version of test failed on my Windows 10 machine with below exception, but the updated version does not fail, test.javafx.stage.FocusedWindowTest > testLeak FAILED junit.framework.AssertionFailedError: Expected: but was: javafx.stage.Stage at 5fe60662 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNull(Assert.java:233) at junit.framework.Assert.assertNull(Assert.java:226) at test.javafx.stage.FocusedWindowTest.assertCollectable(FocusedWindowTest.java:133) at test.javafx.stage.FocusedWindowTest.testLeakOnce(FocusedWindowTest.java:116) at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:84) ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From arapte at openjdk.java.net Fri Apr 17 13:00:20 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 17 Apr 2020 13:00:20 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 19:19:16 GMT, Ambarish Rapte wrote: >> I wasn't able to reproduce the Problem on Window10 with VirtualBox. >> >> How should I do it? Add a second test class without the static code? Do you have a good recommendation on how to add it? > > The previous version of test failed on my Windows 10 machine with below exception, but the updated version does not > fail, > test.javafx.stage.FocusedWindowTest > testLeak FAILED > junit.framework.AssertionFailedError: Expected: but was: javafx.stage.Stage at 5fe60662 > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at junit.framework.Assert.assertNull(Assert.java:233) > at junit.framework.Assert.assertNull(Assert.java:226) > at test.javafx.stage.FocusedWindowTest.assertCollectable(FocusedWindowTest.java:133) > at test.javafx.stage.FocusedWindowTest.testLeakOnce(FocusedWindowTest.java:116) > at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:84) > Do you have a good recommendation on how to add it? May be a test like `MeshManagerCacheLeakTest` should be able to solve the problem. I have not tried it myself, please check if it can help here. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From ghb at openjdk.java.net Fri Apr 17 13:30:30 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 17 Apr 2020 13:30:30 GMT Subject: [Rev 02] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:14:49 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java >> side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Added SVGTest Looks good to me , verified on mac os x and windows. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/164 From jvos at openjdk.java.net Fri Apr 17 14:43:52 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Apr 2020 14:43:52 GMT Subject: [jfx14] RFR: 8242839: Create release notes for JavaFX 14.0.1 Message-ID: Add release notes for 14.0.1 Fix for JDK-8242839 ------------- Commit messages: - Add release notes for 14.0.1 Changes: https://git.openjdk.java.net/jfx/pull/186/files Webrev: https://webrevs.openjdk.java.net/jfx/186/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242839 Stats: 68 lines in 1 file changed: 68 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/186.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/186/head:pull/186 PR: https://git.openjdk.java.net/jfx/pull/186 From kcr at openjdk.java.net Fri Apr 17 14:48:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 14:48:20 GMT Subject: [jfx14] RFR: 8242839: Create release notes for JavaFX 14.0.1 In-Reply-To: References: Message-ID: On Fri, 17 Apr 2020 14:34:01 GMT, Johan Vos wrote: > Add release notes for 14.0.1 > Fix for JDK-8242839 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/186 From john at status6.com Fri Apr 17 14:56:51 2020 From: john at status6.com (John Neffenger) Date: Fri, 17 Apr 2020 07:56:51 -0700 Subject: GitHub glitch - merging master into an old pull request Message-ID: I was surprised to see GitHub listing in my pull request all of the changes I merged from the upstream master branch, as I commented here: Did I merge the upstream master branch correctly? https://github.com/openjdk/jfx/pull/60#issuecomment-614885532 Unfortunately, GitHub also pulled into my pull request anyone who participated in those changes to master, which is why I'm posting this to the mailing list instead of commenting there. This is the first time I've seen the problem, but it dates back to at least 2013 according to this Stack Overflow question: GitHub pull request showing commits that are already in target branch https://stackoverflow.com/q/16306012 Should I try the suggested fix of temporarily switching the base branch? In my case, I would edit the pull request to choose the "jfx14" base branch, save the change, and then edit it again to switch it back to the "master" base branch. The Stack Overflow answers state that the extra commits will then be gone, and I'll have a nice clean pull request again. Thanks, John From kcr at openjdk.java.net Fri Apr 17 15:07:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 15:07:36 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> On Thu, 16 Apr 2020 20:45:17 GMT, John Neffenger wrote: > Let me know if you would like me to rebase my changes and force push a cleaner update. Yes, this is what you will need to do. More than just being needed for a cleaner update, the PR lists 6,151 changed files! Either the merge went badly or it has somehow managed to confuse GitHub (my money is on the latter based on what I see in the diffs). Either way, rebasing and force-pushing your branch is the way to go. You might need to export your patch and reset your branch to master if git has trouble rebasing. ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From kevin.rushforth at oracle.com Fri Apr 17 15:08:30 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Apr 2020 08:08:30 -0700 Subject: GitHub glitch - merging master into an old pull request In-Reply-To: References: Message-ID: <66db2db7-7d63-57f1-41c8-5f761e7206dd@oracle.com> Yeah, something went wrong here. Either the merge went wrong (a quick glance suggests that it didn't) or it has managed to confuse GitHub (that seems likely). I also added a comment to the PR. I do not recommend changing the base branch. Even if that were to fix it, it would be much better for reviewers to rebase and force push. -- Kevin On 4/17/2020 7:56 AM, John Neffenger wrote: > I was surprised to see GitHub listing in my pull request all of the > changes I merged from the upstream master branch, as I commented here: > > Did I merge the upstream master branch correctly? > https://github.com/openjdk/jfx/pull/60#issuecomment-614885532 > > Unfortunately, GitHub also pulled into my pull request anyone who > participated in those changes to master, which is why I'm posting this > to the mailing list instead of commenting there. > > This is the first time I've seen the problem, but it dates back to at > least 2013 according to this Stack Overflow question: > > GitHub pull request showing commits that are already in target branch > https://stackoverflow.com/q/16306012 > > Should I try the suggested fix of temporarily switching the base branch? > > In my case, I would edit the pull request to choose the "jfx14" base > branch, save the change, and then edit it again to switch it back to > the "master" base branch. The Stack Overflow answers state that the > extra commits will then be gone, and I'll have a nice clean pull > request again. > > Thanks, > John > From kcr at openjdk.java.net Fri Apr 17 15:16:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 15:16:30 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> References: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> Message-ID: On Fri, 17 Apr 2020 15:05:22 GMT, Kevin Rushforth wrote: >> @kevinrushforth Did I merge the upstream master branch correctly? The [last time I did >> this](https://github.com/javafxports/openjdk-jfx/pull/522/commits) on the old *openjdk-jfx* repository, the pull >> request showed only the single merge commit. This time all 87 commits from the upstream master branch are shown as part >> of this pull request, even though the code I propose has not changed since the pull request was created on December 4, >> 2019. Let me know if you would like me to rebase my changes and *force push* a cleaner update. While I have your >> attention ... would you be able to be my second reviewer? This pull request is a small update that completes the large >> project begun by [JDK-8217605](https://github.com/javafxports/openjdk-jfx/pull/369) over a year ago. Your comments on >> that first part were very helpful, so I'm hoping you can bring that experience to this second and final part of the >> project. > >> Let me know if you would like me to rebase my changes and force push a cleaner update. > > Yes, this is what you will need to do. > > More than just being needed for a cleaner update, the PR lists 6,151 changed files! Either the merge went badly or it > has somehow managed to confuse GitHub (my money is on the latter based on what I see in the diffs). > Either way, rebasing and force-pushing your branch is the way to go. You might need to export your patch and reset your > branch to master if git has trouble rebasing. I just checked and there is nothing wrong with your merge. But somehow it managed to confuse GitHub. ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From kcr at openjdk.java.net Fri Apr 17 15:19:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 15:19:01 GMT Subject: RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 10:25:52 GMT, Bhawesh Choudhary wrote: > As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to > fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare > against 600 font weight. Can you add a unit test to go along with this fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From github.com+4208131+bhaweshkc at openjdk.java.net Fri Apr 17 15:19:00 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 17 Apr 2020 15:19:00 GMT Subject: RFR: 8191758: Match WebKit's font weight rendering with JavaFX Message-ID: As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare against 600 font weight. ------------- Commit messages: - 8191758: Match WebKit's font weight rendering with JavaFX Changes: https://git.openjdk.java.net/jfx/pull/180/files Webrev: https://webrevs.openjdk.java.net/jfx/180/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8191758 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/180.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/180/head:pull/180 PR: https://git.openjdk.java.net/jfx/pull/180 From nlisker at openjdk.java.net Fri Apr 17 16:04:23 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 17 Apr 2020 16:04:23 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> Message-ID: On Wed, 15 Apr 2020 20:59:40 GMT, Kevin Rushforth wrote: >> Here are the results on Phil's machine, which is a Mac Book Pro with a graphics accelerator (Nvidia, I think). >> >> Without the patch: >> 2000 quads average 8.805 fps >> >> With the patch: >> 2000 quads average 4.719 fps >> >> Almost a 2x performance hit. > > Conclusion: The new shaders that support attenuation don't seem to have much of a performance impact on machines with > an Intel HD, but on systems with a graphics accelerator, it is a significant slowdown. > So we are left with the two choices of doubling the number of shaders (that is, a set of shaders with attenuation and a > set without) or living with the performance hit (which will only be a problem on machines with a dedicated graphics > accelerator for highly fill-limited scenes). The only way we can justify a 2x drop in performance is if we are fairly > certain that this is a corner case, and thus unlikely to hit real applications. If we do end up deciding to replicate > the shaders, I don't think it is all that much work. I'm more worried about how well it would scale to subsequent > improvements, although we could easily decide that for, say, spotlights attenuation is so common that you wouldn't > create a version that doesn't do that. In the D3D HLSL shaders, ifdefs are used, so the work would be to restore the > original code and add the new code under an ifdef. Then double the number of lines of gradle (at that point, I'd do it > in a for-each loop), then modify the logic that loads the shaders to pick the right one. For GLSL, the different parts > of the shader are in different files, so it's a matter of creating new versions of each of the three lighting shaders > that handle attenuation and choosing the right one at runtime. I discussed this with a graphics engineer. He said that a couple of branches do not have any real performance impact even on modern mobile devices, and that, e.g., on iOS 7 using half floats instead of floats was improving shader execution dramatically. Desktops with NVIDIA or AMD and even Intel modern cards can process dozens of branches with no significant performance degradation. He suggested actually to have all the light types in a single shader file (looking ahead here). He also suggested not to permute on shaders based on the number of lights and just pass in a uniform for that number and loop over it. The permutations on the bump, specular and self illuminations components are correct (not sure we are not doing that for the diffuse component). If we add later shadows, which is not on my near to-do list, then we should permute there. It also depends on our target hardware. If we take into account hardware from, say, 2005 then maybe branching will cause significant performance loss, but that hinders our ability to increase performance for newer hardware. What is the policy here? I have a Win10 laptop with a GeForce 610M that I will test this weekend to see if the mobile NVidia cards have some issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From Rony.Flatscher at wu.ac.at Fri Apr 17 17:37:01 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Fri, 17 Apr 2020 19:37:01 +0200 Subject: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> Message-ID: <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> There is a new WIP at which adds a compile PI (process instruction) for turning on and off script compilation if the script engine implements the Compilable interface. By default compilation is off (no compilation), such that one needs to add a compile PI ("") at the top to activate this feature. Supplying "true" (default) or "false" as the PI data turns this feature on and off. The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off", alternating using "compile on and off", and alternating using "compile off and on". This will test all variants of applying the compile PI for all categories of scripts. Any feedback appreciated! ---rony P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes. P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a fallback solution in case a compilation is (unexpectedly) not successful, reverting to (interpretative) evaluation/execution of the script. In that version it is planned to have compilation on by default as in the case of a compilation failure there will be a safe backup solution. On 14.04.2020 19:52, Kevin Rushforth wrote: > Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to > create the CSR until the review is far enough along to know which direction we intend to go. > > Unless there is a real concern about possible regressions if scripts are compiled by default, I > think "enabled by default" is the way to go. Your argument that such script engines are broken > seems reasonable, since this only applies to script engines that implement javax.script.Compilable > in the first place. We still might want to add way to turn compilation off for individual scripts. > One other thing to consider is that if compilation fails, it might make sense to log a warning and > fall back to the existing interpreted mode. > > Does anyone else have any concerns with this? > > -- Kevin > > > On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: >> Hi there, >> >> as there was probably enough time that has passed by I would intend to create a CSR in the next days >> with the PR as per Kevin's suggestion. >> >> (For the case that this feature should not be active by default, the CSR will suggest to define a >> new "compile" PI in the form (default, if no PI data given: true), which >> is independent of the existence of a language PI (this way it becomes also possible to allow >> compilation of external scripts denoted with the script-element, which do not need a page language >> to be set as the file's extension allows the appropriate script engine to be loaded and used for >> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI >> or ? to FXML files (and to turn off), which seems to >> be simple and self-documentary. In general employing such compile PIs allows for setting compilation >> of scripts on and off throughout an FXML file.) >> >> ---rony >> >> >> On 04.04.2020 18:03, Rony G. Flatscher wrote: >> >>> Hi Kevin, >>> >>> On 03.04.2020 01:21, Kevin Rushforth wrote: >>>> I see that you updated the PR and sent it for review. >>>> >>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>>> feature, and if so, what form this feature should take. >>>> >>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>>> from it? >>> Script code should be executed faster after compilation, so any FXML page that hosts script code >>> may >>> benefit. >>> >>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >>> significantly. This is because repeated invocation of compiled script event handlers do not cause >>> the reparsing of that script's source and interpreting it on each invocation, which may be >>> expensive >>> depending on the script engine, but rather allows the immediate evaluation/execution of the >>> compiled >>> script by the script engine. >>> >>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >>> In principle there are three possibilities: >>> >>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the >>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and >>> ???? execute the compiled script each time its registered event fires. >>> >>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts >>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >>> ???????? compiling but have been employed successfully in interpreted mode >>> >>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script >>> ???? engine implements the javax.script.Compilable interface. If missing it would default to >>> "false". >>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the >>> ???? "language" PI was not.) >>> >>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the >>> language >>> ???????? PI gets changed >>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts >>> >>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script >>> and >>> ???? node elements and only compile the scripts, if the property is set to true >>> >>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >>> ???????? accordingly >>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that >>> host scripts >>> >>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >>> overruled individually by 3. >>> >>> The question would be whether 2 or/and 3 are really necessary as it can be expected that >>> compilation >>> of scripts by the script engines would find the same errors as while interpreting the very same >>> scripts (if not, the script engine is badly broken and it could be argued that then the >>> interpretation part of the script engine might be expected to be broken as well which would be >>> quite >>> dangerous from an integrity POV; the same consideration applies as well if the execution of the >>> compiled script would behave differently to interpreting the very same script by the same script >>> engine). >>> >>> The current WIP implements 1 above and includes an appropriate test unit. >>> >>>> What do others think? >>> >>>> In either case, we would need to make sure that this doesn't present any security concerns in the >>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>>> but we would need to ensure that. >>> The compilation of scripts needs to be done by the Java script engines (implementing both, >>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >>> scripts ([javax.script.CompiledScript] >>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >>> >>> >>> ---rony >>> >>> >>> >>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>>> After merging master, applying some fixes and changing the title to reflect the change from >>>>> WIP to a >>>>> pull request I would kindly request a review of this pull request! >>>>> >>>>> Here the URL: , title changed to: "8238080: >>>>> FXMLLoader: if >>>>> script engines implement javax.script.Compilable compile scripts". >>>>> >>>>> ---rony >>>>> >>>>> >>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in >>>>>> review, and >>>>>> has an appropriate test unit going with it as well, please review. >>>>>> >>>>>> There should be no compatibility issue with this implementation. >>>>>> >>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>>> information is present with the FXML file which cannot possibly be present in existing FXML >>>>>> files. >>>>>> In this scenario one possible and probably simple solution would be to only compile scripts >>>>>> if the >>>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>>> value >>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML >>>>>> with >>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up >>>>>> with a >>>>>> respective solution as well. >>>>>> >>>>>> ---rony >>>>>> >>>>>> [1] "Implementation and test unit": >>>>>> >>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>>> scripts": >>>>>> >>>>>> >>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>>> >>>>>> >>>>>> >>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>>> >>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to >>>>>>> illustrate >>>>>>> the concept). >>>>>>> >>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>>> Just filed a RFE with the following information: >>>>>>>> >>>>>>>> ???? * Component: >>>>>>>> ???????? o JavaFX >>>>>>>> >>>>>>>> ???? * Subcomponent: >>>>>>>> ???????? o fxml: JavaFX FXML >>>>>>>> >>>>>>>> ???? * Synopsis: >>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>>> >>>>>>>> ???? * Descriptions: >>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>>> (javax.script.ScriptEngine >>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller >>>>>>>> language in >>>>>>>> ?????????? the FXML file. >>>>>>>> >>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such >>>>>>>> scripts >>>>>>>> could >>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>>> using >>>>>>>> ?????????? its eval() methods. >>>>>>>> >>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>>> invocations, >>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>>> onMouseMove) >>>>>>>> ?????????? which may be repetitevly invoked and evaluated." >>>>>>>> >>>>>>>> ???? * System /OS/Java Runtime Information: >>>>>>>> ???????? o "All systems." >>>>>>>> >>>>>>>> Received the internal review ID: "9063426" >>>>>>>> >>>>>>>> ---rony From prr at openjdk.java.net Fri Apr 17 18:08:16 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 17 Apr 2020 18:08:16 GMT Subject: RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 12:40:24 GMT, Kevin Rushforth wrote: >> As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to >> fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare >> against 600 font weight. > > Can you add a unit test to go along with this fix? Per the opentype spec, 700 is bold. 600 is semi-bold https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass CSS agrees : https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight So are you saying webkit has been using bold at a lower weight than these specs suggest ? I see the logic all comes from Source/WebCore/platform/graphics/FontSelectionAlgorithm.h I suppose the existing code thinks that if we have reached what that file calls the bold threshold of 600 then we should use bold. It isn't necessarily "wrong" but I think I agree that it is more important to be consistent with the rest of Java FX ... which I believe is the point of this change ? ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From twitch at nervestaple.com Fri Apr 17 18:55:48 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Fri, 17 Apr 2020 14:55:48 -0400 Subject: Windows Installation Instructions, All DLL Files Missing Message-ID: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> I manage a project[0]? that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: https://openjfx.io/openjfx-docs/#install-javafx I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: C:\Program Files\Java\javafx-sdk-14\bin Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? Also, what impact does this have on distribution of applications? Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. -- Miles [0]: https://github.com/cmiles74/xmltool [1]: https://openjfx.io/openjfx-docs/#install-javafx From github.com+1413266+jgneff at openjdk.java.net Fri Apr 17 19:11:19 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 17 Apr 2020 19:11:19 GMT Subject: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: > This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements > [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* > repository. Some of the changes were made to support the new device models, while others are minor changes to the > existing support in JavaFX 13. The following changes were made to support the new device models. > * Work around problems on the Kobo Glo HD Model N437. > > Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is > ignored by the driver on the Kobo Glo HD where the error occurs, anyway. > > Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of > the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame > buffer device driver can be an incorrect value. > > * Work around problems on the Kobo Clara HD Model N249. > > The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the > normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The > work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. > > The following changes were made to the existing code that supports e-paper displays in JavaFX 13. > > * Use the correct constant for the number of bytes per pixel. > > Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when > calculating the capacity of the 32-bit off-screen byte buffer. > > * Do not round the luma value to the nearest integer. > > Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of > rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 > percent and doesn't seem worth it for a display with just 16 levels of gray. > > * Change camel case of system property *y8inverted*. > > Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it > is consistent with the other system properties containing Y1, Y4, and Y8 in their names. > > * Improve error handling when mapping the frame buffer. > > Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a > `null` return value from `EPDFrameBuffer.getMappedBuffer`. > > * Replace non-ASCII characters with their ASCII equivalent. > > Replace non-ASCII characters in comments and log messages as follows: > > * "?" with "x" for display resolution and color depth, > * "?" with "*" for multiplication, > * "?" with "to" for transition, and > * "?C" with "degrees Celsius" for temperature. > > * Add descriptions to Monocle EPD system properties. > > Add Javadoc comments to each constant that defines a Monocle EPD system property. > > * Rename `IntStructure.getInteger` to `IntStructure.get`. > > Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method > `Integer.getInteger`, which gets the integer value of a system property. > > Below are some of the more interesting test results. > > * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray > values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. > > * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black > for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that > displays black for values `0x7F` or less and white for values `0x80` or greater. > > * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the > tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame > buffer. I plan to investigate the cause of the performance difference. > > * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold > increase in the number of pixels in their displays. The table below shows the animation speed of each model in > milliseconds per frame and frames per second. > > | Product Name | Speed (ms) | Rate (fps) | > | ------------- |:----------:|:----------:| > | Kobo Touch B | 125 | 8.0 | > | Kobo Touch C | 130 | 7.7 | > | Kobo Glo HD | 140 | 7.1 | > | Kobo Clara HD | 145 | 6.9 | John Neffenger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8227425: Add support for e-paper displays on i.MX6 devices ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/60/files - new: https://git.openjdk.java.net/jfx/pull/60/files/f7028e89..ba668b51 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/60/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/60/webrev.01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60 PR: https://git.openjdk.java.net/jfx/pull/60 From swpalmer at gmail.com Fri Apr 17 19:23:12 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 17 Apr 2020 15:23:12 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> Message-ID: I use jlink and jpackage to distribute JavaFX applications. You suggest there will be a problem if you use jlink, but it will work if you include the needed javafx modules. The .jmod files contain the necessary native libraries and jlink will build a JRE that has the DLLs in the right place for the runtime to find them. Modifying your PATH is not the right way to do this. Distributing a runtime with your application is the right way to solve this. The jlink and jpackage tools make this fairly easy. I use a custom Gradle script to bundle my application, it works well. Scott > On Apr 17, 2020, at 2:55 PM, Christopher Miles wrote: > > I manage a project[0] that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. > > It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: > > https://openjfx.io/openjfx-docs/#install-javafx > > I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: > > Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) > > I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: > > C:\Program Files\Java\javafx-sdk-14\bin > > Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? > > Also, what impact does this have on distribution of applications? > > Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! > > Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. > > -- > Miles > > [0]: https://github.com/cmiles74/xmltool > [1]: https://openjfx.io/openjfx-docs/#install-javafx From hohonuuli at icloud.com Fri Apr 17 20:17:09 2020 From: hohonuuli at icloud.com (hohonuuli at icloud.com) Date: Fri, 17 Apr 2020 13:17:09 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> Message-ID: <05055964-8e47-4e92-892f-7c506543da2c@Spark> I build several JavaFX projects with cross-builds for Windows, Mac, Linux. Note that I build the projects with Java 11, then use Java 14 packager to build the final installer. So my examples require that you set a JPACKAGE_HOME env variable that points at the Java 14 home. Anyway, here?s an example project:?https://github.com/mbari-media-management/vars-query Cheers Brian Schlining Software Engineer P (831) 775-1855 ? F (831) 775-1620 Monterey Bay Aquarium Research Institute 7700 Sandholdt Road, Moss Landing CA 95039 www.mbari.org Advancing marine science and engineering to understand our changing ocean. On Apr 17, 2020, 11:59 AM -0700, Christopher Miles , wrote: > I manage a project[0]? that leverages JavaFX. It's been a while since > I've worked on this project, almost two years. At that time JavaFX was > bundled with the Java runtime from Oracle. The few customers I had would > simply run the application from the bundled launcher and as long as they > had Java installed, it would work. > > It's time for me to add some features to the project, I am now using > OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the > instructions[1] from the following URL: > > https://openjfx.io/openjfx-docs/#install-javafx > > I am on Windows and followed the instructions for that platform. > Unfortunately, things didn't really work. The error was as follows: > > Graphics Device initialization failed for : d3d, sw Error initializing > QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: > java.lang.RuntimeException: Error initializing QuantumRend erer: no > suitable pipeline found at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno > wn Source) > > I fussed with this and that but nothing made a difference. Eventually I > tried adding the "bin" directory from the JavaFX distribution to my > path. This is the entry I added to my global PATH variable: > > C:\Program Files\Java\javafx-sdk-14\bin > > Is this the right way to do this and, if so, why isn't this included in > the directions? Is this a Windows specific issue? > > Also, what impact does this have on distribution of applications? > > Looking at the "Runtime Images" instructions, it looks like the same > issues will be present. Those instructions use `jlink` to point to the > JavaFX libraries and the JAVAFX modules (distributed in another package) > but also leave off references to the DLL files in the "bin" directory. I > am worried that I will need to have people manually install the > OpenJavaFX distribution and add the "bin" directory to their path in > order to run my application. Please say it's not so! > > Any help or pointers to additional documentation would be very much > appreciated! I have made it over the bumps and can now continue > development of my application, my next concern is distributing it to > customers. > > -- > Miles > > [0]: https://github.com/cmiles74/xmltool > [1]: https://openjfx.io/openjfx-docs/#install-javafx From twitch at nervestaple.com Fri Apr 17 20:18:48 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Fri, 17 Apr 2020 16:18:48 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> Message-ID: <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> I have downloaded both the "mods" and the SDK. I put them alongside the JDK on my workstation. C:\Program Files\Java\jdk-14.0.1 C:\Program Files\Java\javafx-sdk-14 C:\Program Files\Java\javafx-jmods-14.0.1 If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... jlink --module-path "C:\Program Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" --add-modules javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base --output C:\Users\cmiles\source\repos\xmltool\target/jlink --strip-debug --no-man-pages --no-header-files --compress=2 ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my global path, the application builds. When I try to run the application I see the following error. Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found Swapping out the mods path for the SDK "lib" directory has, as far as I can tell, the exact same effect. :-( If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my global PATH then it does run successfully. I hear what you're saying but this doesn't seem to be the case... What version of Windows are you using? I don't think this is a Windows 10 specific issue but perhaps there is something platform specific involved. Thank you! Scott Palmer wrote on 4/17/2020 15:23: > I use jlink and jpackage to distribute JavaFX applications. > You suggest there will be a problem if you use jlink, but it will work if you include the needed javafx modules. The .jmod files contain the necessary native libraries and jlink will build a JRE that has the DLLs in the right place for the runtime to find them. > > Modifying your PATH is not the right way to do this. Distributing a runtime with your application is the right way to solve this. The jlink and jpackage tools make this fairly easy. I use a custom Gradle script to bundle my application, it works well. > > Scott > >> On Apr 17, 2020, at 2:55 PM, Christopher Miles wrote: >> >> I manage a project[0] that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. >> >> It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: >> >> https://openjfx.io/openjfx-docs/#install-javafx >> >> I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: >> >> Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) >> >> I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: >> >> C:\Program Files\Java\javafx-sdk-14\bin >> >> Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? >> >> Also, what impact does this have on distribution of applications? >> >> Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! >> >> Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. >> >> -- >> Miles >> >> [0]: https://github.com/cmiles74/xmltool >> [1]: https://openjfx.io/openjfx-docs/#install-javafx > -- Miles From kevin.rushforth at oracle.com Fri Apr 17 20:51:12 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Apr 2020 13:51:12 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: Where are you getting JDK 14.0.1 from? Does it include the Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of them (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 sdk includes them, but the jmods do not. See JDK-8207015 [1] for why not. If the JDK has them, then there should be no problem running a jlinked app. One possible problem is that your jlink line is wrong. You should not point to the SDK at all when running jlink. Use the jmods with jlink (don't use the sdk). Use the sdk with javac and java --module-path (don't use the jmods at all). Btw, even if you are running a JDK that for some reason doesn't have the Microsoft DLLs, you should still be able to run using the SDK (directly, not via jlink, which requires the jmods) as follows: java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" --add-modules javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web MyApplication If this doesn't work without you putting javafx-sdk-14/bin in your PATH then something else is wrong. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8207015 On 4/17/2020 1:18 PM, Christopher Miles wrote: > I have downloaded both the "mods" and the SDK. I put them alongside > the JDK on my workstation. > > ? C:\Program Files\Java\jdk-14.0.1 > ? C:\Program Files\Java\javafx-sdk-14 > ? C:\Program Files\Java\javafx-jmods-14.0.1 > > If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and > point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... > > jlink --module-path "C:\Program > Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" > --add-modules > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base > --output C:\Users\cmiles\source\repos\xmltool\target/jlink > --strip-debug --no-man-pages --no-header-files --compress=2 > > ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my global > path, the application builds. When I try to run the application I see > the following error. > > ? Graphics Device initialization failed for :? d3d, sw > ? Error initializing QuantumRenderer: no suitable pipeline found > > Swapping out the mods path for the SDK "lib" directory has, as far as > I can tell, the exact same effect. :-( > > If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my > global PATH then it does run successfully. > > I hear what you're saying but this doesn't seem to be the case... > > What version of Windows are you using? I don't think this is a Windows > 10 specific issue but perhaps there is something platform specific > involved. > > Thank you! > > > Scott Palmer wrote on 4/17/2020 15:23: >> I use jlink and jpackage to distribute JavaFX applications. >> You suggest there will be a problem if you use jlink, but it will >> work if you include the needed javafx modules. The .jmod files >> contain the necessary native libraries and jlink will build a JRE >> that has the DLLs in the right place for the runtime to find them. >> >> Modifying your PATH is not the right way to do this. Distributing a >> runtime with your application is the right way to solve this. The >> jlink and jpackage tools make this fairly easy. I use a custom Gradle >> script to bundle my application, it works well. >> >> Scott >> >>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>> wrote: >>> >>> I manage a project[0]? that leverages JavaFX. It's been a while >>> since I've worked on this project, almost two years. At that time >>> JavaFX was bundled with the Java runtime from Oracle. The few >>> customers I had would simply run the application from the bundled >>> launcher and as long as they had Java installed, it would work. >>> >>> It's time for me to add some features to the project, I am now using >>> OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed >>> the instructions[1] from the following URL: >>> >>> https://openjfx.io/openjfx-docs/#install-javafx >>> >>> I am on Windows and followed the instructions for that platform. >>> Unfortunately, things didn't really work. The error was as follows: >>> >>> Graphics Device initialization failed for : d3d, sw Error >>> initializing QuantumRenderer: no suitable pipeline found >>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>> initializing QuantumRend erer: no suitable pipeline found at >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>> wn Source) >>> >>> I fussed with this and that but nothing made a difference. >>> Eventually I tried adding the "bin" directory from the JavaFX >>> distribution to my path. This is the entry I added to my global PATH >>> variable: >>> >>> C:\Program Files\Java\javafx-sdk-14\bin >>> >>> Is this the right way to do this and, if so, why isn't this included >>> in the directions? Is this a Windows specific issue? >>> >>> Also, what impact does this have on distribution of applications? >>> >>> Looking at the "Runtime Images" instructions, it looks like the same >>> issues will be present. Those instructions use `jlink` to point to >>> the JavaFX libraries and the JAVAFX modules (distributed in another >>> package) but also leave off references to the DLL files in the "bin" >>> directory. I am worried that I will need to have people manually >>> install the OpenJavaFX distribution and add the "bin" directory to >>> their path in order to run my application. Please say it's not so! >>> >>> Any help or pointers to additional documentation would be very much >>> appreciated! I have made it over the bumps and can now continue >>> development of my application, my next concern is distributing it to >>> customers. >>> >>> -- >>> Miles >>> >>> [0]: https://github.com/cmiles74/xmltool >>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >> > > From twitch at nervestaple.com Fri Apr 17 21:16:11 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Fri, 17 Apr 2020 17:16:11 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: Yeah, I've tried it with both. The instructions on the JavaFX page tell you to add the "lib" directory to the `javac` path and the "mods" to the `jlink` path. I figured, since nothing is working, why not try them the other way around? In all cases the results are the same. I'm using OpenJDK, wouldn't that project have the same issue distributing these DLL files? I would bet they would, since they are also an open source project. I can run Swing projects, however, without these DLL files. I can give the Oracle JDK a try. I had been shying away from it since OpenJDK is getting to be so popular. If that works, I will let the list know. As an aside, the JavaFX home page recommends using OpenJDK right now: https://openjfx.io/openjfx-docs/#install-java Thank you! Kevin Rushforth wrote on 4/17/2020 16:51: > Where are you getting JDK 14.0.1 from? Does it include the Microsoft > VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of them > (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 sdk > includes them, but the jmods do not. See JDK-8207015 [1] for why not. If > the JDK has them, then there should be no problem running a jlinked app. > > One possible problem is that your jlink line is wrong. You should not > point to the SDK at all when running jlink. Use the jmods with jlink > (don't use the sdk). Use the sdk with javac and java --module-path > (don't use the jmods at all). > > Btw, even if you are running a JDK that for some reason doesn't have the > Microsoft DLLs, you should still be able to run using the SDK (directly, > not via jlink, which requires the jmods) as follows: > > java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" > --add-modules > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web > MyApplication > > If this doesn't work without you putting javafx-sdk-14/bin in your PATH > then something else is wrong. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8207015 > > On 4/17/2020 1:18 PM, Christopher Miles wrote: >> I have downloaded both the "mods" and the SDK. I put them alongside >> the JDK on my workstation. >> >> ? C:\Program Files\Java\jdk-14.0.1 >> ? C:\Program Files\Java\javafx-sdk-14 >> ? C:\Program Files\Java\javafx-jmods-14.0.1 >> >> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... >> >> jlink --module-path "C:\Program >> Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" >> --add-modules >> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >> --strip-debug --no-man-pages --no-header-files --compress=2 >> >> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my global >> path, the application builds. When I try to run the application I see >> the following error. >> >> ? Graphics Device initialization failed for :? d3d, sw >> ? Error initializing QuantumRenderer: no suitable pipeline found >> >> Swapping out the mods path for the SDK "lib" directory has, as far as >> I can tell, the exact same effect. :-( >> >> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >> global PATH then it does run successfully. >> >> I hear what you're saying but this doesn't seem to be the case... >> >> What version of Windows are you using? I don't think this is a Windows >> 10 specific issue but perhaps there is something platform specific >> involved. >> >> Thank you! >> >> >> Scott Palmer wrote on 4/17/2020 15:23: >>> I use jlink and jpackage to distribute JavaFX applications. >>> You suggest there will be a problem if you use jlink, but it will >>> work if you include the needed javafx modules. The .jmod files >>> contain the necessary native libraries and jlink will build a JRE >>> that has the DLLs in the right place for the runtime to find them. >>> >>> Modifying your PATH is not the right way to do this. Distributing a >>> runtime with your application is the right way to solve this. The >>> jlink and jpackage tools make this fairly easy. I use a custom Gradle >>> script to bundle my application, it works well. >>> >>> Scott >>> >>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>> wrote: >>>> >>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>> since I've worked on this project, almost two years. At that time >>>> JavaFX was bundled with the Java runtime from Oracle. The few >>>> customers I had would simply run the application from the bundled >>>> launcher and as long as they had Java installed, it would work. >>>> >>>> It's time for me to add some features to the project, I am now using >>>> OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed >>>> the instructions[1] from the following URL: >>>> >>>> https://openjfx.io/openjfx-docs/#install-javafx >>>> >>>> I am on Windows and followed the instructions for that platform. >>>> Unfortunately, things didn't really work. The error was as follows: >>>> >>>> Graphics Device initialization failed for : d3d, sw Error >>>> initializing QuantumRenderer: no suitable pipeline found >>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>> initializing QuantumRend erer: no suitable pipeline found at >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>> wn Source) >>>> >>>> I fussed with this and that but nothing made a difference. >>>> Eventually I tried adding the "bin" directory from the JavaFX >>>> distribution to my path. This is the entry I added to my global PATH >>>> variable: >>>> >>>> C:\Program Files\Java\javafx-sdk-14\bin >>>> >>>> Is this the right way to do this and, if so, why isn't this included >>>> in the directions? Is this a Windows specific issue? >>>> >>>> Also, what impact does this have on distribution of applications? >>>> >>>> Looking at the "Runtime Images" instructions, it looks like the same >>>> issues will be present. Those instructions use `jlink` to point to >>>> the JavaFX libraries and the JAVAFX modules (distributed in another >>>> package) but also leave off references to the DLL files in the "bin" >>>> directory. I am worried that I will need to have people manually >>>> install the OpenJavaFX distribution and add the "bin" directory to >>>> their path in order to run my application. Please say it's not so! >>>> >>>> Any help or pointers to additional documentation would be very much >>>> appreciated! I have made it over the bumps and can now continue >>>> development of my application, my next concern is distributing it to >>>> customers. >>>> >>>> -- >>>> Miles >>>> >>>> [0]: https://github.com/cmiles74/xmltool >>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>> >> >> > -- Miles From kevin.rushforth at oracle.com Fri Apr 17 21:34:31 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Apr 2020 14:34:31 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: From where are you getting your OpenJDK build? https://jdk.java.net/14 ? Somewhere else? -- Kevin On 4/17/2020 2:16 PM, Christopher Miles wrote: > Yeah, I've tried it with both. The instructions on the JavaFX page > tell you to add the "lib" directory to the `javac` path and the "mods" > to the `jlink` path. I figured, since nothing is working, why not try > them the other way around? In all cases the results are the same. > > I'm using OpenJDK, wouldn't that project have the same issue > distributing these DLL files? I would bet they would, since they are > also an open source project. I can run Swing projects, however, > without these DLL files. > > I can give the Oracle JDK a try. I had been shying away from it since > OpenJDK is getting to be so popular. If that works, I will let the > list know. > > As an aside, the JavaFX home page recommends using OpenJDK right now: > > ? https://openjfx.io/openjfx-docs/#install-java > > Thank you! > > Kevin Rushforth wrote on 4/17/2020 16:51: >> Where are you getting JDK 14.0.1 from? Does it include the Microsoft >> VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of >> them (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 >> sdk includes them, but the jmods do not. See JDK-8207015 [1] for why >> not. If the JDK has them, then there should be no problem running a >> jlinked app. >> >> One possible problem is that your jlink line is wrong. You should not >> point to the SDK at all when running jlink. Use the jmods with jlink >> (don't use the sdk). Use the sdk with javac and java --module-path >> (don't use the jmods at all). >> >> Btw, even if you are running a JDK that for some reason doesn't have >> the Microsoft DLLs, you should still be able to run using the SDK >> (directly, not via jlink, which requires the jmods) as follows: >> >> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >> --add-modules >> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >> MyApplication >> >> If this doesn't work without you putting javafx-sdk-14/bin in your >> PATH then something else is wrong. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >> >> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>> I have downloaded both the "mods" and the SDK. I put them alongside >>> the JDK on my workstation. >>> >>> ? C:\Program Files\Java\jdk-14.0.1 >>> ? C:\Program Files\Java\javafx-sdk-14 >>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>> >>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... >>> >>> jlink --module-path "C:\Program >>> Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" >>> --add-modules >>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>> --strip-debug --no-man-pages --no-header-files --compress=2 >>> >>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>> global path, the application builds. When I try to run the >>> application I see the following error. >>> >>> ? Graphics Device initialization failed for :? d3d, sw >>> ? Error initializing QuantumRenderer: no suitable pipeline found >>> >>> Swapping out the mods path for the SDK "lib" directory has, as far >>> as I can tell, the exact same effect. :-( >>> >>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>> global PATH then it does run successfully. >>> >>> I hear what you're saying but this doesn't seem to be the case... >>> >>> What version of Windows are you using? I don't think this is a >>> Windows 10 specific issue but perhaps there is something platform >>> specific involved. >>> >>> Thank you! >>> >>> >>> Scott Palmer wrote on 4/17/2020 15:23: >>>> I use jlink and jpackage to distribute JavaFX applications. >>>> You suggest there will be a problem if you use jlink, but it will >>>> work if you include the needed javafx modules. The .jmod files >>>> contain the necessary native libraries and jlink will build a JRE >>>> that has the DLLs in the right place for the runtime to find them. >>>> >>>> Modifying your PATH is not the right way to do this. Distributing a >>>> runtime with your application is the right way to solve this. The >>>> jlink and jpackage tools make this fairly easy. I use a custom >>>> Gradle script to bundle my application, it works well. >>>> >>>> Scott >>>> >>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>> wrote: >>>>> >>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>> since I've worked on this project, almost two years. At that time >>>>> JavaFX was bundled with the Java runtime from Oracle. The few >>>>> customers I had would simply run the application from the bundled >>>>> launcher and as long as they had Java installed, it would work. >>>>> >>>>> It's time for me to add some features to the project, I am now >>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>> followed the instructions[1] from the following URL: >>>>> >>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>> >>>>> I am on Windows and followed the instructions for that platform. >>>>> Unfortunately, things didn't really work. The error was as follows: >>>>> >>>>> Graphics Device initialization failed for : d3d, sw Error >>>>> initializing QuantumRenderer: no suitable pipeline found >>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>> wn Source) >>>>> >>>>> I fussed with this and that but nothing made a difference. >>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>> distribution to my path. This is the entry I added to my global >>>>> PATH variable: >>>>> >>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>> >>>>> Is this the right way to do this and, if so, why isn't this >>>>> included in the directions? Is this a Windows specific issue? >>>>> >>>>> Also, what impact does this have on distribution of applications? >>>>> >>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>> same issues will be present. Those instructions use `jlink` to >>>>> point to the JavaFX libraries and the JAVAFX modules (distributed >>>>> in another package) but also leave off references to the DLL files >>>>> in the "bin" directory. I am worried that I will need to have >>>>> people manually install the OpenJavaFX distribution and add the >>>>> "bin" directory to their path in order to run my application. >>>>> Please say it's not so! >>>>> >>>>> Any help or pointers to additional documentation would be very >>>>> much appreciated! I have made it over the bumps and can now >>>>> continue development of my application, my next concern is >>>>> distributing it to customers. >>>>> >>>>> -- >>>>> Miles >>>>> >>>>> [0]: https://github.com/cmiles74/xmltool >>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>> >>> >>> >> > > From github.com+636962+ccavanaugh at openjdk.java.net Sat Apr 18 09:43:54 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sat, 18 Apr 2020 09:43:54 GMT Subject: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8129123 > > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Craig Cavanaugh has updated the pull request incrementally with one additional commit since the last revision: Update unit test for JDK_8129123 to check midpoint of the list ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/166/files - new: https://git.openjdk.java.net/jfx/pull/166/files/28b25370..0b6683dd Webrevs: - full: https://webrevs.openjdk.java.net/jfx/166/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/166/webrev.00-01 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/166.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/166/head:pull/166 PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Sat Apr 18 09:43:55 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sat, 18 Apr 2020 09:43:55 GMT Subject: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: On Fri, 17 Apr 2020 10:38:06 GMT, Ajit Ghaisas wrote: >> Craig Cavanaugh has updated the pull request incrementally with one additional commit since the last revision: >> >> Update unit test for JDK_8129123 to check midpoint of the list > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 2097: > >> 2096: first <= index && index <= last); >> 2097: >> 2098: index = LIST_SIZE - 1; > > You have tested first and last index selection. > It will be nice to have a case where we select index = LIST_SIZE/2 Agreed, mid point test added ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From mp at jugs.org Sat Apr 18 10:01:07 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Apr 2020 12:01:07 +0200 Subject: Remove JavaFX JPMS enforcement Message-ID: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Getting started with JavaFX is made overly complicated by the fact that the use of the module system is enforced by some code in the JDK. Especially for beginners, who just want to get some small program running, this is almost always a big source of frustration. It is not very good marketing for JavaFX to make these initial steps such a pain. If you need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar sites (and also this mailing list). Almost every day you can read frustrated posts from helpless people who would just like to get some JavaFX project running but are failing because they get lost in the module system jungle. In order to make JavaFX more easily accessible, especially for beginners, I'd like to start a discussion here about the possibility to unconditionally remove the JavaFX JPMS enforcement. IMHO this enforcement is simply not necessary and is just the root for a lot of frustration with JavaFX. It should just be possible to put all the JavaFX jars on the classpath (instead of the module path) like you would do with any other external dependency in a non-modular setup. With a not very intuitive hack you can circumvent this problem already now. Just add a line like this to the file which contains your main class extending Application (MyApp). class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}} Because of this launcher it is now possible to put all dependencies and all JavaFX jars on the classpath and to completely forget the module system with all its intricacies and pitfalls. But why should people be forced to use such dirty tricks? The better alternative would be to just lift the current constraint. I am using this trick for a long time now, even on bigger projects, and I have never ever experienced any problem resulting from this. Even in theory I don't know anything that could prevent a formally correct module jar to also work on the classpath (which is of course not true the other way round). Therefore I say that this constraint is just not necessary and only does a lot of damage to JavaFXs reputation. I'd now like to have some feedback of the community about this. Michael From youngty1997 at gmail.com Sat Apr 18 10:58:01 2020 From: youngty1997 at gmail.com (Ty Young) Date: Sat, 18 Apr 2020 05:58:01 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> On 4/18/20 5:01 AM, Michael Paus wrote: > Getting started with JavaFX is made overly complicated by the fact > that the use of the > module system is enforced by some code in the JDK. Especially for > beginners, who just > want to get some small program running, this is almost always a big > source of frustration. > It is not very good marketing for JavaFX to make these initial steps > such a pain. If you > need some evidence for this statement, then just follow JavaFX on > Stackoverflow or similar > sites (and also this mailing list). Almost every day you can read > frustrated posts from > helpless people who would just like to get some JavaFX project running > but are failing > because they get lost in the module system jungle. Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and? poor/buggy IDE support. Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: https://openjfx.io/openjfx-docs/#IDE-NetBeans Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way. From mp at jugs.org Sat Apr 18 12:40:34 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Apr 2020 14:40:34 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> Message-ID: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Hi, I would just like to add that many of the problems you have cited would just vanish if the JPMS enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd runtime module VM arguments" anymore and the IDE integration would just be straight forward. JavaFX would become just one more dependency whithout the need for any special treatment. I did, however, not say that JavaFX should be de-modularized. For an expert user who wants to use the JPMS nothing would change at all. Michael Am 18.04.20 um 12:58 schrieb Ty Young: > > On 4/18/20 5:01 AM, Michael Paus wrote: >> Getting started with JavaFX is made overly complicated by the fact >> that the use of the >> module system is enforced by some code in the JDK. Especially for >> beginners, who just >> want to get some small program running, this is almost always a big >> source of frustration. >> It is not very good marketing for JavaFX to make these initial steps >> such a pain. If you >> need some evidence for this statement, then just follow JavaFX on >> Stackoverflow or similar >> sites (and also this mailing list). Almost every day you can read >> frustrated posts from >> helpless people who would just like to get some JavaFX project >> running but are failing >> because they get lost in the module system jungle. > > > Speaking as a long time JavaFX user(literally since Java 8), I have > mostly disagree that the JPMS is hurting JavaFX. > > > That said, I don't think the frustration is misplaced. What you say is > true(Netbeans mailing list is fill of JavaFX issues) and the end user > is *NOT* to be blamed here. > > > Rather, I think what's to blame is poor documentation, JavaFX > requiring absurd runtime module VM arguments, and? poor/buggy IDE > support. > > > Starting with documentation, JavaFX uses reflection for things like > TableView(everyone's favorite) and CSS style sheets. While this may be > obvious for people who are more experienced, those who are not may be > very confused when they get an onslaught of error messages regarding > reflection. Better documentation on what requires reflection, why, and > how to enable it would be useful. > > > Likewise, the notice about having to include javafx.graphics to the > runtime module arguments here: > > > https://openjfx.io/openjfx-docs/#IDE-NetBeans > > > Apply to Maven as well, but it's under Ant for some reason. I don't > know what was changed in JavaFX 14 that now suddenly requires a > runtime VM argument, but it's a PITA and BS. End users are going to > struggle with this, and it prevents JavaFX runtime from being purely > managed by Maven. No other JavaFX version requires this, so it's mind > boggling that all of a sudden JavaFX needs this. > > > Poor/buggy IDE support is really the big one here. I don't know about > other IDEs but Netbeans DOES NOT provide a project template for > creating a JavaFX application with setup dependencies. Netbeans, when > setup with a Maven project, allows you to select an entire > project(pom) rather than the individual dependencies(jar) which > doesn't work. What you search for also matters: if you search for > "JavaFX" you will get the wrong search results. You need to search for > "openjfx" which can be confusing. > > > Anyway, yeah, it's a PITA. There is also an issue with Ant based > projects and Netbeans because JavaFX puts its src.zip in a folder that > is supposed to only include the runtime library that has existed for > years(literally a 1 line fix too). No one really uses Ant anymore so > it's probably not a big deal now but yeah, getting JavaFX working > hasn't been "include and done" when it could potentially be that way. > From weiqigao at gmail.com Sat Apr 18 14:56:46 2020 From: weiqigao at gmail.com (Weiqi Gao) Date: Sat, 18 Apr 2020 09:56:46 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> References: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Message-ID: <86972CED-9549-405D-B963-5065B747D041@gmail.com> I have built both non-modular and modular JavaFX apps in the past five years, and I agree that bootstrapping a modular Hello World JavaFX application is not as trivial as bootstrapping a non-modular one. The big challenges are related to the JPMS. These challenges are not unique to JavaFX. They are present in almost all libraries that are going through the modularization process. (JAXB for example.) The good news in this regard is that with a combination of tools like Gradle and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular JavaFX application has become a non-event that can be done in minutes. And after that initial setup, further development of the application is almost the same as for non-modular JavaFX applications, with the occasional need to add an exports or an opens line to the module-info.java file to allow FXML (or the dependency injector of your choice, I used Juice and Micronaut in two different projects to good effect) reflective access to your controller classes. My IDE of choice, IntelliJ IDEA, works happily with JavaFX. ? Weiqi Gao Sent from my iPhone > On Apr 18, 2020, at 7:43 AM, Michael Paus wrote: > > ?Hi, > I would just like to add that many of the problems you have cited would just vanish if the JPMS > enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd > runtime module VM arguments" anymore and the IDE integration would just be straight forward. > JavaFX would become just one more dependency whithout the need for any special treatment. > > I did, however, not say that JavaFX should be de-modularized. For an expert user who wants > to use the JPMS nothing would change at all. > > Michael > >> Am 18.04.20 um 12:58 schrieb Ty Young: >> >>> On 4/18/20 5:01 AM, Michael Paus wrote: >>> Getting started with JavaFX is made overly complicated by the fact that the use of the >>> module system is enforced by some code in the JDK. Especially for beginners, who just >>> want to get some small program running, this is almost always a big source of frustration. >>> It is not very good marketing for JavaFX to make these initial steps such a pain. If you >>> need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar >>> sites (and also this mailing list). Almost every day you can read frustrated posts from >>> helpless people who would just like to get some JavaFX project running but are failing >>> because they get lost in the module system jungle. >> >> >> Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. >> >> >> That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. >> >> >> Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and poor/buggy IDE support. >> >> >> Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. >> >> >> Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: >> >> >> https://openjfx.io/openjfx-docs/#IDE-NetBeans >> >> >> Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. >> >> >> Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. >> >> >> Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way. >> > From kcr at openjdk.java.net Sat Apr 18 15:32:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 15:32:15 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Fri, 17 Apr 2020 10:42:30 GMT, Jeanette Winzenburg wrote: >> I think, selection and scrolling are two separate operations. Here we use these two operations to achieve the desired >> result for ComboBox. It is nice to have behavior and I am OK with the fix. >>> Also, I believe JDK-8196037 is a duplicate of this issue. >> >> Please Note that - JDK-8196037 is not a duplicate of this issue as described in PR description. >> >> I have a minor comment regarding test. > > repeating my comment from the [previous pull request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): > I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered > :) This will need two reviewers. As part of this review, the questions raised by @kleopatra in [this message from the original PR](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086) need to be answered. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From kcr at openjdk.java.net Sat Apr 18 15:47:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 15:47:46 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> Message-ID: <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> On Fri, 17 Apr 2020 16:02:12 GMT, Nir Lisker wrote: >> Conclusion: The new shaders that support attenuation don't seem to have much of a performance impact on machines with >> an Intel HD, but on systems with a graphics accelerator, it is a significant slowdown. >> So we are left with the two choices of doubling the number of shaders (that is, a set of shaders with attenuation and a >> set without) or living with the performance hit (which will only be a problem on machines with a dedicated graphics >> accelerator for highly fill-limited scenes). The only way we can justify a 2x drop in performance is if we are fairly >> certain that this is a corner case, and thus unlikely to hit real applications. If we do end up deciding to replicate >> the shaders, I don't think it is all that much work. I'm more worried about how well it would scale to subsequent >> improvements, although we could easily decide that for, say, spotlights attenuation is so common that you wouldn't >> create a version that doesn't do that. In the D3D HLSL shaders, ifdefs are used, so the work would be to restore the >> original code and add the new code under an ifdef. Then double the number of lines of gradle (at that point, I'd do it >> in a for-each loop), then modify the logic that loads the shaders to pick the right one. For GLSL, the different parts >> of the shader are in different files, so it's a matter of creating new versions of each of the three lighting shaders >> that handle attenuation and choosing the right one at runtime. > > I discussed this with a graphics engineer. He said that a couple of branches do not have any real performance impact > even on modern mobile devices, and that, e.g., on iOS 7 using half floats instead of floats was improving shader > execution dramatically. Desktops with NVIDIA or AMD and even Intel modern cards can process dozens of branches with no > significant performance degradation. He suggested actually to have all the light types in a single shader file > (looking ahead here). He also suggested not to permute on shaders based on the number of lights and just pass in a > uniform for that number and loop over it. The permutations on the bump, specular and self illuminations components are > correct (not sure we are not doing that for the diffuse component). If we add later shadows, which is not on my near > to-do list, then we should permute there. It also depends on our target hardware. If we take into account hardware > from, say, 2005 then maybe branching will cause significant performance loss, but that hinders our ability to increase > performance for newer hardware. What is the policy here? I have a Win10 laptop with a GeForce 610M that I will test > this weekend to see if the mobile NVidia cards have some issue. I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so far is on graphics accelerators that are a few years old by now. Integrated graphics chipsets (such as Intel HD) either old or new seem largely unaffected by the shader changes. What we are missing is performance metrics from newer graphics accelerators on Mac and Windows. Even with the performance drop on older graphics devices, I'm leaning towards not having the shaders to be shaders to be doubled, since this is an artificial stress test with huge quads. If we could get performance data from a couple more recent graphics accelerators that would be best. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From jvos at openjdk.java.net Sat Apr 18 15:54:47 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 18 Apr 2020 15:54:47 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth wrote: > This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done > for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). > On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by > [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. > I have run a full build and test using this new compiler. Works on my development system (didn't test on our build system yet) ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/178 From kcr at openjdk.java.net Sat Apr 18 16:03:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 16:03:58 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: <9LaXcxJ-7WaC0Rhc-H6fYp0zXJah6SatCRw4ymCKaO4=.7a0e9579-da3a-4ef8-b343-52fa578bcf1e@github.com> On Thu, 9 Apr 2020 10:00:49 GMT, Jesper Skov wrote: >> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. >> >> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 > > /signed @arapte can you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From kcr at openjdk.java.net Sat Apr 18 16:06:49 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 16:06:49 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> On Thu, 9 Apr 2020 09:58:27 GMT, Jesper Skov wrote: > Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. > > This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 The fix looks correct to me. Have you run all tests to ensure no regressions? I left a couple inline comments. modules/javafx.controls/src/main/java/javafx/scene/control/ToggleButton.java line 196: > 195: private ObjectProperty toggleGroup; > 196: @Override > 197: public final void setToggleGroup(ToggleGroup value) { This is unrelated to the fix. The changes in this file should be reverted. modules/javafx.controls/src/test/java/test/javafx/scene/control/ToggleButtonTest.java line 270: > 269: } catch (InterruptedException e) { > 270: System.err.println("InterruptedException occurred during Thread.sleep()"); > 271: } An exception here should cause the test to fail. You can use `Assert.fail` or else re-throw the exception as an `AssertionFailedError`. modules/javafx.controls/src/main/java/javafx/scene/control/ToggleGroup.java line 74: > 73: while (c.next()) { > 74: List addedToggles = c.getAddedSubList(); > 75: This can be declared as final. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From kcr at openjdk.java.net Sat Apr 18 16:16:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 16:16:02 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Sat, 18 Apr 2020 15:52:36 GMT, Johan Vos wrote: >> This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done >> for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). >> On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by >> [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. >> I have run a full build and test using this new compiler. > > Works on my development system (didn't test on our build system yet) I won't integrate this until Monday anyway. If you run into a problem with the actual builds using this compiler, let me know and I'll hold off further (it's been well-tested on my end). ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From tbee at tbee.org Sat Apr 18 16:21:29 2020 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 18 Apr 2020 18:21:29 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <86972CED-9549-405D-B963-5065B747D041@gmail.com> References: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <86972CED-9549-405D-B963-5065B747D041@gmail.com> Message-ID: <3886dff7-67aa-8c5c-97f8-b984bf0f90bb@tbee.org> I'm in the process of porting an app from Java 8 to Java 11. Just getting it to run in classpath mode is not that hard anymore; upgrade a bunch of libraries and you're set. As an experiment I'm now activating JPMS. Right! What a lot of work! Do you have any idea how many fairly common libraries not even include an automatic module name in the manifest? Let alone being full fledged modules. It seems modules is a threshold a lot of projects see no need to cross. So I figure most JavaFX projects also run in classic classpath mode, hence that would be the main usage of the library. Just sayin' Tom On 18-4-2020 16:56, Weiqi Gao wrote: > I have built both non-modular and modular JavaFX apps in the past five years, and I agree that bootstrapping a modular Hello World JavaFX application is not as trivial as bootstrapping a non-modular one. > > The big challenges are related to the JPMS. These challenges are not unique to JavaFX. They are present in almost all libraries that are going through the modularization process. (JAXB for example.) > > The good news in this regard is that with a combination of tools like Gradle and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular JavaFX application has become a non-event that can be done in minutes. > > And after that initial setup, further development of the application is almost the same as for non-modular JavaFX applications, with the occasional need to add an exports or an opens line to the module-info.java file to allow FXML (or the dependency injector of your choice, I used Juice and Micronaut in two different projects to good effect) reflective access to your controller classes. > > My IDE of choice, IntelliJ IDEA, works happily with JavaFX. > > ? > Weiqi Gao > > Sent from my iPhone > >> On Apr 18, 2020, at 7:43 AM, Michael Paus wrote: >> >> ?Hi, >> I would just like to add that many of the problems you have cited would just vanish if the JPMS >> enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd >> runtime module VM arguments" anymore and the IDE integration would just be straight forward. >> JavaFX would become just one more dependency whithout the need for any special treatment. >> >> I did, however, not say that JavaFX should be de-modularized. For an expert user who wants >> to use the JPMS nothing would change at all. >> >> Michael >> >>> Am 18.04.20 um 12:58 schrieb Ty Young: >>> >>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>> Getting started with JavaFX is made overly complicated by the fact that the use of the >>>> module system is enforced by some code in the JDK. Especially for beginners, who just >>>> want to get some small program running, this is almost always a big source of frustration. >>>> It is not very good marketing for JavaFX to make these initial steps such a pain. If you >>>> need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar >>>> sites (and also this mailing list). Almost every day you can read frustrated posts from >>>> helpless people who would just like to get some JavaFX project running but are failing >>>> because they get lost in the module system jungle. >>> >>> Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. >>> >>> >>> That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. >>> >>> >>> Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and poor/buggy IDE support. >>> >>> >>> Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. >>> >>> >>> Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: >>> >>> >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>> >>> >>> Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. >>> >>> >>> Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. >>> >>> >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way. >>> From saleem_yusuf at hotmail.com Sat Apr 18 16:32:20 2020 From: saleem_yusuf at hotmail.com (Mohammad Saleem Yusuf) Date: Sat, 18 Apr 2020 16:32:20 +0000 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: Michael, I completely agree with you. I am Professor at a community college (NHTI) and teach entry level courses to students who have just graduated from high school. About a year ago (JDK 8 to 11), I started including Java FX in my Java course, but after that I had to remove it (JDK > 11.03) as the Oracle examples on web stopped working. I noticed that the textbook I use (Java, The Complete Reference 11 ed, Oracle Press) also took Java FX out. I really like JavaFX and I also teach Microsoft and Google (Android) courses. For GUI, they also use similar technologies in WPF, UWP and Android Development. It would be very helpful to make Java FX use easy again, so students start using Java FX again. I tried for a while but gave as I don't have to time to do all the research and install additional software. M. Saleem Yusuf -----Original Message----- From: openjfx-dev On Behalf Of Michael Paus Sent: Saturday, April 18, 2020 6:01 AM To: OpenJFX Subject: Remove JavaFX JPMS enforcement Getting started with JavaFX is made overly complicated by the fact that the use of the module system is enforced by some code in the JDK. Especially for beginners, who just want to get some small program running, this is almost always a big source of frustration. It is not very good marketing for JavaFX to make these initial steps such a pain. If you need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar sites (and also this mailing list). Almost every day you can read frustrated posts from helpless people who would just like to get some JavaFX project running but are failing because they get lost in the module system jungle. In order to make JavaFX more easily accessible, especially for beginners, I'd like to start a discussion here about the possibility to unconditionally remove the JavaFX JPMS enforcement. IMHO this enforcement is simply not necessary and is just the root for a lot of frustration with JavaFX. It should just be possible to put all the JavaFX jars on the classpath (instead of the module path) like you would do with any other external dependency in a non-modular setup. With a not very intuitive hack you can circumvent this problem already now. Just add a line like this to the file which contains your main class extending Application (MyApp). class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}} Because of this launcher it is now possible to put all dependencies and all JavaFX jars on the classpath and to completely forget the module system with all its intricacies and pitfalls. But why should people be forced to use such dirty tricks? The better alternative would be to just lift the current constraint. I am using this trick for a long time now, even on bigger projects, and I have never ever experienced any problem resulting from this. Even in theory I don't know anything that could prevent a formally correct module jar to also work on the classpath (which is of course not true the other way round). Therefore I say that this constraint is just not necessary and only does a lot of damage to JavaFXs reputation. I'd now like to have some feedback of the community about this. Michael From github.com+7517141+yososs at openjdk.java.net Sat Apr 18 16:49:28 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Sat, 18 Apr 2020 16:49:28 GMT Subject: [Rev 01] RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > > private static final boolean USE_WIDTH_FIXED_SIZE = true; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=300; > private static final int COL_COUNT=600; > // private static final int COL_COUNT=1000; > private static final int ROW_COUNT=1000; > > @Override > public void start(Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if(USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > if(USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > prepareTimeline(scene); > > } > > public static void main(String[] args) { > Application.launch(args); > } > > private void prepareTimeline(Scene scene) { > new AnimationTimer() { > @Override public void handle(long now) { > double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); > } > }.start(); > } > > } yosbits has updated the pull request incrementally with one additional commit since the last revision: 8185886: Fix scroll performance of TableView with many columns ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/125/files - new: https://git.openjdk.java.net/jfx/pull/125/files/04951abf..19fabf2e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/125/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/125/webrev.00-01 Stats: 48 lines in 1 file changed: 24 ins; 19 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/125.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/125/head:pull/125 PR: https://git.openjdk.java.net/jfx/pull/125 From cenbe at kolabnow.com Sat Apr 18 17:15:52 2020 From: cenbe at kolabnow.com (Glenn Holmer) Date: Sat, 18 Apr 2020 12:15:52 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: On 4/18/20 5:01 AM, Michael Paus wrote: > Getting started with JavaFX is made overly complicated by the fact > that the use of the module system is enforced by some code in the > JDK. Especially for beginners, who just want to get some small > program running, this is almost always a big source of frustration. > I'd now like to have some feedback of the community about this. Making it easy for beginners is the job of an IDE. NetBeans 12.0 beta3 can already create modular JavaFX projects using Maven in which "run project" and "debug project" work out of the box. Look for the addition of out-of-box profiling support in beta 4 (hopefully the last before 12.0 releases). -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." From github.com+7517141+yososs at openjdk.java.net Sat Apr 18 17:42:48 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Sat, 18 Apr 2020 17:42:48 GMT Subject: [Rev 01] RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Fri, 3 Apr 2020 03:55:37 GMT, yosbits wrote: >> Hi, >> I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail >> at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. > > My name is "Naohiro Yoshimoto" > I have received an approved email on 2019-8-3. 19fabf2eafcb02b519d39a1b0a9dad5b9209db64 * The constructor creates a cell, but the If the fixedCellSize is not initialized, the Fixed a wasteful process of creating all cells and deleting cells out of the display range. * Reduce the load on ExpressionHelper.removeListener by removing cells outside of the display range from the back of the scrolling operation. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From ajoseph at openjdk.java.net Sat Apr 18 17:49:49 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Sat, 18 Apr 2020 17:49:49 GMT Subject: FYI: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern Message-ID: SVGTest.testSVGRenderingWithPattern is failing frequently due to [JDK-8243110](https://bugs.openjdk.java.net/browse/JDK-8243110). We should skip this test until it is fixed. ------------- Commit messages: - 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern Changes: https://git.openjdk.java.net/jfx/pull/188/files Webrev: https://webrevs.openjdk.java.net/jfx/188/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243112 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/188.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/188/head:pull/188 PR: https://git.openjdk.java.net/jfx/pull/188 From kcr at openjdk.java.net Sat Apr 18 17:49:49 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 17:49:49 GMT Subject: FYI: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern In-Reply-To: References: Message-ID: On Sat, 18 Apr 2020 17:38:17 GMT, Arun Joseph wrote: > SVGTest.testSVGRenderingWithPattern is failing frequently due to > [JDK-8243110](https://bugs.openjdk.java.net/browse/JDK-8243110). We should skip this test until it is fixed. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/188 From twitch at nervestaple.com Sat Apr 18 18:18:44 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Sat, 18 Apr 2020 14:18:44 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> Yep, that's where I downloaded it from. > PS C:\Users\cmiles\source\repos\xmltool> java --version > openjdk 14.0.1 2020-04-14 > OpenJDK Runtime Environment (build 14.0.1+7) > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) When I look at the "bin" directory that came with the JavaFX SDK and compare it to the "bin" directory that comes with OpenJDK there are things in the JavaFX distribution that aren't present in the OpenJDK distribution. These three caught my attention: + prism_common.dll + prism_d3d.dll + prism_sw.dll I suspect missing these DLL's is what is causing the exception when I try to launch my application. I took a look at "JDK-8207015" and I don't think that is my problem, yet. It could be that if the "prism_xxx.dll" files were present, I might run into this issue. I changed my `jlink` command to point at the "mods" as this seems like the correct way to do this. Still, the app refuses to launch with the same error message. > Graphics Device initialization failed for : d3d, sw > Error initializing QuantumRenderer: no suitable pipeline found > java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found I would very much like to avoid adding switches to a `java` invocation in order to run the application. In your example, I would need to have customer installed the JavaFX JDK to a specific location in order for that to work. I'd also need to have some kind of wrapper to handle other operating systems, like Linux or OS X. My goal is to distribute one package with custom launching scripts (i.e. one for batch, Powershell, and Linux/OS X shell) as I did under Java 8. This makes me think that using `jlink` with the mods is the way to go, as long as I can figure out why that is not working. Thank you for your help with this. :-) Kevin Rushforth wrote on 4/17/2020 17:34: > From where are you getting your OpenJDK build? https://jdk.java.net/14 > ? Somewhere else? > > -- Kevin > > > On 4/17/2020 2:16 PM, Christopher Miles wrote: >> Yeah, I've tried it with both. The instructions on the JavaFX page >> tell you to add the "lib" directory to the `javac` path and the "mods" >> to the `jlink` path. I figured, since nothing is working, why not try >> them the other way around? In all cases the results are the same. >> >> I'm using OpenJDK, wouldn't that project have the same issue >> distributing these DLL files? I would bet they would, since they are >> also an open source project. I can run Swing projects, however, >> without these DLL files. >> >> I can give the Oracle JDK a try. I had been shying away from it since >> OpenJDK is getting to be so popular. If that works, I will let the >> list know. >> >> As an aside, the JavaFX home page recommends using OpenJDK right now: >> >> ? https://openjfx.io/openjfx-docs/#install-java >> >> Thank you! >> >> Kevin Rushforth wrote on 4/17/2020 16:51: >>> Where are you getting JDK 14.0.1 from? Does it include the Microsoft >>> VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of >>> them (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 >>> sdk includes them, but the jmods do not. See JDK-8207015 [1] for why >>> not. If the JDK has them, then there should be no problem running a >>> jlinked app. >>> >>> One possible problem is that your jlink line is wrong. You should not >>> point to the SDK at all when running jlink. Use the jmods with jlink >>> (don't use the sdk). Use the sdk with javac and java --module-path >>> (don't use the jmods at all). >>> >>> Btw, even if you are running a JDK that for some reason doesn't have >>> the Microsoft DLLs, you should still be able to run using the SDK >>> (directly, not via jlink, which requires the jmods) as follows: >>> >>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>> --add-modules >>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>> MyApplication >>> >>> If this doesn't work without you putting javafx-sdk-14/bin in your >>> PATH then something else is wrong. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>> >>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>> I have downloaded both the "mods" and the SDK. I put them alongside >>>> the JDK on my workstation. >>>> >>>> ? C:\Program Files\Java\jdk-14.0.1 >>>> ? C:\Program Files\Java\javafx-sdk-14 >>>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>>> >>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... >>>> >>>> jlink --module-path "C:\Program >>>> Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" >>>> --add-modules >>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>> >>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>> global path, the application builds. When I try to run the >>>> application I see the following error. >>>> >>>> ? Graphics Device initialization failed for :? d3d, sw >>>> ? Error initializing QuantumRenderer: no suitable pipeline found >>>> >>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>> as I can tell, the exact same effect. :-( >>>> >>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>> global PATH then it does run successfully. >>>> >>>> I hear what you're saying but this doesn't seem to be the case... >>>> >>>> What version of Windows are you using? I don't think this is a >>>> Windows 10 specific issue but perhaps there is something platform >>>> specific involved. >>>> >>>> Thank you! >>>> >>>> >>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>> You suggest there will be a problem if you use jlink, but it will >>>>> work if you include the needed javafx modules. The .jmod files >>>>> contain the necessary native libraries and jlink will build a JRE >>>>> that has the DLLs in the right place for the runtime to find them. >>>>> >>>>> Modifying your PATH is not the right way to do this. Distributing a >>>>> runtime with your application is the right way to solve this. The >>>>> jlink and jpackage tools make this fairly easy. I use a custom >>>>> Gradle script to bundle my application, it works well. >>>>> >>>>> Scott >>>>> >>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>> wrote: >>>>>> >>>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>>> since I've worked on this project, almost two years. At that time >>>>>> JavaFX was bundled with the Java runtime from Oracle. The few >>>>>> customers I had would simply run the application from the bundled >>>>>> launcher and as long as they had Java installed, it would work. >>>>>> >>>>>> It's time for me to add some features to the project, I am now >>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>> followed the instructions[1] from the following URL: >>>>>> >>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>> >>>>>> I am on Windows and followed the instructions for that platform. >>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>> >>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>> wn Source) >>>>>> >>>>>> I fussed with this and that but nothing made a difference. >>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>> distribution to my path. This is the entry I added to my global >>>>>> PATH variable: >>>>>> >>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>> >>>>>> Is this the right way to do this and, if so, why isn't this >>>>>> included in the directions? Is this a Windows specific issue? >>>>>> >>>>>> Also, what impact does this have on distribution of applications? >>>>>> >>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>> same issues will be present. Those instructions use `jlink` to >>>>>> point to the JavaFX libraries and the JAVAFX modules (distributed >>>>>> in another package) but also leave off references to the DLL files >>>>>> in the "bin" directory. I am worried that I will need to have >>>>>> people manually install the OpenJavaFX distribution and add the >>>>>> "bin" directory to their path in order to run my application. >>>>>> Please say it's not so! >>>>>> >>>>>> Any help or pointers to additional documentation would be very >>>>>> much appreciated! I have made it over the bumps and can now >>>>>> continue development of my application, my next concern is >>>>>> distributing it to customers. >>>>>> >>>>>> -- >>>>>> Miles >>>>>> >>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>> >>>> >>>> >>> >> >> > -- Miles From mp at jugs.org Sat Apr 18 18:44:43 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Apr 2020 20:44:43 +0200 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> Message-ID: <3525e2d5-b813-6895-0bba-a933f0fbc101@jugs.org> Hi Christopher, I do not know what your specific problem is but maybe you just have to shift your goals a little bit. Continuing like you did in the Java 8 days is not a good idea for various reasons. The current trend for distributing desktop software with Java is to build a platform specific installer. The tools for that are all there. Just give it a try. Together with Dirk Lemmermann I have set up a working example and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac and Windows (should also work on Linux but I haven't tested it.) The nice thing about this approach is that your customer does not have to have anything installed on his own machine. He can just install your software like he would install any other piece of software. Michael Am 18.04.20 um 20:18 schrieb Christopher Miles: > Yep, that's where I downloaded it from. > > > PS C:\Users\cmiles\source\repos\xmltool> java --version > > openjdk 14.0.1 2020-04-14 > > OpenJDK Runtime Environment (build 14.0.1+7) > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) > > When I look at the "bin" directory that came with the JavaFX SDK and > compare it to the "bin" directory that comes with OpenJDK there are > things in the JavaFX distribution that aren't present in the OpenJDK > distribution. These three caught my attention: > > ? + prism_common.dll > ? + prism_d3d.dll > ? + prism_sw.dll > > I suspect missing these DLL's is what is causing the exception when I > try to launch my application. > > I took a look at "JDK-8207015" and I don't think that is my problem, > yet. It could be that if the "prism_xxx.dll" files were present, I > might run into this issue. > > I changed my `jlink` command to point at the "mods" as this seems like > the correct way to do this. Still, the app refuses to launch with the > same error message. > > > Graphics Device initialization failed for :? d3d, sw > > Error initializing QuantumRenderer: no suitable pipeline found > > java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing QuantumRenderer: no suitable pipeline found > > I would very much like to avoid adding switches to a `java` invocation > in order to run the application. In your example, I would need to have > customer installed the JavaFX JDK to a specific location in order for > that to work. I'd also need to have some kind of wrapper to handle > other operating systems, like Linux or OS X. My goal is to distribute > one package with custom launching scripts (i.e. one for batch, > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me > think that using `jlink` with the mods is the way to go, as long as I > can figure out why that is not working. > > Thank you for your help with this. :-) > > Kevin Rushforth wrote on 4/17/2020 17:34: >> ?From where are you getting your OpenJDK build? >> https://jdk.java.net/14 ? Somewhere else? >> >> -- Kevin >> >> >> On 4/17/2020 2:16 PM, Christopher Miles wrote: >>> Yeah, I've tried it with both. The instructions on the JavaFX page >>> tell you to add the "lib" directory to the `javac` path and the >>> "mods" to the `jlink` path. I figured, since nothing is working, why >>> not try them the other way around? In all cases the results are the >>> same. >>> >>> I'm using OpenJDK, wouldn't that project have the same issue >>> distributing these DLL files? I would bet they would, since they are >>> also an open source project. I can run Swing projects, however, >>> without these DLL files. >>> >>> I can give the Oracle JDK a try. I had been shying away from it >>> since OpenJDK is getting to be so popular. If that works, I will let >>> the list know. >>> >>> As an aside, the JavaFX home page recommends using OpenJDK right now: >>> >>> ? https://openjfx.io/openjfx-docs/#install-java >>> >>> Thank you! >>> >>> Kevin Rushforth wrote on 4/17/2020 16:51: >>>> Where are you getting JDK 14.0.1 from? Does it include the >>>> Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There >>>> are 45 of them (40 of them are of the form api-ms-win-*.dll). The >>>> JavaFX 14.0.1 sdk includes them, but the jmods do not. See >>>> JDK-8207015 [1] for why not. If the JDK has them, then there should >>>> be no problem running a jlinked app. >>>> >>>> One possible problem is that your jlink line is wrong. You should >>>> not point to the SDK at all when running jlink. Use the jmods with >>>> jlink (don't use the sdk). Use the sdk with javac and java >>>> --module-path (don't use the jmods at all). >>>> >>>> Btw, even if you are running a JDK that for some reason doesn't >>>> have the Microsoft DLLs, you should still be able to run using the >>>> SDK (directly, not via jlink, which requires the jmods) as follows: >>>> >>>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>>> --add-modules >>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>>> MyApplication >>>> >>>> If this doesn't work without you putting javafx-sdk-14/bin in your >>>> PATH then something else is wrong. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>>> >>>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>>> I have downloaded both the "mods" and the SDK. I put them >>>>> alongside the JDK on my workstation. >>>>> >>>>> ? C:\Program Files\Java\jdk-14.0.1 >>>>> ? C:\Program Files\Java\javafx-sdk-14 >>>>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>>>> >>>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` >>>>> path... >>>>> >>>>> jlink --module-path "C:\Program >>>>> Files\Java\javafx-sdk-14\lib;C:\Program >>>>> Files\Java\jdk-14.0.1/jmods" --add-modules >>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>>> >>>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>>> global path, the application builds. When I try to run the >>>>> application I see the following error. >>>>> >>>>> ? Graphics Device initialization failed for :? d3d, sw >>>>> ? Error initializing QuantumRenderer: no suitable pipeline found >>>>> >>>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>>> as I can tell, the exact same effect. :-( >>>>> >>>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>>> global PATH then it does run successfully. >>>>> >>>>> I hear what you're saying but this doesn't seem to be the case... >>>>> >>>>> What version of Windows are you using? I don't think this is a >>>>> Windows 10 specific issue but perhaps there is something platform >>>>> specific involved. >>>>> >>>>> Thank you! >>>>> >>>>> >>>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>>> You suggest there will be a problem if you use jlink, but it will >>>>>> work if you include the needed javafx modules. The .jmod files >>>>>> contain the necessary native libraries and jlink will build a JRE >>>>>> that has the DLLs in the right place for the runtime to find them. >>>>>> >>>>>> Modifying your PATH is not the right way to do this. Distributing >>>>>> a runtime with your application is the right way to solve this. >>>>>> The jlink and jpackage tools make this fairly easy. I use a >>>>>> custom Gradle script to bundle my application, it works well. >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>>> wrote: >>>>>>> >>>>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>>>> since I've worked on this project, almost two years. At that >>>>>>> time JavaFX was bundled with the Java runtime from Oracle. The >>>>>>> few customers I had would simply run the application from the >>>>>>> bundled launcher and as long as they had Java installed, it >>>>>>> would work. >>>>>>> >>>>>>> It's time for me to add some features to the project, I am now >>>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>>> followed the instructions[1] from the following URL: >>>>>>> >>>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>>> >>>>>>> I am on Windows and followed the instructions for that platform. >>>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>>> >>>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>>> wn Source) >>>>>>> >>>>>>> I fussed with this and that but nothing made a difference. >>>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>>> distribution to my path. This is the entry I added to my global >>>>>>> PATH variable: >>>>>>> >>>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>>> >>>>>>> Is this the right way to do this and, if so, why isn't this >>>>>>> included in the directions? Is this a Windows specific issue? >>>>>>> >>>>>>> Also, what impact does this have on distribution of applications? >>>>>>> >>>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>>> same issues will be present. Those instructions use `jlink` to >>>>>>> point to the JavaFX libraries and the JAVAFX modules >>>>>>> (distributed in another package) but also leave off references >>>>>>> to the DLL files in the "bin" directory. I am worried that I >>>>>>> will need to have people manually install the OpenJavaFX >>>>>>> distribution and add the "bin" directory to their path in order >>>>>>> to run my application. Please say it's not so! >>>>>>> >>>>>>> Any help or pointers to additional documentation would be very >>>>>>> much appreciated! I have made it over the bumps and can now >>>>>>> continue development of my application, my next concern is >>>>>>> distributing it to customers. >>>>>>> >>>>>>> -- >>>>>>> Miles >>>>>>> >>>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From github.com+3197675+abhinayagarwal at openjdk.java.net Sun Apr 19 08:22:45 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Sun, 19 Apr 2020 08:22:45 GMT Subject: RFR: 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine Message-ID: Update WebEngine's Javadoc to add information on how it switches to HttpClient instead of URLConnection in JavaFX 14 when used with JDK 12 or later. Identification the correct client is important as both these clients may offer different ways to achieve a task. One such task can be bypassing insecure HTTPS connection. ------------- Commit messages: - Remove trailing whitespace - 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine Changes: https://git.openjdk.java.net/jfx/pull/189/files Webrev: https://webrevs.openjdk.java.net/jfx/189/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242077 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/189/head:pull/189 PR: https://git.openjdk.java.net/jfx/pull/189 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 09:36:12 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 09:36:12 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sat, 18 Apr 2020 15:50:55 GMT, Kevin Rushforth wrote: >> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. >> >> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 > > modules/javafx.controls/src/main/java/javafx/scene/control/ToggleButton.java line 196: > >> 195: private ObjectProperty toggleGroup; >> 196: @Override >> 197: public final void setToggleGroup(ToggleGroup value) { > > This is unrelated to the fix. The changes in this file should be reverted. OK. They are gone. Would this (keeping the changes very specific to the bug?) be worth mentioning in CONTRIBUTING.md? That is, like the note about imports: do not fix warnings that are not directly related to the issue? ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 09:51:07 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 09:51:07 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: > Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. > > This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 Jesper Skov has updated the pull request incrementally with three additional commits since the last revision: - Fail instead of print message - addedToggles list is final - Leave unrelated file alone ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/167/files - new: https://git.openjdk.java.net/jfx/pull/167/files/1386ad74..10eef05b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/167/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/167/webrev.00-01 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/167.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/167/head:pull/167 PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 09:58:42 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 09:58:42 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sat, 18 Apr 2020 16:04:34 GMT, Kevin Rushforth wrote: >> Jesper Skov has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fail instead of print message >> - addedToggles list is final >> - Leave unrelated file alone > > The fix looks correct to me. Have you run all tests to ensure no regressions? > > I left a couple inline comments. @kevinrushforth I tested by: ` bash ./gradlew clean all test -x :web:test ` I assumed that would do it. But I see use of ToggleButton in javafx.web, so that was clearly a faulty assumption. I will try to get webkit working. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+636962+ccavanaugh at openjdk.java.net Sun Apr 19 10:40:14 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sun, 19 Apr 2020 10:40:14 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Fri, 17 Apr 2020 10:42:30 GMT, Jeanette Winzenburg wrote: > repeating my comment from the [previous pull request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): > I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered > :) > - is it really a bug or a nice-to-have enhancement? couldn't find an example in win, didn't try too hard and nowadays, > such plain combos are not a really frequent > - while none of the virtualized controls (nor ChoiceBox) combines selection with scrolling to the selected item. For > combo and choice, I see no reason not make it the default behavior. We need to make certain it behaves "naturally" when > navigating in the open popup. > - instead of catching every list.select (and not forget the unselect) we might consider doing it in a showing handler > - alternatively, we might consider to go deeper and support it directly in the listView - For me / my users / and the open bug, it is a bug due to the current behavior being unexpected. It creates the illusion of a preselected value not actually being selected because it's not visible if the list is large and has been shown. It creates doubt and the user has to scroll to reconfirm their selection which takes extra unnecessary effort and time. - With my testing, for the ComboBox, behavior was smooth and natural. I've not made any attempt to change selection with it shown and I'm not certain it can happen unless done programmatically. User selection within the list requires scrolling, so the selected value is already visible. - I'm not opposed to taking this approach. My current work around by extending ComboBox is based on scrolling when the value is set (restored) programmatically. I could see how it may be more efficient if multiple selections were being performed programmatically, but not sure why someone would write code this way. I would think it's a one shot process to select the final value. - Implementing the change in ListView would not change/improve ChoiceBox simply because it does not use an underlying ListView. My search on uses of ListView only reviled ComboBox other than itself. Since ListView by itself is not collapsed/hidden for typical uses, would automatic scrolling within ListView create a confusing experience? ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 12:44:23 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 12:44:23 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 09:56:27 GMT, Jesper Skov wrote: >> The fix looks correct to me. Have you run all tests to ensure no regressions? >> >> I left a couple inline comments. > > @kevinrushforth I tested by: > ` > bash ./gradlew clean all test -x :web:test > ` > I assumed that would do it. > But I see use of ToggleButton in javafx.web, so that was clearly a faulty assumption. > > I will try to get webkit working. I have failed getting web:tests to work. Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the error below. And that is with both a locally built webkit, and the one from javafx-web-15-ea+3-linux.jar So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW). Any suggestions for how to resolve this? ` > Task :web:test ***************************************************** WARNING: running web tests without building webkit. The webkit native library will be copied from the JDK, which might lead to failures in some web tests. To avoid these failures, you should either build webkit locally, copy the native webkit library from a recent build, or skip execution of web test cases with '-x :web:test' ***************************************************** Exception in thread "JavaFX Application Thread" # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f4e01ae8a61, pid=78774, tid=78815 # # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10) # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x579a61] AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /opt/sources/github/jfx/modules/javafx.web/core.78774) # # An error report file with more information is saved as: # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log # # If you would like to submit a bug report, please visit: # https://github.com/AdoptOpenJDK/openjdk-support/issues # ` ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 12:46:31 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 12:46:31 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 12:42:09 GMT, Jesper Skov wrote: >> @kevinrushforth I tested by: >> ` >> bash ./gradlew clean all test -x :web:test >> ` >> I assumed that would do it. >> But I see use of ToggleButton in javafx.web, so that was clearly a faulty assumption. >> >> I will try to get webkit working. > > I have failed getting web:tests to work. > Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the error below. > > And that is with both a locally built webkit, and the one from javafx-web-15-ea+3-linux.jar > > So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW). > > Any suggestions for how to resolve this? > > ` >> Task :web:test > ***************************************************** > WARNING: running web tests without building webkit. > The webkit native library will be copied from the JDK, > which might lead to failures in some web tests. > To avoid these failures, you should either build > webkit locally, copy the native webkit library from a > recent build, or skip execution of web test cases with > '-x :web:test' > ***************************************************** > Exception in thread "JavaFX Application Thread" > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f4e01ae8a61, pid=78774, tid=78815 > # > # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10) > # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x579a61] AccessInternal::PostRuntimeDispatch, > (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P > %u %g %s %t %c %h" (or dumping to /opt/sources/github/jfx/modules/javafx.web/core.78774) # > # An error report file with more information is saved as: > # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log > # > # If you would like to submit a bug report, please visit: > # https://github.com/AdoptOpenJDK/openjdk-support/issues > # > ` Uh, the exception is (as the comment note suggests) from using a prebuilt webkit. I will try a locally built one now. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 13:52:36 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 13:52:36 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 12:44:23 GMT, Jesper Skov wrote: >> I have failed getting web:tests to work. >> Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the error below. >> >> And that is with both a locally built webkit, and the one from javafx-web-15-ea+3-linux.jar >> >> So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW). >> >> Any suggestions for how to resolve this? >> >> ` >>> Task :web:test >> ***************************************************** >> WARNING: running web tests without building webkit. >> The webkit native library will be copied from the JDK, >> which might lead to failures in some web tests. >> To avoid these failures, you should either build >> webkit locally, copy the native webkit library from a >> recent build, or skip execution of web test cases with >> '-x :web:test' >> ***************************************************** >> Exception in thread "JavaFX Application Thread" >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007f4e01ae8a61, pid=78774, tid=78815 >> # >> # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10) >> # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x579a61] AccessInternal::PostRuntimeDispatch, >> (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 # >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P >> %u %g %s %t %c %h" (or dumping to /opt/sources/github/jfx/modules/javafx.web/core.78774) # >> # An error report file with more information is saved as: >> # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log >> # >> # If you would like to submit a bug report, please visit: >> # https://github.com/AdoptOpenJDK/openjdk-support/issues >> # >> ` > > Uh, the exception is (as the comment note suggests) from using a prebuilt webkit. > I will try a locally built one now. Ah, well. Ended with the same VM crash when building webkit myself. So I am kinda stuck. Suggestions? ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From apurwaagr at gmail.com Sun Apr 19 21:34:00 2020 From: apurwaagr at gmail.com (Apurwa Agrawal) Date: Mon, 20 Apr 2020 03:04:00 +0530 Subject: mailing list invite Message-ID: Hello Please add me to mailing list: apurwagr at gmail.com Thanks and Regards Apurwa Agrawal From ebresie at gmail.com Mon Apr 20 01:55:17 2020 From: ebresie at gmail.com (Eric Bresie) Date: Sun, 19 Apr 2020 20:55:17 -0500 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: 3525e2d5-b813-6895-0bba-a933f0fbc101@jugs.org References: 68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com BDCD737D-A161-40D0-9CAE-1828BFC03CAF@gmail.com 9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com a9ec3335-3e5c-4988-68f5-1f4318e61d5f@oracle.com e8105ea9-62b9-49b3-e1a5-cfb2e4677e1a@nervestaple.com acc3cc78-ef1c-96a3-20be-4a6f45ccd867@oracle.com 8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com 8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com Message-ID: <83c6e199-d7cd-4a44-b0bf-9c5ab01e65c5@Erics-iPhone-X> Would jdeps help to see what dependencies are needed? Eric Bresie Ebresie at gmail.com > On April 18, 2020 at 1:44:43 PM CDT, Michael Paus wrote: > Hi Christopher, > I do not know what your specific problem is but maybe you just have to > shift your goals a little bit. > Continuing like you did in the Java 8 days is not a good idea for > various reasons. The current trend > for distributing desktop software with Java is to build a platform > specific installer. The tools for that > are all there. Just give it a try. Together with Dirk Lemmermann I have > set up a working example > and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac > and Windows (should also work > on Linux but I haven't tested it.) > > The nice thing about this approach is that your customer does not have > to have anything installed on his > own machine. He can just install your software like he would install any > other piece of software. > Michael > > Am 18.04.20 um 20:18 schrieb Christopher Miles: > > Yep, that's where I downloaded it from. > > > > > PS C:\Users\cmiles\source\repos\xmltool> java --version > > > openjdk 14.0.1 2020-04-14 > > > OpenJDK Runtime Environment (build 14.0.1+7) > > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) > > > > When I look at the "bin" directory that came with the JavaFX SDK and > > compare it to the "bin" directory that comes with OpenJDK there are > > things in the JavaFX distribution that aren't present in the OpenJDK > > distribution. These three caught my attention: > > > > + prism_common.dll > > + prism_d3d.dll > > + prism_sw.dll > > > > I suspect missing these DLL's is what is causing the exception when I > > try to launch my application. > > > > I took a look at "JDK-8207015" and I don't think that is my problem, > > yet. It could be that if the "prism_xxx.dll" files were present, I > > might run into this issue. > > > > I changed my `jlink` command to point at the "mods" as this seems like > > the correct way to do this. Still, the app refuses to launch with the > > same error message. > > > > > Graphics Device initialization failed for : d3d, sw > > > Error initializing QuantumRenderer: no suitable pipeline found > > > java.lang.RuntimeException: java.lang.RuntimeException: Error > > initializing QuantumRenderer: no suitable pipeline found > > > > I would very much like to avoid adding switches to a `java` invocation > > in order to run the application. In your example, I would need to have > > customer installed the JavaFX JDK to a specific location in order for > > that to work. I'd also need to have some kind of wrapper to handle > > other operating systems, like Linux or OS X. My goal is to distribute > > one package with custom launching scripts (i.e. one for batch, > > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me > > think that using `jlink` with the mods is the way to go, as long as I > > can figure out why that is not working. > > > > Thank you for your help with this. :-) > > > > Kevin Rushforth wrote on 4/17/2020 17:34: > > > From where are you getting your OpenJDK build? > > > https://jdk.java.net/14 ? Somewhere else? > > > > > > -- Kevin > > > > > > > > > On 4/17/2020 2:16 PM, Christopher Miles wrote: > > > > Yeah, I've tried it with both. The instructions on the JavaFX page > > > > tell you to add the "lib" directory to the `javac` path and the > > > > "mods" to the `jlink` path. I figured, since nothing is working, why > > > > not try them the other way around? In all cases the results are the > > > > same. > > > > > > > > I'm using OpenJDK, wouldn't that project have the same issue > > > > distributing these DLL files? I would bet they would, since they are > > > > also an open source project. I can run Swing projects, however, > > > > without these DLL files. > > > > > > > > I can give the Oracle JDK a try. I had been shying away from it > > > > since OpenJDK is getting to be so popular. If that works, I will let > > > > the list know. > > > > > > > > As an aside, the JavaFX home page recommends using OpenJDK right now: > > > > > > > > https://openjfx.io/openjfx-docs/#install-java > > > > > > > > Thank you! > > > > > > > > Kevin Rushforth wrote on 4/17/2020 16:51: > > > > > Where are you getting JDK 14.0.1 from? Does it include the > > > > > Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There > > > > > are 45 of them (40 of them are of the form api-ms-win-*.dll). The > > > > > JavaFX 14.0.1 sdk includes them, but the jmods do not. See > > > > > JDK-8207015 [1] for why not. If the JDK has them, then there should > > > > > be no problem running a jlinked app. > > > > > > > > > > One possible problem is that your jlink line is wrong. You should > > > > > not point to the SDK at all when running jlink. Use the jmods with > > > > > jlink (don't use the sdk). Use the sdk with javac and java > > > > > --module-path (don't use the jmods at all). > > > > > > > > > > Btw, even if you are running a JDK that for some reason doesn't > > > > > have the Microsoft DLLs, you should still be able to run using the > > > > > SDK (directly, not via jlink, which requires the jmods) as follows: > > > > > > > > > > java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" > > > > > --add-modules > > > > > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web > > > > > MyApplication > > > > > > > > > > If this doesn't work without you putting javafx-sdk-14/bin in your > > > > > PATH then something else is wrong. > > > > > > > > > > -- Kevin > > > > > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8207015 > > > > > > > > > > On 4/17/2020 1:18 PM, Christopher Miles wrote: > > > > > > I have downloaded both the "mods" and the SDK. I put them > > > > > > alongside the JDK on my workstation. > > > > > > > > > > > > C:\Program Files\Java\jdk-14.0.1 > > > > > > C:\Program Files\Java\javafx-sdk-14 > > > > > > C:\Program Files\Java\javafx-jmods-14.0.1 > > > > > > > > > > > > If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and > > > > > > point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` > > > > > > path... > > > > > > > > > > > > jlink --module-path "C:\Program > > > > > > Files\Java\javafx-sdk-14\lib;C:\Program > > > > > > Files\Java\jdk-14.0.1/jmods" --add-modules > > > > > > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base > > > > > > --output C:\Users\cmiles\source\repos\xmltool\target/jlink > > > > > > --strip-debug --no-man-pages --no-header-files --compress=2 > > > > > > > > > > > > ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my > > > > > > global path, the application builds. When I try to run the > > > > > > application I see the following error. > > > > > > > > > > > > Graphics Device initialization failed for : d3d, sw > > > > > > Error initializing QuantumRenderer: no suitable pipeline found > > > > > > > > > > > > Swapping out the mods path for the SDK "lib" directory has, as far > > > > > > as I can tell, the exact same effect. :-( > > > > > > > > > > > > If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my > > > > > > global PATH then it does run successfully. > > > > > > > > > > > > I hear what you're saying but this doesn't seem to be the case... > > > > > > > > > > > > What version of Windows are you using? I don't think this is a > > > > > > Windows 10 specific issue but perhaps there is something platform > > > > > > specific involved. > > > > > > > > > > > > Thank you! > > > > > > > > > > > > > > > > > > Scott Palmer wrote on 4/17/2020 15:23: > > > > > > > I use jlink and jpackage to distribute JavaFX applications. > > > > > > > You suggest there will be a problem if you use jlink, but it will > > > > > > > work if you include the needed javafx modules. The .jmod files > > > > > > > contain the necessary native libraries and jlink will build a JRE > > > > > > > that has the DLLs in the right place for the runtime to find them. > > > > > > > > > > > > > > Modifying your PATH is not the right way to do this. Distributing > > > > > > > a runtime with your application is the right way to solve this. > > > > > > > The jlink and jpackage tools make this fairly easy. I use a > > > > > > > custom Gradle script to bundle my application, it works well. > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > On Apr 17, 2020, at 2:55 PM, Christopher Miles > > > > > > > > wrote: > > > > > > > > > > > > > > > > I manage a project[0] that leverages JavaFX. It's been a while > > > > > > > > since I've worked on this project, almost two years. At that > > > > > > > > time JavaFX was bundled with the Java runtime from Oracle. The > > > > > > > > few customers I had would simply run the application from the > > > > > > > > bundled launcher and as long as they had Java installed, it > > > > > > > > would work. > > > > > > > > > > > > > > > > It's time for me to add some features to the project, I am now > > > > > > > > using OpenJDK 14.0.1 and I installed the OpenJavaFX package and > > > > > > > > followed the instructions[1] from the following URL: > > > > > > > > > > > > > > > > https://openjfx.io/openjfx-docs/#install-javafx > > > > > > > > > > > > > > > > I am on Windows and followed the instructions for that platform. > > > > > > > > Unfortunately, things didn't really work. The error was as follows: > > > > > > > > > > > > > > > > Graphics Device initialization failed for : d3d, sw Error > > > > > > > > initializing QuantumRenderer: no suitable pipeline found > > > > > > > > java.lang.RuntimeException: java.lang.RuntimeException: Error > > > > > > > > initializing QuantumRend erer: no suitable pipeline found at > > > > > > > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno > > > > > > > > wn Source) > > > > > > > > > > > > > > > > I fussed with this and that but nothing made a difference. > > > > > > > > Eventually I tried adding the "bin" directory from the JavaFX > > > > > > > > distribution to my path. This is the entry I added to my global > > > > > > > > PATH variable: > > > > > > > > > > > > > > > > C:\Program Files\Java\javafx-sdk-14\bin > > > > > > > > > > > > > > > > Is this the right way to do this and, if so, why isn't this > > > > > > > > included in the directions? Is this a Windows specific issue? > > > > > > > > > > > > > > > > Also, what impact does this have on distribution of applications? > > > > > > > > > > > > > > > > Looking at the "Runtime Images" instructions, it looks like the > > > > > > > > same issues will be present. Those instructions use `jlink` to > > > > > > > > point to the JavaFX libraries and the JAVAFX modules > > > > > > > > (distributed in another package) but also leave off references > > > > > > > > to the DLL files in the "bin" directory. I am worried that I > > > > > > > > will need to have people manually install the OpenJavaFX > > > > > > > > distribution and add the "bin" directory to their path in order > > > > > > > > to run my application. Please say it's not so! > > > > > > > > > > > > > > > > Any help or pointers to additional documentation would be very > > > > > > > > much appreciated! I have made it over the bumps and can now > > > > > > > > continue development of my application, my next concern is > > > > > > > > distributing it to customers. > > > > > > > > > > > > > > > > -- > > > > > > > > Miles > > > > > > > > > > > > > > > > [0]: https://github.com/cmiles74/xmltool > > > > > > > > [1]: https://openjfx.io/openjfx-docs/#install-javafx > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nlisker at gmail.com Mon Apr 20 04:43:08 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 20 Apr 2020 07:43:08 +0300 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> Message-ID: I managed to get it working by adding "--enable-preview" in several places, I'm not sure if they are all needed. There will be a test branch in my fork with the working build.grade. On Tue, Apr 14, 2020 at 4:35 AM Nir Lisker wrote: > It contains: > -source > 14 > -target > 14 > > Looks like I'll have to do some digging. > > Thanks > > On Tue, Apr 14, 2020 at 2:38 AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Not sure, but you might check here: >> >> modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt >> >> That's the list of args that gradle generates to pass to javac (using >> @.../java-compiler-args.txt) >> >> -- Kevin >> >> On 4/13/2020 4:10 PM, Nir Lisker wrote: >> >> Thanks, yes, testing on JavaFX itself. >> I made these changes. I'm getting "error: invalid source release: 14" >> when trying to build. These are the settings that are output during the >> task: >> >> Gradle Distribution: Gradle wrapper from target build >> Gradle Version: 6.3 >> Java Home: C:\Program Files\Java\jdk-14 >> JVM Arguments: None >> Program Arguments: None >> Build Scans Enabled: false >> Offline Mode Enabled: false >> Gradle Tasks: build >> >> This is the full error message: >> >> error: invalid source release: 14 >> Usage: javac >> use --help for a list of possible options >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> Execution failed for task ':base:compileJava'. >> > Compilation failed with exit code 2; see the compiler error output for >> details. >> >> On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> I guess you mean modifying the FX build in your local repo so that you >>> can test the use of JDK 14 preview features in FX itself? (if you were >>> just trying to use it from your app you wouldn't need any build changes >>> in FX). At a minimum you would need to add the "--enable-preview" flag >>> to compile.options.compilerArgs, and change "sourceCompatibility" from >>> "11" to "14". Not sure if anything more is needed. I've never tried it. >>> >>> -- Kevin >>> >>> >>> On 4/13/2020 1:49 PM, Nir Lisker wrote: >>> > Hi, >>> > >>> > I would like to test the preview features in Java 14 on JavaFX. What >>> > changes should I make in the build files to get it working? >>> > >>> > - Nir >>> >>> >> From mp at jugs.org Mon Apr 20 06:51:44 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 08:51:44 +0200 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <83c6e199-d7cd-4a44-b0bf-9c5ab01e65c5@Erics-iPhone-X> References: <83c6e199-d7cd-4a44-b0bf-9c5ab01e65c5@Erics-iPhone-X> Message-ID: <71071db3-acf8-6c83-94a5-b165d08961d1@jugs.org> Yes, that's what I use in my example together with jlink and jpackage. Am 20.04.20 um 03:55 schrieb Eric Bresie: > Would jdeps help to see what dependencies are needed? > > Eric Bresie > Ebresie at gmail.com >> On April 18, 2020 at 1:44:43 PM CDT, Michael Paus wrote: >> Hi Christopher, >> I do not know what your specific problem is but maybe you just have to >> shift your goals a little bit. >> Continuing like you did in the Java 8 days is not a good idea for >> various reasons. The current trend >> for distributing desktop software with Java is to build a platform >> specific installer. The tools for that >> are all there. Just give it a try. Together with Dirk Lemmermann I have >> set up a working example >> and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac >> and Windows (should also work >> on Linux but I haven't tested it.) >> >> The nice thing about this approach is that your customer does not have >> to have anything installed on his >> own machine. He can just install your software like he would install any >> other piece of software. >> Michael >> >> Am 18.04.20 um 20:18 schrieb Christopher Miles: >>> Yep, that's where I downloaded it from. >>> >>>> PS C:\Users\cmiles\source\repos\xmltool> java --version >>>> openjdk 14.0.1 2020-04-14 >>>> OpenJDK Runtime Environment (build 14.0.1+7) >>>> OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) >>> When I look at the "bin" directory that came with the JavaFX SDK and >>> compare it to the "bin" directory that comes with OpenJDK there are >>> things in the JavaFX distribution that aren't present in the OpenJDK >>> distribution. These three caught my attention: >>> >>> + prism_common.dll >>> + prism_d3d.dll >>> + prism_sw.dll >>> >>> I suspect missing these DLL's is what is causing the exception when I >>> try to launch my application. >>> >>> I took a look at "JDK-8207015" and I don't think that is my problem, >>> yet. It could be that if the "prism_xxx.dll" files were present, I >>> might run into this issue. >>> >>> I changed my `jlink` command to point at the "mods" as this seems like >>> the correct way to do this. Still, the app refuses to launch with the >>> same error message. >>> >>>> Graphics Device initialization failed for : d3d, sw >>>> Error initializing QuantumRenderer: no suitable pipeline found >>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>> initializing QuantumRenderer: no suitable pipeline found >>> >>> I would very much like to avoid adding switches to a `java` invocation >>> in order to run the application. In your example, I would need to have >>> customer installed the JavaFX JDK to a specific location in order for >>> that to work. I'd also need to have some kind of wrapper to handle >>> other operating systems, like Linux or OS X. My goal is to distribute >>> one package with custom launching scripts (i.e. one for batch, >>> Powershell, and Linux/OS X shell) as I did under Java 8. This makes me >>> think that using `jlink` with the mods is the way to go, as long as I >>> can figure out why that is not working. >>> >>> Thank you for your help with this. :-) >>> >>> Kevin Rushforth wrote on 4/17/2020 17:34: >>>> From where are you getting your OpenJDK build? >>>> https://jdk.java.net/14 ? Somewhere else? >>>> >>>> -- Kevin >>>> >>>> >>>> On 4/17/2020 2:16 PM, Christopher Miles wrote: >>>>> Yeah, I've tried it with both. The instructions on the JavaFX page >>>>> tell you to add the "lib" directory to the `javac` path and the >>>>> "mods" to the `jlink` path. I figured, since nothing is working, why >>>>> not try them the other way around? In all cases the results are the >>>>> same. >>>>> >>>>> I'm using OpenJDK, wouldn't that project have the same issue >>>>> distributing these DLL files? I would bet they would, since they are >>>>> also an open source project. I can run Swing projects, however, >>>>> without these DLL files. >>>>> >>>>> I can give the Oracle JDK a try. I had been shying away from it >>>>> since OpenJDK is getting to be so popular. If that works, I will let >>>>> the list know. >>>>> >>>>> As an aside, the JavaFX home page recommends using OpenJDK right now: >>>>> >>>>> https://openjfx.io/openjfx-docs/#install-java >>>>> >>>>> Thank you! >>>>> >>>>> Kevin Rushforth wrote on 4/17/2020 16:51: >>>>>> Where are you getting JDK 14.0.1 from? Does it include the >>>>>> Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There >>>>>> are 45 of them (40 of them are of the form api-ms-win-*.dll). The >>>>>> JavaFX 14.0.1 sdk includes them, but the jmods do not. See >>>>>> JDK-8207015 [1] for why not. If the JDK has them, then there should >>>>>> be no problem running a jlinked app. >>>>>> >>>>>> One possible problem is that your jlink line is wrong. You should >>>>>> not point to the SDK at all when running jlink. Use the jmods with >>>>>> jlink (don't use the sdk). Use the sdk with javac and java >>>>>> --module-path (don't use the jmods at all). >>>>>> >>>>>> Btw, even if you are running a JDK that for some reason doesn't >>>>>> have the Microsoft DLLs, you should still be able to run using the >>>>>> SDK (directly, not via jlink, which requires the jmods) as follows: >>>>>> >>>>>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>>>>> --add-modules >>>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>>>>> MyApplication >>>>>> >>>>>> If this doesn't work without you putting javafx-sdk-14/bin in your >>>>>> PATH then something else is wrong. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>>>>> >>>>>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>>>>> I have downloaded both the "mods" and the SDK. I put them >>>>>>> alongside the JDK on my workstation. >>>>>>> >>>>>>> C:\Program Files\Java\jdk-14.0.1 >>>>>>> C:\Program Files\Java\javafx-sdk-14 >>>>>>> C:\Program Files\Java\javafx-jmods-14.0.1 >>>>>>> >>>>>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>>>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` >>>>>>> path... >>>>>>> >>>>>>> jlink --module-path "C:\Program >>>>>>> Files\Java\javafx-sdk-14\lib;C:\Program >>>>>>> Files\Java\jdk-14.0.1/jmods" --add-modules >>>>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>>>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>>>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>>>>> >>>>>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>>>>> global path, the application builds. When I try to run the >>>>>>> application I see the following error. >>>>>>> >>>>>>> Graphics Device initialization failed for : d3d, sw >>>>>>> Error initializing QuantumRenderer: no suitable pipeline found >>>>>>> >>>>>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>>>>> as I can tell, the exact same effect. :-( >>>>>>> >>>>>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>>>>> global PATH then it does run successfully. >>>>>>> >>>>>>> I hear what you're saying but this doesn't seem to be the case... >>>>>>> >>>>>>> What version of Windows are you using? I don't think this is a >>>>>>> Windows 10 specific issue but perhaps there is something platform >>>>>>> specific involved. >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> >>>>>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>>>>> You suggest there will be a problem if you use jlink, but it will >>>>>>>> work if you include the needed javafx modules. The .jmod files >>>>>>>> contain the necessary native libraries and jlink will build a JRE >>>>>>>> that has the DLLs in the right place for the runtime to find them. >>>>>>>> >>>>>>>> Modifying your PATH is not the right way to do this. Distributing >>>>>>>> a runtime with your application is the right way to solve this. >>>>>>>> The jlink and jpackage tools make this fairly easy. I use a >>>>>>>> custom Gradle script to bundle my application, it works well. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I manage a project[0] that leverages JavaFX. It's been a while >>>>>>>>> since I've worked on this project, almost two years. At that >>>>>>>>> time JavaFX was bundled with the Java runtime from Oracle. The >>>>>>>>> few customers I had would simply run the application from the >>>>>>>>> bundled launcher and as long as they had Java installed, it >>>>>>>>> would work. >>>>>>>>> >>>>>>>>> It's time for me to add some features to the project, I am now >>>>>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>>>>> followed the instructions[1] from the following URL: >>>>>>>>> >>>>>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>>>>> >>>>>>>>> I am on Windows and followed the instructions for that platform. >>>>>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>>>>> >>>>>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>>>>> wn Source) >>>>>>>>> >>>>>>>>> I fussed with this and that but nothing made a difference. >>>>>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>>>>> distribution to my path. This is the entry I added to my global >>>>>>>>> PATH variable: >>>>>>>>> >>>>>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>>>>> >>>>>>>>> Is this the right way to do this and, if so, why isn't this >>>>>>>>> included in the directions? Is this a Windows specific issue? >>>>>>>>> >>>>>>>>> Also, what impact does this have on distribution of applications? >>>>>>>>> >>>>>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>>>>> same issues will be present. Those instructions use `jlink` to >>>>>>>>> point to the JavaFX libraries and the JAVAFX modules >>>>>>>>> (distributed in another package) but also leave off references >>>>>>>>> to the DLL files in the "bin" directory. I am worried that I >>>>>>>>> will need to have people manually install the OpenJavaFX >>>>>>>>> distribution and add the "bin" directory to their path in order >>>>>>>>> to run my application. Please say it's not so! >>>>>>>>> >>>>>>>>> Any help or pointers to additional documentation would be very >>>>>>>>> much appreciated! I have made it over the bumps and can now >>>>>>>>> continue development of my application, my next concern is >>>>>>>>> distributing it to customers. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Miles >>>>>>>>> >>>>>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>>>> >>>>> >>> From mike at plan99.net Mon Apr 20 09:28:14 2020 From: mike at plan99.net (Mike Hearn) Date: Mon, 20 Apr 2020 02:28:14 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: With respect to reflection, it seems like the module system really wants you to use Lookup capabilities rather than "open" modules to reflection. That is, JFX could be changed to use var objects = FXMLLoader.load(MethodHandles.lookup(), new URL("....")); The semantics of a Lookup are that it grants whoever holds the object the same access rights as whoever created it. Thus if an object creates a Lookup and gives it to a framework, that framework can access anything the object could itself access. The lookup object would then be used to do reflection rather than the classical reflection API. With this change the API would guide you to a form that always works, regardless of module configuration. Due to its nature as a GUI toolkit JFX often needs to reflect over user code. It may be worth considering a deeper upgrade in which a Lookup object is provided during application startup, and passed in to the framework e.g. the Application class. Lookup objects can be 'teleported' so JFX components that wish to work with user GUI code generically can then fetch a Lookup from a central place. However, this wouldn't allow overriding of access control (i.e. FXMLLoader that takes such a lookup and teleports it to the right class for access, wouldn't be able to access private fields, because the original place where the lookup was created also couldn't). From nlisker at gmail.com Mon Apr 20 10:46:11 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 20 Apr 2020 13:46:11 +0300 Subject: Gradle task for running tests without Webkit Message-ID: Hi, For those who didn't build Webkit, running tests is done with `-x :web:test`. I think it makes sense to just add a test task that does exactly that, for convenience. What do you think? - Nir From fastegal at openjdk.java.net Mon Apr 20 12:31:18 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 20 Apr 2020 12:31:18 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown Message-ID: The issue is that ChoiceBoxSkin a) doesn't update the text of the label if the value is not contained in the items b) doesn't respect converter for label text Fixed by - listening to value changes to update the label - removing ad-hoc updates (not needed), added update on converter change - passing all label updates through converter Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, so for coveragy, contains also tests that passed before as well as after) ------------- Commit messages: - 8087555: [ChoiceBox] uncontained value not shown Changes: https://git.openjdk.java.net/jfx/pull/191/files Webrev: https://webrevs.openjdk.java.net/jfx/191/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8087555 Stats: 464 lines in 2 files changed: 451 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/191.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/191/head:pull/191 PR: https://git.openjdk.java.net/jfx/pull/191 From kevin.rushforth at oracle.com Mon Apr 20 12:57:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 05:57:51 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> Message-ID: <46f0e60c-4629-e81a-ecd8-5b4c32b47703@oracle.com> Can you try running your app with the following two flags? java -Djavafx.verbose=true -Dprism.verbose=true That might help diagnose the problem. -- Kevin On 4/18/2020 11:18 AM, Christopher Miles wrote: > Yep, that's where I downloaded it from. > > > PS C:\Users\cmiles\source\repos\xmltool> java --version > > openjdk 14.0.1 2020-04-14 > > OpenJDK Runtime Environment (build 14.0.1+7) > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) > > When I look at the "bin" directory that came with the JavaFX SDK and > compare it to the "bin" directory that comes with OpenJDK there are > things in the JavaFX distribution that aren't present in the OpenJDK > distribution. These three caught my attention: > > ? + prism_common.dll > ? + prism_d3d.dll > ? + prism_sw.dll > > I suspect missing these DLL's is what is causing the exception when I > try to launch my application. > > I took a look at "JDK-8207015" and I don't think that is my problem, > yet. It could be that if the "prism_xxx.dll" files were present, I > might run into this issue. > > I changed my `jlink` command to point at the "mods" as this seems like > the correct way to do this. Still, the app refuses to launch with the > same error message. > > > Graphics Device initialization failed for :? d3d, sw > > Error initializing QuantumRenderer: no suitable pipeline found > > java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing QuantumRenderer: no suitable pipeline found > > I would very much like to avoid adding switches to a `java` invocation > in order to run the application. In your example, I would need to have > customer installed the JavaFX JDK to a specific location in order for > that to work. I'd also need to have some kind of wrapper to handle > other operating systems, like Linux or OS X. My goal is to distribute > one package with custom launching scripts (i.e. one for batch, > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me > think that using `jlink` with the mods is the way to go, as long as I > can figure out why that is not working. > > Thank you for your help with this. :-) > > Kevin Rushforth wrote on 4/17/2020 17:34: >> ?From where are you getting your OpenJDK build? >> https://jdk.java.net/14 ? Somewhere else? >> >> -- Kevin >> >> >> On 4/17/2020 2:16 PM, Christopher Miles wrote: >>> Yeah, I've tried it with both. The instructions on the JavaFX page >>> tell you to add the "lib" directory to the `javac` path and the >>> "mods" to the `jlink` path. I figured, since nothing is working, why >>> not try them the other way around? In all cases the results are the >>> same. >>> >>> I'm using OpenJDK, wouldn't that project have the same issue >>> distributing these DLL files? I would bet they would, since they are >>> also an open source project. I can run Swing projects, however, >>> without these DLL files. >>> >>> I can give the Oracle JDK a try. I had been shying away from it >>> since OpenJDK is getting to be so popular. If that works, I will let >>> the list know. >>> >>> As an aside, the JavaFX home page recommends using OpenJDK right now: >>> >>> ? https://openjfx.io/openjfx-docs/#install-java >>> >>> Thank you! >>> >>> Kevin Rushforth wrote on 4/17/2020 16:51: >>>> Where are you getting JDK 14.0.1 from? Does it include the >>>> Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There >>>> are 45 of them (40 of them are of the form api-ms-win-*.dll). The >>>> JavaFX 14.0.1 sdk includes them, but the jmods do not. See >>>> JDK-8207015 [1] for why not. If the JDK has them, then there should >>>> be no problem running a jlinked app. >>>> >>>> One possible problem is that your jlink line is wrong. You should >>>> not point to the SDK at all when running jlink. Use the jmods with >>>> jlink (don't use the sdk). Use the sdk with javac and java >>>> --module-path (don't use the jmods at all). >>>> >>>> Btw, even if you are running a JDK that for some reason doesn't >>>> have the Microsoft DLLs, you should still be able to run using the >>>> SDK (directly, not via jlink, which requires the jmods) as follows: >>>> >>>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>>> --add-modules >>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>>> MyApplication >>>> >>>> If this doesn't work without you putting javafx-sdk-14/bin in your >>>> PATH then something else is wrong. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>>> >>>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>>> I have downloaded both the "mods" and the SDK. I put them >>>>> alongside the JDK on my workstation. >>>>> >>>>> ? C:\Program Files\Java\jdk-14.0.1 >>>>> ? C:\Program Files\Java\javafx-sdk-14 >>>>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>>>> >>>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` >>>>> path... >>>>> >>>>> jlink --module-path "C:\Program >>>>> Files\Java\javafx-sdk-14\lib;C:\Program >>>>> Files\Java\jdk-14.0.1/jmods" --add-modules >>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>>> >>>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>>> global path, the application builds. When I try to run the >>>>> application I see the following error. >>>>> >>>>> ? Graphics Device initialization failed for :? d3d, sw >>>>> ? Error initializing QuantumRenderer: no suitable pipeline found >>>>> >>>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>>> as I can tell, the exact same effect. :-( >>>>> >>>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>>> global PATH then it does run successfully. >>>>> >>>>> I hear what you're saying but this doesn't seem to be the case... >>>>> >>>>> What version of Windows are you using? I don't think this is a >>>>> Windows 10 specific issue but perhaps there is something platform >>>>> specific involved. >>>>> >>>>> Thank you! >>>>> >>>>> >>>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>>> You suggest there will be a problem if you use jlink, but it will >>>>>> work if you include the needed javafx modules. The .jmod files >>>>>> contain the necessary native libraries and jlink will build a JRE >>>>>> that has the DLLs in the right place for the runtime to find them. >>>>>> >>>>>> Modifying your PATH is not the right way to do this. Distributing >>>>>> a runtime with your application is the right way to solve this. >>>>>> The jlink and jpackage tools make this fairly easy. I use a >>>>>> custom Gradle script to bundle my application, it works well. >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>>> wrote: >>>>>>> >>>>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>>>> since I've worked on this project, almost two years. At that >>>>>>> time JavaFX was bundled with the Java runtime from Oracle. The >>>>>>> few customers I had would simply run the application from the >>>>>>> bundled launcher and as long as they had Java installed, it >>>>>>> would work. >>>>>>> >>>>>>> It's time for me to add some features to the project, I am now >>>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>>> followed the instructions[1] from the following URL: >>>>>>> >>>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>>> >>>>>>> I am on Windows and followed the instructions for that platform. >>>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>>> >>>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>>> wn Source) >>>>>>> >>>>>>> I fussed with this and that but nothing made a difference. >>>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>>> distribution to my path. This is the entry I added to my global >>>>>>> PATH variable: >>>>>>> >>>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>>> >>>>>>> Is this the right way to do this and, if so, why isn't this >>>>>>> included in the directions? Is this a Windows specific issue? >>>>>>> >>>>>>> Also, what impact does this have on distribution of applications? >>>>>>> >>>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>>> same issues will be present. Those instructions use `jlink` to >>>>>>> point to the JavaFX libraries and the JAVAFX modules >>>>>>> (distributed in another package) but also leave off references >>>>>>> to the DLL files in the "bin" directory. I am worried that I >>>>>>> will need to have people manually install the OpenJavaFX >>>>>>> distribution and add the "bin" directory to their path in order >>>>>>> to run my application. Please say it's not so! >>>>>>> >>>>>>> Any help or pointers to additional documentation would be very >>>>>>> much appreciated! I have made it over the bumps and can now >>>>>>> continue development of my application, my next concern is >>>>>>> distributing it to customers. >>>>>>> >>>>>>> -- >>>>>>> Miles >>>>>>> >>>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Rony.Flatscher at wu.ac.at Mon Apr 20 12:58:35 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 20 Apr 2020 14:58:35 +0200 Subject: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> Message-ID: <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at> There is a new WIP at : This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be done without compilation. Because of the fallback scripts get compiled with this version by default. It extends PR 187 #187. To further ease spotting scripts that cause a ScriptException a message in the form of "filename: caused ScriptException" gets added to the exception handling in either of the three locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three different kinds of reporting ScriptExceptions may be questioned, however none of these tear down the FXML GUI). This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged whenever a script cannot be compiled and the fallback gets used. It is suggested to use this WIP as it includes the compilation by default with a safe fallback to evaluate the uncompiled script, if compilation (unexpectedly) fails. Again, any feedback, discussion welcome! ---rony P.S.: In the log history there is a commit message "Make message more pregnant.", it should have read "Make messages more terse." instead|.|| | On 17.04.2020 19:37, Rony G. Flatscher wrote: > There is a new WIP at which adds a compile PI (process > instruction) for turning on and off script compilation if the script engine implements the > Compilable interface. > > By default compilation is off (no compilation), such that one needs to add a compile PI > ("") at the top to activate this feature. Supplying "true" (default) or "false" as the PI > data turns this feature on and off. > > The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off", > alternating using "compile on and off", and alternating using "compile off and on". This will test > all variants of applying the compile PI for all categories of scripts. > > Any feedback appreciated! > > ---rony > > P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get > ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes. > > P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a > fallback solution in case a compilation is (unexpectedly) not successful, reverting to > (interpretative) evaluation/execution of the script. In that version it is planned to have > compilation on by default as in the case of a compilation failure there will be a safe backup solution. > > > On 14.04.2020 19:52, Kevin Rushforth wrote: >> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to >> create the CSR until the review is far enough along to know which direction we intend to go. >> >> Unless there is a real concern about possible regressions if scripts are compiled by default, I >> think "enabled by default" is the way to go. Your argument that such script engines are broken >> seems reasonable, since this only applies to script engines that implement javax.script.Compilable >> in the first place. We still might want to add way to turn compilation off for individual scripts. >> One other thing to consider is that if compilation fails, it might make sense to log a warning and >> fall back to the existing interpreted mode. >> >> Does anyone else have any concerns with this? >> >> -- Kevin >> >> >> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: >>> Hi there, >>> >>> as there was probably enough time that has passed by I would intend to create a CSR in the next days >>> with the PR as per Kevin's suggestion. >>> >>> (For the case that this feature should not be active by default, the CSR will suggest to define a >>> new "compile" PI in the form (default, if no PI data given: true), which >>> is independent of the existence of a language PI (this way it becomes also possible to allow >>> compilation of external scripts denoted with the script-element, which do not need a page language >>> to be set as the file's extension allows the appropriate script engine to be loaded and used for >>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI >>> or ? to FXML files (and to turn off), which seems to >>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation >>> of scripts on and off throughout an FXML file.) >>> >>> ---rony >>> >>> >>> On 04.04.2020 18:03, Rony G. Flatscher wrote: >>> >>>> Hi Kevin, >>>> >>>> On 03.04.2020 01:21, Kevin Rushforth wrote: >>>>> I see that you updated the PR and sent it for review. >>>>> >>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>>>> feature, and if so, what form this feature should take. >>>>> >>>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>>>> from it? >>>> Script code should be executed faster after compilation, so any FXML page that hosts script code >>>> may >>>> benefit. >>>> >>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >>>> significantly. This is because repeated invocation of compiled script event handlers do not cause >>>> the reparsing of that script's source and interpreting it on each invocation, which may be >>>> expensive >>>> depending on the script engine, but rather allows the immediate evaluation/execution of the >>>> compiled >>>> script by the script engine. >>>> >>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >>>> In principle there are three possibilities: >>>> >>>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the >>>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and >>>> ???? execute the compiled script each time its registered event fires. >>>> >>>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts >>>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >>>> ???????? compiling but have been employed successfully in interpreted mode >>>> >>>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >>>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script >>>> ???? engine implements the javax.script.Compilable interface. If missing it would default to >>>> "false". >>>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >>>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the >>>> ???? "language" PI was not.) >>>> >>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the >>>> language >>>> ???????? PI gets changed >>>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts >>>> >>>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script >>>> and >>>> ???? node elements and only compile the scripts, if the property is set to true >>>> >>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >>>> ???????? accordingly >>>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that >>>> host scripts >>>> >>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >>>> overruled individually by 3. >>>> >>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that >>>> compilation >>>> of scripts by the script engines would find the same errors as while interpreting the very same >>>> scripts (if not, the script engine is badly broken and it could be argued that then the >>>> interpretation part of the script engine might be expected to be broken as well which would be >>>> quite >>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the >>>> compiled script would behave differently to interpreting the very same script by the same script >>>> engine). >>>> >>>> The current WIP implements 1 above and includes an appropriate test unit. >>>> >>>>> What do others think? >>>>> In either case, we would need to make sure that this doesn't present any security concerns in the >>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>>>> but we would need to ensure that. >>>> The compilation of scripts needs to be done by the Java script engines (implementing both, >>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >>>> scripts ([javax.script.CompiledScript] >>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >>>> >>>> >>>> ---rony >>>> >>>> >>>> >>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>>>> After merging master, applying some fixes and changing the title to reflect the change from >>>>>> WIP to a >>>>>> pull request I would kindly request a review of this pull request! >>>>>> >>>>>> Here the URL: , title changed to: "8238080: >>>>>> FXMLLoader: if >>>>>> script engines implement javax.script.Compilable compile scripts". >>>>>> >>>>>> ---rony >>>>>> >>>>>> >>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in >>>>>>> review, and >>>>>>> has an appropriate test unit going with it as well, please review. >>>>>>> >>>>>>> There should be no compatibility issue with this implementation. >>>>>>> >>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML >>>>>>> files. >>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts >>>>>>> if the >>>>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>>>> value >>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML >>>>>>> with >>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up >>>>>>> with a >>>>>>> respective solution as well. >>>>>>> >>>>>>> ---rony >>>>>>> >>>>>>> [1] "Implementation and test unit": >>>>>>> >>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>>>> scripts": >>>>>>> >>>>>>> >>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>>>> >>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to >>>>>>>> illustrate >>>>>>>> the concept). >>>>>>>> >>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>>>> Just filed a RFE with the following information: >>>>>>>>> >>>>>>>>> ???? * Component: >>>>>>>>> ???????? o JavaFX >>>>>>>>> >>>>>>>>> ???? * Subcomponent: >>>>>>>>> ???????? o fxml: JavaFX FXML >>>>>>>>> >>>>>>>>> ???? * Synopsis: >>>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>>>> >>>>>>>>> ???? * Descriptions: >>>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>>>> (javax.script.ScriptEngine >>>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller >>>>>>>>> language in >>>>>>>>> ?????????? the FXML file. >>>>>>>>> >>>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such >>>>>>>>> scripts >>>>>>>>> could >>>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>>>> using >>>>>>>>> ?????????? its eval() methods. >>>>>>>>> >>>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>>>> invocations, >>>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>>>> onMouseMove) >>>>>>>>> ?????????? which may be repetitevly invoked and evaluated." >>>>>>>>> >>>>>>>>> ???? * System /OS/Java Runtime Information: >>>>>>>>> ???????? o "All systems." >>>>>>>>> >>>>>>>>> Received the internal review ID: "9063426" >>>>>>>>> >>>>>>>>> ---rony From mp at jugs.org Mon Apr 20 13:06:16 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 15:06:16 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: This is deviating quite a bit from the original issue of this thread, isn't it? As a side note: MethodHandles are not supported by GraalVM native image and so this would probably collide with the attempts to get JavaFX running on Android/iOS. Am 20.04.20 um 11:28 schrieb Mike Hearn: > With respect to reflection, it seems like the module system really wants > you to use Lookup capabilities rather than "open" modules to reflection. > That is, JFX could be changed to use > > var objects = FXMLLoader.load(MethodHandles.lookup(), new URL("....")); > > The semantics of a Lookup are that it grants whoever holds the object the > same access rights as whoever created it. Thus if an object creates a > Lookup and gives it to a framework, that framework can access anything the > object could itself access. > > The lookup object would then be used to do reflection rather than the > classical reflection API. With this change the API would guide you to a > form that always works, regardless of module configuration. > > Due to its nature as a GUI toolkit JFX often needs to reflect over user > code. It may be worth considering a deeper upgrade in which a Lookup object > is provided during application startup, and passed in to the framework e.g. > the Application class. Lookup objects can be 'teleported' so JFX components > that wish to work with user GUI code generically can then fetch a Lookup > from a central place. However, this wouldn't allow overriding of access > control (i.e. FXMLLoader that takes such a lookup and teleports it to the > right class for access, wouldn't be able to access private fields, because > the original place where the lookup was created also couldn't). From Rony.Flatscher at wu.ac.at Mon Apr 20 13:26:19 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 20 Apr 2020 15:26:19 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> On 20.04.2020 15:06, Michael Paus wrote: > This is deviating quite a bit from the original issue of this thread, isn't it? > > As a side note: MethodHandles are not supported by GraalVM native image > and so this would probably collide with the attempts to get JavaFX running > on Android/iOS. Would you have some link where there would be a technical overview about how Java and JavaFX support gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on that platform, ie. is java.lang.reflect available? ---rony From johan.vos at gluonhq.com Mon Apr 20 13:54:34 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 20 Apr 2020 15:54:34 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> Message-ID: Hi, The JavaFX implementation used in Android and iOS is using 100% the same code as the one on desktop. JavaFX internally uses reflection, and that is supported indeed (can be used in app-specific code as well). The best place to get started is at https://github.com/gluonhq/client-samples - Johan On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher wrote: > On 20.04.2020 15:06, Michael Paus wrote: > > This is deviating quite a bit from the original issue of this thread, > isn't it? > > > > As a side note: MethodHandles are not supported by GraalVM native image > > and so this would probably collide with the attempts to get JavaFX > running > > on Android/iOS. > Would you have some link where there would be a technical overview about > how Java and JavaFX support > gets currently realized under Android/iOS? Also, how is reflection > supposed to be carried out on > that platform, ie. is java.lang.reflect available? > > ---rony > > > From Rony.Flatscher at wu.ac.at Mon Apr 20 13:59:23 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 20 Apr 2020 15:59:23 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> Message-ID: Hi Johan, On 20.04.2020 15:54, Johan Vos wrote: > The JavaFX implementation used in Android and iOS is using 100% the same code as the one on desktop. > JavaFX internally uses reflection, and that is supported indeed (can be used in app-specific code > as well). > The best place to get started is at?https://github.com/gluonhq/client-samples thank you very much for both, the link and assuring that reflection is still available to apps as well! ---rony > > On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher > wrote: > > On 20.04.2020 15:06, Michael Paus wrote: > > This is deviating quite a bit from the original issue of this thread, isn't it? > > > > As a side note: MethodHandles are not supported by GraalVM native image > > and so this would probably collide with the attempts to get JavaFX running > > on Android/iOS. > Would you have some link where there would be a technical overview about how Java and JavaFX > support > gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on > that platform, ie. is java.lang.reflect available? > > ---rony > From mike at plan99.net Mon Apr 20 14:44:23 2020 From: mike at plan99.net (Mike Hearn) Date: Mon, 20 Apr 2020 07:44:23 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: Possibly - I posted this because, being ultimately still a product of the Java group at Oracle, I'm sceptical JavaFX will become *less* dependent on the module system when the trend has been to use it more. So there are at least two usability problems: 1 - needing additional downloads and new JVM flags to use JavaFX as modules rather than ordinary JARs 2 - needing to open packages to JavaFX so it can reflect over them (not a problem if your app runs on the classpath, but can hit you the moment you use a component that's been modularised) The first one has a few workarounds/solutions but what I do is go with the flow and prepare my own JDK using jlink, which has JavaFX baked in like it did before. I use a variant on this script: https://gist.github.com/mikehearn/b18842d45181ac150ec9e6d0b2bb1e24 The output is a JDK directory I can point my IDE at. It's seen as a normal JDK, but like in Java 8 JavaFX is now fully baked in and available by default. Because it's already on the module path no special JVM flags are required. Probably someone (me?) should upload JDKs for each platform that are "fully baked" like this. That leaves the second problem, for which there's no good solution with the current JFX API. Dependency injectors fundamentally don't mix well with JPMS. Using Lookup objects is a backwards compatible addition that would remove part of the pain of using modules with JavaFX because you'd no longer need to remember to add special incantations to a module-info.java to enable reflection - incantations which might change between JFX versions as reflection uses are added or changed. On Mon, Apr 20, 2020 at 15:06:16, Michael Paus wrote: > This is deviating quite a bit from the original issue of this thread, > isn't it? > > As a side note: MethodHandles are not supported by GraalVM native image > and so this would probably collide with the attempts to get JavaFX running > on Android/iOS. > > Am 20.04.20 um 11:28 schrieb Mike Hearn: > > With respect to reflection, it seems like the module system really wants > you to use Lookup capabilities rather than "open" modules to reflection. > That is, JFX could be changed to use > > var objects = FXMLLoader.load(MethodHandles.lookup(), new URL("....")); > > The semantics of a Lookup are that it grants whoever holds the object the > same access rights as whoever created it. Thus if an object creates a > Lookup and gives it to a framework, that framework can access anything the > object could itself access. > > The lookup object would then be used to do reflection rather than the > classical reflection API. With this change the API would guide you to a > form that always works, regardless of module configuration. > > Due to its nature as a GUI toolkit JFX often needs to reflect over user > code. It may be worth considering a deeper upgrade in which a Lookup object > is provided during application startup, and passed in to the framework e.g. > the Application class. Lookup objects can be 'teleported' so JFX components > that wish to work with user GUI code generically can then fetch a Lookup > from a central place. However, this wouldn't allow overriding of access > control (i.e. FXMLLoader that takes such a lookup and teleports it to the > right class for access, wouldn't be able to access private fields, because > the original place where the lookup was created also couldn't). > > From David.Grieve at microsoft.com Mon Apr 20 15:13:27 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Mon, 20 Apr 2020 15:13:27 +0000 Subject: Windows Installation Instructions, All DLL Files Missing Message-ID: Set -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin For the jlink question, look at jmod. You'll use jmod to bundle up the dll's and whatever else you need, then jlink to create the custom runtime. -----Original Message----- From: openjfx-dev On Behalf Of Christopher Miles Sent: Friday, April 17, 2020 2:56 PM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files Missing I manage a project[0]? that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: https://openjfx.io/openjfx-docs/#install-javafx I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: C:\Program Files\Java\javafx-sdk-14\bin Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? Also, what impact does this have on distribution of applications? Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. -- Miles [0]: https://github.com/cmiles74/xmltool [1]: https://openjfx.io/openjfx-docs/#install-javafx From kevin.rushforth at oracle.com Mon Apr 20 15:19:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 08:19:49 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: Message-ID: <035b1f84-9f13-38b1-bca4-c1e09f95bf4a@oracle.com> That shouldn't be necessary. It's a better workaround than setting the PATH env variable to be sure, but there is some underlying problem that isn't yet understood. -- Kevin On 4/20/2020 8:13 AM, David Grieve wrote: > Set -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin > > For the jlink question, look at jmod. You'll use jmod to bundle up the dll's and whatever else you need, then jlink to create the custom runtime. > > -----Original Message----- > From: openjfx-dev On Behalf Of Christopher Miles > Sent: Friday, April 17, 2020 2:56 PM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files Missing > > I manage a project[0]? that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. > > It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: > > https://openjfx.io/openjfx-docs/#install-javafx > > I am on Windows and followed the instructions for that platform. > Unfortunately, things didn't really work. The error was as follows: > > Graphics Device initialization failed for : d3d, sw Error initializing > QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: > java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno > wn Source) > > I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: > > C:\Program Files\Java\javafx-sdk-14\bin > > Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? > > Also, what impact does this have on distribution of applications? > > Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! > > Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. > > -- > Miles > > [0]: https://github.com/cmiles74/xmltool > [1]: https://openjfx.io/openjfx-docs/#install-javafx From youngty1997 at gmail.com Mon Apr 20 15:25:58 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 20 Apr 2020 10:25:58 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Message-ID: On 4/18/20 7:40 AM, Michael Paus wrote: > Hi, > I would just like to add that many of the problems you have cited > would just vanish if the JPMS > enforcement would be removed from the JDK. There would be no "JavaFX > requiring absurd > runtime module VM arguments" anymore and the IDE integration would > just be straight forward. > JavaFX would become just one more dependency whithout the need for any > special treatment. The custom Maven runtime arguments shouldn't exist, period. They didn't exist before 14 and there was zero discussion here as to why they are suddenly required on this mailing list. It just kinda came out of no where. Also, correction, the wiki is wrong: that JVM argument is ONLY for Maven projects, not Ant. I still stand that the fault isn't JPMS but rather people not willing to add documentation or support for it. When JavaFX fails to reflect on a class file or a CSS file it could suggest that it needs to be "open"ed. > > I did, however, not say that JavaFX should be de-modularized. For an > expert user who wants > to use the JPMS nothing would change at all. I'm a bit confused here. if you don't want JPMS then you should be able to run everything on the classpath like normal. Netbeans at least doesn't force modules wtih Maven. Or is reflection disabled on classpath as of Java 9 too unless you have a module-info? > > Michael > > Am 18.04.20 um 12:58 schrieb Ty Young: >> >> On 4/18/20 5:01 AM, Michael Paus wrote: >>> Getting started with JavaFX is made overly complicated by the fact >>> that the use of the >>> module system is enforced by some code in the JDK. Especially for >>> beginners, who just >>> want to get some small program running, this is almost always a big >>> source of frustration. >>> It is not very good marketing for JavaFX to make these initial steps >>> such a pain. If you >>> need some evidence for this statement, then just follow JavaFX on >>> Stackoverflow or similar >>> sites (and also this mailing list). Almost every day you can read >>> frustrated posts from >>> helpless people who would just like to get some JavaFX project >>> running but are failing >>> because they get lost in the module system jungle. >> >> >> Speaking as a long time JavaFX user(literally since Java 8), I have >> mostly disagree that the JPMS is hurting JavaFX. >> >> >> That said, I don't think the frustration is misplaced. What you say >> is true(Netbeans mailing list is fill of JavaFX issues) and the end >> user is *NOT* to be blamed here. >> >> >> Rather, I think what's to blame is poor documentation, JavaFX >> requiring absurd runtime module VM arguments, and? poor/buggy IDE >> support. >> >> >> Starting with documentation, JavaFX uses reflection for things like >> TableView(everyone's favorite) and CSS style sheets. While this may >> be obvious for people who are more experienced, those who are not may >> be very confused when they get an onslaught of error messages >> regarding reflection. Better documentation on what requires >> reflection, why, and how to enable it would be useful. >> >> >> Likewise, the notice about having to include javafx.graphics to the >> runtime module arguments here: >> >> >> https://openjfx.io/openjfx-docs/#IDE-NetBeans >> >> >> Apply to Maven as well, but it's under Ant for some reason. I don't >> know what was changed in JavaFX 14 that now suddenly requires a >> runtime VM argument, but it's a PITA and BS. End users are going to >> struggle with this, and it prevents JavaFX runtime from being purely >> managed by Maven. No other JavaFX version requires this, so it's mind >> boggling that all of a sudden JavaFX needs this. >> >> >> Poor/buggy IDE support is really the big one here. I don't know about >> other IDEs but Netbeans DOES NOT provide a project template for >> creating a JavaFX application with setup dependencies. Netbeans, when >> setup with a Maven project, allows you to select an entire >> project(pom) rather than the individual dependencies(jar) which >> doesn't work. What you search for also matters: if you search for >> "JavaFX" you will get the wrong search results. You need to search >> for "openjfx" which can be confusing. >> >> >> Anyway, yeah, it's a PITA. There is also an issue with Ant based >> projects and Netbeans because JavaFX puts its src.zip in a folder >> that is supposed to only include the runtime library that has existed >> for years(literally a 1 line fix too). No one really uses Ant anymore >> so it's probably not a big deal now but yeah, getting JavaFX working >> hasn't been "include and done" when it could potentially be that way. >> > From github.com+1413266+jgneff at openjdk.java.net Mon Apr 20 15:31:44 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 20 Apr 2020 15:31:44 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> Message-ID: On Fri, 17 Apr 2020 15:14:19 GMT, Kevin Rushforth wrote: > I just checked and there is nothing wrong with your merge. But somehow it managed to confuse GitHub. Thanks, Kevin. A simple `git rebase master` and `git push --force` did the trick! I hope it's okay for me to add some advocacy to the conversation here. My initial comment makes it easy to miss the general context of this update. This pull request completes the project of adding support for e-paper displays that we started back in JavaFX 13. I would love to see these last few changes merged in time for JavaFX 15. Below are five reasons to merge this pull request into the next release: 1. It's small. It's only 50 lines of code ? the last 3 percent of the entire project. 2. It's done. It completes the work already included in JavaFX 13, which was 1,812 lines of code and 97 percent of the project. 3. It's safe. The code runs only when the system properties include `glass.platform=Monocle` and `monocle.platform=EPD`, and even then, only when the system has an e-paper display with the EPD Controller frame buffer driver. There are no changes to any JavaFX code outside of the Monocle EPD platform. 4. It's tested. I tested the code in November with JDK 13 and JavaFX 14. I tested the code again this week with JDK 14 and JavaFX 15. I ran tests with Ubuntu OpenJDK 11 and 13 as well as AdoptOpenJDK 11 and 14. I tested older devices under Ubuntu 14.04 and newer devices under Ubuntu 20.04 Beta. All tests passed. 5. It's unique. This pull request makes JavaFX the only cross-platform application framework with built-in support for e-paper displays. It demonstrates that the Java slogan "write once, run anywhere" is as true today as it was in 1995, not just for different operating systems and processor architectures, but even for radically different display technologies like electronic ink. To my potential reviewers, @johanvos and @kevinrushforth, is there anything I can do to make your code review easier? ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From hjohn at xs4all.nl Mon Apr 20 15:34:25 2020 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 20 Apr 2020 17:34:25 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: > With a not very intuitive hack you can circumvent this problem already now. > Just add a line like this to the file which contains your main class > extending > Application (MyApp). > > class MyAppLauncher {public static void main(String[] args) > {MyApp.main(args);}} I do exactly the same, I construct a fat jar with all of JavaFX included and run it as above. I was looking forward to the module system allowing a clean and easy way to have a visibility scope inbetween public and package (by making packages hierarchical for example), but it turned into a monster that just seems to make projects fragile and hard to build/run. I suppose it may be possible to just generate and publish JavaFX jars without all the module-info files included, but I'm not sure it is as simple as that. --John From yousef.alhashemi at gmail.com Mon Apr 20 16:12:36 2020 From: yousef.alhashemi at gmail.com (Yousef Alhashemi) Date: Mon, 20 Apr 2020 19:12:36 +0300 Subject: Porting OpenJFX to BSD Message-ID: Hello, How difficult would it be to port/compile the latest version of openjfx (14?) on BSD? On FreeBSD, only version 8 is available as a port/package and it's deprecated and will be removed later this year. I haven't done any large scale porting of code, but I do understand the basic concepts (using typedefs, not using compiler-specific optimizations so say gcc code can also be compiled on clang, etc). If porting to BSD is well-documented somewhere and is fairly systematic, I'd be happy to give it a shot. Any pointers are appreciated. Thanks, Yousef From org.openjdk at io7m.com Mon Apr 20 15:47:50 2020 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 20 Apr 2020 15:47:50 +0000 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: <20200420154750.7a38ec8b@sunflower.int.arc7.info> Am I missing something here? What absurd arguments are required for Maven projects? I have multiple applications here running in full module-path mode (the applications are modularized, and JavaFX is on the module path), using plain Maven builds with no special arguments, and IDEA as the IDE. This is on JDK 13, with the 13.0.2 JavaFX release from Central. -- Mark Raynsford | https://www.io7m.com From youngty1997 at gmail.com Mon Apr 20 16:37:16 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 20 Apr 2020 11:37:16 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <20200420154750.7a38ec8b@sunflower.int.arc7.info> <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> Message-ID: On 4/20/20 11:36 AM, Ty Young wrote: > > On 4/20/20 10:47 AM, Mark Raynsford wrote: >> Am I missing something here? What absurd arguments are required for >> Maven projects? >> >> I have multiple applications here running in full module-path mode (the >> applications are modularized, and JavaFX is on the module path), using >> plain Maven builds with no special arguments, and IDEA as the IDE. >> This is on JDK 13, with the 13.0.2 JavaFX release from Central. >> > > From the second warning on this page: > > > https://openjfx.io/openjfx-docs/ > > > That's the absurd part. JavaFX 14 now requires this as a JVM runtime > argument: > > > --module-path /path/to/javafx-sdk-12/lib --add-modules > javafx.controls,javafx.fxml > > > Which wasn't required before. Not only is this a PITA and confusing > but it also prevents Maven from just handling everything. Netbeans > uses a custom file for runtime arguments, which the above is added to. > Also, it gives JavaFX 12 as an example, which is wrong. It should be 14. From youngty1997 at gmail.com Mon Apr 20 16:36:05 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 20 Apr 2020 11:36:05 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <20200420154750.7a38ec8b@sunflower.int.arc7.info> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <20200420154750.7a38ec8b@sunflower.int.arc7.info> Message-ID: <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> On 4/20/20 10:47 AM, Mark Raynsford wrote: > Am I missing something here? What absurd arguments are required for > Maven projects? > > I have multiple applications here running in full module-path mode (the > applications are modularized, and JavaFX is on the module path), using > plain Maven builds with no special arguments, and IDEA as the IDE. > This is on JDK 13, with the 13.0.2 JavaFX release from Central. > From the second warning on this page: https://openjfx.io/openjfx-docs/ That's the absurd part. JavaFX 14 now requires this as a JVM runtime argument: --module-path /path/to/javafx-sdk-12/lib --add-modules javafx.controls,javafx.fxml Which wasn't required before. Not only is this a PITA and confusing but it also prevents Maven from just handling everything. Netbeans uses a custom file for runtime arguments, which the above is added to. From twitch at nervestaple.com Mon Apr 20 17:26:54 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Mon, 20 Apr 2020 13:26:54 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <035b1f84-9f13-38b1-bca4-c1e09f95bf4a@oracle.com> References: <035b1f84-9f13-38b1-bca4-c1e09f95bf4a@oracle.com> Message-ID: <325af10f-295c-58ef-bd96-28acf7a05516@nervestaple.com> I really appreciate all of the helpful comments in this thread! I have made a lot of progress on this issue, I can compile and run my application and am working on packaging. In my opinion, my big problem was that when I was compiling I wasn't setting the correct flags with `javac` and, at the same time, probably didn't have the correct flags for `java` either. To be honest I was mostly button mashing at that point in the hopes that I'd stumble across the correct combination. To get everything working I have moved to using the "mods" with `javac` and to compile and then using `jlink` build an image. After `jlink` runs I am using the `java` that is in the image directory to run the compiled "JAR" file and that is working well. I think one big hurdle here was my lack of familiarity with Java modules and how they work. While I knew that Java modules had been a thing for a while I've been working on non-Java projects and it was not at the front of my mind. While the examples on the JavaFX "Getting Started" page worked for me, I don't think I came away with a clear understanding of what the flags where actually doing and that made it a little harder to migrate that information over to my own project. My thinking is that using the "mods" will make it easier to eventually get my application packaged but I'm not entirely clear on the bit about the JavaFX runtime and if I need it at all. I don't think a discussion of the Java modules system would be appropriate on the "Getting Started" page, but maybe getting a little more into the details of which approach makes the most sense (mods vs. the SDK) in which situations would clarify some things. Thank you all for your help on this! :-) -- Miles Kevin Rushforth wrote on 4/20/2020 11:19: > That shouldn't be necessary. It's a better workaround than setting the > PATH env variable to be sure, but there is some underlying problem that > isn't yet understood. > > -- Kevin > > On 4/20/2020 8:13 AM, David Grieve wrote: >> Set? -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin >> >> For the jlink question, look at jmod. You'll use jmod to bundle up the >> dll's and whatever else you need, then jlink to create the custom >> runtime. >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Christopher Miles >> Sent: Friday, April 17, 2020 2:56 PM >> To: openjfx-dev at openjdk.java.net >> Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files >> Missing >> >> I manage a project[0]? that leverages JavaFX. It's been a while since >> I've worked on this project, almost two years. At that time JavaFX was >> bundled with the Java runtime from Oracle. The few customers I had >> would simply run the application from the bundled launcher and as long >> as they had Java installed, it would work. >> >> It's time for me to add some features to the project, I am now using >> OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the >> instructions[1] from the following URL: >> >> https://openjfx.io/openjfx-docs/#install-javafx >> >> I am on Windows and followed the instructions for that platform. >> Unfortunately, things didn't really work. The error was as follows: >> >> Graphics Device initialization failed for : d3d, sw Error initializing >> QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: >> java.lang.RuntimeException: Error initializing QuantumRend erer: no >> suitable pipeline found at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >> >> wn Source) >> >> I fussed with this and that but nothing made a difference. Eventually >> I tried adding the "bin" directory from the JavaFX distribution to my >> path. This is the entry I added to my global PATH variable: >> >> C:\Program Files\Java\javafx-sdk-14\bin >> >> Is this the right way to do this and, if so, why isn't this included >> in the directions? Is this a Windows specific issue? >> >> Also, what impact does this have on distribution of applications? >> >> Looking at the "Runtime Images" instructions, it looks like the same >> issues will be present. Those instructions use `jlink` to point to the >> JavaFX libraries and the JAVAFX modules (distributed in another >> package) but also leave off references to the DLL files in the "bin" >> directory. I am worried that I will need to have people manually >> install the OpenJavaFX distribution and add the "bin" directory to >> their path in order to run my application. Please say it's not so! >> >> Any help or pointers to additional documentation would be very much >> appreciated! I have made it over the bumps and can now continue >> development of my application, my next concern is distributing it to >> customers. >> >> -- >> Miles >> >> [0]: https://github.com/cmiles74/xmltool >> [1]: https://openjfx.io/openjfx-docs/#install-javafx > From mp at jugs.org Mon Apr 20 17:29:26 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 19:29:26 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> Message-ID: The Android/iOS work is based on GraalVMs Native Image which has some limitations. These can be found here: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md I stumbled over the problem with Method Handles when I tried to integrate some third-party software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and fixed the problems in NSMenuFX.) Am 20.04.20 um 15:26 schrieb Rony G. Flatscher: > On 20.04.2020 15:06, Michael Paus wrote: >> This is deviating quite a bit from the original issue of this thread, isn't it? >> >> As a side note: MethodHandles are not supported by GraalVM native image >> and so this would probably collide with the attempts to get JavaFX running >> on Android/iOS. > Would you have some link where there would be a technical overview about how Java and JavaFX support > gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on > that platform, ie. is java.lang.reflect available? > > ---rony > > From mp at jugs.org Mon Apr 20 17:31:19 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 19:31:19 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Message-ID: <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Oh I see. You? are obviously not familiar with the fact that the JDK has a built-in test which checks whether the JavaFX graphics module is on the module path when you try to launch an application main class which is derived from the JavaFX Application class. If you try this and the graphics module is not on the module path the launch will fail with an error message. That's the only reason why JavaFX programs cannot be launched completely on the classpath and that's where all the trouble starts. If you circumvent this test with the trick, I have mentioned before, everything becomes nice and easy. So for me there are only two questions. 1. Is there any proof of a technical reason why JavaFX could not run correctly on the classpath? 2. If there is no such reason, then why do we torture all the newbies with the "intricacies" of the module system instead of just removing this barrier? As I said before, I have not found any such problem in all the time since JavaFX was separated from the JDK, so this test seems to be quite artificial to me but of course I may be wrong. That's why I asked here. Am 20.04.20 um 17:25 schrieb Ty Young: > > I'm a bit confused here. if you don't want JPMS then you should be > able to run everything on the classpath like normal. Netbeans at least > doesn't force modules wtih Maven. Or is reflection disabled on > classpath as of Java 9 too unless you have a module-info? > > >> >> Michael >> >> Am 18.04.20 um 12:58 schrieb Ty Young: >>> >>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>> Getting started with JavaFX is made overly complicated by the fact >>>> that the use of the >>>> module system is enforced by some code in the JDK. Especially for >>>> beginners, who just >>>> want to get some small program running, this is almost always a big >>>> source of frustration. >>>> It is not very good marketing for JavaFX to make these initial >>>> steps such a pain. If you >>>> need some evidence for this statement, then just follow JavaFX on >>>> Stackoverflow or similar >>>> sites (and also this mailing list). Almost every day you can read >>>> frustrated posts from >>>> helpless people who would just like to get some JavaFX project >>>> running but are failing >>>> because they get lost in the module system jungle. >>> >>> >>> Speaking as a long time JavaFX user(literally since Java 8), I have >>> mostly disagree that the JPMS is hurting JavaFX. >>> >>> >>> That said, I don't think the frustration is misplaced. What you say >>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>> user is *NOT* to be blamed here. >>> >>> >>> Rather, I think what's to blame is poor documentation, JavaFX >>> requiring absurd runtime module VM arguments, and? poor/buggy IDE >>> support. >>> >>> >>> Starting with documentation, JavaFX uses reflection for things like >>> TableView(everyone's favorite) and CSS style sheets. While this may >>> be obvious for people who are more experienced, those who are not >>> may be very confused when they get an onslaught of error messages >>> regarding reflection. Better documentation on what requires >>> reflection, why, and how to enable it would be useful. >>> >>> >>> Likewise, the notice about having to include javafx.graphics to the >>> runtime module arguments here: >>> >>> >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>> >>> >>> Apply to Maven as well, but it's under Ant for some reason. I don't >>> know what was changed in JavaFX 14 that now suddenly requires a >>> runtime VM argument, but it's a PITA and BS. End users are going to >>> struggle with this, and it prevents JavaFX runtime from being purely >>> managed by Maven. No other JavaFX version requires this, so it's >>> mind boggling that all of a sudden JavaFX needs this. >>> >>> >>> Poor/buggy IDE support is really the big one here. I don't know >>> about other IDEs but Netbeans DOES NOT provide a project template >>> for creating a JavaFX application with setup dependencies. Netbeans, >>> when setup with a Maven project, allows you to select an entire >>> project(pom) rather than the individual dependencies(jar) which >>> doesn't work. What you search for also matters: if you search for >>> "JavaFX" you will get the wrong search results. You need to search >>> for "openjfx" which can be confusing. >>> >>> >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>> projects and Netbeans because JavaFX puts its src.zip in a folder >>> that is supposed to only include the runtime library that has >>> existed for years(literally a 1 line fix too). No one really uses >>> Ant anymore so it's probably not a big deal now but yeah, getting >>> JavaFX working hasn't been "include and done" when it could >>> potentially be that way. >>> >> From alexander.scherbatiy at bell-sw.com Mon Apr 20 18:15:48 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Mon, 20 Apr 2020 21:15:48 +0300 Subject: JavaFX controls have large size on Raspberry Pi Message-ID: <82483b58-595a-b407-28af-ea6b344eae38@bell-sw.com> Hello, I run a simple JavaFX application which shows a button with jdk 14.0.1 on Raspberry Pi and the drawn button has large size. This is because of the algorithm which is used by PrismFontFactory.getSystemFontSize() method [1] to select a system font size. If a system is embedded then the font size is calculated as ??? int screenDPI = Screen.getMainScreen().getResolutionY(); ??? systemFontSize = ((float) screenDPI) / 6f; // 12 points and the system is detected as embedded because the armv6hf architecture is defined as embedded in the armv6hf.gradle file [2]. Raspberri Pi can work both with small touch displays and with big monitors. It looks like Raspberry Pi should support two modes for font size calculation: one for small screens and another for large. I would like to contribute a fix for this but I do not know how the right fix could look like. Should there be a special screen size so for smaller screens the font is is proportional to the screen size and for bigger screens the font size is fixed? Is there a way to check that used screen is from embedded device? May be it should be solved in different way? [1] https://github.com/openjdk/jfx/blob/ec8608f39576035d41e8e532e9334b979b859543/modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java#L1944 [2] https://github.com/openjdk/jfx/blob/ec8608f39576035d41e8e532e9334b979b859543/buildSrc/armv6hf.gradle#L182 JavaFX application: ---------------------------- import javafx.application.Application; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class ButtonFX extends Application { ??? public static void main(String[] args) { ??????? launch(args); ??? } ??? @Override ??? public void start(Stage primaryStage) { ??????? primaryStage.setTitle("Hello World!"); ??? Button button = new Button("Hello, World!"); ??????? StackPane root = new StackPane(); ??????? root.getChildren().add(button); ??????? primaryStage.setScene(new Scene(root, 300, 250)); ??????? primaryStage.show(); ??? } } ---------------------------- Thanks, Alexander. From bruno.borges at gmail.com Mon Apr 20 18:18:40 2020 From: bruno.borges at gmail.com (Bruno Borges) Date: Mon, 20 Apr 2020 11:18:40 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: I do wonder why isn't JavaFX in a single module, like Swing? For Java developers to build Swing apps, all they need is a "requires java.desktop". But for JavaFX, there are multiple modules. --- *Bruno Borges* brunoborges.io On Mon, Apr 20, 2020 at 10:36 AM Michael Paus wrote: > Oh I see. You are obviously not familiar with the fact that the JDK has > a built-in test > which checks whether the JavaFX graphics module is on the module path > when you > try to launch an application main class which is derived from the JavaFX > Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs cannot > be launched > completely on the classpath and that's where all the trouble starts. If > you circumvent this > test with the trick, I have mentioned before, everything becomes nice > and easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies > with the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time > since JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > I'm a bit confused here. if you don't want JPMS then you should be > > able to run everything on the classpath like normal. Netbeans at least > > doesn't force modules wtih Maven. Or is reflection disabled on > > classpath as of Java 9 too unless you have a module-info? > > > > > >> > >> Michael > >> > >> Am 18.04.20 um 12:58 schrieb Ty Young: > >>> > >>> On 4/18/20 5:01 AM, Michael Paus wrote: > >>>> Getting started with JavaFX is made overly complicated by the fact > >>>> that the use of the > >>>> module system is enforced by some code in the JDK. Especially for > >>>> beginners, who just > >>>> want to get some small program running, this is almost always a big > >>>> source of frustration. > >>>> It is not very good marketing for JavaFX to make these initial > >>>> steps such a pain. If you > >>>> need some evidence for this statement, then just follow JavaFX on > >>>> Stackoverflow or similar > >>>> sites (and also this mailing list). Almost every day you can read > >>>> frustrated posts from > >>>> helpless people who would just like to get some JavaFX project > >>>> running but are failing > >>>> because they get lost in the module system jungle. > >>> > >>> > >>> Speaking as a long time JavaFX user(literally since Java 8), I have > >>> mostly disagree that the JPMS is hurting JavaFX. > >>> > >>> > >>> That said, I don't think the frustration is misplaced. What you say > >>> is true(Netbeans mailing list is fill of JavaFX issues) and the end > >>> user is *NOT* to be blamed here. > >>> > >>> > >>> Rather, I think what's to blame is poor documentation, JavaFX > >>> requiring absurd runtime module VM arguments, and poor/buggy IDE > >>> support. > >>> > >>> > >>> Starting with documentation, JavaFX uses reflection for things like > >>> TableView(everyone's favorite) and CSS style sheets. While this may > >>> be obvious for people who are more experienced, those who are not > >>> may be very confused when they get an onslaught of error messages > >>> regarding reflection. Better documentation on what requires > >>> reflection, why, and how to enable it would be useful. > >>> > >>> > >>> Likewise, the notice about having to include javafx.graphics to the > >>> runtime module arguments here: > >>> > >>> > >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans > >>> > >>> > >>> Apply to Maven as well, but it's under Ant for some reason. I don't > >>> know what was changed in JavaFX 14 that now suddenly requires a > >>> runtime VM argument, but it's a PITA and BS. End users are going to > >>> struggle with this, and it prevents JavaFX runtime from being purely > >>> managed by Maven. No other JavaFX version requires this, so it's > >>> mind boggling that all of a sudden JavaFX needs this. > >>> > >>> > >>> Poor/buggy IDE support is really the big one here. I don't know > >>> about other IDEs but Netbeans DOES NOT provide a project template > >>> for creating a JavaFX application with setup dependencies. Netbeans, > >>> when setup with a Maven project, allows you to select an entire > >>> project(pom) rather than the individual dependencies(jar) which > >>> doesn't work. What you search for also matters: if you search for > >>> "JavaFX" you will get the wrong search results. You need to search > >>> for "openjfx" which can be confusing. > >>> > >>> > >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based > >>> projects and Netbeans because JavaFX puts its src.zip in a folder > >>> that is supposed to only include the runtime library that has > >>> existed for years(literally a 1 line fix too). No one really uses > >>> Ant anymore so it's probably not a big deal now but yeah, getting > >>> JavaFX working hasn't been "include and done" when it could > >>> potentially be that way. > >>> > >> > > > From mp at jugs.org Mon Apr 20 18:36:44 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 20:36:44 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <3d3de6ba-27cd-254a-dd7a-583e161cc780@jugs.org> Hi Bruno I actually like the fact that JavaFX has been split up into some smaller parts. E.g., javafx.web is the biggest moster in this context and if you do not really need it, it is nice that you leave it out. Also media, swing and fxml are not always needed and so you can leave them out. I even have cases where I only allow javafx.base because that is all you need to write your view-models and it is good that you can explicitly separate that from all the graphics and control stuff. So I have absolutely no problem with that kind of modularization. Michael Am 20.04.20 um 20:18 schrieb Bruno Borges: > I do wonder why isn't JavaFX in a single module, like Swing? > > For Java developers to build Swing apps, all they need is a "requires > java.desktop". > > But for JavaFX, there are multiple modules. > > --- > *Bruno Borges* > brunoborges.io > > > On Mon, Apr 20, 2020 at 10:36 AM Michael Paus > wrote: > > Oh I see. You? are obviously not familiar with the fact that the > JDK has > a built-in test > which checks whether the JavaFX graphics module is on the module path > when you > try to launch an application main class which is derived from the > JavaFX > Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs > cannot > be launched > completely on the classpath and that's where all the trouble > starts. If > you circumvent this > test with the trick, I have mentioned before, everything becomes nice > and easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies > with the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time > since JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > I'm a bit confused here. if you don't want JPMS then you should be > > able to run everything on the classpath like normal. Netbeans at > least > > doesn't force modules wtih Maven. Or is reflection disabled on > > classpath as of Java 9 too unless you have a module-info? > > > > > >> > >> Michael > >> > >> Am 18.04.20 um 12:58 schrieb Ty Young: > >>> > >>> On 4/18/20 5:01 AM, Michael Paus wrote: > >>>> Getting started with JavaFX is made overly complicated by the > fact > >>>> that the use of the > >>>> module system is enforced by some code in the JDK. Especially > for > >>>> beginners, who just > >>>> want to get some small program running, this is almost always > a big > >>>> source of frustration. > >>>> It is not very good marketing for JavaFX to make these initial > >>>> steps such a pain. If you > >>>> need some evidence for this statement, then just follow > JavaFX on > >>>> Stackoverflow or similar > >>>> sites (and also this mailing list). Almost every day you can > read > >>>> frustrated posts from > >>>> helpless people who would just like to get some JavaFX project > >>>> running but are failing > >>>> because they get lost in the module system jungle. > >>> > >>> > >>> Speaking as a long time JavaFX user(literally since Java 8), I > have > >>> mostly disagree that the JPMS is hurting JavaFX. > >>> > >>> > >>> That said, I don't think the frustration is misplaced. What > you say > >>> is true(Netbeans mailing list is fill of JavaFX issues) and > the end > >>> user is *NOT* to be blamed here. > >>> > >>> > >>> Rather, I think what's to blame is poor documentation, JavaFX > >>> requiring absurd runtime module VM arguments, and? poor/buggy IDE > >>> support. > >>> > >>> > >>> Starting with documentation, JavaFX uses reflection for things > like > >>> TableView(everyone's favorite) and CSS style sheets. While > this may > >>> be obvious for people who are more experienced, those who are not > >>> may be very confused when they get an onslaught of error messages > >>> regarding reflection. Better documentation on what requires > >>> reflection, why, and how to enable it would be useful. > >>> > >>> > >>> Likewise, the notice about having to include javafx.graphics > to the > >>> runtime module arguments here: > >>> > >>> > >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans > >>> > >>> > >>> Apply to Maven as well, but it's under Ant for some reason. I > don't > >>> know what was changed in JavaFX 14 that now suddenly requires a > >>> runtime VM argument, but it's a PITA and BS. End users are > going to > >>> struggle with this, and it prevents JavaFX runtime from being > purely > >>> managed by Maven. No other JavaFX version requires this, so it's > >>> mind boggling that all of a sudden JavaFX needs this. > >>> > >>> > >>> Poor/buggy IDE support is really the big one here. I don't know > >>> about other IDEs but Netbeans DOES NOT provide a project template > >>> for creating a JavaFX application with setup dependencies. > Netbeans, > >>> when setup with a Maven project, allows you to select an entire > >>> project(pom) rather than the individual dependencies(jar) which > >>> doesn't work. What you search for also matters: if you search for > >>> "JavaFX" you will get the wrong search results. You need to > search > >>> for "openjfx" which can be confusing. > >>> > >>> > >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based > >>> projects and Netbeans because JavaFX puts its src.zip in a folder > >>> that is supposed to only include the runtime library that has > >>> existed for years(literally a 1 line fix too). No one really uses > >>> Ant anymore so it's probably not a big deal now but yeah, getting > >>> JavaFX working hasn't been "include and done" when it could > >>> potentially be that way. > >>> > >> > > From philip.race at oracle.com Mon Apr 20 18:52:49 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 Apr 2020 11:52:49 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <5E9DEF81.6000401@oracle.com> On 4/20/20, 11:18 AM, Bruno Borges wrote: > I do wonder why isn't JavaFX in a single module, like Swing? > > > For Java developers to build Swing apps, all they need is a "requires > java.desktop". Well it isn't because we wanted to do that for Swing. It is because it was too hard to decompose it because of interdependencies between AWT and Swing and 2D. For example AWT + 2D APIs are in the same java.awt package. And Swing is the 99% use case so it would have amounted to using all of the same anyway. But even if it could have been done likely we would still have had an aggregator module to make it easy. Note that java.datatransfer is required by java.desktop. -phil. > But for JavaFX, there are multiple modules. > > --- > *Bruno Borges* > brunoborges.io > > > On Mon, Apr 20, 2020 at 10:36 AM Michael Paus wrote: > >> Oh I see. You are obviously not familiar with the fact that the JDK has >> a built-in test >> which checks whether the JavaFX graphics module is on the module path >> when you >> try to launch an application main class which is derived from the JavaFX >> Application class. >> If you try this and the graphics module is not on the module path the >> launch will fail >> with an error message. That's the only reason why JavaFX programs cannot >> be launched >> completely on the classpath and that's where all the trouble starts. If >> you circumvent this >> test with the trick, I have mentioned before, everything becomes nice >> and easy. >> >> So for me there are only two questions. >> 1. Is there any proof of a technical reason why JavaFX could not run >> correctly on the classpath? >> 2. If there is no such reason, then why do we torture all the newbies >> with the "intricacies" of the >> module system instead of just removing this barrier? >> >> As I said before, I have not found any such problem in all the time >> since JavaFX was separated >> from the JDK, so this test seems to be quite artificial to me but of >> course I may be wrong. That's >> why I asked here. >> >> Am 20.04.20 um 17:25 schrieb Ty Young: >>> I'm a bit confused here. if you don't want JPMS then you should be >>> able to run everything on the classpath like normal. Netbeans at least >>> doesn't force modules wtih Maven. Or is reflection disabled on >>> classpath as of Java 9 too unless you have a module-info? >>> >>> >>>> Michael >>>> >>>> Am 18.04.20 um 12:58 schrieb Ty Young: >>>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>>>> Getting started with JavaFX is made overly complicated by the fact >>>>>> that the use of the >>>>>> module system is enforced by some code in the JDK. Especially for >>>>>> beginners, who just >>>>>> want to get some small program running, this is almost always a big >>>>>> source of frustration. >>>>>> It is not very good marketing for JavaFX to make these initial >>>>>> steps such a pain. If you >>>>>> need some evidence for this statement, then just follow JavaFX on >>>>>> Stackoverflow or similar >>>>>> sites (and also this mailing list). Almost every day you can read >>>>>> frustrated posts from >>>>>> helpless people who would just like to get some JavaFX project >>>>>> running but are failing >>>>>> because they get lost in the module system jungle. >>>>> >>>>> Speaking as a long time JavaFX user(literally since Java 8), I have >>>>> mostly disagree that the JPMS is hurting JavaFX. >>>>> >>>>> >>>>> That said, I don't think the frustration is misplaced. What you say >>>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>>>> user is *NOT* to be blamed here. >>>>> >>>>> >>>>> Rather, I think what's to blame is poor documentation, JavaFX >>>>> requiring absurd runtime module VM arguments, and poor/buggy IDE >>>>> support. >>>>> >>>>> >>>>> Starting with documentation, JavaFX uses reflection for things like >>>>> TableView(everyone's favorite) and CSS style sheets. While this may >>>>> be obvious for people who are more experienced, those who are not >>>>> may be very confused when they get an onslaught of error messages >>>>> regarding reflection. Better documentation on what requires >>>>> reflection, why, and how to enable it would be useful. >>>>> >>>>> >>>>> Likewise, the notice about having to include javafx.graphics to the >>>>> runtime module arguments here: >>>>> >>>>> >>>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>>>> >>>>> >>>>> Apply to Maven as well, but it's under Ant for some reason. I don't >>>>> know what was changed in JavaFX 14 that now suddenly requires a >>>>> runtime VM argument, but it's a PITA and BS. End users are going to >>>>> struggle with this, and it prevents JavaFX runtime from being purely >>>>> managed by Maven. No other JavaFX version requires this, so it's >>>>> mind boggling that all of a sudden JavaFX needs this. >>>>> >>>>> >>>>> Poor/buggy IDE support is really the big one here. I don't know >>>>> about other IDEs but Netbeans DOES NOT provide a project template >>>>> for creating a JavaFX application with setup dependencies. Netbeans, >>>>> when setup with a Maven project, allows you to select an entire >>>>> project(pom) rather than the individual dependencies(jar) which >>>>> doesn't work. What you search for also matters: if you search for >>>>> "JavaFX" you will get the wrong search results. You need to search >>>>> for "openjfx" which can be confusing. >>>>> >>>>> >>>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>>>> projects and Netbeans because JavaFX puts its src.zip in a folder >>>>> that is supposed to only include the runtime library that has >>>>> existed for years(literally a 1 line fix too). No one really uses >>>>> Ant anymore so it's probably not a big deal now but yeah, getting >>>>> JavaFX working hasn't been "include and done" when it could >>>>> potentially be that way. >>>>> >> >> From mailinglist2020 at protonmail.com Mon Apr 20 19:28:55 2020 From: mailinglist2020 at protonmail.com (Mailing User) Date: Mon, 20 Apr 2020 19:28:55 +0000 Subject: Is it possible to customise the theme of the Scene Builder itself? Message-ID: I have downloaded the latest version from a website called Gluon or something. The problem is that the default theme lacks contrast. It looks like grey text on light grey background. Also the font is too small for me. In File -> Preferences, I can see "Scene Builder Theme", but it only has two themes: Default and Dark. The Dark theme also lacks contrast. It looks like grey text on dark grey background. Is there any way to change the colours or the font size of Scene Builder itself, NOT the scene of my application that I am editing with Scene Builder? From David.Grieve at microsoft.com Mon Apr 20 20:13:49 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Mon, 20 Apr 2020 20:13:49 +0000 Subject: Is it possible to customise the theme of the Scene Builder itself? Message-ID: This is probably not the right forum for this question. Try a forum like stackoverflow. Or reach out to great people at Gluon. The short answer, however, is that you can play with the CSS styles that make up the theme. You'd either need to update the stylesheets in the jar or build scene builder yourself. -----Original Message----- From: openjfx-dev On Behalf Of Mailing User Sent: Monday, April 20, 2020 3:29 PM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Is it possible to customise the theme of the Scene Builder itself? I have downloaded the latest version from a website called Gluon or something. The problem is that the default theme lacks contrast. It looks like grey text on light grey background. Also the font is too small for me. In File -> Preferences, I can see "Scene Builder Theme", but it only has two themes: Default and Dark. The Dark theme also lacks contrast. It looks like grey text on dark grey background. Is there any way to change the colours or the font size of Scene Builder itself, NOT the scene of my application that I am editing with Scene Builder? From David.Grieve at microsoft.com Mon Apr 20 20:25:17 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Mon, 20 Apr 2020 20:25:17 +0000 Subject: JavaFX controls have large size on Raspberry Pi Message-ID: The sizes of controls are controlled by CSS styles. Things like borders, backgrounds, padding, insets, all of that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning they are relative to the size of the font. JavaFX CSS will use the Font.getDefault() font size if there is no font explicitly set in either the styles or in the application code. I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. It could also be an issue with the default stylesheets themselves. -----Original Message----- From: openjfx-dev On Behalf Of Alexander Scherbatiy Sent: Monday, April 20, 2020 2:16 PM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi Hello, I run a simple JavaFX application which shows a button with jdk 14.0.1 on Raspberry Pi and the drawn button has large size. This is because of the algorithm which is used by PrismFontFactory.getSystemFontSize() method [1] to select a system font size. If a system is embedded then the font size is calculated as ??? int screenDPI = Screen.getMainScreen().getResolutionY(); ??? systemFontSize = ((float) screenDPI) / 6f; // 12 points and the system is detected as embedded because the armv6hf architecture is defined as embedded in the armv6hf.gradle file [2]. Raspberri Pi can work both with small touch displays and with big monitors. It looks like Raspberry Pi should support two modes for font size calculation: one for small screens and another for large. I would like to contribute a fix for this but I do not know how the right fix could look like. Should there be a special screen size so for smaller screens the font is is proportional to the screen size and for bigger screens the font size is fixed? Is there a way to check that used screen is from embedded device? May be it should be solved in different way? [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 JavaFX application: ---------------------------- import javafx.application.Application; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class ButtonFX extends Application { ??? public static void main(String[] args) { ??????? launch(args); ??? } ??? @Override ??? public void start(Stage primaryStage) { ??????? primaryStage.setTitle("Hello World!"); ??? Button button = new Button("Hello, World!"); ??????? StackPane root = new StackPane(); ??????? root.getChildren().add(button); ??????? primaryStage.setScene(new Scene(root, 300, 250)); ??????? primaryStage.show(); ??? } } ---------------------------- Thanks, Alexander. From tbee at tbee.org Mon Apr 20 20:33:58 2020 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 20 Apr 2020 22:33:58 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <8826d71f-1f8c-0c56-8aca-3d0b706e5722@tbee.org> JFXtras is split in many modules as well, the question is if it really is that important to do. Splitting up in jars -so you don't need to include what is not needed- is good, but whether they need to be modules... The way I see it is that JPMS requires the same amount of effort as OSGi for example, but does not provide the same functionality (most importantly class load separation) and thus is simply less worthwhile. So either 'we' start adding that last piece (I recently learned there is such a thing as JPMS layers, which provides for that), or it probably will stay a Java core thing only. Regards, Tom On 20-4-2020 20:18, Bruno Borges wrote: > I do wonder why isn't JavaFX in a single module, like Swing? > > > For Java developers to build Swing apps, all they need is a "requires > java.desktop". > > But for JavaFX, there are multiple modules. > > --- > *Bruno Borges* > brunoborges.io > > > On Mon, Apr 20, 2020 at 10:36 AM Michael Paus wrote: > >> Oh I see. You are obviously not familiar with the fact that the JDK has >> a built-in test >> which checks whether the JavaFX graphics module is on the module path >> when you >> try to launch an application main class which is derived from the JavaFX >> Application class. >> If you try this and the graphics module is not on the module path the >> launch will fail >> with an error message. That's the only reason why JavaFX programs cannot >> be launched >> completely on the classpath and that's where all the trouble starts. If >> you circumvent this >> test with the trick, I have mentioned before, everything becomes nice >> and easy. >> >> So for me there are only two questions. >> 1. Is there any proof of a technical reason why JavaFX could not run >> correctly on the classpath? >> 2. If there is no such reason, then why do we torture all the newbies >> with the "intricacies" of the >> module system instead of just removing this barrier? >> >> As I said before, I have not found any such problem in all the time >> since JavaFX was separated >> from the JDK, so this test seems to be quite artificial to me but of >> course I may be wrong. That's >> why I asked here. >> >> Am 20.04.20 um 17:25 schrieb Ty Young: >>> I'm a bit confused here. if you don't want JPMS then you should be >>> able to run everything on the classpath like normal. Netbeans at least >>> doesn't force modules wtih Maven. Or is reflection disabled on >>> classpath as of Java 9 too unless you have a module-info? >>> >>> >>>> Michael >>>> >>>> Am 18.04.20 um 12:58 schrieb Ty Young: >>>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>>>> Getting started with JavaFX is made overly complicated by the fact >>>>>> that the use of the >>>>>> module system is enforced by some code in the JDK. Especially for >>>>>> beginners, who just >>>>>> want to get some small program running, this is almost always a big >>>>>> source of frustration. >>>>>> It is not very good marketing for JavaFX to make these initial >>>>>> steps such a pain. If you >>>>>> need some evidence for this statement, then just follow JavaFX on >>>>>> Stackoverflow or similar >>>>>> sites (and also this mailing list). Almost every day you can read >>>>>> frustrated posts from >>>>>> helpless people who would just like to get some JavaFX project >>>>>> running but are failing >>>>>> because they get lost in the module system jungle. >>>>> >>>>> Speaking as a long time JavaFX user(literally since Java 8), I have >>>>> mostly disagree that the JPMS is hurting JavaFX. >>>>> >>>>> >>>>> That said, I don't think the frustration is misplaced. What you say >>>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>>>> user is *NOT* to be blamed here. >>>>> >>>>> >>>>> Rather, I think what's to blame is poor documentation, JavaFX >>>>> requiring absurd runtime module VM arguments, and poor/buggy IDE >>>>> support. >>>>> >>>>> >>>>> Starting with documentation, JavaFX uses reflection for things like >>>>> TableView(everyone's favorite) and CSS style sheets. While this may >>>>> be obvious for people who are more experienced, those who are not >>>>> may be very confused when they get an onslaught of error messages >>>>> regarding reflection. Better documentation on what requires >>>>> reflection, why, and how to enable it would be useful. >>>>> >>>>> >>>>> Likewise, the notice about having to include javafx.graphics to the >>>>> runtime module arguments here: >>>>> >>>>> >>>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>>>> >>>>> >>>>> Apply to Maven as well, but it's under Ant for some reason. I don't >>>>> know what was changed in JavaFX 14 that now suddenly requires a >>>>> runtime VM argument, but it's a PITA and BS. End users are going to >>>>> struggle with this, and it prevents JavaFX runtime from being purely >>>>> managed by Maven. No other JavaFX version requires this, so it's >>>>> mind boggling that all of a sudden JavaFX needs this. >>>>> >>>>> >>>>> Poor/buggy IDE support is really the big one here. I don't know >>>>> about other IDEs but Netbeans DOES NOT provide a project template >>>>> for creating a JavaFX application with setup dependencies. Netbeans, >>>>> when setup with a Maven project, allows you to select an entire >>>>> project(pom) rather than the individual dependencies(jar) which >>>>> doesn't work. What you search for also matters: if you search for >>>>> "JavaFX" you will get the wrong search results. You need to search >>>>> for "openjfx" which can be confusing. >>>>> >>>>> >>>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>>>> projects and Netbeans because JavaFX puts its src.zip in a folder >>>>> that is supposed to only include the runtime library that has >>>>> existed for years(literally a 1 line fix too). No one really uses >>>>> Ant anymore so it's probably not a big deal now but yeah, getting >>>>> JavaFX working hasn't been "include and done" when it could >>>>> potentially be that way. >>>>> >> >> From kevin.rushforth at oracle.com Mon Apr 20 20:56:44 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 13:56:44 -0700 Subject: JavaFX controls have large size on Raspberry Pi In-Reply-To: References: Message-ID: <8343639b-c75e-0e72-3420-62100b60bdc4@oracle.com> Another thing to check is that the reported DPI of the screen is correct. -- Kevin On 4/20/2020 1:25 PM, David Grieve wrote: > The sizes of controls are controlled by CSS styles. Things like borders, backgrounds, padding, insets, all of > that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning they are relative to the size > of the font. JavaFX CSS will use the Font.getDefault() font size if there is no font explicitly set in either the > styles or in the application code. > > I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. > It could also be an issue with the default stylesheets themselves. > > -----Original Message----- > From: openjfx-dev On Behalf Of Alexander Scherbatiy > Sent: Monday, April 20, 2020 2:16 PM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi > > Hello, > > I run a simple JavaFX application which shows a button with jdk 14.0.1 on Raspberry Pi and the drawn button has large size. > > This is because of the algorithm which is used by > PrismFontFactory.getSystemFontSize() method [1] to select a system font size. > If a system is embedded then the font size is calculated as > > ??? int screenDPI = Screen.getMainScreen().getResolutionY(); > ??? systemFontSize = ((float) screenDPI) / 6f; // 12 points > > and the system is detected as embedded because the armv6hf architecture is defined as embedded in the armv6hf.gradle file [2]. > > Raspberri Pi can work both with small touch displays and with big monitors. It looks like Raspberry Pi should support two modes for font size calculation: one for small screens and another for large. > > I would like to contribute a fix for this but I do not know how the right fix could look like. > Should there be a special screen size so for smaller screens the font is is proportional to the screen size and for bigger screens the font size is fixed? > Is there a way to check that used screen is from embedded device? > May be it should be solved in different way? > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 > [2] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 > > JavaFX application: > ---------------------------- > import javafx.application.Application; > import javafx.event.ActionEvent; > import javafx.event.EventHandler; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.layout.StackPane; > import javafx.stage.Stage; > > public class ButtonFX extends Application { > ??? public static void main(String[] args) { > ??????? launch(args); > ??? } > > ??? @Override > ??? public void start(Stage primaryStage) { > ??????? primaryStage.setTitle("Hello World!"); > ??? Button button = new Button("Hello, World!"); > > ??????? StackPane root = new StackPane(); > ??????? root.getChildren().add(button); > ??????? primaryStage.setScene(new Scene(root, 300, 250)); > ??????? primaryStage.show(); > ??? } > } > ---------------------------- > > Thanks, > Alexander. > > From philip.race at oracle.com Mon Apr 20 21:18:37 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 Apr 2020 14:18:37 -0700 Subject: JavaFX controls have large size on Raspberry Pi In-Reply-To: <8343639b-c75e-0e72-3420-62100b60bdc4@oracle.com> References: <8343639b-c75e-0e72-3420-62100b60bdc4@oracle.com> Message-ID: <5E9E11AD.3070901@oracle.com> > I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. I think the code below is the code that decides what the code above should return > Another thing to check is that the reported DPI of the screen is correct. The way I read the code below is that it wants the default font to be 1/6 of an inch high on the screen. I think any smaller than 6 lines per inch and it will be hard to read. To do this correctly, it relies on the y-res being accurate for the device. So I would follow the path Kevin suggests. For example if something is wrongly returning the *dimension* of the screen when it should be the *dpi* of the screen then you'd have 6 lines of text filling up the screen. -phil. On 4/20/20, 1:56 PM, Kevin Rushforth wrote: > Another thing to check is that the reported DPI of the screen is correct. > > -- Kevin > > > On 4/20/2020 1:25 PM, David Grieve wrote: >> The sizes of controls are controlled by CSS styles. Things like >> borders, backgrounds, padding, insets, all of >> that defaults to the styles in a stylesheet. Most sizes are 'em' >> units, meaning they are relative to the size >> of the font. JavaFX CSS will use the Font.getDefault() font size if >> there is no font explicitly set in either the >> styles or in the application code. >> >> I would start by looking at what Font.getDefault().getSize() returns >> since everything should be based off that. >> It could also be an issue with the default stylesheets themselves. >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Alexander Scherbatiy >> Sent: Monday, April 20, 2020 2:16 PM >> To: openjfx-dev at openjdk.java.net >> Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi >> >> Hello, >> >> I run a simple JavaFX application which shows a button with jdk >> 14.0.1 on Raspberry Pi and the drawn button has large size. >> >> This is because of the algorithm which is used by >> PrismFontFactory.getSystemFontSize() method [1] to select a system >> font size. >> If a system is embedded then the font size is calculated as >> >> int screenDPI = Screen.getMainScreen().getResolutionY(); >> systemFontSize = ((float) screenDPI) / 6f; // 12 points >> >> and the system is detected as embedded because the armv6hf >> architecture is defined as embedded in the armv6hf.gradle file [2]. >> >> Raspberri Pi can work both with small touch displays and with big >> monitors. It looks like Raspberry Pi should support two modes for >> font size calculation: one for small screens and another for large. >> >> I would like to contribute a fix for this but I do not know how the >> right fix could look like. >> Should there be a special screen size so for smaller screens the font >> is is proportional to the screen size and for bigger screens the font >> size is fixed? >> Is there a way to check that used screen is from embedded device? >> May be it should be solved in different way? >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 >> >> [2] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 >> >> >> JavaFX application: >> ---------------------------- >> import javafx.application.Application; >> import javafx.event.ActionEvent; >> import javafx.event.EventHandler; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.StackPane; >> import javafx.stage.Stage; >> >> public class ButtonFX extends Application { >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) { >> primaryStage.setTitle("Hello World!"); >> Button button = new Button("Hello, World!"); >> >> StackPane root = new StackPane(); >> root.getChildren().add(button); >> primaryStage.setScene(new Scene(root, 300, 250)); >> primaryStage.show(); >> } >> } >> ---------------------------- >> >> Thanks, >> Alexander. >> >> > From kevin.rushforth at oracle.com Mon Apr 20 22:54:22 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 15:54:22 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> As of JDK 9, there are a few places in JavaFX that assume the JavaFX modules are, in fact modules. While it would likely be technically possible to find them all, and make modifications that will allow running JavaFX either on the classpath or on the module path, I am not in favor of that. I think it would be a step backwards. For one thing, we would lose the encapsulation that the module system provides, and applications would be able to access internal packages without so much as a warning that it's not public API. Also it would increase the testing burden, since that would be one more mode in which it would need to be tested to ensure that it doesn't break. I tend to agree with those who say that this is mostly a documentation issue. I suppose it's also a bit of a tooling problem, since first class support for modules is still in progress in various IDEs and build tools (gradle, maven, etc). The support in the IDEs is pretty good now, and gradle 6.4 reportedly has full support for modules. Someone with more familiarity with Maven can comment about their module support. -- Kevin On 4/20/2020 10:31 AM, Michael Paus wrote: > Oh I see. You? are obviously not familiar with the fact that the JDK > has a built-in test > which checks whether the JavaFX graphics module is on the module path > when you > try to launch an application main class which is derived from the > JavaFX Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs > cannot be launched > completely on the classpath and that's where all the trouble starts. > If you circumvent this > test with the trick, I have mentioned before, everything becomes nice > and easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies > with the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time > since JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: >> >> I'm a bit confused here. if you don't want JPMS then you should be >> able to run everything on the classpath like normal. Netbeans at >> least doesn't force modules wtih Maven. Or is reflection disabled on >> classpath as of Java 9 too unless you have a module-info? >> >> >>> >>> Michael >>> >>> Am 18.04.20 um 12:58 schrieb Ty Young: >>>> >>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>>> Getting started with JavaFX is made overly complicated by the fact >>>>> that the use of the >>>>> module system is enforced by some code in the JDK. Especially for >>>>> beginners, who just >>>>> want to get some small program running, this is almost always a >>>>> big source of frustration. >>>>> It is not very good marketing for JavaFX to make these initial >>>>> steps such a pain. If you >>>>> need some evidence for this statement, then just follow JavaFX on >>>>> Stackoverflow or similar >>>>> sites (and also this mailing list). Almost every day you can read >>>>> frustrated posts from >>>>> helpless people who would just like to get some JavaFX project >>>>> running but are failing >>>>> because they get lost in the module system jungle. >>>> >>>> >>>> Speaking as a long time JavaFX user(literally since Java 8), I have >>>> mostly disagree that the JPMS is hurting JavaFX. >>>> >>>> >>>> That said, I don't think the frustration is misplaced. What you say >>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>>> user is *NOT* to be blamed here. >>>> >>>> >>>> Rather, I think what's to blame is poor documentation, JavaFX >>>> requiring absurd runtime module VM arguments, and poor/buggy IDE >>>> support. >>>> >>>> >>>> Starting with documentation, JavaFX uses reflection for things like >>>> TableView(everyone's favorite) and CSS style sheets. While this may >>>> be obvious for people who are more experienced, those who are not >>>> may be very confused when they get an onslaught of error messages >>>> regarding reflection. Better documentation on what requires >>>> reflection, why, and how to enable it would be useful. >>>> >>>> >>>> Likewise, the notice about having to include javafx.graphics to the >>>> runtime module arguments here: >>>> >>>> >>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>>> >>>> >>>> Apply to Maven as well, but it's under Ant for some reason. I don't >>>> know what was changed in JavaFX 14 that now suddenly requires a >>>> runtime VM argument, but it's a PITA and BS. End users are going to >>>> struggle with this, and it prevents JavaFX runtime from being >>>> purely managed by Maven. No other JavaFX version requires this, so >>>> it's mind boggling that all of a sudden JavaFX needs this. >>>> >>>> >>>> Poor/buggy IDE support is really the big one here. I don't know >>>> about other IDEs but Netbeans DOES NOT provide a project template >>>> for creating a JavaFX application with setup dependencies. >>>> Netbeans, when setup with a Maven project, allows you to select an >>>> entire project(pom) rather than the individual dependencies(jar) >>>> which doesn't work. What you search for also matters: if you search >>>> for "JavaFX" you will get the wrong search results. You need to >>>> search for "openjfx" which can be confusing. >>>> >>>> >>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>>> projects and Netbeans because JavaFX puts its src.zip in a folder >>>> that is supposed to only include the runtime library that has >>>> existed for years(literally a 1 line fix too). No one really uses >>>> Ant anymore so it's probably not a big deal now but yeah, getting >>>> JavaFX working hasn't been "include and done" when it could >>>> potentially be that way. >>>> >>> > > From bruno.borges at gmail.com Tue Apr 21 01:04:10 2020 From: bruno.borges at gmail.com (Bruno Borges) Date: Mon, 20 Apr 2020 18:04:10 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> Message-ID: One thing I do miss in openjfx.io website in terms of documentation is the definition of a jmods file and the sdk. For new developers looking at the download page, it's really not simple to figure it out. On Mon, Apr 20, 2020, 15:55 Kevin Rushforth wrote: > As of JDK 9, there are a few places in JavaFX that assume the JavaFX > modules are, in fact modules. While it would likely be technically > possible to find them all, and make modifications that will allow > running JavaFX either on the classpath or on the module path, I am not > in favor of that. I think it would be a step backwards. For one thing, > we would lose the encapsulation that the module system provides, and > applications would be able to access internal packages without so much > as a warning that it's not public API. Also it would increase the > testing burden, since that would be one more mode in which it would need > to be tested to ensure that it doesn't break. > > I tend to agree with those who say that this is mostly a documentation > issue. I suppose it's also a bit of a tooling problem, since first class > support for modules is still in progress in various IDEs and build tools > (gradle, maven, etc). The support in the IDEs is pretty good now, and > gradle 6.4 reportedly has full support for modules. Someone with more > familiarity with Maven can comment about their module support. > > -- Kevin > > > On 4/20/2020 10:31 AM, Michael Paus wrote: > > Oh I see. You are obviously not familiar with the fact that the JDK > > has a built-in test > > which checks whether the JavaFX graphics module is on the module path > > when you > > try to launch an application main class which is derived from the > > JavaFX Application class. > > If you try this and the graphics module is not on the module path the > > launch will fail > > with an error message. That's the only reason why JavaFX programs > > cannot be launched > > completely on the classpath and that's where all the trouble starts. > > If you circumvent this > > test with the trick, I have mentioned before, everything becomes nice > > and easy. > > > > So for me there are only two questions. > > 1. Is there any proof of a technical reason why JavaFX could not run > > correctly on the classpath? > > 2. If there is no such reason, then why do we torture all the newbies > > with the "intricacies" of the > > module system instead of just removing this barrier? > > > > As I said before, I have not found any such problem in all the time > > since JavaFX was separated > > from the JDK, so this test seems to be quite artificial to me but of > > course I may be wrong. That's > > why I asked here. > > > > Am 20.04.20 um 17:25 schrieb Ty Young: > >> > >> I'm a bit confused here. if you don't want JPMS then you should be > >> able to run everything on the classpath like normal. Netbeans at > >> least doesn't force modules wtih Maven. Or is reflection disabled on > >> classpath as of Java 9 too unless you have a module-info? > >> > >> > >>> > >>> Michael > >>> > >>> Am 18.04.20 um 12:58 schrieb Ty Young: > >>>> > >>>> On 4/18/20 5:01 AM, Michael Paus wrote: > >>>>> Getting started with JavaFX is made overly complicated by the fact > >>>>> that the use of the > >>>>> module system is enforced by some code in the JDK. Especially for > >>>>> beginners, who just > >>>>> want to get some small program running, this is almost always a > >>>>> big source of frustration. > >>>>> It is not very good marketing for JavaFX to make these initial > >>>>> steps such a pain. If you > >>>>> need some evidence for this statement, then just follow JavaFX on > >>>>> Stackoverflow or similar > >>>>> sites (and also this mailing list). Almost every day you can read > >>>>> frustrated posts from > >>>>> helpless people who would just like to get some JavaFX project > >>>>> running but are failing > >>>>> because they get lost in the module system jungle. > >>>> > >>>> > >>>> Speaking as a long time JavaFX user(literally since Java 8), I have > >>>> mostly disagree that the JPMS is hurting JavaFX. > >>>> > >>>> > >>>> That said, I don't think the frustration is misplaced. What you say > >>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end > >>>> user is *NOT* to be blamed here. > >>>> > >>>> > >>>> Rather, I think what's to blame is poor documentation, JavaFX > >>>> requiring absurd runtime module VM arguments, and poor/buggy IDE > >>>> support. > >>>> > >>>> > >>>> Starting with documentation, JavaFX uses reflection for things like > >>>> TableView(everyone's favorite) and CSS style sheets. While this may > >>>> be obvious for people who are more experienced, those who are not > >>>> may be very confused when they get an onslaught of error messages > >>>> regarding reflection. Better documentation on what requires > >>>> reflection, why, and how to enable it would be useful. > >>>> > >>>> > >>>> Likewise, the notice about having to include javafx.graphics to the > >>>> runtime module arguments here: > >>>> > >>>> > >>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans > >>>> > >>>> > >>>> Apply to Maven as well, but it's under Ant for some reason. I don't > >>>> know what was changed in JavaFX 14 that now suddenly requires a > >>>> runtime VM argument, but it's a PITA and BS. End users are going to > >>>> struggle with this, and it prevents JavaFX runtime from being > >>>> purely managed by Maven. No other JavaFX version requires this, so > >>>> it's mind boggling that all of a sudden JavaFX needs this. > >>>> > >>>> > >>>> Poor/buggy IDE support is really the big one here. I don't know > >>>> about other IDEs but Netbeans DOES NOT provide a project template > >>>> for creating a JavaFX application with setup dependencies. > >>>> Netbeans, when setup with a Maven project, allows you to select an > >>>> entire project(pom) rather than the individual dependencies(jar) > >>>> which doesn't work. What you search for also matters: if you search > >>>> for "JavaFX" you will get the wrong search results. You need to > >>>> search for "openjfx" which can be confusing. > >>>> > >>>> > >>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based > >>>> projects and Netbeans because JavaFX puts its src.zip in a folder > >>>> that is supposed to only include the runtime library that has > >>>> existed for years(literally a 1 line fix too). No one really uses > >>>> Ant anymore so it's probably not a big deal now but yeah, getting > >>>> JavaFX working hasn't been "include and done" when it could > >>>> potentially be that way. > >>>> > >>> > > > > > > From github.com+4208131+bhaweshkc at openjdk.java.net Tue Apr 21 09:05:27 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 21 Apr 2020 09:05:27 GMT Subject: [Rev 01] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: > As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to > fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare > against 600 font weight. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: added unit test for 8191758 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/180/files - new: https://git.openjdk.java.net/jfx/pull/180/files/d3d3e716..43c7cbf1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/180/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/180/webrev.00-01 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/180.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/180/head:pull/180 PR: https://git.openjdk.java.net/jfx/pull/180 From fastegal at swingempire.de Tue Apr 21 11:06:47 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 21 Apr 2020 13:06:47 +0200 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> Message-ID: <20200421130647.Horde.9OZ6De4A76UMi5Og6Hg7Lg1@webmail.df.eu> part of the confusion might be the reporter's workaround in https://bugs.openjdk.java.net/browse/JDK-8193286 which effectively clamps (doesn't make a difference, having amountPerStep=1 and not incrementing programatically) commented that bug with an alternative implemenation and a couple of tests (for the most simple case ;) -- Jeanette Zitat von Kevin Rushforth : > I just took another look at the SpinnerValueFactory API docs. The > use of the term "circular" heavily implies modulo arithmetic as the > expected behavior if wrapAround is true. That the usual meaning of > "wrap" versus "clamp" when you have a range bounded on both ends. > Maybe the confusion comes from the fact that it isn't stated as > clearly as it might be, coupled with a single example of a step by > one going from max to min (if incrementing). I note that example > doesn't say what the amountToStepBy is, but it wasn't trying to be > prescriptive. > > Since the current behavior of "wrap around unless you happen to wrap > a bit too much and then we'll clamp" doesn't make sense in any > universe that I can think of, it is fine to treat this as a bug. I'm > not worried about "bug compatibility" here. > > Clarifying the spec at the same time seems like a good idea to me. A > related issue is that the default value of wrapAround is not > specified (the default is `false`, but you wouldn't know that from > reading the docs). This should also be addressed at the same time. > > You mentioned that this is specific to IntegerValueFactory, but it > looks like DoubleValueFactory (and maybe ListValueFactory) have the > same bug. Or am I missing something? > > On an unrelated note, I just noticed that the SpinnerValueFactory > constructor has no documentation. This is because it is an > implicitly added constructor, which is an anti-pattern for public > API. I'll file a separate issue for that. > > -- Kevin > > > On 4/15/2020 2:23 AM, Jeanette Winzenburg wrote: >> Hi Ajit, >> >> yes, I read the doc, probably a bit differently - could well be my >> misunderstanding and misunderstandable wording :) >> >> Trying again: >> >> - I read your suggestion (in >> https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. >> that being at value and incrementing a full-cycle (that is max -min >> +1), I will land on value again >> - for me the doc seemed to imply that in such a case I would land >> on min. Though, given the "circular" as you pointed out correctly, >> was my misunderstanding >> - the current implementation is buggy >> (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating >> the remainder (which is what the first bullet amounts to) >> incorrectly for min != 0 >> >> Where do I err? >> >> -- Jeanette >> >> >> Zitat von Ajit Ghaisas : >> >>> Hi Jeanette, >>> >>> The doc never assumes amountPerStep = 1. I am quoting it here - >>> ?The wrapAround property is used to specify whether the value >>> factory should be circular. For example, should an integer-based >>> value model increment from the maximum value back to the minimum >>> value (and vice versa).? >>> >>> The word ?circular? clarifies that once we exceed maximum value, >>> we should start from minimum. >>> I think, the doc is OK in it?s current form, but implementation >>> needs to be corrected. >>> >>> Regards, >>> Ajit >>> >>> >>>> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg >>>> wrote: >>>> >>>> >>>> Hi Ajit, >>>> >>>> thought the doc was simply bad (in specifying the behavior for >>>> amountPerStep = 1 and not thinking of larger amounts) - my >>>> expection is a calculated wrap, that is the target as you suggest >>>> via modulo the difference from current value. Don't know if >>>> anybody took the doc literally .. >>>> >>>> -- Jeanette >>>> >>>> Zitat von Ajit Ghaisas : >>>> >>>>> Hi, >>>>> >>>>> ? Once I fix JDK-8193286, I would like to take up JDK-8242553 >>>>> (IntegerSpinner does not wrap around values correctly if >>>>> amountToStepBy is larger than total numbers between Max and Min) >>>>> >>>>> ? The current implementation is not as per what is documented. >>>>> ? Refer : >>>>> https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>>>> >>>>> ? I propose to fix the current buggy behavior of IntegerSpinner. >>>>> ? Although it is a corner case, I would like to know if anybody >>>>> relies on this buggy behavior? >>>>> >>>>> Regards, >>>>> Ajit >>>> >>>> >>>> >> >> >> From mike at plan99.net Tue Apr 21 11:30:21 2020 From: mike at plan99.net (Mike Hearn) Date: Tue, 21 Apr 2020 04:30:21 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> Message-ID: Maybe openjfx.io needs more maintainers? I opened a PR against that repo some days ago and it's not been looked at. The JavaFX docs are certainly a weak point right now, given that the Java 8 era docs aren't really being maintained, and aren't open source, and the main docsite isn't really actively worked on either. On Tue, Apr 21, 2020 at 03:04:10, Bruno Borges wrote: > One thing I do miss in openjfx.io website in terms of documentation is > the definition of a jmods file and the sdk. > > For new developers looking at the download page, it's really not simple to > figure it out. > > On Mon, Apr 20, 2020, 15:55 Kevin Rushforth > wrote: > > As of JDK 9, there are a few places in JavaFX that assume the JavaFX > modules are, in fact modules. While it would likely be technically possible > to find them all, and make modifications that will allow running JavaFX > either on the classpath or on the module path, I am not in favor of that. I > think it would be a step backwards. For one thing, we would lose the > encapsulation that the module system provides, and applications would be > able to access internal packages without so much as a warning that it's not > public API. Also it would increase the testing burden, since that would be > one more mode in which it would need to be tested to ensure that it doesn't > break. > > I tend to agree with those who say that this is mostly a documentation > issue. I suppose it's also a bit of a tooling problem, since first class > support for modules is still in progress in various IDEs and build tools > (gradle, maven, etc). The support in the IDEs is pretty good now, and > gradle 6.4 reportedly has full support for modules. Someone with more > familiarity with Maven can comment about their module support. > > -- Kevin > > On 4/20/2020 10:31 AM, Michael Paus wrote: > > Oh I see. You are obviously not familiar with the fact that the JDK has a > built-in test > which checks whether the JavaFX graphics module is on the module path when > you > try to launch an application main class which is derived from the JavaFX > Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs cannot > be launched > completely on the classpath and that's where all the trouble starts. If > you circumvent this > test with the trick, I have mentioned before, everything becomes nice and > easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies with > the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time since > JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: > > I'm a bit confused here. if you don't want JPMS then you should be able to > run everything on the classpath like normal. Netbeans at least doesn't > force modules wtih Maven. Or is reflection disabled on classpath as of Java > 9 too unless you have a module-info? > > Michael > > Am 18.04.20 um 12:58 schrieb Ty Young: > > On 4/18/20 5:01 AM, Michael Paus wrote: > > Getting started with JavaFX is made overly complicated by the fact that > the use of the > module system is enforced by some code in the JDK. Especially for > beginners, who just > want to get some small program running, this is almost always a big source > of frustration. > It is not very good marketing for JavaFX to make these initial steps such > a pain. If you > need some evidence for this statement, then just follow JavaFX on > Stackoverflow or similar > sites (and also this mailing list). Almost every day you can read > frustrated posts from > helpless people who would just like to get some JavaFX project running but > are failing > because they get lost in the module system jungle. > > Speaking as a long time JavaFX user(literally since Java 8), I have mostly > disagree that the JPMS is hurting JavaFX. > > That said, I don't think the frustration is misplaced. Wha